Live data from Hacker News

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

251–260 of 349 posts

Re: Cross-compiling binaries for Windows is easier than building natively

#251

Only if you want to be trendchasing rather than letting backwards compatibility take care of itself... I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes Long file paths: Azure, OpenSearch, and ~90 other open source projects have to document how to enable long file paths on Windows because the default is a ~…

The 260 path limit is a pain for organizing media. It's not surprising most applications/games store their media in giant blobs instead of just individual files. This makes software updates a pain since it requires users to download the entire blob if you can't diff the blobs or if the diff corrupts the blob due to mismatched implementation versions.

Mostly blob based game assets is a system motivated by consoles, then reused on pc to keep build process consistent.

You'll see older pc centric game engines use loose files. With the advent of ssds on consoles we might see a return to bunch of files approach as it keeps patches smaller.

Steam and EGS updating handles binary diffing wonderfully. While consoles, not so much. Specifics are NDA of course but I bet any game dev reading will know who I am talking about when I say: "platform x has a horrible diffing algo yet requires approvals for updates over size Y". If I could ship a loose filesystem and get reasonable load times I would just for the update package advantage.

Re: Cross-compiling binaries for Windows is easier than building natively

#252
post #80

Earlier quoted context omitted.

If you toggle that response to "All Respondents" instead of "Professional Developers" Windows goes up to 45%. Plus, 3% of users are using windows subsystem for Linux. So 48%. Whereas Mac and Linux are both at 25%. Even for developers, Windows is still the clear majority.

Interesting. So 50% Unix and 48% Windows (and 3% are targeting Unix anyway). That's quite a swing over the past 20 years - there was a time where aside the occasional web developer with a Mac, everyone was on Windows. Leaving out Linux, the interesting part has been how much market that Apple has chiseled away.

Cloud workloads mean UNIX has effectively won the server room for classical deployments, however UNIX !== Developer.

There are plenty of other workloads and platforms to target.

Desktop, mobile devices, IoT, medical, game consoles, infotainment, unikernel, serverless....

Re: Cross-compiling binaries for Windows is easier than building natively

#253

Earlier quoted context omitted.

Apple only supports the last three macOS versions too, so if you're on an older one than that you are not getting security vulnerability patches.

Go tell that to the schools I have to ship software to which can't upgrade past 10.13 because their Macs are too old but they don't get enough budget to buy new ones

Maybe they shouldn't have buy Macs in the first place.

Re: Cross-compiling binaries for Windows is easier than building natively

#254
post #81

Earlier quoted context omitted.

The visual studio build tools are substantially smaller than 40GB. My IDE install is about 25GB, and visual studio has distributed the build tools separately since vs2015 - my toolchains directory is about 4GB including whatever dotnet runtimes, windows GDK. > Not so easy to fit it all on an SSD drive. Professionally, no excuse. As an open source or otherwise unpaid pursuit, a 250GB SSD is about $45 on Amazon right n…

It's interesting how people assume that their world is everyone else's... It's easy to forget that there are billions of people for whom $45 is a massive investment, and that SSD isn't so conveniently available even if they have the money. I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was…

> it's easy to forget that there are billions of people for whom $45 is a massive investment, and that SSD isn't so conveniently available even if they have the money.

So those people can use whatever hardware they have available to them and not buy the SSD. The parent specifically said it was hard to fit on an SSD, so I assumed they could buy one based on that

> I know I got into programming on a mix of graphing calculators and thrown out PCs, and I also distinctly remember having to work around the download sizes of tooling because I was using really crappy internet.

Graphing calculators, and raspberry PIs (and other various low power devices) are still widely available for people to learn and experiment with. Internet speeds are still a problem in many places but ay some point the software has to be delivered to you, and as I mentioned previously the actually install sizes are not 60GB, and the downloads are significantly smaller (a windows 10 iso fits on a 4GB usb)

> without 60GBs of downloading and storage...

Firstly, it's not 60GB - see my previous post about how much space it actually takes up. It's closer to 30GB. Secondly, if you don't have 30GB of storage of any kind available to you on a computing device,then sure, meanwhile anyone running a machine bought in the last 15 years will have that space available to them.

Re: Cross-compiling binaries for Windows is easier than building natively

#255

Earlier quoted context omitted.

And then you discover your program can't resolve hostnames because "DNS responses shouldn't be that big".

Can you explain how musl is related to this DNS resolving problem?

https://news.ycombinator.com/item?id=28312935

Re: Cross-compiling binaries for Windows is easier than building natively

#256
post #81

Earlier quoted context omitted.

The visual studio build tools are substantially smaller than 40GB. My IDE install is about 25GB, and visual studio has distributed the build tools separately since vs2015 - my toolchains directory is about 4GB including whatever dotnet runtimes, windows GDK. > Not so easy to fit it all on an SSD drive. Professionally, no excuse. As an open source or otherwise unpaid pursuit, a 250GB SSD is about $45 on Amazon right n…

*>My IDE install is about 25GB Would love to see a breakdown of where that space is going. FWIW IntelliJ takes up 2.5GB, and honestly, even THAT seems like a lot to me.

I have no idea sorry! On the Jetbrains front that's interesting. My Intellij folder is closer to 4GB, but that's only for one language. I've also got Rider and Goland installed, and Jetbrains duplicates the entire install per IDE. My Jetbrains folder is 12GB.

> even THAT seems like a lot to me.

That's a little silly - what is an acceptable amount in that case. The JDK on its own is about 700MB (that's a guesstimate based on last time I installed it sorry).

Re: Cross-compiling binaries for Windows is easier than building natively

#257
post #253

Earlier quoted context omitted.

Go tell that to the schools I have to ship software to which can't upgrade past 10.13 because their Macs are too old but they don't get enough budget to buy new ones

Maybe they shouldn't have buy Macs in the first place.

anything else is a hard sell for art schools sadly, especially in 2010

Re: Cross-compiling binaries for Windows is easier than building natively

#258
post #140
post #94

Earlier quoted context omitted.

WiX is great. I have been using it for over a decade to package an internal application. It's all driven by a simple text file which I liked over Microsoft's packaging offerings.

It's another example where the free tools are better than Microsoft's.

Except it's also Microsoft's.

Re: Cross-compiling binaries for Windows is easier than building natively

#259
post #128

I’m surprised Qt hasn’t been mentioned yet for c/c++. You can get qtcreator and mingw baked in for the cost of a couple GB, and it “just works” even if you aren’t using the qt framework. I much prefer qtcreator to visual studio anyways. I suppose this breaks down for the use cases that aren’t c/c++ though.

Sadly Qt ships MinGW 8.1 which is positively ancient (released in 2018). If you're starting a new project (which you likely are if you are installing an IDE aha) there's no reason not to go for more recent compilers - msys2 has GCC12 (https://packages.msys2.org/package/mingw-w64-x86_64-gcc) and Clang 14 (https://packages.msys2.org/package/mingw-w64-x86_64-clang) which just work better overall, have much more complete C++20 support, have less bugs, better compile times (especially clang with the various PCH options that appeared in the last few versions), better static analysis, etc.

Personally I use https://github.com/mstorsjo/llvm-mingw's releases directly which does not require MSYS but that's because I recompile all my libraries with specific options - if the MSYS libs as they are built are good for you there's no reason not to use them.

Re: Cross-compiling binaries for Windows is easier than building natively

#260
post #226

Earlier quoted context omitted.

> Windows’ file I/O and process launching is so slow. It's not Windows' fault, rather it's NTFS.

Rather it's their baroque ACL permission system, which is not able to cache inherited perms.

The ACL permission system is in NTFS. For example FAT32 doesn't have it.
Post reply on HN