Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Wine works 101

werat.dev

Post reply on HN
Print view View original

91–100 of 188 posts

Re: How Wine works 101

#91

Post by monocasa »

lozenge wrote: post #89
rcoveson wrote: post #80

Earlier quoted context omitted.

If your plan is to maintain decades of backwards compatibility with software from thousands of third parties, it's going to involve maintaining some originally-undocumented behaviors that people exploited. That's what the wine developers got themselves into willingly, and it's what the Windows devs are increasingly shirking.

It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998? Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the chu…

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.

Re: How Wine works 101

#92

Post by gulerch »

One incredibly cool thing about Linux is you can install the qemu-user-static package and run binaries intended for other architectures. They install as new binfmt handlers. Got an executable that was compiled for ARM and want to run it on your X86 box? No problem, just go ahead and run it, - it'll be seamlessly emulated and, if needed, syscalls with architecture-specific quirks will be automatically translated to your host kernel (the rest being passed on verbatim). It's like the opposite and the complement of Wine, in a sense.

Re: How Wine works 101

#93

Post by nyanpasu64 »

How did you generate the screenshot of the Windows/Linux call stack? It seems to be running on Windows, from the GDI-style font rendering and Visual Studio-style appearance; is it Visual Studio or a custom program, and can you run the debugger on Linux?

Re: How Wine works 101

#95

Post by G3rn0ti »

> Wine has been in development for many years and came a long way.

And still my daughter can't play "Sims 4" on her Linux laptop ... not because of the game itself but because of EA's pathetic program starter "Origin". Even Steam's Proton environment stopped working.

So sad and frustrating.

Isn't there a way to play this game without "Origin"?

The mileage you get with Wine is highly dependent on the individual game.

Re: How Wine works 101

#96

Post by realjhol »

bee_rider wrote: post #55
haunter wrote: post #6

What I'm curious about (and probably there are some good write ups about this somewhere) that how come modern Linux and modern Wine is better to run old Windows applications than modern Windows (7 to some extent but mostly 10&11). Did MS "intentionally" "left behind" certain APIs and system calls to sacrifice it for some greater good? Like I use Windows every day and have no problems at all. And I use Linux every day…

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.

This something I'm currently working on - for both Msys2 and Cygwin.

https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-7/

There's a few low level issues to solve, but also theres bunch of patches around that never made it upstream that just need some love to get them up to standard.

At this point Msys2 installs, we can run bash and install software using pacman (- with workabouts for varies janky problems).

Re: How Wine works 101

#97

Post by Deukhoofd »

G3rn0ti wrote: post #95

> Wine has been in development for many years and came a long way. And still my daughter can't play "Sims 4" on her Linux laptop ... not because of the game itself but because of EA's pathetic program starter "Origin". Even Steam's Proton environment stopped working. So sad and frustrating. Isn't there a way to play this game without "Origin"? The mileage you get with Wine is highly dependent on the individual game.

I recommend checking out protondb.com, a lot of users have posted workarounds that allowed them to make Origin work.

Re: How Wine works 101

#98

Post by planede »

ChuckNorris89 wrote: post #83
monocasa wrote: post #67

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.

>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. Mate, I played Red Alert 2 off the original 1999(?) ISO last month on my Windows 11 installation. I had to copy some missing deprecated Direct Draw DLLs that don't ship with modern Windows anymore and everything worked. If you would have Googled the issue, you would have found tons of forum…

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

Re: How Wine works 101

#100

Post by messe »

monocasa wrote: post #91
lozenge wrote: post #89

Earlier quoted context omitted.

It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998? Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the chu…

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.
Post reply on HN