Wine doesn't have any APIs to wrap to at that point, so crazy talk? yes. The closest thing to it is that HX DOS extender.

Well there is danoon's experiment, but he has not done anything on it for a while

Java Port

Those are very interesting projects. I haven't run into HX DOS before, I'll check it out, thanks.

When you say "no APIs to wrap to", I'm not clear what you mean, could you expand on that? What I understand of Wine is basically a translation layer of libraries to load and provide Windows API support to a Windows PE executable, and filter/translate those calls to the host OS: be it linux or whatever. Is that close enough to true, or do I have the wrong picture of it? If there is just no "translation to dos/dosbox host" written yet, makes sense. If it means something else, I'd love to know more so I can grok why it's crazy talk for myself.
😀

Quadko wrote:

When you say "no APIs to wrap to", I'm not clear what you mean, could you expand on that? What I understand of Wine is basically a translation layer of libraries to load and provide Windows API support to a Windows PE executable, and filter/translate those calls to the host OS: be it linux or whatever. Is that close enough to true, or do I have the wrong picture of it?

I guess? This is not a Wine forum.

Apparently a recent Linux kernel update broke whatever trick Wine was using to achieve compatibility with 16-bit programs, so it seems to me that the Wine developers might move in a direction that relies more on emulation via DOSBox, but this is just speculation.

😀 Yes, I should pester them for details if I really want to follow up, but was curious what leileilol had in mind.

I like your speculation, we'll see. If'n I had the big bucks, that's another place I'd like to spend some for "the good of the community." And a further tangent, IIRC, I remember the Wine community talking about replacing dlls in '98 or XP with the wine versions for debugging purposes. That blew my mind but was cool, and that was years ago. Ah well, I really was thinking dosbox outward, and seeing what more could be done that I haven't heard of yet. I was glad to find SHDON's RunExit tool so one doesn't have to exit win31 after exiting a game.

I think it would be pretty cool to be able to run WINE under DosBox, as it would theoretically allow Win9x games to run, with the same wide range of settings and tweaks DosBox allows for DOS-based games. It would be great for games that are speed-sensitive, games that have color palette and resolution problems, and possibly even games that have 16-bit components. It would greatly expand the range of games DosBox can play, and you wouldn't have to deal with all of the glitches and overhead that come with emulating a full install of Win95 or Win98.

Wine is heavily dependent on the X Window System, if I'm not mistaken, which is why getting it to run under Windows directly is so infeasible. Magically smooshing it together with DOSBox seems highly unlikely – I reckon the closest we'll get will be running Linux or ReactOS in DOSBox (or something like DOSBox that is more geared towards running either of those things, since of course DOSBox is for games. 😉 )

Quadko wrote:

Those are very interesting projects. I haven't run into HX DOS before, I'll check it out, thanks.

When you say "no APIs to wrap to", I'm not clear what you mean, could you expand on that? What I understand of Wine is basically a translation layer of libraries to load and provide Windows API support to a Windows PE executable, and filter/translate those calls to the host OS: be it linux or whatever. Is that close enough to true, or do I have the wrong picture of it? If there is just no "translation to dos/dosbox host" written yet, makes sense. If it means something else, I'd love to know more so I can grok why it's crazy talk for myself.
😀

You're right, Wine takes calls to Windows APIs (like Direct*, GDI, Windows Forms, etc) and translates them to things Linux understands (Mesa, OSS/Alsa, GDK for instance).

DOS (and by extension, DOSBox) offers no APIs for these relatively high-level tasks. DOS' API consists of a handful soft interrupts at INT 21h, for rudimentary tasks like reading/writing files, writing characters to the screen, or getting the keyboard state.

For anything beyond that, software talks directly to hardware through base IO, hardware interrupts, DMA, and/or MMIO. Wine would have to grow from a translation layer, to essentially a full OS. Hence things like ReactOS.

ReactOS is probably the solution here, though I don't know how friendly it is with DOSBox. It runs fine in other VMs, though I guess most of them lack the sound/video support of DOSBox.

At the same time it's current compatibility isn't stellar.

ReactOS is a cool project, and I've followed it from afar for a few years. I'd love to see it succeed, but that seems far away for now. Ubuntu's billionaire made me wish for such patrons for projects like ReactOS and DosBOX "those unlikely features" versions and so forth. Happy to fall on that sword and be that person myself, of course, just have to scrounge a meaningful subset of that billion dollars first... 😉

I follow what you are saying on Wine more now. I still wonder if we exclude everything 32 bit - Win32s and above, everything -post Win 3x, and everything in Win 3x that isn't game related (printers and multiple processes?) if a simple window manager and mouse layer and the (hopefully few) surprises could be enough to load and play a Win31 game? And if Wine can supply the windows compatibility side, what support would it need to run on DosBOX or directly on DOS? But I can also see why that's maybe an argument for most-minimal-linux-that-can-run-wine, too.

Because of that curiosity, I'm looking around for a way to peek at some of these games to see what Windows APIs they are linking. It's been a while since I played with the PE format, and never in 16 bit windows; maybe a rather over-zelous emulator-from-scratch project, or fire up ida pro, or just a utility like depends for 16 bit to dig around? (Cool, a quick google just turned one of those up! Hope it works...) But as I recall, win3x apps were basically dos apps + pe header + dll loader/linker to win APIs. But I wouldn't bet any money on my memory. If Wine has the loaders already... but maybe they are the easy part. 😀

There have been conversations along those lines several times before. See for instance HX DOS Extender.

Just for grins: the 16 bit windows depend.exe I found seems to work. Misc demos/games/WinPascal report linking to "Kernal, GDI, User", Stars! game reports "Win87EM, Kernal, GDI, User, CommDlg, ToolHelp". The Stars! dirctory also has dlls "CTL3Dv2.dll, Hyperfind.dll, WaveMix.dll", but apparently doesn't directly link them - maybe a manual linklibrary call to load them and indirect linking.

Curious! (Only have to implement the Kernal layer, the User layer, and the Graphics layer. How simple! But hopefully I can find a way to get functions called as well as dll's loaded before digging in too far.)

Yes, I didn't know about HX Dos Extender until ya'll mentioned it. I'm taking a look at it; overview is very cool, haven't dived into the details too much yet or browsed the forum. I'm happy to see the 16 bit support explicitly listed. - one thing I'm not clear on is console apps only vs. graphical apps - the documentation says console an awful lot, but I'm still early in the learning curve.

Hm: PE format was for post win3.x, win3.x NE format! "New Executable!" but not yet a "Portable Executable!". Fun with names.
http://en.wikipedia.org/wiki/New_Executable & http://wiki.osdev.org/NE & http://www.x-ways.net/winhex/kb/ff/NE_EXE.txt

If you google a bit you can find the windows 1-3.1 sdk

Thanks, good thinking, advice taken. I also decided it was worth the price of a book, so I ordered a windows internal book for the 3.1 era.

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

Probably OT by now, but for everyone still interested on running older games on wine trough an emulator, I've found that running it inside an ubuntu VM in Vmware Fusion is...well, surprisingly decent enough - with a level of compatibility way higher than expected for such kind of hodge-podge of a solution. I know, you can build wine natively for Mac, but not the same could be said for a windows version.

Even If no wrappers are used, we're talking about a " wine-abstracted windows calls -> emulated linux calls -> mac os x calls" kind of translation. And yet I've been to run Colin McRae Rally 2 and the demo of the original (CM1) version.
By the way, Wine doesn't even require a WM anymore for its more recent builds on Mac os X, so I'm not sure that not having a port of X11/X.org is the main hindrance for getting wine to run under windows.

I wonder if virtualbox, which is also free, is a viable alternative for this kind of "extreme virtualization".

Orka Borka wrote:

I know, you can build wine natively for Mac, but not the same could be said for a windows version.

It's actually even more fun.
http://wiki.winehq.org/WineD3DOnWindows
http://wiki.winehq.org/WineOnWindows
http://www.nongnu.org/wined3d/
http://savannah.nongnu.org/projects/wined3d
http://community.pcgamingwiki.com/files/file/ … ows-directx-81/
http://community.pcgamingwiki.com/files/file/ … dows-directx-9/
http://www.gog.com/forum/divine_divinity_seri … g_wined3d/page1
https://forums.virtualbox.org/viewtopic.php?f=6&t=25939

Heh, cool links. I've downloaded the Wine code this week and started poking around to get a feel for it. I was assuming a real or emulated Window Manager was going to be required no matter what, but Wine doesn't even require a WM anymore sure sounds interesting, if I understood it correctly.

Meanwhile, still working on the NE loading; coming along a bit at a time.