Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

Post reply on HN
Print view View original

331–340 of 349 posts

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

#331

Post by pjmlp »

jeroenhd wrote: post #221
gizmo686 wrote: post #9

Earlier quoted context omitted.

The higher level thing to notice is that Windows is a second class platform for much of the software world. As such, it is in a position where it needs to bend the knee for compatibility with the dominant platform if they want it to be an active player in the larger ecosystem. In the case of symlinks, the hard part is already done, to the point where it is a toggle that has already been implemented, the UX of enablin…

Both soft links and hard links, as well as directory junctions, have been possible in Windows since Windows XP (though soft links have only been available since the release of Windows Vista 18 years ago). In fact, hard links are essential parts of Microsoft's solution to the DLL hell problem without wasting gigabytes of space. The problem people are running into is that the OS hasn't been designed with wild symlinks…

Even earlier, the Technet tools for it were introduced in Windows 2000.

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

#332

Post by pjmlp »

blibble wrote: post #138
eknkc wrote: post #78

Earlier quoted context omitted.

Microsoft always had great developer tech. And having access to that tech more freely (as in on other platforms, partially open source etc) is a significant plus for me. I loved .net back in 2003 or whatever. Then I never got to use it for years because I was on unix land. It is now open source and multi platform. They attacked open anything with all their might (and they were fucking mighty) and the enemy still flou…

> Microsoft always had great developer tech. when, exactly? in the 90s-2000s they were always a poor imitation of Borland's and from the 2010s to today JetBrain's tools blow them out of the water

Only for Java, for C++, .NET and GPGPU programming? Not really.

And even Java it is debatable, since JetBrains would rather sell CLion licenses than support some of the stuff Netbeans and Eclipse have been doing for 15 years regarding mixing Java and C++ development on the same source base.

When is InteliJ going to have an incremental Java compiler by the way?

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

#333

Post by faho »

criddell wrote: post #154
Arnavion wrote: post #118

Earlier quoted context omitted.

If you want to build binaries for a distro, build in that distro. If that distro has a Docker image, it's as simple as: docker run -v "$PWD:/src" olddistro:version /src/build.sh $dayjob supports distros as old as CentOS 7 and as new as Ubuntu 22.04 this way. Compiling on one distro and then expecting it to work on another distro is a foolhardy errand. Libraries have different versions, different paths (eg /usr/lib vs…

CentOS 7 is from 2014. That isn’t very old.

CentOS 7 may have been released in 2014, but the software it shipped was already quite old then.

As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9.

Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009).

[0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.

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

#335

Post by rurban »

forgotpwd16 wrote: post #286
rurban wrote: post #282

Earlier quoted context omitted.

Yes, but if you turn off inheritance perf goes up 10x. It's a policy, not the NTFS driver itself.

Can you provide links providing more info for those statements?

no, just try it out.

all my cygwin build rules contained turning off inherited perms to be able to compile bigger systems under an hour. e g. https://github.com/rurban/cygwin-rurban/blob/master/release/...

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

#336

Post by account42 »

Danieru wrote: post #251
trinovantes wrote: post #101

Earlier quoted context omitted.

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 g…

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

No, packing individual files into archives makes sense on PCs too due the native filesystem usually having a much bigger per-file storage overhead as well as non-negligible open() times - the second is especially true for Windows with "Anti Virus" software installed.

> You'll see older pc centric game engines use loose files.

Some maybe, but packing game assets into archives is as old as Doom and has been the norm all this time.

> Steam and EGS updating handles binary diffing wonderfully.

Steam handles binary diffin now, but it was not that long ago that it re-downloaded the whole changed file.

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

#337

Post by account42 »

colinfinck wrote: post #328
userbinator wrote: post #72

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 ~…

> 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 I share your view about the unmatched backwards compatibility of Win32 binaries, but I wouldn't let a 24-year old compiler like MSVC6 near any new proj…

That's really cool, was wondering how hard it would be to make libc++ play nice with XP - currently I still use MSVC 2017 for those builds but that won't get newer language features and I am planning to move to Clang anyway. Do you know of any effort to go even further back and support pre-NT Windows with a modern C++ compiler?

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

#338

Post by Animats »

giancarlostoro wrote: post #311
Animats wrote: post #202

Earlier quoted context omitted.

> Found this Cargo package rust-msi. I looked at that crate. That lets you read and write .msi files, but those are just containers. It doesn't help you set up the rather complicated contents required. Someone who's into the Windows ecosystem could probably use it to do the limited things cargo-bundler does. The neat thing about cargo-bundle is that it only needs the info from the Cargo.toml file to drive the bundlin…

Ah I see. Honestly if I knew Rust better I wouldnt mind taking a stab at the project but I am cozy with dotnet currently. I love building systems tools but very little work I apply for does just that. It is a shame companies dont invest more into R&D.

The Rust part of this isn't that hard. cargo bundler already has a place where the .msi output generator is supposed to go. The reading of the cargo.toml file and the writing in .msi format is already written. It's just generating the Microsoft-specific content for the .msi file that's hard. That takes Microsoft platform expertise.

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

#339

Post by BoorishBears »

dgfitz wrote: post #120
BoorishBears wrote: post #111

Earlier quoted context omitted.

... what? You think someone stretching their money for an SSD somehow indicates that they're not worried about their budget? Here's a hint: if they had the budget and availability they'd just get a bigger SSD and not write that comment. - Obviously , due to some aspect of their circumstance, be it availability, cost, download speeds, etc. the size of the toolkit is problematic. I mean there's no intrinsic size for a…

What I’m saying is the delta between a very cheap hdd and an ssd is 20 bucks. This whole assuming everyone is destitute is getting rather tiring.

It's strange that I'm repeatedly explaining you don't even have to be destitute for it to be a problem, but your mind can only latch onto "at the store I have access to with almost everything one could ever want in stock, the price delta is 'only' $20"

But yeah, seriously woe is you having to momentarily imagine some people are poor or have trouble getting access to tech.

I'm from Ghana so I guess it's not as onerous to imagine people don't live the exact same life I do in the US.

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

#340

Post by BoorishBears »

maccard wrote: post #254
BoorishBears wrote: post #90

Earlier quoted context omitted.

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 cal…

The forest for the trees wouldn't begin to cover half these responses.

Let me say it again, 60, 30, even 10GBs, is a lot when there's tooling from the same company, that still make similarly functional binaries, that took 342 MB.

You don't need to keep obsessing over "how dare this person with limited resources use an SSD!", like I said you run into similar issues with just downloading the stuff.

Again, forest for the trees.

-

Instead maybe you can sit back and just ask "why the bloat over time"?

And the reality is likely: "because no one optimized for it". Because for them lots of fast storage and internet speed are no problem

That line of reasoning maybe allows you to see things from a different prospective and break some assumptions about end users.

Isn't that more useful than browbeating some random for not having 30GB free on their SSD?

Post reply on HN