[HN Gopher] DOS/4GW made Windows 95 game compatibility easier, b...
       ___________________________________________________________________
        
       DOS/4GW made Windows 95 game compatibility easier, but with higher
       stakes
        
       Author : zdw
       Score  : 134 points
       Date   : 2023-08-29 17:57 UTC (5 hours ago)
        
 (HTM) web link (devblogs.microsoft.com)
 (TXT) w3m dump (devblogs.microsoft.com)
        
       | leslielurker wrote:
       | I wish Apple could figure out something like Proton for MacOS. It
       | feels like a relatively small investment in this area could
       | unlock a huge catalogue of classic games. It's the only thing I
       | feel I'm missing by switching from Linux.
        
         | elteto wrote:
         | They did just that with the new Game Porting Toolkit.
        
           | irq wrote:
           | This is true. Worthy of note: this toolkit was released
           | fairly recently and there hasn't been much time yet for
           | commercial game devs to consider using it. Here's hoping they
           | do.
        
         | marcodiego wrote:
         | I wish not. It can now be one more reason to more easily
         | convince users to switch to Linux.
        
       | stkdump wrote:
       | The article is written with the assumption that various intricate
       | historical technical facts are known to the reader and others
       | aren't (hence they are explained). But still it fit my knowledge
       | profile perfectly as these assumptions were exactly true for me.
        
       | markus_zhang wrote:
       | A side question, any recommendation on emulator and books if I
       | want to replicate what Carmack did for Commander Keen? The keen
       | dream source code uses C and assembly so I'll do the same.
       | 
       | I guess Dosbox is accurate enough for a 386dx with an ega card,
       | and this book ( https://www.amazon.ca/Programmers-Guide-Ega-Vga-
       | Cards/dp) is good enough for the guide?
       | 
       | For development tool I plan to use vscode with openwatcom C
       | compiler.
       | 
       | Any other book I should take to learn assembly and DOS C? I
       | already know some C but I guess it's a bit different than the old
       | C.
        
         | badsectoracula wrote:
         | Check out 86Box[0], unlike Dosbox it does full system emulation
         | and tries to be cycle accurate (or cycle accurate enough) so
         | that you will notice little to no discrepancies between the
         | emulated hardware and the real one.
         | 
         | 86Box was forked from PCem which is kinda similar but PCem
         | development has practically stopped and all development
         | nowadays goes towards 86Box.
         | 
         | Also FWIW do not use plain Dosbox, it has longstanding bugs
         | that haven't been fixed in years (some have been fixed in SVN
         | but they haven't made a new major release for a very long
         | time). Use Dosbox-X or at least Dosbox Staging instead
         | (Dosbos-X is more accurate). As an example Post Apocalyptic
         | Petra[1], a game i made ~3 years ago for a DOS game jam doesn't
         | work on plain Dosbox because of some timing issues (you may get
         | a black screen or visual glitches) - you need either Dosbox-X
         | or Dosbox Staging.
         | 
         | Also note that these projects have slightly different goals:
         | 86Box tries to emulate the hardware as precisely as it can
         | whereas Dosbox(-X/Staging/etc) tries to provide a compatibility
         | layer for running older software (plain Dosbox is only focused
         | on games but other forks expand that to include all software).
         | This means that Dosbox(/etc) will be more likely to ignore
         | "bad" programming that wouldn't work on (or only work on some)
         | real hardware - e.g. its Sound Blaster emulation is very
         | forgiving and if you write some SB code and test it only on
         | Dosbox chances are it wont work on the real hardware.
         | 
         | [0] https://86box.net/
         | 
         | [1] https://bad-sector.itch.io/post-apocalyptic-petra
        
           | markus_zhang wrote:
           | Thanks, will do! Glad that I learn about other emulators.
        
         | simcop2387 wrote:
         | Absolutely check out PCem for a closer to hardware emulation
         | than dosbox, https://pcem-emulator.co.uk/
        
           | badsectoracula wrote:
           | PCem is dead, use 86Box[0] (forked off PCem) instead.
           | 
           | [0] https://86box.net/
        
           | markus_zhang wrote:
           | Thanks will download. Is there any particular reason this one
           | is more accurate than dosbox?
        
         | nickt wrote:
         | That link to the book isn't working for me, any chance you can
         | post the details please?
        
           | markus_zhang wrote:
           | Sorry here you go: https://www.amazon.ca/Programmers-Guide-
           | Ega-Vga-Cards/dp/020...
        
         | rzzzt wrote:
         | Some useful tutorials can be found in PC-GPE:
         | http://qzx.com/pc-gpe/
        
           | markus_zhang wrote:
           | Ah, thanks a lot. I used to have this page bookmarked but
           | lost due to unforeseen consequences.
        
             | rzzzt wrote:
             | I think this one is already a mirror, with the original
             | lost in time, but not sure... I had the .txt files as a
             | collection downloaded in 2004 or so, the readme file in it
             | says the previous location was on an Oulu University FTP
             | site.
        
         | bluedino wrote:
         | I would check out the Andre Lamothe DOS game programming books
         | 
         | You will also want to start with a 16-bit C compiler like
         | Borland Turbo C or Microsoft C, a lot of the code is very
         | different from the 32 but protected mode versions
         | 
         | There's always DJGPP which Quake was written in, but again
         | 16-bit DOS code isn't going to run as-is.
        
           | badsectoracula wrote:
           | > You will also want to start with a 16-bit C compiler like
           | Borland Turbo C or Microsoft C
           | 
           | The parent post mentioned they're going to use OpenWatcom
           | which is an actively developed[0] C and C++ compiler that
           | targets 16bit DOS (among others).
           | 
           | [0] https://github.com/open-watcom/open-watcom-v2
        
             | bluedino wrote:
             | Ahhh I thought it was 32-bit only, not sure if I ever used
             | their DOS compiler in the old days or not.
        
           | markus_zhang wrote:
           | Thanks. I used to do some C++/sdl2 game programming just for
           | fun but I think this project needs more study.
           | 
           | TBH I don't know if Commander Keen is using protected mode. I
           | do not understand the code and I assume not. I need to know
           | how to program and compile for DOS 16-bit, as you said, and
           | how to inline assembly, and how to use assembly to put pixels
           | on screen using a virtual ega card provided by dosbox.
        
             | bluedino wrote:
             | It did not use protected mode
             | 
             | https://github.com/keendreams/keen
             | 
             | https://fabiensanglard.net/ega/
        
           | myth_drannon wrote:
           | Lamothe or Michael Abrash. Archive.org has books from both
           | authors.
        
         | jandrese wrote:
         | C isn't C++. Most of what you know today applies to older
         | compilers as well, with only a handful of features added over
         | the years. You aren't going all the way back to K&R calling
         | syntax here, I'm assuming you will target C89. You will just
         | have to remember to declare all of your variables at the top of
         | each function and the stdint types won't be available. There
         | are a few other things added over the years, but its going to
         | be pretty much the C you know and love.
        
           | badsectoracula wrote:
           | > I'm assuming you will target C89
           | 
           | OpenWatcom (the compiler the parent post mentioned) supports
           | C99.
        
           | lockhouse wrote:
           | Pedantically you are correct, but it is and was common to use
           | C++ compilers as a slightly more convenient dialect of C.
           | This gives you the performance and simplicity of the C
           | language with some very nice quality of life improvements.
           | 
           | With few exceptions, C++ can mostly be treated as a superset
           | of C.
        
             | jandrese wrote:
             | What I was trying to say is that if you're comfortable
             | using modern C++ and try to switch back to a C++ compiler
             | from the early 90s you are going to find a lot of the
             | features you regularly use suddenly being absent. With C
             | this is much less of an issue.
        
               | lockhouse wrote:
               | Sorry, I misread your comment, that makes a lot more
               | sense now!
        
               | duskwuff wrote:
               | The newer C features that you're most likely to feel the
               | lack of in an older compiler are:
               | 
               | 1) Mixed declarations and code. All variables must be
               | declared at the top of a basic block.
               | 
               | 2) Along similar lines, declaring variables in control
               | statements like for().
               | 
               | 3) // comments. (Hardly a critical feature, but you're
               | probably used to having them.)
               | 
               | Perhaps not coincidentally, I think these were all
               | features which began their life in C++, and were
               | backported to C in C99.
        
           | deaddodo wrote:
           | > You will just have to remember to declare all of your
           | variables at the top of each function
           | 
           | This is still idiomatic to the C community, even if it isn't
           | strictly required any longer. About the only place it's
           | ignored is inline variables for loops.
        
         | lockhouse wrote:
         | Fabian Sanglard's books are excellent! I highly recommend them
         | for retro DOS game engine programming.
         | 
         | https://fabiensanglard.net/
        
           | markus_zhang wrote:
           | Thanks, I actually got the idea after reading his adapt
           | refresh article as I didn't understand it.
        
       | euos wrote:
       | Ha. I barely recall details (it was 30 years ago) but I remember
       | there was a trick to somehow run Windows 3.x to make the game
       | believe your system had more RAM that it actually did. Don't
       | remember details, but remember it _mostly worked_ (swapping was
       | an issue and some games would not work). This -
       | https://devblogs.microsoft.com/oldnewthing/20160328-00/?p=93... -
       | explains it.
       | 
       | I believe I had to do that to run some games in SVGA mode. It
       | might've been KKND or some other game...
        
         | icoder wrote:
         | I've used this once! Warcraft 2, playing against a friend over
         | a null-modem, it all started out great but the swapping became
         | worse and worse during the game. It lagged both our games, but
         | he (actually having the physical RAM required) at least had a
         | responsive UI, that was too big of competitive advantage.
        
       | Dalewyn wrote:
       | >Miraculously, most games just worked despite running under a
       | different DPMI server from what they were originally developed
       | with. There were occasional issues with specific games. Popular
       | ones include games which assumed that all memory was physical and
       | games which assumed the interrupt flag was unvirtualized, but for
       | the most part, things worked well enough that the remaining
       | issues could be treated as app-specific bugs.
       | 
       | That is Microsoft-speak for _" We're going to patch SimCity
       | because we need that to run absolutely."_ and I have nothing but
       | the utmost respect and admiration.
        
       | stuaxo wrote:
       | Interesting reading this, just at a point when dosemu2 got a load
       | of fixes for DPMI 1 (note -DPMI programs have worked for a long
       | time in dosemu / dosemu 2).
        
       | LeoPanthera wrote:
       | A modern replacement for DOS/4GW is "DOS/32A". It's compatible
       | and you can even patch out old binaries to replace DOS/4GW with
       | DOS/32A.
       | 
       | https://github.com/yetmorecode/dos32a-ng
        
         | gattilorenz wrote:
         | I can't see why I would want to do that from your post or the
         | Github readme. Care to elaborate?
         | 
         | I mean, if I'm using an old closed-source application, what
         | would be the advantage of changing its extender?
        
           | shdon wrote:
           | DOS/4GW was a limited version of DOS/4G. Early versions had
           | trouble with secondary DMA channels on the ISA bus (wreaking
           | havoc with certain 16 bit soundcards). The 4GW version
           | especially was also considered slow and bloated, and allows
           | only up to 64MB of memory to be used. DOS/32A allowed
           | allocation of up to 2GB, and has better performance and a
           | smaller binary.
        
             | dale_glass wrote:
             | That's neat, but I think the DOS era was over well before a
             | 64MB limit became a limitation.
             | 
             | Maybe for very specialized stuff like 3D Studio it'd make a
             | difference.
        
           | aargh_aargh wrote:
           | The DOSBox wiki only provides a vague statement:
           | > Once a game uses this, it is expected to run faster and
           | better in DOSBox.
           | 
           | The references on Wikipedia could shed some light
           | https://en.wikipedia.org/wiki/DOS/32
           | 
           | The most concrete I've noticed is https://web.archive.org/web
           | /20171224010653/http://dos32a.nar...                 > DOS/32
           | Advanced DOS Extender provides full compatibility with Watcom
           | C/C++ and features one of the most complete software
           | emulations of DOS/4GW, thus allowing the users to "plug" it
           | into the protected mode programs which use DOS/4G, DOS/4GW,
           | DOS/4GW Professional and any other compatible DOS Extenders
           | without the need to modify a single line of code.       >
           | > DOS/32 Advanced DOS Extender has been designed to be fast,
           | flexible and reliable. It features very fast mode translation
           | and interrupt servicing, ability to configure and bind the
           | DOS Extender to applications, protected mode executable
           | compression, support for allocation of up to 2 GB of memory,
           | Null-pointer protection and more.
           | 
           | There's also HTML docs in the repo:
           | https://github.com/yetmorecode/dos32a-ng/tree/main/doc
        
       | freewizard wrote:
       | Reminds me of lots of fun memory in last but great days of DOS as
       | mainstream and dawn of Win32.
       | 
       | DOS/4GW was not the only game in town, there were a few of those
       | 32bit extenders, I recall using sth called WDosX to run Delphi
       | compiled (win32) exe in DOS. DOS/4GW was probably the most
       | popular one partly thanks to the popularity of Watcom C compiler.
        
         | Borg3 wrote:
         | PMODE/32 (and PMODEW/32) was another small and pretty popular
         | DOS extender. I used it myself with WATCOM compiler and TASM
         | occasionally :)
         | 
         | Another one was CWSDPMI. Just found it on my old backups.
         | 
         | As for DOS4GW popularity, it all exploded when DOOM was
         | released :)
        
           | svilen_dobrev wrote:
           | Pharlap was doing Pmode ; Zortech C (bought later by
           | Symantec), were doing X32 which was compatible with Pharlap
           | but like 5 times smaller ; djgpp (gnu cpp for dos/win then)
           | had a variation
           | 
           | And you could mix and match (if u have written good
           | parametrized makefile/s that is), i had like 6 compilers vs
           | 3-4 diff.extenders (but not all combinations possible)
           | 
           | interesting times these were. internet? what's that?
        
             | lockhouse wrote:
             | Zortech actually went through several iterations and is
             | still available in the form of the Digital Mars C and C++
             | developement system.
             | 
             | Unfortunately it looks like the X32 DOS extender link on
             | the page below is dead.
             | 
             | https://www.digitalmars.com/
        
       | PreInternet01 wrote:
       | It is, especially in hindsight, difficult to appreciate how big a
       | deal DPMI was.
       | 
       | But to try to give you an idea: I was in an OS/2 seminar
       | (because, well, OS/2 was the _future_ at that point in time) when
       | someone from Microsoft circulated photocopies of an early DPMI
       | document.
       | 
       | This instantly divided the audience in two groups: those who
       | _got_ it (and abandoned the OS /2 hype train that instant), and
       | those who did not.
       | 
       | When (some years later: Internet time was not yet invented
       | either) Windows 95 came out with pretty much flawless DOS
       | compatibility, whereas OS/2 was still struggling to run more than
       | one DOS app simultaneously (with DOS apps still being _very_ much
       | the only revenue-positive game in town), OS /2 was effectively
       | dead.
       | 
       | Sure, NT put the nails in the coffin, but it would be a few years
       | before typical consumer/business hardware could reliably run
       | that. With DPMI (an API, not even a product...), Microsoft
       | settled the OS wars (as they were at the time...) decisively.
        
         | dale_glass wrote:
         | > This instantly divided the audience in two groups: those who
         | got it (and abandoned the OS/2 hype train that instant), and
         | those who did not.
         | 
         | Why? Was there something stopping OS/2 from implementing DPMI
         | as well?
        
           | fredoralive wrote:
           | Why develop for OS/2 when you can use protected mode from DOS
           | anyway?
           | 
           | OS/2 2.0 added DPMI support so it can run there, although
           | this anecdote is presumably from the OS/2 1.x era.
        
             | dale_glass wrote:
             | > Why develop for OS/2 when you can use protected mode from
             | DOS anyway?
             | 
             | GUI? Multitasking?
             | 
             | But was it even viable to use anything but DOS for gaming
             | back then? WinG/DirectX took a good while to show up, and
             | I'm not sure if OS/2 ever developed anything comparable.
             | 
             | Windows gaming was mostly things like chess and solitaire
             | until then.
        
         | pavlov wrote:
         | _> "Windows 95 came out with pretty much flawless DOS
         | compatibility, whereas OS /2 was still struggling to run more
         | than one DOS app simultaneously"_
         | 
         | This doesn't match my recollection. Yes, 16-bit OS/2 1.x did
         | poorly with DOS because it couldn't use the 386 virtualization
         | capabilities, but 32-bit OS/2 2.x was a great environment for
         | multitasking DOS apps. It definitely supported DPMI too.
         | 
         | Many people ran complex apps like 3D Studio under OS/2 rather
         | than plain DOS. It even had the ability to preemptively
         | multitask Windows 3.0 apps which Windows itself didn't.
         | 
         | IBM used to have a marketing slogan for OS/2:
         | 
         | "A better DOS than DOS and a better Windows than Windows."
         | 
         | Unfortunately that was a fairly niche market after all. People
         | didn't want a somewhat better environment for running Windows
         | apps in parallel sandboxes when it came with so much
         | installation hassle and such high system requirements. With
         | practically no native apps and losing the ability to run
         | Windows soon (since IBM's license only covered Windows 3.x), it
         | had no chance.
        
           | pdonis wrote:
           | _> t even had the ability to preemptively multitask Windows
           | 3.0 apps which Windows itself didn't._
           | 
           | I remember this as well. For a while I was running Windows
           | apps on OS/2 Warp instead of Windows for just this reason.
        
           | Lerc wrote:
           | When it came to games I had written I had relied on promises
           | that Microsoft had made that dos virtualization would be
           | quite seamless. My game used a pseudo retrace interrupt by
           | carefully calibrating the timer every frame to generate an
           | interrupt just before the screen retrace and adjusting the
           | timer to compensate for drift.
           | 
           | This did not work in Windows95. OS/2 did it almost perfectly
           | (it missed the occasional frame but not enough to matter)
        
       | badsectoracula wrote:
       | Fun fact: the DPMI server was active on Windows 3.x even when DOS
       | programs weren't running. This was taken advantage by Watcom
       | compilers for their "win386" target to generate 32bit code that
       | ran under Windows 3.x (this was unrelated to Win32s and didn't
       | require it).
        
       | mromanuk wrote:
       | > Miraculously, most games just worked despite running under a
       | different DPMI server from what they were originally developed
       | with. There were occasional issues with specific games. Popular
       | ones include games which assumed that all memory was physical and
       | games which assumed the interrupt flag was unvirtualized, but for
       | the most part, things worked well enough that the remaining
       | issues could be treated as app-specific bugs.
       | 
       | It's funny because at that moment in time I was running DOS
       | games, and most of them worked without issues and I was thinking
       | that Win95, wasn't too different and just a UI, like it was Win
       | 3.1x
        
         | bluedino wrote:
         | I felt like a wizard, running multiple windowed DOS VGA games,
         | along with Word and a video (Weezer!) playing all at the same
         | time on Windows 95
         | 
         | Something about the multitasking in Win95 (among other things)
         | was so different in Windows 3.1, even on the same hardware. You
         | could clearly see processes passing control to each other and
         | updates were so slow.
        
           | irq wrote:
           | > and a video (Weezer!)
           | 
           | Was it the Happy Days music video that came on the Win95 CD?
           | :)
        
           | marcodiego wrote:
           | For those who don't know: win95 came with an 'extras' cd-rom
           | with a few videos. Among them there a Weezer clip [1] and
           | "Good Times"[2]
           | 
           | [1] https://www.youtube.com/watch?v=kemivUKb4f4 [2]
           | https://www.youtube.com/watch?v=iqL1BLzn3qc
        
             | dxdm wrote:
             | Good times. I remember finding these videos after
             | installing Win95 on my very first self-built PC. Thanks for
             | the nostalgia hit.
        
       ___________________________________________________________________
       (page generated 2023-08-29 23:00 UTC)