Live data from Hacker News

Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

xda-developers.com

491–500 of 512 posts

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#491

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…

There is also a port of Wine’s VDM back to Windows called otvdm or winevdm that is able to run 16-bit programs on Windows. It is surprisingly capable, I was able to run a 16-bit VB program that used a serial based optical modem without issue.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#492

Earlier 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.

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

#493
post #18

Earlier 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!

That will never happen.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#494

Earlier quoted context omitted.

The latest Xcode supports targeting back to macOS 11. This covers >99% of macs which is acceptable for most developers. https://developer.apple.com/support/xcode/

that leaves out every mac made before 2014

At less than 1% why does it matter?

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#495

Earlier 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…

That sounds almost as easy as just copying an .exe file from Windows and running it.

/s

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#497
post #442

Earlier 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.

I fully agree with that. Sadly there is always the odd application out there that uses the lower level stuff and is therefore tricky to get to run on Wine. Or more recent Windows versions for that matter.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#498

Earlier 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…

Yes, developers used to like Microsoft. That was where all the money was, and Visual Studio was an extremely good IDE in the late 90s and early 2000s. And at the time, Microsoft's documentation was the best. C++, VB, and then .Net development combined with Sql Server (then a budget option) was a very enticing stack. Using ASP instead of Perl or ColdFusion or PHP was also attractive.

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

#499

Earlier 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.

I'm guessing it'd be too much reverse-engineering. WoW64 was Microsoft themselves.

Re: Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains

#500

Earlier 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…

> Tbh, though, the only computer I've ever seen Hibernate work well on are Macs. Every x86 computer usually has some sort of issue with it, except for maybe business laptop models (eg HP's Elitebook line).

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.

Post reply on HN