4 ms·

>Imagine trying to build Windows or Mac OS code from the early 90's on a modern OS... I guess, in Windows case it also should be relatively easy?

phendrenad2 6y ago
It's really amazing that win32 has remained unchanged for so long. I guess they got it right the first time (or rather, Palo Alto Research Centre got it right the first time). And if it ain't broke, don't fix it.
dbremner 6y ago
Porting 16-bit assembly is harder but porting C code from Win16 to Win32 is pretty easy. https://github.com/dbremner/cake https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.
badsectoracula 6y ago
Yeah, though pure X11 code should still be easier (ignoring anything not related to the APIs at hand of course, like the assumptions the existing code had about 32bit-ness) since the API hasn't changed at all. Win16 vs Win32 is 99% the same, but there are still a few minor differences, like some changes in how WPARAM (which was now 32bit) was interpreted in a few messages. Mac OS would be a complete rewrite though, no salvaging that.
- p_l 6y ago
  Early 1990s X11 clients are sometimes broken on recent X.Org setups in my experience, in subtle ways usually involving keyboard. And that's assuming running under X.Org. As for Win32, if the application didn't do stupid things like setting bitflags that were "reserved for future use", things apparently work without recompile for basic GUI from 1.01 to Windows 10.
  - badjeans 6y ago
    Only on Windows 10 32bit, which according to steam stats, is used by 0.10% of users.
  - badsectoracula 6y ago
    The post above was about compiling not running older programs. In terms of running Windows is better, though in either case you do need to find workarounds (what you describe sounds like such a case).
    - p_l 6y ago
      No workarounds - the 16bit DLLs were compatible all the way up from 1.01 to Windows 10 32bit, and from WinNT 3.0 all the way up to Windows 10 64bit. The problem is that a lot of software... disregarded the specs. Including infamously using "reserved for future use" areas of bitfields, which for example caused a lot of app crashes during early days of Windows 95 (where certain common API gained a new flag that was not compatible with previous flags, which worked fine so long as you didn't set them concurrently - which all properly written applications avoided.)
      - badsectoracula 6y ago
        The specs might be compatible but the programs aren't, exactly because of the assumptions (or plain old buggy code) you mention. So you need workarounds. I run a lot of older software, especially (though not only) games and i often have to do such workarounds like wrapper or replacement libs. I've also tried running older stuff on Linux (e.g. i have a collection of Linux game demos from the late 90s to early 2000s) and while most stuff run, you do need to find and install a bunch of missing libraries and wrappers (e.g. for OSS support).
- mattl 6y ago
  > Mac OS would be a complete rewrite though, no salvaging that. I bet you could get a NeXT application from the early 90s running without too much pain.
  - tjalfi 6y ago
    The early (earliest?) NeXT APIs start with NX. macOS doesn't have support for any of these. I found this out when I tried porting Tim Berners-Lee's WorldWideWeb to macOS as a weekend hack.

phendrenad2 6y ago

It's really amazing that win32 has remained unchanged for so long. I guess they got it right the first time (or rather, Palo Alto Research Centre got it right the first time). And if it ain't broke, don't fix it.

dbremner 6y ago

Porting 16-bit assembly is harder but porting C code from Win16 to Win32 is pretty easy. https://github.com/dbremner/cake https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

badsectoracula 6y ago

Yeah, though pure X11 code should still be easier (ignoring anything not related to the APIs at hand of course, like the assumptions the existing code had about 32bit-ness) since the API hasn't changed at all. Win16 vs Win32 is 99% the same, but there are still a few minor differences, like some changes in how WPARAM (which was now 32bit) was interpreted in a few messages. Mac OS would be a complete rewrite though, no salvaging that.

p_l 6y ago
Early 1990s X11 clients are sometimes broken on recent X.Org setups in my experience, in subtle ways usually involving keyboard. And that's assuming running under X.Org. As for Win32, if the application didn't do stupid things like setting bitflags that were "reserved for future use", things apparently work without recompile for basic GUI from 1.01 to Windows 10.
- badjeans 6y ago
  Only on Windows 10 32bit, which according to steam stats, is used by 0.10% of users.
- badsectoracula 6y ago
  The post above was about compiling not running older programs. In terms of running Windows is better, though in either case you do need to find workarounds (what you describe sounds like such a case).
  - p_l 6y ago
    No workarounds - the 16bit DLLs were compatible all the way up from 1.01 to Windows 10 32bit, and from WinNT 3.0 all the way up to Windows 10 64bit. The problem is that a lot of software... disregarded the specs. Including infamously using "reserved for future use" areas of bitfields, which for example caused a lot of app crashes during early days of Windows 95 (where certain common API gained a new flag that was not compatible with previous flags, which worked fine so long as you didn't set them concurrently - which all properly written applications avoided.)
    - badsectoracula 6y ago
      The specs might be compatible but the programs aren't, exactly because of the assumptions (or plain old buggy code) you mention. So you need workarounds. I run a lot of older software, especially (though not only) games and i often have to do such workarounds like wrapper or replacement libs. I've also tried running older stuff on Linux (e.g. i have a collection of Linux game demos from the late 90s to early 2000s) and while most stuff run, you do need to find and install a bunch of missing libraries and wrappers (e.g. for OSS support).
mattl 6y ago
> Mac OS would be a complete rewrite though, no salvaging that. I bet you could get a NeXT application from the early 90s running without too much pain.
- tjalfi 6y ago
  The early (earliest?) NeXT APIs start with NX. macOS doesn't have support for any of these. I found this out when I tried porting Tim Berners-Lee's WorldWideWeb to macOS as a weekend hack.