I got a tip in another post about this fantastical project, boxedwine! It’s Wine + a 386 processor emulator, and it’s been targeted to SDL. What does this mean? Wine on Windows!
I went ahead with one of the oldest Windows games I have around, SimEarth, for Windows 3.0. I don’t have Balance of Power, although I guess I may procure a copy one day. Anyways it’s Windows in it’s 1990 glory 16bit, 286 protected mode, and sure as heck won’t run on Win64. Oh sure you can run this on MS-DOS + Windows, but where is the fun in that?
Now that’s all good fun, sure Wine can run stuff, sure, but it’s still wine. Well remember all that noise about android running Wine? Yeah, well here we go.
Here we go. Games, and the BoxedWine project page.  And yes, it can run stuff like Quake 2, and other far more intense applications. Just like Wine. It’s really great stuff, check it out, if only in a browser.
If you want to run ancient Win16 stuff in a pinch, it may actually run. I had issues with win87em.dll stuff, but just like Wine it’s a moving window of compatibility.
Nice! I played Balance of Power back in the day (and perhaps still have the floppies) but the only thing I can remember about it is that it included the Windows Runtime and I desperately wanted to try to do other stuff in Windows. I was just a kid and probably never succeeded, and never got to use Windows until 3.0.
Another old Windows game I find interesting is Klotz, a shareware or freeware Tetris clone. I think the oldest version I found was for Windows 2.x, and there was an early 32 bit build made for an early NT beta if I recall correctly.
I recently found the Macintosh Pascal source to BOP 2. It’s… Very Pascal. And I think I forgot a lot of Pascal. Last time I used it was translating Tradewars 200.
Maybe it’s another thing to try another day. Carbon is apparently very much preserves a lot of the API, maybe it’s be a weird Pascal to C translation project.
I haven’t looked as Pascal since Delphi – even then I think 4.0 was the last version I played with.
Looks like he’s got the source for a few other games. http://www.erasmatazz.com/library/source-code/index.html
Free Pascal might be able to handle it. There’s a MACPAS compiler mode and it supports Carbon…http://wiki.freepascal.org/FPC_and_Carbon
Hmm it even support m68k and can be called in MPW…in theory one could create a Pascal app and have it target every version of MacOS was one (bastardized) source.
Seems neat but I have no clue how to really use it. Plus the game it comes with ran too fast.
Wine can be a little tricky at first. And it took me a few minutes of messing around to get SimEarth running.
Its easier to copy stuff into the ‘root’ directory and change chomp to explorer and run stuff that way.
Wow – I just had a play and it is quite neat. I was hoping win3mu (http://www.win3mu.com/) would be released soon, but the author hasn’t posted any update in sometime. Shame it’s not open-source – it’d be a great thing to hack around with.
That pretty much sums up how I feel. This is cooler as the source exists. And it’ll emscripten which is totally WTF and awesome too.
The tools for MS Sql Server run, but the server triggers an unknown opcode..
I’ve actually thought about using an approach similar to win3mu. He pretty much documented the guts, so it wouldn’t be so hard, in theory, to reimplement it – but I’m not good at writing CPU cores and don’t have a working one to experiment with. :/
Well, look no further than the MAME i86/i286 and i386/i486 cores that are in MS-DOS Player.
It should be enough to give you that simple start .
usotsuki,
I also thought it wouldn’t be too hard to get something up and running with my own version of the Windows API. And the truth is, it’s not too hard to get the kernel up and running. The idea of a process, thread, file, it all makes sense. I got Age of Empires and Caesar 3 working with my own implementation using the cpu core from jDosbox. But when I started to work on getting Diablo to work that is when I realized it would going to get really hard, having to implement everything in usr32.dll was pain, all the common controls and the dialog APIs was a lot of work. That is when I decided to change track and work on BoxedWine and just use what Wine has already done. Win16 is smaller than Win32, but I looked at the exports of user.dll and I expect there would be the same insane amount of code that would have to be written to cover everything. It is certainly not impossible, but it would take a long time to complete.