Re: No more XP lag with Tamedos

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Michael Norman  on Mon, 27 Dec
2004 15:27:06 -0500


> I discovered that for some reason I had disabled the default key
> assignment, 69=NO, [the NUMLOCK KEY] and had replaced it with 69=AS
> [Alternate Screen].

Oh! 69=AS. Well, I'm tempted to say "Brilliant!" -- but I certainly don't
want to be snotty, because I'll get another chastisement from Mr. Ed Reading.
Look, there are certain keys that are *hardware* keys, what XyWrite calls
"toggle keys", that you cannot mess around with: ScrollLock, NumLock,
CapsLock, Mouse. If you reassign them to something other than the functions
assigned to them by your machine's ring 0 BIOS, and possibly by your keyboard
hardware, and certainly by any Windows operating system, you are asking for
trouble -- especially in a multitasking environment. For example, CapsLock can
*easily* get out of sync with other programs -- OFF in XyWrite, ON everywhere
else, or v.v. -- and you're incessantly hitting the CapsLock key to reach a
temporary accommodation. (I can anticipate that people will say, "hey I've
been using Numlock as a DEFINITIONS TABLE key since King Kong climbed K-2" --
but it is NOT a smart thing to do, IMO.)

Tame is using (this is a guess, but damn near guaranteed) the Windows API
called "keybd_event", which takes three or four arguments: a virtual key, a
keyboard code (69, in this case), a flag or two (Shift up, Shift down, Alt up,
Alt down, etc). In short, it is the next best thing to the keyboard
controller, and what it does is poke into the keyboard buffer the same exact
info that manual keypresses would put in the buffer: a keycode (which key did
you hit, by number [69]), the state of Shift/Alt/Ctrl/Caps etc up or down,
whether Shift/Alt/Ctrl/Caps are still depressed or were released (went back up)
after you hit the primary key number (69), etc etc. Now, XyWrite had LOADed
your KBD file, and therefore what it sees incoming is func AS. It's all pretty
straightforward and logical.

Re: "X" on the PRompt line. Yeah, it just means swapfile -- XyWrite calls it
the "Overflow" file. Can be hard disk, can be RAM disk -- doesn't really
matter nowadays (long ago, when drives were slow and memory was fast, RAM disks
made some sense; today... truth is, your machine can put the memory to better
use by keeping it part of the available memory pool, than by stealing it for a
RAM disk). That's why I asked you about DeFault DR: it assigns the d:\path
location for overflow files. To be honest, I've never paid the slightest
attention whether it was on or off. For me, it's mostly on. Who cares.

What does matter is this: the selected overflow file Dir should have a good
amount of free disk space, say 15-20Mb, and the drive should be defragged, so
that overflow files are written there in one piece. Moreover, it should be a
stable directory that *NEVER* has a file in it with a *.TMP extension (I use
the Speedo font dir, d:\XY4\BTFONTS) -- because the overflow files can
sometimes be left hanging around on disk, and they can accumulate, and they can
be fairly large (2-3Mb apiece sometimes), and they all have TMP extensions. So
what I do is have a line in STARTUP.INT that points at my DR spec, and does the
following -- these are the *first two* instructions issued by INT, after the
drive-blind code that I described the other day, which essentially makes my
installation transportable between machines, and which stored "d:\XY4\" in
:

BX d dr=BTFONTS\Q2 ;*;
BX dos/nv/x/z /c del BTFONTS\*.TMPQ2 ;*;

Why are these the *first two* instructions? Because, go much further into INT
and XyWrite may already have created a TMP file on BTFONTS\ (i.e. the "X"
may be lit up), and then that file will be undeleteable, and you'll get an
error. My purpose here is to erase *yesterday's* Overflow files -- wipe the
temporary file slate clean.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------