Live data from Hacker News

Windows 1.0 and the WinAPI, 40 Years Later

medium.com

51–55 of 55 posts

Re: Windows 1.0 and the WinAPI, 40 Years Later

#51
post #45

Earlier quoted context omitted.

86box is a PC emulator, not a compatibility layer.

The official compatibility layer of Microsoft works the same way as 86box: https://betawiki.net/wiki/NTVDM There is no magic

That link says NTVDM uses the CPUs virtual-8086 mode, rather than emulating a CPU; NTVDM's approach can't be done on a CPU that's in 64bit mode (per Intel's docs), the CPU would have to be stepped back into protected mode first (which isn't the same as when you run a 32bit application in a 64bit OS, that's a separate compatibility state within 64bit mode).

Re: Windows 1.0 and the WinAPI, 40 Years Later

#52
post #45

Earlier quoted context omitted.

86box is a PC emulator, not a compatibility layer.

The official compatibility layer of Microsoft works the same way as 86box: https://betawiki.net/wiki/NTVDM There is no magic

It's not the same at all. 86box emulates the whole PC, every component and peripheral. NTVDM is just a compatibility layer.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#53
post #44

Earlier quoted context omitted.

> Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money Those wheels are already spinning at a fast pace, the French government has its own NixOS-based distro for public servants¹, teams-up with the German and Dutch governments to develop a productivity suite as to not rely on MSOffice², NLNet sponsors many "infrastructure-level" initiatives though…

Money is one thing, it's desperately needed. The key question is, who will call the shots? That's the most pressing problem with many open-source projects without commercial backers - they completely lack focus, unless there is either some sort of BDFL providing the guardrails (be it Linus Torvalds, Guido van Rossum, Daniel Stenberg, Fabrice Bellard or the other usual suspects), or someone backed by serious financial…

Not saying that more governance and focus wouldn't bring more bang for buck, but from the lists I sent, you would notice a pattern of investing on open standards and vendor-agnostic infrastructure. It makes servicing specific needs overall easier, because the whole field is elevated through easier interop and efficiency. If LDAP, email, GUI apps and videoconferencing become easier, making an "LDAP-enabled GUI email client that does group calls" that's perfect your (industry/trade/…) needs goes from "near impossible, requires millions in CAPEX" to "we'll have it in a matter of days/weeks".

The other nice thing is, the whole world benefits from it, for free. The only losers are the monopolists and other societal parasites.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#54
post #50

Earlier quoted context omitted.

I'd like to know which ones you've had issues with. I've compiled a collection of hundreds of Windows games from ~96-2006 and I've only run into one that's required an appcompat flag (carmageddon 2).

Dark Messiah of Might and Magic, and a lot of other early Source games will just outright crash. Crysis Wars, Word '03, the Saboteur are all in a similar boat. They're not address aware, meaning they overallocate at launch, and Windows handling of 32bit compatibility is dead end code that hasn't been worked on in decades. These are 64bit executables, with 32bit memory mapping inside them.

We regularly play Dark Messiah at our LAN, and I got that working straight off the disc. The only issue I've had with Source is SDK 2007 mods, but only because it's _extremely_ hard coded to have the SDK in a specific location.

But yeah, games that do outright crash are pretty easily patchable and most likely already have been.

Re: Windows 1.0 and the WinAPI, 40 Years Later

#55
post #50

Earlier quoted context omitted.

Dark Messiah of Might and Magic, and a lot of other early Source games will just outright crash. Crysis Wars, Word '03, the Saboteur are all in a similar boat. They're not address aware, meaning they overallocate at launch, and Windows handling of 32bit compatibility is dead end code that hasn't been worked on in decades. These are 64bit executables, with 32bit memory mapping inside them.

We regularly play Dark Messiah at our LAN, and I got that working straight off the disc. The only issue I've had with Source is SDK 2007 mods, but only because it's _extremely_ hard coded to have the SDK in a specific location. But yeah, games that do outright crash are pretty easily patchable and most likely already have been.

If its the disk version, you have the 32bit executable. That'll work just fine. It's when the executable is 64bit, but the rest of the engine isn't.
Post reply on HN