Haven't played with the documentation yet, but have a little app that loads a win31 exe, shows binhex, and has a start parsing/displaying the NE format. A little more work on the basics of the format and hopefully I can output the initial depends info with actual function bindings, and enough info to load the exe into memory properly.
Not sure the best way to emulate the windows layer, but perfect world, I'm thinking some client code for loader in dosbox, some function stubs for the linked files (i.e. a callable shim for gdi.dll->drawline(...)) and the shim passes the call across to the emulation inside dosbox to do the actual work.
As I recall, dosbox communicates/crosses over from emulated code to the emulator using specific ports, doesn't it? So design decisions for this would include leveraging the existing ports or coopting new ports for the windows emulation, deciding whether to use any of Wine or just write new code, and what's on the emulator side vs. being code inside "dos". I'm sure there are other problems I haven't thought of yet - like "Windows 3.1 cannot run in real mode, but Windows 3.0 can" - but so far so good in my imagination.
The goal of the emulation would be to run one game app in psudo-windows mode, with a fixed chosen video mode (640x480x16 -> 800x600x256), and either the window takes the full screen or is center top. I have a few games but not really a list of "success targets" that must run. Running something like the Baloon demo, Reversi and Solitare from MS, and maybe the more complex Stars! game - i.e. Microsoft and other developer "simple" Win31 games - would be a nice first target.
If I get this far, looks like "learn to load a NE app", "branch/local build of DosBox", "create and communicate with windows emulaton functions from emulated code", and "evaluate wine code to see if it will save time" would be the big hurdles to getting this actually running. Neither impossible nor trivial, but certainly an interesting looking project. 😀
-edit for clarity