41–50 of 55 posts
Earlier quoted context omitted.
Some games that ran on Vista, can run under Wine, but not on Windows 11. The backwards compatibility story has changed in the last few years.
Games for Windows, can’t play any of those anymore without cracking them since the severs got turned off.
Earlier quoted context omitted.
Intel backwards compatibility has meant that real mode is still with us more of less, but to give context to people who aren't as familiar: real mode was superseded by protected mode with the introduction of the 80286, in 1982.
I believe Microsoft removed support for 16bit Windows applications some time ago. The hardware may be willing but the software is now incapable.
Excellent article. The stability of the Win32 API is a gold standard. \
Before Vista, there were two rects, the Window Rect (which included the title bar, menu bar, and the resize border), and the Client Rect, which includes the work area of the window.
Once Vista came around, Window Rects became completely different. After a window becomes shown, the Window Rect expands outwards (around 8 pixels or so) to include a drop shadow and larger resize area. So it's no longer just Window Rect and Client Rect, now there's a third rect called the DWM Extended Frame Bounds, and that corresponds to what the Window Rect used to be on earlier versions of Windows.
To try to make things more compatible, the Window Rect will behave like older versions of windows before the window is shown, and there is no way to access DWM Extended Frame Bounds before a window is shown. But once a window is shown, your Window Rect is bigger now, and in a different location. Programs that try to move the window will instead move it to a location 8 pixels down-right of the target location. Programs that try to resize the window will instead make it 16 pixels too narrow and short. If a program tried to remember the difference between the Client Rect and Window Rect, suddenly that number changed just because the window got shown.
So newer programs need to ask for the DWM Extended Frame Bounds to get an idea of where their window actually is. And it also happens that DWM Extended Frame Bounds are not DPI adjusted, but the Window Rect and Client Rect are. So you need to DPI adjust it into a coordinate system which matches the Window Rect. Now you finally have your three rects, and can properly place a window somewhere on the screen.
Earlier quoted context omitted.
Who exactly in the Linux world is supposed to get paid wonderfully to keep mountains of old cruft and technical debt in working order? Not to say I'm insensitive to your point, but when whole UI frameworks are amateurs' passion-projects, the practical burden of maintenance has very real implications. That's essentially the whole story behind the Linux desktop losing Xorg.
In the end, it's always the old problem, how to properly fund open source projects. Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money under "digital sovereignty" programs - but given the rabid opposition to systemd (funded by RedHat), I fear that any attempt by the EU to get some order into the chaos will be met with just the same toxicity.
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 NGI Zero³ (many in the area of networking, computer design, federated/P2P communication protocols, …)
¹: https://github.com/rlahfa-dinum/securix ²: https://www.opendesk.eu/en ; https://lasuite.numerique.gouv.fr/ ³: https://nlnet.nl/project/
Earlier quoted context omitted.
You just need to install 86Box as a compatibility layer. Everything runs perfectly. You only have to copy-paste one .exe file and then you can launch your app from Windows, that’s it. Sounds perfectly reasonable.
86box is a PC emulator, not a compatibility layer.
There is no magic
16-bit windows applications aren't supported natively by 64-bit windows, but OTVDM (based on Wine code) will run most of them fine.
While I haven't daily driven Windows in years and am usually the first to criticize Microsoft. You have to give credit where credit is due; Windows backwards compatibility is simply nuts. I had never run into compatibility issues with programs or games built for older Windows version, nor have I heard of anyone who did.
Earlier quoted context omitted.
In the end, it's always the old problem, how to properly fund open source projects. Maybe with the current political events and subsequent changes in priorities we'll see EU governments ponying up some money under "digital sovereignty" programs - but given the rabid opposition to systemd (funded by RedHat), I fear that any attempt by the EU to get some order into the chaos will be met with just the same toxicity.
> 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…
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 firepower uses said influence (i.e. Lennart Poettering of systemd).
Particularly something like an office / productivity suite is ripe for conflicts. One group of users (i.e. stingy governments) want something that can run on computers that would be more fitting in a museum. Other groups want pixel-perfect compatibility with Microsoft products, even if it results in a ton of extra work. Others don't want LDAP support for the email client's address book, but instead other stuff like an integration into Okta or whatever other SaaS. And either someone will get empowered to make such decisions by everyone involved... or it will be a lot of money wasted or a lot of chaos.
Earlier quoted context omitted.
Intel backwards compatibility has meant that real mode is still with us more of less, but to give context to people who aren't as familiar: real mode was superseded by protected mode with the introduction of the 80286, in 1982.
I believe Microsoft removed support for 16bit Windows applications some time ago. The hardware may be willing but the software is now incapable.
I don't recall seeing a technical justification, however I suspect it's related to what CPU state transitions are allowed; protected mode (32bit) is allowed to swap to "virtual-8086" mode, which I guess is how real mode applications were run (rather than the processor completely turning off virtual memory, or completely emulating a CPU a la qemu).
IA32e mode (Intel's name for X64) however is not allowed to transition into virtual-8086 mode[0]; it has to drop the processor into 32 bit mode first. That would chop off the top level of page tables, so short of something you do to affect the whole machine, that sounds like a non-starter for running an application.
[0] Intel software developer manual 3, 2.2
Earlier quoted context omitted.
Some games that ran on Vista, can run under Wine, but not on Windows 11. The backwards compatibility story has changed in the last few years.
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).
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.