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.
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.
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.
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)
On a tangential note, I must say that I do not quite appreciate this obsession with 64 bits, especially for "smaller" use cases, such as a PC for the "everyday" use. There's still plenty of perfectly usable machines sold with 4GB of RAM. Also, pointers are everywhere, and 64-bit ones take twice as much space, so the gain is not as big as one might think.
I still use an EeePC on a fairly regular basis, so I agree with your statement, but also I think that the desire to drop support for older platforms is itself a concession, that it's too hard to engineer software at an abstract enough level where ISA doesn't really matter. I understand that maybe fewer people are using those machines, but outside of some really platform-dependent code in the deeper parts of the kernel, how much should ISA really matter? Of course, in reality it does, in the sense that virtually nobody writes truly "portable" C code and instead encode all kinds of implicit assumptions about things, but that doesn't mean we should accept that or that the solution is to just bake those assumptions into the system as a whole and stop supporting architectures that violate those assumptions. Instead, supporting more architectures and finding more instances where implicit assumptions about hardware behavior are violated is actually beneficial to constructing a more abstract and easily-portable system, which incidentally can benefit all of the rest of the architectures as well.
A few years after the project was created, I was contacted occasionally by people who wanted to assist in developing a 64-bit port. This required the same technical depth in kernel hacking as recreating the thing, and quite a lot of work. Unfortunately I was occupied with other things and it never fell through. Also, hardware-assisted virtualization came about the same years and made the project somewhat obsolete. It was still very good for its time!
As reasons why the port never happened? I don't really know, but the sense I get is that it just got too hard to find and sustain the kind of developer interest it needed. Again, though, I don't really know; my familiarity with coLinux tops out at having been an enthusiastic user, and even that was quite a long time ago now.
As reasons for WSL to happen anyway? It's hard to know, despite my earlier glib comment that it would. It's plausible that a 64-bit coLinux might have found enough adoption to provide the same support for Microsoft's Windows strategy that WSL does, although coLinux's FOSS licensing model would certainly complicate that a lot - but, on the third hand, how much does it cost to convince a dev team it's time for an acquihire and a community fork? And how much is WSL or something like it worth to Microsoft, anyway? I know a fair number of devs who are glad to have it, but the next I meet who actually switched (or switched back) to Windows for it will be the first.
