[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: W2K - comments & questions

** Reply to message from "Martin J. Osborne"  on
Tue, 12 Nov 2002 14:19:47 -0500

> I see that
> the manual (page 2-34 of the CRG) says that XyW "automatically" uses up to 4megs
> of expanded memory.)

Here's what I know. Under OS/2, /e#### indisputably makes a difference (the
"MEM /C" command tells you how much of the available EMS pool EDITOR has
grabbed for its use). Suppose you make, say, 5Mb of
EMS available to the DOS session. If you shell to DOS from within
Editor and run MEM /C, it reports the amount of "total EMS memory" that was set
aside for the DOS *session*, and the amount of "free EMS memory" remaining at
the moment (i.e. with Editor loaded). If you just command EDITOR.EXE to launch
Editor, the total amount and the free amount are identical. If however you
command EDITOR.EXE/e4000, it shows that the free amount is at least 4000Kb less
than the total amount available to the session.

Think about it: Editor's actions are *independent* of any OpSys (I just don't
run Win32 much, but it *must* be true there also, because Editor doesn't know
nothing about OpSys-ShmopSys). AFAIK, the rule is: if you don't tell Editor
to use an available amount of EMS, it does not grab it, and therefore (I
assume) does not/can not use it. I'm talking Xy4DOS v4.018. I think this
implies that "automatically" means you don't have to grab a shovel and scoop
the memory into Editor manually.

Let's take this a bit further. What are we using EMS for? Quite a lot,
actually. The Signature Tech Ref Guide has this to say about VAriable ZX (this
info does not appear in later books, but then, there's a fair amount of
stuff that remains operative and relevant that was omitted in later manuals):

"DF ZX - Cancel Expanded Memory -- Turns Signature's use of expanded memory on
and off. (The initial default is 0.)

"df zx=0 Signature automatically uses expanded memory that conforms to LIM
specification 3.2 or later for the following information: main and
supplemental spelling dictionaries; temporary personal dictionary; SIG.MNU
index; and SIG.HLP index.

"df zx=1 Signature does not automatically use expanded memory.

"Note: The ZX default setting was introduced in Signature Version 1.01."

End quote. Now, at the time this manual was printed, there were no DLG or
U1-U4 files. But, like HLP and MNU, those files also generate fairly
large indices, so it stands to reason that they are loaded into EMS too, and
may help to explain why U2 (for example, with a 10Kb index) can be so large
without any apparent adverse effect.

Now, there is one problem in Windows, if I recall correctly. Many of the more
modern machines use the high memory area in such a way that there is no 64Kb
area that can be set aside for EMS. In which case, it isn't available. If I
used Windows more, I'd find out what the fix is, if any... but frankly, I don't
really care enough to dope it out.

>> %windir%\system32\cmd.exe /c editor.exe/e4000 ,d:\path\startup2.int

> 2. I can't get that to work---XyWrite starts, but it doesn't run
> startup2.int.

Hmmm. It worked here a few days ago... Wait, I forgot, that will only work if
you're in the directory of STARTUP2. Sorry about that. Use this instead (it
will work):

%windir%\system32\cmd.exe /c d:\path\editor.exe ,d:\path\startup2.int /e4000

>> Layout --- screen buffer size & window size = 80 width x 50 height

> 3. That needs to be coupled with a
> df sl=50
> setting in the settings.dfl (or whatever) file, right?


> Is 50 the maximum setting for sl?


> is it possible
> to create and use one's own fonts for programs running in cmd.exe windows?

Sure. There are packages that allow you to make DOSbox fonts. Check out
FONTMAN is another package.

> 5. Even though it doesn't currently solve the keyboard-response problem,
> Tame is essential, it seems, when running DOS programs---otherwise Windows
> programs come to a near-standstill.

CPU hogging. DOS programs own the machine -- right? Most people don't realize,
but under pure DOS, the CPU is *always* 100%. I know exactly what you're
talking about, but, funny thing, I don't have this problem, and I don't run
Tame. Frankly, I've forgotten what I did, lowered the priority of the session
or the timeslices or *something* like that, I just don't remember, some sort of
tweak (maybe to the registry), long long ago. But when XyWrite doesn't have
focus, it uses less than 1% of the CPU; when it does have focus, CPU usage
jumps around wildly (who cares). Bottom line: the program with focus always
gets the juice it needs. If you're not using Tame, raise Idle sensitivity back
up to a high level. Make sure your pagefile has the size it needs: set
recommended size=starting size=maximum size (all the same, and usually big,
like 1.5x RAMsize, e.g. if 256Mb RAM, pagefile.sys can be 375Mb or thereabouts,
then defrag the disk, delete PAGEFILE.SYS via a W98 diskette, reboot W2K so
PAGEFILE is reconstituted in one piece). There are several small programs that
manage DOS idle detection, not just Tame. DOSIDLE is one. Poke around.

> When running a DOS program in cmd.exe..., it seems not possible to block
> alt-space and other useful keystrokes from Windows. (By contrast, it is
> possible when running under command.com.) Am I right?

You are right, AFAIK. You gotta dump the nifty icons from the SysTray, or dump
DOS keystrokes that usurp Windows reserved functions.

Robert Holmgren