Really, at this point you need to be talking to your software vendor, and asking for them to pick up their game.

Workarounds are no good for mission-critical software. They can't be relied upon.

Windows Vista/7/8 32bit support NTVDM.

If you want to run the programs full-screen though you'll need to install XP drivers. (Only valid for Vista/7)

Also NTVDM support has gone downhill since the XP days so it may not be as compatible.

Apparently EMS support was removed in Vista - at least, that's why http://www.emsmagic.com/ says you might need their product.

Our application is VERY tight on memory and the problem is getting at least one page frame in upper memory so ems magic may not be the solution. Also screen updates in NTVDM (in vista+) are terrible, the lag! oh the lag.

As to the previous comment about our vendor. The conversion route is the one our vendor advocates but its not a simple process. We have to recompile all our software and then modify some of it to fit in with the new environment. Also there is a lot of finding solutions to all the DOS workarounds that we'd put in place. All in its a big job and so a workaround like DOSBOX would save the company quite a large amount of cash even if we have to get one of our C++ coders to mod the source so that it will do what I want. I just need to know if its possible and a bit of a steer in the right direction if it is.

Odin2001 wrote:

I just need to know if its possible

Really now, anything is possible. 🤣

I don't really know what you mean by "interface to windows DLLs". If your DOS application won't work in plain MS-DOS with no Windows present, then it really isn't a DOS application, is it?

For me it seems that in reality you have a windows console application that uses EMS functions of ntvdm.
So maybe it is just easier to replace the EMS function with some own handler that manages allocated memory in 64 kB chunks similar to EMS page frames. You can even keep the pointer constant if you imitate the mapping into the frame with copying from a pool of allocated EMS pages.

Just as a side note, this concept is really retro, real EMS expansion cards are outdated for a long time. Already the NEAT chipset for 80286 included a EMS emulation and in 1987 with the 386 EMS was emulated in software (via EMM386 etc.).
You might try to load AboveDisk though.

Odin2001 wrote:

As to the previous comment about our vendor. The conversion route is the one our vendor advocates but its not a simple process. We have to recompile all our software and then modify some of it to fit in with the new environment. Also there is a lot of finding solutions to all the DOS workarounds that we'd put in place. All in its a big job and so a workaround like DOSBOX would save the company quite a large amount of cash even if we have to get one of our C++ coders to mod the source so that it will do what I want. I just need to know if its possible and a bit of a steer in the right direction if it is.

Believe me, I appreciate that position. But as someone who is heavily involved in Information Systems, clinging to old versions of software is a very bad path in the long run. Without wanting to sound like a creepy old doomsayer: You're only delaying the inevitable.

It might seem like Dosbox will save you money today, but consider the cost impact of data loss. Dosbox is for playing games, it's not designed to do anything else. It's unlikely, but it might have some unforseen effect on your software, which could result in incorrect results or loss of work. We don't know, and the authors can't and won't make guarantees.

Not having guarantees on mission-critical software for business is suicide.

Sorry if this comes off as preachy, but I've seen what happens to businesses that depend on workarounds and kludges to survive. I'd hate for that to happen, and I didn't say anything! 😀

the EMS page frame location can be moved in SVN versions of DOSBox, so the upper memory problem goes away in that respect. It requires a small amount of code on your side, but it comes down to essentially one function call.