upvote
> some of it will only ever run on linux servers.

I’ve spent quite a lot of time dealing with code that will ever run on Linux which did not in fact only ever run on Linux!

Obviously for hobby projects anyone can do what they want. But adult projects should support Windows imho and consider Windows support from the start. Cross-platform is super easy unless you choose to make it hard.

reply
> But adult projects should support Windows imho and consider Windows support from the start.

Hope whatever "adult" is working on the project this is getting paid handsomely. They'd certainly need to pay me big bucks to care about Windows support.

In any case, Linux system call ABI is becoming a lingua franca of systems programming. BSDs have implemented Linux system calls. Windows has straight up included Linux in the system. It looks like simply targeting Linux can easily result in a binary that actually does run anywhere.

reply
Try playing audio or displaying image on the screen using only documented syscalls. And make it work on all platforms you mentioned.
reply
Displaying an image on the screen is not that difficult a task. Linux has framebuffer device files. You open them, issue an ioctl to get metadata like screen geometry and color depth, then mmap the framebuffer as an array of pixels you can CPU render to. It's eerily similar to the way terminal applications work.

It's also possible to use Linux KMS/DRM without any user space libraries.

https://github.com/laxyyza/drmlist/

The problem with hardware accelerated rendering is much of the associated functionality is actually implemented in user space and therefore not part of the kernel. They unfortunately force the libc on us. One would have to reimplement things like Mesa in order to do this. Not impossible, just incredibly time consuming.

Things could have been organized in a way that makes this feasible. Example: SQLite. You can plug in your own memory allocation functions and VFS layer. I've been slowly porting the SQLite Unix VFS to freestanding Linux in order to use it in my freestanding applications.

reply
> Windows has straight up included Linux in the system. It looks like simply targeting Linux can easily result in a binary that actually does run anywhere.

Kind of. But not really. WSL2 is a thing. But most code isn’t running in WSL2 so if your thing “runs on windows” but requires running in a WSL2 context then oftentimes it might as well not exist.

> They'd certainly need to pay me big bucks to care about Windows support.

The great irony is that Windows is a much much much better and more pleasant dev environment. Linux is utterly miserable and it’s all modern programmers know. :(

reply
There is also WSL1 and Cygwin and MinGW/MSYS2.

And no WSL2 is not a newer version of WSL1, they are entirely different products.

reply
MinGW is awful. Avoid. Cygwin is honestly not really something that has come up in my career.

I don’t know why Linux people are so adamant to break their backs - and the backs of everyone around them - to try and do things TheLinuxWay. It’s weird. IMHo it’s far far far better and to take a “when in Rome” approach.

My experience is that Linux people are MUCH worse at refusing to take a When in Rome approach than the other way. The great tragedy is that the Linux way is not always the best way.

reply
I found MinGW to be quite nice, but ymmv.

> to try and do things TheLinuxWay

It's not really about TheLinuxWay. It's more that Microsoft completely lacks POSIX tools at all and the compiler needs to have a complete IDE installed, which I would need a license for, and the compiler invocation also doesn't really correspond to any other compiler.

reply
> Microsoft completely lacks POSIX tools

True!

> compiler needs to have a complete IDE installed

Not true. You can download just MSVC the toolchain sans IDE. Works great. https://stackoverflow.com/questions/76792904/how-to-install-...

> compiler invocation also doesn't really correspond to any other compiler

True. But you don’t have to use MSVC. You can just use Clang for everything.

Clang on Windows does typically use the Microsoft C++ standard library implementation. But that’s totally fine and won’t impact your invocation.

reply
But then I don't understand your complaints against MSYS2/MinGW. MSYS2 UCRT (the default environment) is a collection of POSIX tools and GCC to compile against the Microsoft C++ standard library. The only difference to what you tell me is completely fine is, that it uses GCC instead of Clang. Other MSYS2 environments are Clang instead of GCC.

MinGW is the open-source implementation of the Windows API, so that you can use the Microsoft C++ standard library, without needing to use the MS toolchain.

reply
Using MinGW and POSIX tools is trying to force a square Linux peg through a round Windows hole. You can try and force it if you want.

If you started with a native Windows-only project you would never use MinGW. Probably 0.01% of Windows projects use GCC.

Over the years I have come to associate “project uses MinGW” with “this probably take two days of my life to get running and I’m just going to hit hurdle after hurdle after hurdle”.

The whole Linux concept of a “dev environment” is kind of really bad and broken and is why everyone uses Docker or Linux or one of a dozen different mutually incompatible environments.

The actually correct thing to do is for projects to include their fucking dependencies so they JustWork without jumping through all these hoops.

reply
> Not true. You can download just MSVC the toolchain sans IDE. Works great.

How is the standalone MS build system called?

reply
The standalone IDE-less build tools comes with MsBuild.exe. So you just use that.
reply
I don't think we are talking about the same type of software? The type I was talking about will only ever run on Linux because it's a (HTTP-ish) server that will only ever run on Linux.

Probably a server that is only ever run by a single company on a single CPU type. That company will have complete control of the OS stack, so if it says no Windows, then no Windows has to be supported.

reply
I've worked on dozens of "adult" projects for 30 years, only 2 of which ever needed to run against the Win32 API, and only one of which ever ran on Windows. There's a whole world of people out there who don't care about Windows compatibility because it's usually not relevant to the work we do.
reply
deleted
reply