3 ms·

Wine is not an emulator, it is a compatibility layer for Windows system calls on a Unix-like platform. If something runs on wine, the performance overhead shoul

by ijlx 5y ago

Wine is not an emulator, it is a compatibility layer for Windows system calls on a Unix-like platform. If something runs on wine, the performance overhead should be unnoticeable/very small for the typical user.

chungy 5y ago
Ironically, it seems quite often that Wine runs apps/games faster than Windows does.
encryptluks2 5y ago
A compatibility layer wouldn't require that you essentially emulate the same file system layout, registry and functionality. It is basically emulating a Windows environment.
- anthk 5y ago
  So Windows 10 emulates Windows XP/2000/98 too?
  - encryptluks2 5y ago
    Pretty much... they took a pile of crap and kept adding onto it.
    - Dah00n 5y ago
      That has nothing in common with emulating though. Running ARM code in x64 is emulating. If adding code were emulating than Linux is emulating Linux v0.1. Wine isn't an emulator. PCSX2 is an emulator.
      - chungy 5y ago
        The word "emulate" is overloaded, but because there's often an assumption of ISA emulation, Wine for a time called itself "WINE Is Not an Emulator" to prevent said assumption. Taking "emulate" at its dictionary-definition, which is to imitate or copy, it's easy to argue that Wine is an emulator, because it copies and imitates the Windows ABI and API (the earliest versions of Wine even called itself a "WINdows Emulator"). They just happen to draw a hard line against emulating x86.
- samus 5y ago
  In many cases it is indeed not so simple: * Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on. * Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace. * The application might issue system calls that have different semantics, or that don't even exist on Linux. TA is significant because it paves the way to an efficient implementation of one of these system calls.
  - encryptluks2 5y ago
    > Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on. The application data in windows would not be the same as `/usr/` paths. It would be the equivalent of `~/.config` and `~/.local`. The last thing anyone in Linux would want is for Windows to start populating their system folders, let alone probably creating hundreds of top-level folders in their `~/.config` or `~/.local` directory. > Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace. The Windows registry is an atrocious monster that should have died already. You can rarely ever truly delete an app in Windows, as there will be sometimes hundreds of registry keys leftover. > TA is significant because it paves the way to an efficient implementation of one of these system calls. If there is mutual benefit outside of Windows, then sure why not. If it is built just for better Wine compatibility with Windows then I hope to see a rant by Linus telling them how ridiculous they are.
    - samus 5y ago
      Sorry, my bad here. Of course, only the binaries and static assets are stored in C:\Program Files. Your point is the perfect argument though for why Wine emulates a Windows file system hierarchy. I don't like the registry either. My `not too bad` refers to the effort required to support it. Wine should make it possible though give each application its own copy of the registry. This copy could be nuked along with the application when it is uninstalled. Linus doesn't like a lot of things. ZFS for example. It certainly sucks to maintain out-of-kernel patches, but if there is enough benefit, someone will do it. And it would be actually pretty sweet and ironic if Windows applications run faster on the Linux desktop than on Windows. Also, I am optimistic that futex2 will find many applications outside of Wine.

by ijlx 5y ago

chungy 5y ago

Ironically, it seems quite often that Wine runs apps/games faster than Windows does.

encryptluks2 5y ago

A compatibility layer wouldn't require that you essentially emulate the same file system layout, registry and functionality. It is basically emulating a Windows environment.

anthk 5y ago
So Windows 10 emulates Windows XP/2000/98 too?
- encryptluks2 5y ago
  Pretty much... they took a pile of crap and kept adding onto it.
  - Dah00n 5y ago
    That has nothing in common with emulating though. Running ARM code in x64 is emulating. If adding code were emulating than Linux is emulating Linux v0.1. Wine isn't an emulator. PCSX2 is an emulator.
    - chungy 5y ago
      The word "emulate" is overloaded, but because there's often an assumption of ISA emulation, Wine for a time called itself "WINE Is Not an Emulator" to prevent said assumption. Taking "emulate" at its dictionary-definition, which is to imitate or copy, it's easy to argue that Wine is an emulator, because it copies and imitates the Windows ABI and API (the earliest versions of Wine even called itself a "WINdows Emulator"). They just happen to draw a hard line against emulating x86.
samus 5y ago
In many cases it is indeed not so simple: * Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on. * Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace. * The application might issue system calls that have different semantics, or that don't even exist on Linux. TA is significant because it paves the way to an efficient implementation of one of these system calls.
- encryptluks2 5y ago
  > Most nontrivial Windows program would get very confused if exposed to a trivially mapped Unix filesystem. It's not so bad if every program would use environment variables to locate stuff, but you can't discount the possibility that some of them hardcode paths. Also, application data in Windows is usually kept in a common folder, while in Unix filesystems it is usually split across `/usr/bin`, `/usr/share`, `/usr/lib` and so on. The application data in windows would not be the same as `/usr/` paths. It would be the equivalent of `~/.config` and `~/.local`. The last thing anyone in Linux would want is for Windows to start populating their system folders, let alone probably creating hundreds of top-level folders in their `~/.config` or `~/.local` directory. > Many Windows applications store their configuration in the registry. That part is not too bad though; it should be completely doable in userspace. The Windows registry is an atrocious monster that should have died already. You can rarely ever truly delete an app in Windows, as there will be sometimes hundreds of registry keys leftover. > TA is significant because it paves the way to an efficient implementation of one of these system calls. If there is mutual benefit outside of Windows, then sure why not. If it is built just for better Wine compatibility with Windows then I hope to see a rant by Linus telling them how ridiculous they are.
  - samus 5y ago
    Sorry, my bad here. Of course, only the binaries and static assets are stored in C:\Program Files. Your point is the perfect argument though for why Wine emulates a Windows file system hierarchy. I don't like the registry either. My `not too bad` refers to the effort required to support it. Wine should make it possible though give each application its own copy of the registry. This copy could be nuked along with the application when it is uninstalled. Linus doesn't like a lot of things. ZFS for example. It certainly sucks to maintain out-of-kernel patches, but if there is enough benefit, someone will do it. And it would be actually pretty sweet and ironic if Windows applications run faster on the Linux desktop than on Windows. Also, I am optimistic that futex2 will find many applications outside of Wine.