I *think* you need emm368 for Dos4/GW games, but other games might need it, too or they don't (Ultima 7 for example needs himem but not emm386)

Most DOS Extenders run fine with whatever you have loaded or not loaded.

IIRC technically dos4gw (and similar) doesn't need himem.sys or emm386.exe since it can access the memory directly. Of course if you don't load himem.sys and emm386.exe then what are you going to do with your other TSR/drivers unless you boot with a clean config.

Also even though they may not technically be required it depends on how the software was programed since sometimes the program will check for himem.sys or emm386 and fail to load if they aren't present.

Finally DOS(not 9x) himem.sys has a 64mb limitation and emm386 (which requires himem.sys) has a 32mb one (unless you add some switch).

No DOS game needs more than 64mb anyway so not really an issue. (Not counting any DOS ports that are still being developed 😉 )

I usually tried to make a one size fits all config with memory to load tsr/drivers in HMA, extended, and expanded memory, etc.
If I ran into a situation where there was a compatibility issue then I had a bare config with only the essentials.

*EDIT*

Removed for being wrong.

http://www.ada95.com/jvandyk/faq013.html

The later versions of cwsdpmi allow djgpp compiled binaries to access up to 256mb of ram in dos, but the memory managers, such as himem and emm386, should not be installed (although there are some workarounds if they are installed). I confirmed this in a patched dosbox so the mem parameter can be set higher. The 9x dos box has a built-in dpmi server, but there is a workaround to access some memory over 64mb.

Well the only things I need EMS for are for trackers, so starting EMS386 with NOEMS frees up more conventional memory (somehow) while having the upper memory to load my basic drivers high.

That's interesting what truth5678 said... Only thing I know that uses djgpp is the... DOS Port of Hexen 2 which I've yet to try...

The NOEMS option avoids the need for the memory "window" that is used for transferring data to and from EMS. This window is placed in conventional memory, when it is present. So no window = more conventional memory.

DracoNihil wrote:

Do I really need these things to run software\games that come with DOS extenders like DOS4/G, DOS4/GW, DOS32a, CWSDPMI and etc? Can these programs really access all installed RAM without having either of these TSR's loaded?

I know I need EMM386 for older software, particularly trackers like FastTracker 2 and ImpulseTracker but I'm not sure how games and such work in terms of memory access.

IIRC, I remember quite a few games that autoloaded DOS4/GW, and I think I was just using HIMEM.SYS at the time . I don;t have any custom boot floppies to go back and look at.

Now, you wanna talk pain in the but, try to get Ultima 7's VOODOO memory manager to work. *THAT* required jumping thru hoops!

ElectricMonk wrote:

Now, you wanna talk pain in the but, try to get Ultima 7's VOODOO memory manager to work. *THAT* required jumping thru hoops!

I really hope you're not going to start randomly bringing that up in every thread about memory. 😒

UMBPCI is a well-esablished means of circumventing the requirements of Ultima 7's memory manager for those who don't want to use U7Run. Or DOSBox. Or Exult.

Jorpho wrote:

ElectricMonk wrote:

Now, you wanna talk pain in the but, try to get Ultima 7's VOODOO memory manager to work. *THAT* required jumping thru hoops!

I really hope you're not going to start randomly bringing that up in every thread about memory. 😒

UMBPCI is a well-esablished means of circumventing the requirements of Ultima 7's memory manager for those who don't want to use U7Run. Or DOSBox. Or Exult.

Fine, I'll quit bring it up. Happy, now?

And I was talking about making DOS boot disks to get it to work back in the day. U7run and Exult are all cheats, imho.

It wasn't as bad as you described. Back then I had established a series of batch files to automate copying the right autoexec/config.sys set for a couple of games, so making a lean boot for u7 wasn't that hard.
And then with umbpci setting up a good all thrills set for u7 was a piece of cake...

And I take offense to labeling Exult a cheat! It's a modern engine for the Ultima 7 games and not just a way to run the original ;(

Dominus wrote:

And I take offense to labeling Exult a cheat! It's a modern engine for the Ultima 7 games and not just a way to run the original ;(

You'll get over it. 😉

Actually no. I'll hold a grudge and will question validity of your posts...

Dominus wrote:

Actually no. I'll hold a grudge and will question validity of your posts...

Holding grudges will get your bodily humours out of balance. Maybe a trip to your barber/surgeon for a leeching will help. 😜

Question the validity of my posts all you want. I was married once, so I'm more than used to it. 😀

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.

'Twas apparently copypasta'd from http://www.techexams.net/forums/a/940-what-di … -himem-sys.html , which doesn't seem particularly official at all.

So is there a reliable source on DOS memory I can read up on so I can try to make Gunmetal not crash VirtualBox? (Or rather not crash at all even on a real system, this engine is ridiculously unstable)

I'm not sure exactly what you would expect to learn. If the engine was written that badly, nothing short of disassembly and patching (or getting appropriate period-correct hardware) will be much help, I reckon. (Did you get the patch? Wikipedia says there was a patch.)