Earlier quoted context omitted.
16-bit software won't run natively in 64-bit mode. It requires some programmatic emulator, like DosBox. Or am I missing something?
The thing that you're missing is that Microsoft used to ship that emulator with Windows. Then they stopped doing that. AFAICT, Wine can run WIN16 programs. I don't know if it can run DOS programs. There's a WineHQ wiki page that says it can load DOS programs, but various internet fora seem to believe that Wine's DOS support is pretty broken. I've never tried it, and have no DOS programs handy, so I can't verify those…
Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
491–500 of 512 posts
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#492Earlier quoted context omitted.
Wine actually does run some ancient Windows games better than Windows 11 itself.
Wine is also the reason why Windows software has more longevity on Mac than Mac software. Like, 32-bit didn't get deprecated in Wine.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#493Earlier quoted context omitted.
Wine's APIs are more stable than Linux's APIs, so it seems more plausible to me that Wine will become the first class target itself.
What I'd like to see would be some useful extra APIs in Wine, that would allow it to perform even better in some situations, and that such APIs would be then embraced by the game developers. Finally some embrace, extend, and extinguish love right back at Microsoft!
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#494Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#495Earlier quoted context omitted.
Not really. I actually tried building an "old" game (read: not updated since 2014 or so) on Linux when I used it. It didn't work because autotools changed, some weird errors with make, and the library APIs have changed too. In the end I gave up and just used proton on the windows .exe. Unbelievable. :(
I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will n…
/s
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#496Wine removed 32-bit support, breaking 90% of programs people used it for.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#497Earlier quoted context omitted.
The API underneath the Win32 API, the Windows Native API, is not necessarily stable and therefore not intended for direct consumption by applications.
If you're utilizing undocumented APIs that aren't meant for public use, sure... but the core Win32 APIs have been pretty stable for going on 3+ decades now. You can take a lot of win32 apps from the early 90's and they'll run without modification in windows today... though, they'll probably run in Wine and likely a better chance there... but still.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#498Earlier quoted context omitted.
Yeah, that's because Microsoft can see the writing on the wall. They don't want Windows to die, but they know the whole OS is at a point where it's probably inevitable that it will. Developers don't want to use Windows anymore. They all want to run Linux because servers do. Ballmer was right about one thing: It was about the developers. Microsoft can't compete with Chrome at the K-12 level. A Chromebook is a fraction…
> Developers don't want to use Windows anymore. I mean, did they ever? I've been programming just since ~2010, but I've only ever saw majority prefer macs due to hardware (with exception being late intel macs) and linux on the regular PCs. With exception of game devs, I've not seen person who _happily_ defaults to windows, not due to fact that they have to because of company policy or because company is too cheap for…
At the time Mac was still largely dominated by PowerPC and Classic OS. And Linux was still seen as an OS for hobbyists and universities. It was not taken seriously until well into the 00s and the 2.4 kernel. Sun was struggling with Java, and the unices were well into their decline from the 80s.
I would say that the transition was how much better Apache was than IIS when it came to operational and security issues.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#499Earlier quoted context omitted.
Wine is also the reason why Windows software has more longevity on Mac than Mac software. Like, 32-bit didn't get deprecated in Wine.
If enough people cared it seems like someone would have created a MacOS32 in MacOS64 like WoW64.
Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
#500Earlier quoted context omitted.
The Windows ecosystem does a lot of things that, to me, as a Linux/MacOS user, seem like a weird bunch of crazy decisions that are different just because. Whether that's true or not, it does mean that a lot of people who came up on Windows IT don't have a mental framework for how to run or manage Linux systems. Likewise, when I'm trying to diagnose something on Windows it just seems like the entire thing is a disaste…
> For example, when my Windows gaming machine comes out of hibernation my ethernet controller insists that there's no connection. I can't convince it otherwise except by disabling the device and re-enabling it. I can't figure out where I might find information that tells me why this is happening, so I just wrote a powershell script to turn it off and then on again. I bet some Windows IT dork could figure it out in 30…
This has always been my experience, going back I'd say at least to the early 2000s on cheap laptops, and all the way back to the earliest days of sleep and hibernate on desktops, where sleep just doesn't matter that much.
When I started dabbling in boot code around 2006, I read a bunch of the specs and one of them was ACPI, which I only scratched the surface of.
I think until then it had just not occurred to me that a modern paged protected OS would even want to call into any code supplied with the computer, vs. having it come from a driver disk, or be built in to the kernel where everyone can see it.
The whole idea of a bytecode interpreter running random code supplied by a fly-by-night system builder is a little unsettling.