Forum Home
Press F1
Thread ID: 25679	2002-10-09 19:19:00	Upper Memory!!!	Derek (1260)	Press F1

Post ID	Timestamp	Content	User
87537	2002-10-09 19:19:00	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	Derek (1260)
87538	2002-10-09 19:36:00	Derek, This link may help you with VMM32.vxd (www.webopedia.com) Cheers, Babe.	Babe Ruth (416)
87539	2002-10-09 21:49:00	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.	Terry Porritt (14)
87540	2002-10-10 03:16:00	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	Derek (1260)
87541	2002-10-10 04:07:00	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 (14)
87542	2002-10-10 04:18:00	This MS Knowledge Base page gives a good description of the startup procedure: click here (support.microsoft.com)	Terry Porritt (14)
87543	2002-10-10 04:20:00	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 ?:|	Graham L (2)
87544	2002-10-10 06:45:00	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.	Terry Porritt (14)
87545	2002-10-10 07:17:00	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	Derek (1260)
87546	2002-10-10 08:27:00	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.	Terry Porritt (14)
1 2