6 ms·

Cygwin is WINE in reverse. It provides POSIX APIs in a Windows DLL, and the implementation tries to map them immediately to Windows API calls. You should then b

Cygwin is WINE in reverse. It provides POSIX APIs in a Windows DLL, and the implementation tries to map them immediately to Windows API calls. You should then be able to take source written for Unix and you should be able to compile it and have it run on Windows. MinGW is a GNU toolchain for writing Windows-native software... that happens to be used quite often to compile Unixy non-Windows software, so they added MSYS which is derived from Cygwin and works like Cygwin (a DLL providing POSIX APIs implemented using Windows APIs), to make it easier to compile and run Unixy software unmodified. WSL is a VM that runs your choice of Linux kernel and distro as a guest OS, and adds integrations with the host system that make it seem much more native than it really is.

haolez 2y ago
This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.
- pjc50 2y ago
  WSL1 mapped Linux file API calls directly to NTFS file API calls. Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.
  - jandrese 2y ago
    Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.
    - heftig 2y ago
      Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
  - moomin 2y ago
    Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.
- mikepurvis 2y ago
  Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different. Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.
  - apatheticonion 2y ago
    but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM. For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux. A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need. The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage. WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.
    - amiga386 2y ago
      The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other. For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead. So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally. See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8
- emulio 2y ago
  > it was too complex to maintain and Microsoft decided to take the easy road. This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft. This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that
  - lproven 2y ago
    > both WSL1 and WSL2 continue to be developed I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022. So I have to call [[citation needed]] on that.
- wvenable 2y ago
  > but it was too complex to maintain and Microsoft decided to take the easy road. The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference. At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.
- lproven 2y ago
  > it was too complex to maintain Nah. It was fine. Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.
kevin_thibedeau 2y ago
WSL2 is a VM. WSL1 is Wine in reverse. They run ELF binaries compiled against the Linux ABI. Cygwin/Msys is a Posix compatability layer for PE binaries.
- ryao 2y ago
  I thought WSL1 implemented Linux's ABI in the NT kernel and uses a Linux userland. Wine reimplements the a Windows userland and emulates NT kernel services in userland. The two do not seem the same, although the intention of running Linux software on Windows is the opposite of the intention of letting UNIX system run Windows applications.
  - kevin_thibedeau 2y ago
    That's a byproduct of NT being designed from the start to have subsystems for alternate execution environments and was the path of least resistance. Conversely, it wouldn't be logical to make Wine tightly integrated into the Linux kernel when it had broader portability goals.
    - ryao 2y ago
      Interestingly, they recently pushed ntsync into the Linux kernel specifically for use by wine.
  - lproven 2y ago
    > I thought WSL1 implemented Linux's ABI in the NT kernel Yeah, I thought that too, and said so in an article. It would be the clean, logical, elegant way to do it and inline with the history of NT. I got angry denials from several Microsofties on Twitter! It isn't at all. WSL1 is an offshoot of the now-cancelled Android runtime for Windows. They wanted to run Android's JVM/Dalvik apps on Windows Mobile... but discovered more and more native OS calls. So, they ended up implementing 90% of a Linux kernel emulator in userland. Later, they made it standalone and complete enough to run a real Linux userland on top, and marketed it as a Linux runtime. It is tragic to me that senior MS execs are now proud of this approach and scolded me for thinking otherwise. My conclusion is that MS no longer has: • Any kernel engineers who really understand how NT works deep down; • Anyone skilled enough to modernise the NT kernel's POSIX personality to be Linux personality; • Anyone in authority who realises it ought to have these things; • Nobody left who feels shame at this.
nialv7 2y ago
Cygwin is not wine. Wine lets you run existing windows executables unmodified on Linux. Cygwin does not let you run ELFs on windows.
- amiga386 2y ago
  Good point, using wine as the interpreter for PE executables is another cool part of the WINE project. But it is the case that you can build a Windows application from source on Linux and link it with libwine, in the same way you can build a Unix program from source on Windows and link it with cygwin.dll -- I seem to remember some time ago CorelDRAW (or at least Corel Photo-Paint) was made available for Linux that way, officially supported by Corel.

haolez 2y ago

This is WSL2, right? I had the impression that WSL1 provided a better experience, but it was too complex to maintain and Microsoft decided to take the easy road.

pjc50 2y ago
WSL1 mapped Linux file API calls directly to NTFS file API calls. Unfortunately this was cripplingly slow for use in e.g. Git, so they moved to a model which is more of a VM.
- jandrese 2y ago
  Is this why Cygwin is such a dog at disk access? It seems like anytime a Cygwin binary needs to open a file it suffers from 100ms of stall.
  - heftig 2y ago
    Pretty much. AFAIK you're waiting for Windows Defender and other hooks to run.
- moomin 2y ago
  Yeah, WSL1 was a great idea but there were so many edge cases. e.g. allocating a gig of memory you’re not actually using is fast in Linux, not so on Windows.
mikepurvis 2y ago
Yes WSL2 is a mini-VM. Having used both, I don't think it's a slam dunk that 1 was better, really just different. Particularly for the more complex cases of container APIs, GPU access, desktop integration, etc. Those are solved problems in the VM space and reinventing new solutions at a slightly different layer is not necessarily wise or realistic.
- apatheticonion 2y ago
  but also WSL2 doesn't add anything of value to the development experience on Windows that wasn't already possible with a VM. For my use cases, I just want to target unix-like APIs and use bash-isms so I can reuse my build scripts and tooling. I don't really care if the binary format I consume or compile to is different to Linux - as long as my development experience is identical across MacOS, Windows and Linux. A thin layer on top of Windows that mimics Linux so I can run bash _properly_ is all I really need. The closest I've come is using Msys2 with zsh and uutils and it is so close but there are still cases where it simply doesn't work. WSL1 was pretty close but it falls short by needing remote development tools and having isolated storage/poor performance interacting with host storage. WSL2 is DOA for me, I just hand roll my own Linux VM and call it a day.
  - amiga386 2y ago
    The thinness is actually part of the problem. POSIX and Windows APIs don't work like each other. For example, if you were a Unix archiver extracting a file, you'd call stat() open() write() close() chmod() utimes(). On Linux/BSD that's 1 file open/close, but on Windows, that's 4 file opens/closes because the Windows APIs need an open filehandle, while the POSIX APIs take a filepath. Linux/BSD have LRU caches of filepath->inode because they're designed around these APIs, Windows doesn't. Cygwin has to open/close a Windows filehandle each time because it can't make the calling code pass a filehandle instead. So it may be more comfortable and familiar, but also Windows APIs are unsympathetic to code designed for Unix originally. See this talk on how the developers of rustup massively improved their performance on Windows by restructuring their code: https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8
emulio 2y ago
> it was too complex to maintain and Microsoft decided to take the easy road. This is a common confusion. WSL1 is not deprecated, and both WSL1 and WSL2 continue to be developed and supported in parallel by Microsoft. This is example of bad Microsoft marketing. Maybe they should have added a postfixes instead of numbers: "WSL-native" "WSL-VM" or something like that
- lproven 2y ago
  > both WSL1 and WSL2 continue to be developed I have had a 'Softie deny, in person to my face at the Ubuntu Summit, that any further development would occur on WSL1, in 2022. So I have to call [[citation needed]] on that.
wvenable 2y ago
> but it was too complex to maintain and Microsoft decided to take the easy road. The insurmountable problem was file system semantics. In Linux, files are dumb and fast. On Windows, files are smarter and therefore also slower. Linux applications expect dumb fast files and they produce a lot of them. Mapping Linux file system calls to Windows file system calls is doable but you can't overcome that difference. At that point, simply virtualizing the Linux kernel itself is an obvious better solution long term.
lproven 2y ago
> it was too complex to maintain Nah. It was fine. Filesystem access was slow. That meant that Git was slow. And every Linux techie thinks they're the next Torvalds and hacks on code and uses Git, so Git needed to work well.

kevin_thibedeau 2y ago

WSL2 is a VM. WSL1 is Wine in reverse. They run ELF binaries compiled against the Linux ABI. Cygwin/Msys is a Posix compatability layer for PE binaries.

ryao 2y ago
I thought WSL1 implemented Linux's ABI in the NT kernel and uses a Linux userland. Wine reimplements the a Windows userland and emulates NT kernel services in userland. The two do not seem the same, although the intention of running Linux software on Windows is the opposite of the intention of letting UNIX system run Windows applications.
- kevin_thibedeau 2y ago
  That's a byproduct of NT being designed from the start to have subsystems for alternate execution environments and was the path of least resistance. Conversely, it wouldn't be logical to make Wine tightly integrated into the Linux kernel when it had broader portability goals.
  - ryao 2y ago
    Interestingly, they recently pushed ntsync into the Linux kernel specifically for use by wine.
- lproven 2y ago
  > I thought WSL1 implemented Linux's ABI in the NT kernel Yeah, I thought that too, and said so in an article. It would be the clean, logical, elegant way to do it and inline with the history of NT. I got angry denials from several Microsofties on Twitter! It isn't at all. WSL1 is an offshoot of the now-cancelled Android runtime for Windows. They wanted to run Android's JVM/Dalvik apps on Windows Mobile... but discovered more and more native OS calls. So, they ended up implementing 90% of a Linux kernel emulator in userland. Later, they made it standalone and complete enough to run a real Linux userland on top, and marketed it as a Linux runtime. It is tragic to me that senior MS execs are now proud of this approach and scolded me for thinking otherwise. My conclusion is that MS no longer has: • Any kernel engineers who really understand how NT works deep down; • Anyone skilled enough to modernise the NT kernel's POSIX personality to be Linux personality; • Anyone in authority who realises it ought to have these things; • Nobody left who feels shame at this.

nialv7 2y ago

Cygwin is not wine. Wine lets you run existing windows executables unmodified on Linux. Cygwin does not let you run ELFs on windows.

amiga386 2y ago
Good point, using wine as the interpreter for PE executables is another cool part of the WINE project. But it is the case that you can build a Windows application from source on Linux and link it with libwine, in the same way you can build a Unix program from source on Windows and link it with cygwin.dll -- I seem to remember some time ago CorelDRAW (or at least Corel Photo-Paint) was made available for Linux that way, officially supported by Corel.