Re: DOS box creepers and (now AUTOEXEC and CONFIG)

[michael.norman@xxxxxxxx]

Robert Holmgren had written:

≪When you start XyWrite, doesn't your shortcut call AUTOEXEC.NT
when NTVDM is opened?? You don't want to bypass AUTOEXEC and CONFIG, do you?
XyWrite will be miserable without memory management and that sort of thing.≫

This was in response to a small .bat file I'd written as a shortcut to
start XyDos (with Tame) in XP. Now that the TAME thread is back, I'd like
to echo some questions (I'll include answers already posted here):


1. Is it better in XP to create a shortcut (pif) right from editor.exe or
write a .bat that switches to the \xy directory where editor resides?


1A. If it's a pif for editor.exe, then what are the best settings for the
properties tab, especially with memory management. (There was partial
discussion of this here in four posts, but no conclusion to the thread.)


2. If it is best to create a .bat, I'm assuming it is still better to start
TSR's like TAME in autoexec.nt, rather than do it through commands in the
bat file?


2A. But how about memory management. Should that now be addressed in
config.nt or in the properties window of the .bat pif?


Robert Holmgren addressed some of these points with:
≪First, get TAME working correctly, and confirm that it works -- you
should see Tame's logo in the XyWrite Toolbar (upper edge of window) when
running in a Desktop

window. Yes, AUTOEXEC and CONFIG are run unless you specifically disable them,
or edit them to change the content (obviously), or specifically indicate an
alternative CONFIG/AUTOEXEC. Look in d:\WINNT\system32\AUTOEXEC.NT to make
sure that TAME-MON.COM is there. If you've edited AUTOEXEC.NT with XyWrite, it
is possible that the line about Tame was tacked on after the EOF character, so
do "DEL26" against the file to remove EOF and make TAME-MON visible
and runnable. NTVDM = Virtual DOS Machine = a separate DOS session running
on your machine. Look at TaskManager -- every DOS session has its own VDM.≫


N.B. Also see his 11/14 post attached below.

3. But re-reading the inquiries here about memory management, I don't think
anyone yet has posted standard settings for Config.sys or Config.nt memory
management or pif memory management under properties, if there are such
standard or recommended settings.


Thanks.

Michael Norman


Date: Thu, 14 Nov 2002 14:46:43 -0800
From: Robert Holmgren 
Subject: Re: W2K - comments & questions
Sender: owner-xywrite@xxxxxxxx
To: xywrite@xxxxxxxx
Reply-to: xywrite@xxxxxxxx
X-Mailer: The Polarbar Mailer; version=1.23; build=1422
Original-recipient: rfc822;mn2@xxxxxxxx

** 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 Signature
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?

Correct.

> Is 50 the maximum setting for sl?

Dunno

> 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 http://www.chebucto.ns.ca/~af380/Tips.html 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 the
DOS keystrokes that usurp Windows reserved functions.

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