> Why not point the finger at Windows? Development on Windows is archaic.
How so? Zig is a programming language, so I'm guessing the main interactions it needs with the OS are file IO. It shouldn't need to do any GUI work as long as it provides proper bindings to the C functions. And file IO is essentially cross platform in C++ as long as you use the stdlib. Threads are also essentially multiplatform if you're using the stdlib. I also don't know if Zig is written in C, C++, or Zig so it may differ.
Generating binaries is different, but I wouldn't consider windows binaries any more archaic than Mac or Linux binaries, and I'm not sure if zig already uses LLVM backend or something anyways.
But given all that, writing basic Win32 code to do file IO or any sort of OS level interactions isn't any less archaic than what I've had to do in Linux. It's an API, and it's got a lot of cruft built up over the years, but so does any sort of Linux OS API.
Here's the Linux API for creating a file[0] and here's windows[1]. There's more parameters for the Win32 version, but the documentation is solid and gives a lot of tangential information. I actually prefer the Win32 docs to a lot of the Linux docs that I've used because they describe all the details very explicitly. So I wouldn't call Windows any more archaic then any other OS.
Basically what I'm saying is, it takes like 2-3 hours at most to add Windows support to a programming language unless you've architected your code in a way that tangles OS operations with regular operations. It's really not that hard to keep OS code separate from the apps logic to make porting the app to different operating systems trivial.
This is all that it took me to port a fairly sizeable code base to Linux[0]. This commit allowed me to run the app with the only problem being some font issues that I needed to fix by modifying how I used a library.
The total:
> Showing 26 changed files with 255 additions and 90 deletions.
If you architect your code well, porting between different systems shouldn't take anymore than a few hours ;)
Edit: I just looked through the diff and remembered that the bulk of these changes was fixing warnings that surfaced from using a different compiler.
The actual code that I changed necessary to get this running on Linux was in File.cpp and consisted of 124 lines of code. Going the other way (from Linux to windows) would have been just as simple, I just would have added the code in the __WIN32__ macro block instead of the code in the __linux__ macro block.
It really isn't that much different though. After skimming through the source code of Zig, you can see that well over 90% of the code is OS independent.
Not only that, it looks like they do have windows support and it's just failing atm. It also looks like they have cleanly separated all OS functionality from the logic. This is where it looks like the majority of the OS dependent code lives[0], and the implementation for this is 1000 lines of code. So clearly, it looks like it shouldn't take more than a few hours to get even a programming language up and running when porting it.
Further, it looks like they're using the cpp stdlib to assist with some OS dependent functions[1]. They're clearly using at least:
* std filesystem
* std future
* std iostream
* std mutex
* std thread
* std atomic
And more. So if you're being smart about things, which it looks like the developers most certainly are, then you don't need to reinvent 90% of the OS dependent code and can instead use the stdlib that already exists to automagically get that functionality.