Sign in with
Sign up | Sign in
Your question

Force mouse driver to load into low memory

Last response: in Windows XP
Share
January 7, 2013 10:19:54 AM

Hello,
"mem /c" shows that the mouse driver has loaded into upper memory --

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 196592 (192.0K) 2FFF0
MOUSE 12528 ( 12.2K) 30F0
FREE 52960 ( 51.7K) CEE0

In order to free up some upper memory I want to force the mouse driver into low (conventional) memory.

My config.nt & autoexec.nt don't have any commands related to the mouse so the mouse driver must be loaded elsewhere.

Thanks.
a b \ Driver
a b } Memory
January 7, 2013 5:13:50 PM

The concept of upper and lower memory stopped being relevant with XP. This was always one of the issues that came up on DOS derived versions of Windows (1.x-ME) because of a decision Microsoft made on how to handle the situation of PCs coming with more than 1MB of RAM.

The NT branch of Windows always treated all RAM as one giant pool, not the first 1MB being low/conventional, and then everything else being upper memory. XP is based on the NT branch of Windows.
m
0
l
January 8, 2013 10:53:48 AM

Scott --

I'm trying to run an old DOS program that needs about 590K free conventional memory. "mem /c" (below) shows that I have about 582K conventional memory for which the largest executable program size is 579K. What I want to do is move the mouse driver to low memory in order to free additional upper memory and then try loading dosx high. The net result should be more free conventional memory. (Right now my autoexec.nt has "lh %SystemRoot%\system32\dosx" but for some reason only a portion of dosx loads high. Hence I think that dosx may need more free upper memory in order to load high. What is odd, however, is that dosx only uses 35K whereas the largest available upper memory block is already 50K.)

Since mem shows that the mouse is loaded into upper memory, it must be loading there from somewhere. However, it's not loading from my config.nt or autoexec.nt since these don't have any mouse commands. Hence, I'm also trying to figure out what causes the mouse to load. If Windows loads the mouse after config.nt and autoexec.nt then perhaps I can pre-load the mouse in config.nt or autoexec.nt to prevent Windows from loading it later.

--------------------------------------------------------------------------
mem /c -->
Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12496 ( 12.2K) 30D0
KBD 3296 ( 3.2K) CE0
HIMEM 1248 ( 1.2K) 4E0
COMMAND 4384 ( 4.3K) 1120
MSCDEXNT 464 ( 0.5K) 1D0
REDIR 2672 ( 2.6K) A70
DOSX 34720 ( 33.9K) 87A0
FREE 112 ( 0.1K) 70
FREE 1568 ( 1.5K) 620
FREE 594160 (580.2K) 910F0

Total FREE : 595840 (581.9K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 196592 (192.0K) 2FFF0
DOSX 128 ( 0.1K) 80
MOUSE 12528 ( 12.2K) 30F0
FREE 1568 ( 1.5K) 620
FREE 51232 ( 50.0K) C820

Total FREE : 52800 ( 51.6K)

Total bytes available to programs (Conventional+Upper) : 648640 (633.4K)
Largest executable program size : 592544 (578.7K)
Largest available upper memory block : 51232 ( 50.0K)

1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area
m
0
l
Related resources
a b \ Driver
a b } Memory
January 8, 2013 5:49:21 PM

As I said, there is no such thing as upper and lower memory in XP. So what I might suggest, is get a copy of VirtualBox or any other VM you want, and load into that a copy of FreeDOS to run your program in.

DOS programs in general, are often problematic in XP. DOS programs would typically try and access hardware directly, and XP will absolutely not allow that (which is a good thing), so the program crashes.
m
0
l
January 9, 2013 6:46:31 PM

Scott --

I understand that XP memory is one contiguous block. However, when starting cmd.exe Windows somehow "fakes" (or emulates) conventional and upper memory, as witnessed by running "mem /c". What I'm trying to do is prevent the mouse driver from loading into this faked upper memory (again, per "mem /c"). Perhaps this is not possible but I'm looking for a definitive answer.
m
0
l
a b \ Driver
January 9, 2013 6:50:20 PM

Your definitive answer was presented right here:

cl-scott said:
.... So what I might suggest, is get a copy of VirtualBox or any other VM you want, and load into that a copy of FreeDOS to run your program in.

DOS programs in general, are often problematic in XP. DOS programs would typically try and access hardware directly, and XP will absolutely not allow that (which is a good thing), so the program crashes.

m
0
l
January 9, 2013 7:25:34 PM

ex_bubblehead said:
Your definitive answer was presented right here:


Using "VirtualBox or any other VM" is not a definitive answer as to whether the mouse driver can be prevented from loading into upper memory when running a cmd session. Other devices/drivers can be loaded high (or not) via config.nt and autoexec.nt. I'm simply trying to find out if the same is true for the mouse driver and, if so, how this can be accomplished.

The DOS program doesn't crash. It just needs more "conventional" memory to run on this particular computer. (It runs fine on my laptop but there are other differences.)

m
0
l
a b \ Driver
January 9, 2013 7:29:40 PM

A 'cmd' session IS NOT DOS. It may look like DOS, act like DOS, but it is absolutely not DOS. You can not treat it the same. If you want DOS then run a VM where you'll have complete control via memmaker or QEMM.
m
0
l
!