I haven't seen the inside of either project, but Wine seems like a much more difficult system. Cygwin is able to port large amounts of their stack from existing software (mostly gnu), whereas Wine needs to reimplement almost the entire stack. Furthermore, Wine needs to maintain binary compatibility whereas Cygwin only attempts source code compatability.
Win32 is a much, MUCH larger beast than POSIX. POSIX is a fairly small specification compared to Win32. A lot of the useful stuff on Unices is vendor-specific, but a lot of software is written with portability in mind so not a lot of them require vendor-specific APIs.
Countrary to Windows. You wouldn't believe the enormous amounts of stuff that Windows has, and apps rely on almost everything they can rely on. COM is huge. DCOM is huge. DirectX is huge. The list goes on and on.
Really, that's my answer. Win32 is Raymond Chen Land, Fear and Loathing With Backwards Compatibility. SimCity relied on internal details of how the kernel managed memory such that it reused memory it had already freed and they kept it working. MSFT modified the Windows kernel to avoid breaking it.
Torvalds is Chen-like in his adamance that the kernel can't break userspace, but Torvalds never had to deal with Windows 95 and the strange MS-DOS-derived world it inhabited. Linux never had to deal with 16-bit x86 code, so it was always able to keep its internals private, limiting the random stuff user programs could end up relying on. Win32 offers no such consolations.
I'd implement POSIX on top of Win32 any day to avoid the alternative, with the caveat that some things are flatly impossible and some things are possible but will never be efficient.
> Can someone actually explain to me what Cygwin does internally? Doesn't Windows already implement POSIX?.
Used to. Subsystem for UNIX Applications is now deprecated.
Cygwin runs on top of Win32, and its library functions call into Win32. Thus, it is strictly a compatibility layer.
Whereas SUA runs alongside Win32 and does not depend on Win32 APIs. Thus, it is theoretically a replacement for Win32, for people who wanted to run a UNIX environment on top of the NT kernel. Practically, however, it was used primarily for application porting.
