3 ms·

I actually remember the discussion on that. The reason 64-bit port didn't happen can be tracked to 1 key difference between Windows and Linux. On 64-bit Windows

I actually remember the discussion on that. The reason 64-bit port didn't happen can be tracked to 1 key difference between Windows and Linux. On 64-bit Windows, the sizeof(long) is 4, while on 64-bit Linux it is 8. While this looks superficial and has known workarounds like INT_PTR and intptr_t, it's a deal-breaker when you want to marry 2 huge codebases that aren't using these workarounds properly. Microsoft had enough resources to painstakingly go through massive amounts of existing code, catalogue the differences and eventually deliver WSL. A small enthusiast group behind CoLinux would never commit to anything like this, since it's hard to imagine a less rewarding and intellectually stimulating job.

temac 6y ago
While this is true that on Windows 64 the sizeof(long) is 4 while on 64-bit Linux it is 8, and while it may have been a problem for coLinux (I don't know how it was built, however I doubt it was with much MSVC anyway because the Linux codebase uses tons of GNUisms), and don't think it was very much relevant for WSL1 (they only had to implement the syscall APIs correctly), and probably even less so for the core of WSL2. WSL2 is basically a VM plus some integration bits (think kind of like your VMWare / Virtual Box integration tools) -- this may be tricky for the DirectX forwarding, but I'm not really following the recent devs and MS made it work already anyway (not upstream, but they have the code and they posted it on the LKML, so you can take a look at it) pretty much with a gigantic copy past of tons of data structures, so they somehow managed to handle that. And I suspect it was not even too hard anyway: identify from which universe comes a type, then identify where you need compat, and use an explicit size to setup the typedef, and it's ok. Windows typically uses uppercase defined types like LONG, and Linux does not do that, so it's hard to mix up unintentionally.
- john_moscow 6y ago
  OK, I've found the page [0] outlining the blockers. It's not a hard task, it's just extremely boring and repetitive, so open-source developers who are driven by fun, rather than tickets and deadlines, won't bother doing it. [0] https://colinux.fandom.com/wiki/Dashboard_for_developing_a_64_bit_coLinux https://colinux.fandom.com/wiki/Dashboard_for_developing_a_6...
  - temac 6y ago
    Oh I see the architecture, it make sense in their case to consider it an important issue depending on the surface area to audit and the amount of work it would take. The architecture of both WSL1 and 2 are different, and neither have this problem I think (maybe punctually in some very limited indirect fashion and easy to handle, but both were developed for 64-bits from the beginning so they obviously did not attempt to share the same struct between both world with bare 'long' in it)

temac 6y ago

While this is true that on Windows 64 the sizeof(long) is 4 while on 64-bit Linux it is 8, and while it may have been a problem for coLinux (I don't know how it was built, however I doubt it was with much MSVC anyway because the Linux codebase uses tons of GNUisms), and don't think it was very much relevant for WSL1 (they only had to implement the syscall APIs correctly), and probably even less so for the core of WSL2. WSL2 is basically a VM plus some integration bits (think kind of like your VMWare / Virtual Box integration tools) -- this may be tricky for the DirectX forwarding, but I'm not really following the recent devs and MS made it work already anyway (not upstream, but they have the code and they posted it on the LKML, so you can take a look at it) pretty much with a gigantic copy past of tons of data structures, so they somehow managed to handle that. And I suspect it was not even too hard anyway: identify from which universe comes a type, then identify where you need compat, and use an explicit size to setup the typedef, and it's ok. Windows typically uses uppercase defined types like LONG, and Linux does not do that, so it's hard to mix up unintentionally.

john_moscow 6y ago
OK, I've found the page [0] outlining the blockers. It's not a hard task, it's just extremely boring and repetitive, so open-source developers who are driven by fun, rather than tickets and deadlines, won't bother doing it. [0] https://colinux.fandom.com/wiki/Dashboard_for_developing_a_64_bit_coLinux https://colinux.fandom.com/wiki/Dashboard_for_developing_a_6...
- temac 6y ago
  Oh I see the architecture, it make sense in their case to consider it an important issue depending on the surface area to audit and the amount of work it would take. The architecture of both WSL1 and 2 are different, and neither have this problem I think (maybe punctually in some very limited indirect fashion and easy to handle, but both were developed for 64-bits from the beginning so they obviously did not attempt to share the same struct between both world with bare 'long' in it)