Just finished hand-creating stub DLLs for all the 32-bit Windows system DLLs I've had referenced so far.
Prior to this, whenever a program linked against a DLL, I would intercept known system DLLs and route calls to a dynamically-generated set of stub functions that triggered my emulation of each API.
However, I have run into several cases where programs grope around for specific DLLs in Windows\System32 and even query version resources embedded within.
I figured this was a good excuse to make DREAMM's runtime a little more like the real thing, so now I produce these stub DLLs which have all the exports (at least as of Windows 2000/DX9) available. Each stub then triggers a call into the emulator with EAX pointing to a string containing the name of the function.
The first time this happens, I look the function up by name, convert it to an index in my table of APIs, and then patch the stub code to load the table index in EAX instead of a string pointer so that subsequent calls are cheap.
This also means I can implement some calls purely in emulation (for example, qsort and math helpers in the CRT), which is cleaner. And I can bundle a version resource for nosy programs to examine.
I kind of want to do this for 16-bit DLLs as well. We'll see if I can get the VC++1.5 tools to cooperate....
@aaronsgiles if vc++1.5 doesn't work there's always openwatcom (which is what i used last time i compiled an NE DLL)
@Rairii Yeah, wasn't able to get VC++1.5 to work. The compiler seems to be a 32-bit program, but it falls over with an "out of memory" message no matter what I try to feed it.
I almost have OpenWatcom working for what I need, but can't seem to coax it to create a constant value export, which I need for a few kernel symbols like __AHSHIFT and __AHINCR.
@aaronsgiles i guess you could always use a dos compiler inside msdos player or dosbox
@aaronsgiles I am most of the way through implementing a similar change!