Coordinate porting to Windows

[straight-shoota]

UPDATE 2023-04-24:

All the main platform features for Windows are finished! 🚀

There are still some smaller stories pending. Project board: Windows Support (view)

You can support the ongoing development financially: Windows suppport project on Open Collective.

UPDATE 2021-11-18:

By now, the compiler works pretty well on windows and most of the standard library has been ported as well. Besides a couple other smaller missing pieces, the major gap is in concurrency-related features held back by the missing event loop implementation.

---

With #5339 being merged, the first step of bringing Crystal to Windows has been accomplished!
With current master branch it is possible to cross-compile and run simple programs (alá Hello, World!) on native Windows.

Obviously we're still far away from porting the compiler or entire standard library to windows. This issue is supposed to coordinate and keep track of ongoing efforts to add support for more and more of the crystal standard library.

TODO

The primary focus should be on the core library (somewhat odered by priority):

• File descriptors "hello world" windows port #5339
• GC "hello world" windows port #5339
• Errno "hello world" windows port #5339
• Basic Exceptions "hello world" windows port #5339
• Regex "hello world" windows port #5339
• Random Implement Crystal::System::Random for win32 #5539
• Time Implement Crystal::System::Time for win32 #5422
• Raising Support exception handling on windows #6419
• File Implement File and Dir for win32 #5623
• Dir Implement File and Dir for win32 #5623
• ENV Extract platform-specifics from ENV to Crystal::System::Env and implement for win32 #6333
• Fibers Implement fibers for win32 #7995
• Event loop Windows: Event loop based on IOCP #12149
• Signal Port signals to Windows #7339
• Mutex Enable Mutex on Windows #12213
• Sockets Porting Socket to win32 #10696
• Process
• Backtraces Support call stacks on Windows #11461
• Iconv (Support custom encodings on Windows through GNU libiconv #11480)
• System Implement System for Win32 #6972
• Threads (Implement multithreading primitives on Windows #11647)
• Compiler Bootstrapping compiler on Windows (tracking bug) #9032

And of course a CI infrastructure once specs are running on windows.

Proceedings

The general course of action is to extract platform-specific implementations and then add the implementation for win32 platform.

A lot of work has already been done in #3582 but it needs to be updated and chopped into smaller pieces of changes.

The first goal should probably be to get specs running on windows to be able to verify the windows implementations. Essential for this are as far as I can see file, dir, exceptions (backtrace!), process and signal.

If you want to help with that effort, or want to "take" a piece of that work to work on, please comment below.

Useful References

• Wiki page Porting to Windows
• Support Windows as a first class platform (note: not WSL or emulation) #26 Support Windows as a first class platform (note: not WSL or emulation)
• [WIP] Windows #3582 [WIP] Windows by @lbguilherme
• "hello world" windows port #5339 "hello world" windows port by @RX14
• Win: define Win32 API functions #4832 Win: define Win32 API functions by @txe
• Remove c/winapi and rename some windows types #5448 Remove c/winapi and rename some windows types (some pieces from removed c/winapi can be salvaged for implementations)

Please feel free to add and edit this post as appropriate (core team).

[RX14]

@straight-shoota that's a good point. We need to figure out the basics of getting a blank spec suite working on windows (we should do this first without unwind support, just the raise==exit we have now). Then we need to create some kind of win32_spec.cr which requires only the parts of spec/std that work. I'll take on this task (tomorrow).

[RX14]

Another area of priority is looking at c168035 and working out ways of reducing that stubbing. For example: get iconv working so we can remove the stubbing in src/io/encoding.cr. The modified parts of the corelib are actually I think worth focus much more than the missing parts (for now).

[straight-shoota]

A very basic working spec shouldn't be too hard I think. I've tried it earlier to figure out what might be needed for that. It seems to be missing mostly some basic file and dir methods. After disabling all feature options I even got a simple spec to compile, allthough it resulted a LLVM error at codegen.

[s5bug]

I'll take Fibers, I'll be able to start work on them after January 2nd.

[RX14]

@straight-shoota looks like my spec PR has turned into a Dir PR first.

[RX14]

Also of importance: deciding what to do about windows's UTF-16 use. There should definitely be a really quick and easy way of going between String -> UTF-16 WCHAR* and the reverse. We should also have a policy of no A functions, only W functions even this early in the port.

This is an important issue: we shouldn't rely on iconv for this (I presume it's slow for small strings, and we don't have it in windows anyway). We need to write UTF-16 infrastructure for all platforms first.

[RX14]

Good news: spec compiles and works on my fork.

Bad news: it only works sometimes.

From this spec failure, looks like we have a codegen or ABI bug somewhere:

[RX14]

Here's my branch porting spec: https://github.com/RX14/crystal/commits/feature/windows-spec

I'll turn "Remove c/winbase" and "Add Crystal::System::Dir" into PRs.

[RX14]

Another idea before I forget it:

Consolidate all stubbing out into one huge windows_stubs.cr file so that we can keep track of them all.

[straight-shoota]

You mean to remove winapi.cr, not winbase.
And this commit should also rename DWord.