• Please review our updated Terms and Rules here

Windows 9x drivers and memory management

maferv

Experienced Member
Joined
Jan 5, 2017
Messages
67
Location
Argentina
Hello everybody,

I'm trying to figure out how Windows 9x loads its components and drivers into memory.

Experimenting with UMBPCI, I noticed that Windows always takes all the upper memory and it's usually VMM32 that consumes it all.

But if I don't load UMBPCI, VMM32 only takes a few bytes of conventional memory.

Can anybody please explain me what's going on? Is the rest of VMM32 being loaded into extended memory directly?

I'm trying to understand because I thought that those free UMBs could be used by other software/games too, but I suppose they should be used BEFORE Windows boots, is that correct? Is there a way to prevent Windows from taking all the upper memory?

If I restart in DOS mode, I see the free upper memory.

Also, are all the virtual device drivers loaded from the vmm32.vxd and its folder and the iosubsys folder? Are there other important folders? Which VXD files are being loaded in that VMM32 program that's taking the upper memory?

I also would like to know if there are any downsides to loading EMM386 on each boot, since it puts the processor in protected mode and I remember reading somewhere that that could bring problems.
 
Last edited:
I don't know what exactly is going on, or what you are looking at to determine how much "memory" VMM32 us using.

But UMBPCI is a real-mode DOS based hardware UMB driver. With that loaded, Windows may see that memory area as "used" by something. But it probably won't know what unless UMBPCI is telling it.

I haven't tried UMBPCI myself, so I don't know how it works when Windows is loaded. But since it uses hardware to map memory, then logically Windows would not have control over it.

Normally the way you use UMB is is to start DOS, load your DOS device drivers using the UMB memory block to save the 640k conventional memory, and then start Windows. Applications/Games do NOT make use of UMB. They use the extra space in the 640k conventional memory that you have saved. You also would not load device drivers in to UMB AFTER Windows starts.

As for EMM386, don't bother unless something specifically requires it. EMM386 is redundant to the Windows VMM, and basically switches operation to the Windows VMM when it starts.
 
I have no idea, but there could be documents on old Microsoft TechNet or MSDN CDs - including the Resource Kit, the DDK, or documents that describe migrating to 9x - which explain in detail what is going on.
 
Once Windows is loaded it takes up all the UMBs you left empty.

You could load some TSRs or drivers before (DOSKEY, for example). But once Windows is loaded you can forget about the rest of the UMBs you didn't use. They're filled with VMM32. And that's not convenient if you want to use them later, i.e. inside a DOS box, especially considering that Windows doesn't really need those UMBs, because normally, it can load VMM32 to extended memory (XMS).

So that's the question I was posing. Maybe now it's clear.

Why don't leave those empty UMBs alone so that I can use them freely to load whatever TSRs I want inside a DOS box... Why does Windows disrespectfully takes them over and fills them with its filth...?
 
Experimenting with UMBPCI, I noticed that Windows always takes all the upper memory and it's usually VMM32 that consumes it all.
Windows does not load itself into UMBs, but it will take ownership of all address space below 1 MB. This is necessary to allow BIOS and DOS drivers (e.g. APM or CD-ROM drivers) to continue to function even while Windows is running. Since Windows itself does not know about any unknown DOS drivers (otherwise, it would replace the 16-bit driver code with its own 32-bit driver while running for performance reasons), it plays safe and prevents applications from using UMBs at all. After all, memory there may behave strange. However, it does know about EMM386 (and maybe similar XMS-to-UMB providers, I don't know).

In theory, Windows could expose the UMBs it found to its DOS boxes, but I don't think it does. There is little use for UMBs in DOS boxes, since TSRs to use them can be loaded into them before starting Windows.

I also would like to know if there are any downsides to loading EMM386 on each boot, since it puts the processor in protected mode and I remember reading somewhere that that could bring problems.
A running EMM386 prevents applications from using Protected Mode directly. This prevents some games and other applications from running, and reduces the system performance slightly. Applications accessing Protected Mode through VCPI or DPMS are not affected.
 
Back
Top