PDA

View Full Version : Upper Memory!!!



Derek
10-10-2002, 07:19 AM
I require free upper memory for a DOS (yes DOS!!) program under Windows I attain this with the following config.sys file.
DEVICE=C:\dos\HIMEM.SYS
DEVICE=C:\dos\EMM386.EXE NOEMS x=c800-dfff
dos=high,umb
files=255
buffers=25,0
lastdrive=z
fcbs=4,0
stacks 9,256
device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=044,850,C:\WINDOWS\COMMAND\country.sys


However when checking with the "MEM command I find a ?program VMM32 hogging the whole of the free memory. Has anybody got any idea on how to get some of this memory back?
Derek

Babe Ruth
10-10-2002, 07:36 AM
Derek,

This link may help you with VMM32.vxd (http://www.webopedia.com/TERM/V/VMM32_vxd.html)

Cheers, Babe.

Terry Porritt
10-10-2002, 09:49 AM
You seem to have a mixture of early dos and windows??
The lines in error should read:
device=c:\windows\himem.sys
device=c:\windows\emm386.exe noems

Unless you have specifically created a dos directory, the above drivers are in c:\windows.

Also display.sys and country.sys are probably just taking up space unless you really need them for a specific purpose.

In window9x it is very much better to have multi configuration boot autoexec.bat and config.sys files, one section for dos and one for windows, so that you have the choice of booting into dos or into windows. That way each system can be optimised without conflicts or compromises.

Derek
10-10-2002, 03:16 PM
Thanks Guys,
In fact I had tried the drivers from Dos and Windows i.e. emm386 and himem but with no imrovement. Looked at that site but it was all tooo much for my little brain
Derek

Terry Porritt
10-10-2002, 04:07 PM
Hello Derek, you have a strange problem there that I haven't come across before. However you cant use 'old dos' versions of himem and emm386, you should use the ones supplied with windows. Vmm32.vxd is a compendium of virtual device drivers that is formed to suit your system.

The link given by Babe exposes some early fallacious thinking about this file that thought that vxd files were missing. On the other hand loading the individual drivers via system.ini doesnt seem to do any harm, and has been reported to solve some problems, there is even a small program called vxd fix that does that.

You havent said what you have in your autoexec.bat (or what your OS is but assume it is Win95 or 98).

What I should do to start with is to rename config.sys to something like config.sy_ , and autoexec.bat to autoexec.ba_ , so that windows starts up without either.
If there is no config.sys, then himem.sys is loaded by the IO.sys file when windows starts.
Then issue the mem command from the dos prompt within windows, and see what memory you have. It's really really odd that vmm32 should appear in the mem report though.

Terry Porritt
10-10-2002, 04:18 PM
This MS Knowledge Base page gives a good description of the startup procedure:
click here (http://support.microsoft.com/default.aspx?scid=KB;EN-US;q174018&)

Graham L
10-10-2002, 04:20 PM
Terry: For a memory manager to be able to allocate memory, it has to "own" it all itself... so that is probably quite normal. I've never thought of using "MEM" from a DOS window ... I've just run DOSsy things in it. :D I fully agree about using DOS versions of HIMEM and EMM ... problems are likely ...

Derek: have you tried to run the programme, or have you just given up because MEM says there isn't any? Is it Win9x or Win3.xx? (I wonder because you are using an EGA monitor ?:|

Terry Porritt
10-10-2002, 06:45 PM
Just need to amplify a bit more. You dont get upper memory available in Windows to load drivers into. Windows reserves it all for itself, that is why it is best to have a multiboot configuration in config.sys and autoexec.bat.
If you boot into pure dos you can get program sizes up to about 618KB, or higher, even up to 627KB with some clever maximising devices, (at least in dos6.22 you could).

So the dos=high,umb, and devicehigh= lines arent going to do anything (I think!!!!), the drivers will all be loaded into conventional memory.

Vmm32 is only going to take up about 17KB of conventional memory anyway in Windows, and together with any other drivers you may load. you'll be lucky to get 600KB, probably nearer to 500KB, so I dont understand your statement that vmm32 is hogging all the memory.

Derek
10-10-2002, 07:17 PM
Hi Guys
Firstly I am under Win98SE with VGA.

I have a P350 running the necessary upper memory for the program I must load. (Which is a Windows program which extracts bmps of parts of the screen to other networked computers) The memory shows on this computer that only 4k is being taken by vmm32.vxd. The configuration gives surplus upper memory.

My mission in life is achieve the same thing with a P2G but this is showing that VMM32 is taking 35k of the upper memory which leaves nothing free.

The only difference between the two computers apart from the CPU is that one has 124m ram (works) and the P2G has 62 DDR which doesnt work (if ram has any significance???)

Removing the autoexec.bat file and config .sys gives me no upper memory at all.

I will try loading into pure Dos and then W98 and see wot happens.

The reason for this complicated rigmarole is that I have built a 747-400 fixed base trainer which presents 5 monitors of cockpit information running in real time. The program I MUST load in the upper memory block connects all these readouts.
Derek

Terry Porritt
10-10-2002, 08:27 PM
I wonder if it is possible for you to post the screen readout for the mem /c command, showing the memory allocations for each computer.

This can be easily done by a command like mem /c >c:\temp\mem.txt
then open the text file and copy and paste into Press F1.

This is my readout (win98se):

Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
MSDOS 74,384 (73K) 74,384 (73K) 0 (0K)
HIMEM 1,168 (1K) 1,168 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
ANSI 4,320 (4K) 4,320 (4K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
IFSHLP 2,864 (3K) 2,864 (3K) 0 (0K)
COMMAND 7,424 (7K) 7,424 (7K) 0 (0K)
WIN 2,416 (2K) 2,416 (2K) 0 (0K)
vmm32 14,304 (14K) 14,304 (14K) 0 (0K)
DOSKEY 4,688 (5K) 4,688 (5K) 0 (0K)
COMMAND 7,344 (7K) 7,344 (7K) 0 (0K)
Free 528,848 (516K) 528,848 (516K) 0 (0K)

Memory Summary:

Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 126,512 528,848
Upper 0 0 0
Reserved 0 0 0
Extended (XMS) 67,043,328 ? 400,797,696
---------------- ----------- ----------- -----------
Total memory 67,698,688 ? 401,326,544

Total under 1 MB 655,360 126,512 528,848

Largest executable program size 528,832 (516K)
Largest free upper memory block 0 (0K)
MS-DOS is resident in the high memory area.

The F1 formatting is again not clever, but it gives an idea. You can see why I was puzzled over the upper memory, there is none free at all. It has all been taken by Windows.

bmason
10-10-2002, 11:19 PM
Terry, you will notice that you also have 0kb total/used upper memory which means that emm386 isn't providing upper memory at all. For reference this is what I have in my config.sys:


DEVICEHIGH=C:\WINDOWS\HIMEM.SYS
DOS=HIGH,UMB
DEVICEHIGH=C:\WINDOWS\EMM386.EXE RAM MIN=0 AUTO
BUFFERSHIGH=99,8


The reason the size of vmm32 varies is because its using up any unallocated upper memory you have. You can check it with the output of "mem /c" and a calcuator.

Here's another badly formatted copy of "mem /c" from 98se where you can see upper memory being used by both windows and dos:


Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 75,488 (74K) 14,720 (14K) 60,768 (59K)
HIMEM 1,120 (1K) 1,120 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
WIN 3,904 (4K) 3,904 (4K) 0 (0K)
vmm32 25,472 (25K) 1,040 (1K) 24,432 (24K)
SBEINIT 4,736 (5K) 4,736 (5K) 0 (0K)
COMMAND 11,392 (11K) 11,392 (11K) 0 (0K)
IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K)
DOSKEY 4,688 (5K) 0 (0K) 4,688 (5K)
Free 610,672 (596K) 610,672 (596K) 0 (0K)

Memory Summary:

Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 44,688 610,672
Upper 92,752 92,752 0
Reserved 0 0 0
Extended (XMS) 66,950,576 ? 266,870,784
---------------- ----------- ----------- -----------
Total memory 67,698,688 ? 267,481,456
Total under 1 MB 748,112 137,440 610,672
Total Expanded (EMS) 67,108,864 (64M)
Free Expanded (EMS) 16,777,216 (16M)
Largest executable program size 610,656 (596K)
Largest free upper memory block 0 (0K)
MS-DOS is resident in the high memory area.



Back to the origional problem, it is caused by the EMM386 line in your config.sys.
The "x=" parameter is used to stop EMM386 from using a particular region of memory for EMS or UMB, and a quick check with "mem /d/p" confirms that the region you are excluding is the entire upper memory region.

Dropping the "x=c800-dfff" should fix your problem, or you can copy the line I use above if you also need EMS memory.

Don't forget to find out why it was excluded in the first place because there was probably a reason.

Terry Porritt
11-10-2002, 06:42 AM
Excellent Brett, that explains a lot. Your formatting was good too, my pasting was rotten.
A vmm32 of 35 K would also suggest Derek has a lot of real mode drivers loaded.

I will try your switches for emm386 and see what happens, I havent played with them for a long time.
Cheers

Terry Porritt
11-10-2002, 07:24 AM
Brett, your comment about vmm32 is also interesting, its reported size changes according to how memory is allocated.

Derek
11-10-2002, 09:29 AM
Hi Guys,
Thanx for your great help I have changed my config,.sys file as suggested which would appear on the face of it to have reduced the VMM32 in Upper mem but filled it with "system'

Any comments. ? Sorry about the pasting.



Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 75,488 (74K) 20,112 (20K) 55,376 (54K)
HIMEM 1,168 (1K) 1,168 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
WIN 3,712 (4K) 3,712 (4K) 0 (0K)
vmm32 14,560 (14K) 12,816 (13K) 1,744 (2K)
COMMAND 7,472 (7K) 7,472 (7K) 0 (0K)
IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K)
Free 602,496 (588K) 602,496 (588K) 0 (0K)

Memory Summary:

Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 52,864 602,496
Upper 59,984 59,984 0
Reserved 0 0 0
Extended (XMS) 67,047,856 ? 535,060,480

Derek
11-10-2002, 10:07 AM
Hi Below is the set and results from the P350 computer which works fine!!!
You will see that I have 18608 free in the upper memory and yet the config file duplicates the one on the P2000. Incidentally everything is duplicated on the four computers! i.e. "zone alarm/nortons etc
Thought this may help



DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS x=c800-dfff
dos=high,umb
files=30
buffers=25,0
lastdrive=z
fcbs=4,0
stacks 9,256
device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=044,850,C:\WINDOWS\COMMAND\country.sys
Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 31,728 (31K) 10,624 (10K) 21,104 (21K)
HIMEM 1,168 (1K) 1,168 (1K) 0 (0K)
EMM386 4,320 (4K) 4,320 (4K) 0 (0K)
DISPLAY 8,304 (8K) 8,304 (8K) 0 (0K)
DBLBUFF 2,976 (3K) 2,976 (3K) 0 (0K)
WIN 3,680 (4K) 3,680 (4K) 0 (0K)
vmm32 17,296 (17K) 9,952 (10K) 7,344 (7K)
IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K)
COMMAND 10,064 (10K) 0 (0K) 10,064 (10K)
Free 632,736 (618K) 614,128 (600K) 18,608 (18K)

Memory Summary:

Type of Memory Total Used Free
---------------- ----------- ----------- -----------
Conventional 655,360 41,232 614,128
Upper 59,984 41,376 18,608
Reserved 0 0 0
Extended (XMS) 66,983,344 ? 132,780,032
---------------- ----------- ----------- -----------
Total memory 67,698,688 ? 133,412,768

Total under 1 MB 715,344 82,608 632,736

Largest executable program size 614,112 (600K)
Largest free upper memory block 18,608 (18K)
MS-DOS is resident in the high memory area.

Terry Porritt
11-10-2002, 10:25 AM
Derek, I think one of the questions to ask is whether the DOS program requires extended or expanded memory. Bretts 'RAM' switch enables emulated expanded memory. If you have 'NOEMS' ie no expanded memory then you get only extended memory. I didnt think that expanded memory (which goes way way back to plug in memory boards on XTs) was used by dos programs these days, but I could be wrong. Also I didnt think that the AUTO switch was compatible with the RAM switch, but was used to provide expanded memory when requested by an application.
It gets quite confusing!

The size of vmm32 also seems to change with whether you have NOEMS or RAM, I dont think it matters as long as your DOS program runs ok, that is the important thing.

It's interesting to revisit the problem of memory allocation, Im getting rusty and hadnt looked at my start up files in a long time. For windows I dont load upper memory, ( I think my emm386 in windows had crept in at some time), but for booting to dos I use dos=high,umb in autoexec, and noems with the emm386 in config.

The big problem with Windows is that when you choose the 'Restart in Dos' option it doesnt load a new config.sys, only an adaption to autoexec.bat via dosstart.bat (if you have such a file).
Thats why I think separate dos OR windows boots using a multiconfiguration are preferable if you are running dos programs. Thats just my opinion.
I had cdrom drive conlicts at one time in Win95, between the windows protected mode driver and the real mode dos driver for the cdrom, that was why I originally went to separate boots.

Must re-study this memory business again :)