Hacker News Reader

Comment by Koshkin | Hacker News Reader

I am probably misreading this, but: what is the use case in which a Windows program must call a Unix library?

Every windows program has to (eventually) call a Linux library, since Wine emulates Windows on top of Linux.

Take for example "decoding an MP3 frame". A 32bit program calls a Windows API to decode an MP3 frame, that gets intercepted by Wine and forwarded to libmpg123. Since it's a 32bit program, you need (or needed, until now) the 32bit mpg123 library to handle the request.

So it's not a matter of a Windows program actually calling a Linux library, but rather Wine forwarding the function call

Forwarding 32bit calls to 64bit functions sounds simple, but it is incredibly complex. It might be simple for a function that only takes an int as argument, but on Windows, functions often take pointers to Windows structures, and those structures are often different between 32 and 64 bit. You have to translate them on-the-fly....

Wine emulates Windows APIs.

You would need something like qemu to do arm->x86-64 to do CPU emulation and then use WINE to run Windows programs on a Raspberry Pi.

https://github.com/ptitSeb/box64 can do it a little lighter than a full qemu VM

I think your comment went to the wrong post.

I know how Wine works, and in my example I explicitly said "API". And I don't think I ever said something about ARM or the RaspberryPi?

My point was to explicitly make it simple to understand, as most people don't know what thunks are, or trampolines, or the differences between protected mode and long mode. And yes, I called Wine an emulator, because that's what it is...

> Every windows program has to (eventually) call a Linux library, since Wine emulates Windows on top of Linux.

Obligatory reminder: Wine Is Not Emulator.

The word is overloaded and the implication that emulator means ISA emulation is why Wine for a time adopted that expansion. It still very much emulates the Windows ABI and API.

It's original name was "Windows Emulator", even, hence the abbreviation Wine.

WINE is implemented using Unix libraries underneath. And since it essentially supports and entire modern OS, there is quite a bit of depdencies. The wine package available in Arch Linux for example depends on 72 lib32-* packages. The majority of these are just 32 bit compiled versions of standard libraries that a user on x86_64 will have a native 64 bit version of already.

There's a lot of redundancy and obsolete stuff in the main repo Wine package. I maintain wine-stable and I have just 45 lib32 dependencies.

To compare:

Main repo wine: https://github.com/archlinux/svntogit-community/blob/abf380b...

AUR wine-stable: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wine-...

Please make a bug report about how we can improve the package if you have the time. I'll see that it's taken care of, then.

Wine itself did the calling in it's own dlls/exes.

Now there's a more clear split between the unix side and the windows side.

Of course! These "Windows programs" must indeed be Win32 DLLs provided by Wine. Thanks.

Think a second about how Wine implements Win32.

Reply on news.ycombinator.com