131–140 of 188 posts
Earlier quoted context omitted.
Most old games do not work because of old graphics apis. Wine emulates these apis on top of modern graphic apis. Windows users usually need to use wrappers, or wined3d from wine.
Yeah, 3D games using DirectX 8- are a shitshow on Windows Vista+...
Earlier quoted context omitted.
> You can't expect modern Windows to ship 20+ year old DLLs that allow running Windows 98 APIs as that's a major security vulnerability since older APIs had direct hardware/memory access without any kind of checks and balances. That doesn't make sense. If those old DLLs could bypass some security protections in Windows than that would be still a major vulnerability in recent Windows itself.
Makes sense to me: Exactly, that's why they're not shipped with recent Windows.
E.g., Wine ships other implementations of the same libraries and this causes zero extra security problems in Linux.
Earlier quoted context omitted.
MS are profit motivated (by definition) and Wine is functionality motivated (again by definition). MS are currently hell bent on getting you onto a cloud subscription for Windows as a service (WAAS) because that is their current business model. The Wine project is hell bent on delivering functionality that you want and they think you might want. Wine is less about shuffling the start menu to the middle of the taskbar…
Wine has been affected by profit too. Nobody remembers CodeWeavers? Let alone plenty of distros are for-profit and use it as a means to advertise their game-playing capabilities.
Earlier quoted context omitted.
Wine on Windows is technically interesting, even if others might argue that it's pointless. At the very least, these are also good tests of how much compatibility the layers provide. There's also WineVDM that actually solves a "need" to run 16bit Windows programs on 64bit Windows. I've considered using it for retro programming without leaving a modern OS, although DosBox may be a more reliable option. Now, if Win32s…
Wine on Windows would be great for running some 90s Windows video games.
Earlier quoted context omitted.
A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.
According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior. When Windows removes undocumented APIs or changes behavior not covered by the documentation, such apps break and people blame Microsoft. For example, I remember one app used to programmatically find some kind of "Print" menu in Windows' desktop environment and call it to implement printing functionality. W…
This may have been the case, but it no longer is. DirectDraw and other _official_ APIs have been removed from Windows, providing no official replacement (other than the ones coming from Wine itself!), and leaving hundreds of programs in the dust.
The MS of Chen no longer exists. Or may have never existed... https://en.wikipedia.org/wiki/AARD_code
Earlier quoted context omitted.
It is apparently possible to run Wine on WSL. https://liliputing.com/wine-on-windows-lets-you-run-windows-... I wonder if you can run Cygwin on it.
Wine on Windows is technically interesting, even if others might argue that it's pointless. At the very least, these are also good tests of how much compatibility the layers provide. There's also WineVDM that actually solves a "need" to run 16bit Windows programs on 64bit Windows. I've considered using it for retro programming without leaving a modern OS, although DosBox may be a more reliable option. Now, if Win32s…
Earlier quoted context omitted.
You can run 16 bit code in long mode just fine. It's just a different GDT entry like 32 bit code is. Windows didn't cut 16 but mode because of the processor ut because they took the opportunity to increase the max HANDLE table size greater than 16 bit code can address.
Just want to point out that not all 16-bit code can run unhindered in long mode. You can run 16-bit protected mode code. But long mode dropped the V8086 mode that made easily emulating 16-bit real mode possible.
> Fifth, oh, did you want to run a game? Not just a hello world? Then you need to deal with DirectX, audio (hello PulseAudio, my old friend), input devices (gamepads, joysticks), etc. It’s a lot of work! These last paragraphs just made me realise how grateful I am to people who work on these open source projects without expecting any compensation or even praise for their work. It has happened once or twice that I tri…
A lot of the work required to get games working transparently on Wine was thanks to Valve, who released Proton as open source, along with heavy work on DXVK to simulate DirectX, etc.
Of course they did it because it benefits them, but still they could have kept it private and it would have boosted only Steam sales. Instead it's a win for them AND for the community, an example that should be followed by other companies.
What a time to be alive indeed!
Earlier quoted context omitted.
Linux will shortly remove support for DECNet. That's deprecating something responsibly. Your SimCity example was an easy win and yet more wankery. They have not put a huge amount of work in compatibility. MS have done just enough always and only enough. That is precisely what a large commercial business would do and they did.
I'm saying this as someone who does not care about Windows (or Microsoft) at all, and hasn't been using Windows besides maybe in a vm once a year for at least a decade now: To say they have done "just enough always and only enough" is massively underselling it to a level where it's basically wrong. Everyone who has been following Raymond Chen's The Old New Thing blog for some time knows the massive, quite impressive,…
But the lengths to which Microsoft has historically gone to for backwards compatibility have been legendary - if decades-old internal corporate apps for which the source was lost 10 years ago don't work on the latest Windows, they don't get all that sweet upgrade license revenue. It's their bread and butter.