kjliew wrote:

ElectricMonk wrote:

"HIMEM.SYS allows memory beyond 1MB to become visible as expanded memory if you have a 386 chip. From there you get high memory […]
Show full quote

"HIMEM.SYS allows memory beyond 1MB to become visible as expanded memory if you have a 386 chip. From there you get high memory (the first 64k or so of expanded memory-- but that goes a bit further).

If you had an 8088 or 286 processor, you still couldn't directly access the expanded memory. This is where EMM386.EXE steps in. If you understand swapfiles, then you can get this easily... but lets back up just a bit here.

The first meg of memory is divided into conventional and upper memory. Conventional is the first 640k of memory, where applications would go. Upper memory is the remaining portion of that first meg-- 384k. This is where device drivers would sit. This is also the limit of 8088 and 80286 processors.

Sooo, here comes HIMEM.SYS, making memory beyond this first meg visible (but not directly useful if you have the older processor). So, in steps EMM386.EXE.... when the processor needs that extra memory, EMM386 swaps out what is in upper memory (that 384k after conventional) with a chunk of expanded memory. When it's no longer needed, EMM386 swaps it back in.

Because of this, you need HIMEM.SYS before you can use EMM386.EXE. HIMEM makes it visible, EMM386 makes it usable to 8088 and 286s. If you can't see it, you can't use it, so HIMEM.SYS is first.

This process of swapping expanded memory in and out of upper memory is called paging (just like a swapfile). The term "extended memory" encapsulates using expanded memory as upper memory."

What, you called this official definition??? They are mostly wrong in details.

I was lazy, and copy-pasta'd from Wikipedia. I've removed the offending post. My apologizes.

The patch only fixes the fact the retail game didn't come with several RPV logos for some reason, it seemed to also patched some of the level data but there are still really horrible bugs in this game. It also included a new deathmatch only level. (No level editor for this game either, heh...)

The MRL will crash the DirectX version of the game, so fighting Gunships = crash.

Though when playing under MS-DOS I've rarely experienced a single crash or oddity with the engine, it seems like they just failed to properly port the engine to Win32 DirectX. Even EmulateHeap doesn't solve all the problems but it does solve it hard freezing. (instead of freezing it GPF's at AcLayers.DLL)

DracoNihil wrote:

Though when playing under MS-DOS I've rarely experienced a single crash or oddity with the engine

I completely fail to comprehend how you could have arrived at the conclusion that Gunmetal crashing VirtualBox has anything at all to do with DOS memory.

Maybe it's best to take this to another thread.

The whole point of this thread is to figure out if these memory drivers are really needed for 32-bit Protected Mode programs. I have both VBox and a real DOS machine at my family's place that I'm using to experiment and draw my own conclusions with. I just want to understand more what's going on under the hood.

No, you don't need them for 32-bit PMODE DOS programs using DOS/4G, DOS/4GW or CWSDPMI or most 32-bit DOS extender stubs. But they won't cause any harm if you keep them.

I have an old DOS program that is not a game. It is a fantastic modeling package that I would very much like to use again. The last time it was usable was on Win NT (at least on the computers I have had). Can someone offer a simple how-to set of steps to enable me to use it on my Win 8.1 machine? The package requires extended and expanded memory. Thank you.

Classicsman wrote:

I have an old DOS program that is not a game. It is a fantastic modeling package that I would very much like to use again. The last time it was usable was on Win NT (at least on the computers I have had). Can someone offer a simple how-to set of steps to enable me to use it on my Win 8.1 machine? The package requires extended and expanded memory. Thank you.

Which version of NT was it? And could you install it in VirtualBox? I'm trying that now with Netware 5.1 (long story), and that boots off it's own DR-DOS, so you should be ok. In theory, you could run MS-DOS 6.22 VM, and eliminate the need for NT at all. I used to be certified in NT4, and the DOS support was wonky at the best of times, to be honest. It was heavily emphasized in the courseware script I had to teach, that DOS support was going away, and should be avoided like the plague (NT4 SP6a)

*EDIT*

Just looked at the VirtualBox manual, and NT4.0 is fully supported (SP6a *highly* recommended). DOS/Win9x/ME have only had limited testing. So it may or may not work with DOS6.22 or DOS "7". But like said, I'm working on getting a Netware server running, and it's not supported at all. 🤣

Classicsman wrote:

I have an old DOS program that is not a game. It is a fantastic modeling package that I would very much like to use again. The last time it was usable was on Win NT (at least on the computers I have had). Can someone offer a simple how-to set of steps to enable me to use it on my Win 8.1 machine? The package requires extended and expanded memory. Thank you.

You will probably want to set up another OS in VMware, Virtual PC, or VirtualBox. If what you were running is indeed a DOS program, you could in theory use FreeDOS as a "guest" OS, but if your DOS program was running in NT you could probably just as well use XP. There are many guides out there regarding the installation of XP in a virtual machine; see for instance http://www.pcworld.com/article/2139983/compat … al-machine.html . I cannot imagine any reason why you would want to stick with Windows NT in any way for running a DOS program.

Alternatively, your DOS program will probably run just fine in the 32-bit version of Windows 8.1. Or you could use Windows 7 Pro or Windows 7 Ultimate, which include "XP mode", which is basically a pre-configured virtual machine.

DOSBox is technically an option, but running a non-game application in DOSBox is generally ill-advised.

In any case, your problem has absolutely nothing to do with HIMEM.SYS or EMM386, so if you have further questions you should probably make a new thread.