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

301–310 of 349 posts

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

#301

Post by MikusR »

tialaramex wrote: post #91
akelly wrote: post #77

Earlier quoted context omitted.

It's incredibly fitting that all the links on that post are 403 Forbidden

Microsoft has never really "got" the idea of URLs. The only links to Microsoft stuff you should expect to still work properly in a year from learning them are in the form of an aka.ms alias which is publicly advertised . Anything else, maybe it's a brief article explaining a technology you care about, next week somebody replaces that with a video blog of some people who don't really know much about it but are sure th…

And even there they deleted all the comments.

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

#302

Post by maccard »

javajosh wrote: post #287
maccard wrote: post #256

Earlier quoted context omitted.

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

We are two wealthy people arguing over rents, with you saying $1M/month is reasonable, I'm saying it's not, I'm only paying $100k/month, meanwhile most of the world is paying on average $100/month. 25GB is enormous. 2.5GB is enormous. Consider that the core value of this software is text editing . Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all (e.g. the…

It's not a text editor. It's an IDE, with built in development environments, SDKs, deployment tools. Debug symbols for native binaries are often 2-4x the size of the binaries themselves.

> Consider that not long ago people were buying PCs with perhaps 10MB of hard disk - or even no hard disk at all

Not that long ago in history, but an absolute eternity ago in computing terms. I have a direct internet connection to my home that is faster than the read write speeds of those computers.

> Consider that with a thoughtful use of resources and an eye toward minimizing attack surface

Attack surfaces have changed significantly since people were buying 10MB hard drives - you cannot write applications with the same security considerations from that time.

> you can put a fully functional http/s app server in a 1.9MB package (redbean). The space is cheap, yes, but the attack surface is not.

Firstly, redbean is the absolute extreme example of minimalism and portability. It's not "normal" it's an incredible feat of engineering frankly. Nginx isn't much bigger (~5mb) and caddy is bigger but still small (30Mb). The big difference between these and IDEs is that web servers dont provide client interfaces. For user facing tools they rely on web browsers to render html and interpret JS, so to make a comparison it's only fair to compare redbean + chrome to a Windows SDK install for example.

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

#303

Post by pxc »

espenwa wrote: post #246
pxc wrote: post #222

Earlier quoted context omitted.

There's some documentation on this in some WSL issues on GitHub, but it's not just NTFS. It's stuff like the broader filesystem architecture's inclusion of pluggable 'filters' (kinda neat, but each layer of them incurs a performance cost) or the way commands on other operating systems depend on caches for certain syscalls that Windows doesn't keep, or keep anything equivalent to. Too tired to go find them atm

This one? I remember it as an earnest description of the difficulties the WSL team had with the speed of NTFS - and I think it was one of the reasons for the switch to virtualisation in WSL2. https://github.com/Microsoft/WSL/issues/873#issuecomment-425... >

Yeah, that's the GitHub comment, thank you!

My takeaway from that comment is that there are some important performances issues that apply generally to all filesystems on Windows. Maybe we can partially test whether that's the case by playing with WSL1 on ReFS, ExFAT (if that's even supported, with its limited permissions support, or ZFS, once OpenZFS on Windows stabilizes a bit.

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

#304

Post by moogly »

codedokode wrote: post #217

The post mentions CRLF line end syntax, I don't understand why anyone should bother with it. Use \n only, it works everywhere including Windows. Any modern IDE can handle Unix line endings. The same about file paths, use forward slash (/) everywhere and don't waste your time supporting DOS era standards. I think the core.autocrlf option in Git is more harmful than useful (for example, it can change file hashes and br…

Agreed.

  autocrlf = input
Then change your editors and IDEs to save files with LF line endings (preferably with something like .editorconfig) and you'll have fewer problems.

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

#305

Post by naikrovek »

denimnerd42 wrote: post #192
naikrovek wrote: post #180

Earlier quoted context omitted.

they knew they would and they advertised that fact, and made blog and content owners migrate their stuff if they wanted it kept. many chose not to. those are the people you should be angry with.

that's quite a take.. expecting previous article writers to manually migrate their stuff is just as good as killing it.

the blog authors knew the content was their own responsibility going in.

"quite a take" f u

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

#306

Post by Dylan16807 »

pjmlp wrote: post #247
Dylan16807 wrote: post #219

Earlier quoted context omitted.

Even if we pretend that's a symlink, it only works for directories, not files.

We moved from Windows doesn't do it, it does but isn't available to non admins, it is but non admins can't do files,.... Yep.

We started at "not supported", talking about making symlinks inside projects.

We backed off to "not supported on normal systems", which is a reasonable change to me.

You mentioning junctions is not even close to a solution, and I am not moving the goalposts. If junctions worked, the complaint wouldn't have been needed from the start. No, this is about actual symlinks, not a similar feature that can do 5% of what symlinks can do.

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

#307

Post by int_19h »

jeroenhd wrote: post #275
int_19h wrote: post #269

Earlier quoted context omitted.

"Statically link or bundle everything" is how most Windows apps deal with this tho. So if we're comparing Windows and Linux, and saying that Linux packaging is worse, this method can't just be dismissed on security grounds.

Windows developers tend to stuff directories full of DLLs if they need to ship dependencies, they're not statically linked per se. Regardless, it's incredibly complicated to compare linking behaviour between Windows and Linux. Windows has tons of components built into the API (and which is maintained by Microsoft) which you'd need an external dependency for in Linux. Microsoft provides interfaces for things like XML…

Hence "... or bundle everything". But what difference does it make from the security perspective? If the app ships its own copy of the DLL, it still needs to do security updates for it - the OS won't.

As far as the OS offering more - it's true, but not to the extent you describe. For example, Windows does offer UI (Win32), but most apps use a third-party toolkit on top of that. Windows does offer MSXML, but it's so dated you'd be hard-pressed to find anything written in the past decade that uses it. And so on, and so forth. I just went and did a search for Qt*.DLL in my Program Files, and it looks like there's a dozen apps that bundle it, including even Microsoft's own OneDrive (which has a full set including QML!).

Even with .NET, the most recent version bundled with Windows is .NET Framework 4.8, which is already legacy by this point - if you want .NET 5+, the standard approach is to package it with your app.

And then there's Electron, which is probably the most popular framework for new desktop apps on any platform including Windows - and it is, of course, bundled.

"Some application code and maybe a few proprietary DLLs" is how things were back in 00s, but it hasn't been true for a while now.

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

#308

Post by seba_dos1 »

exDM69 wrote: post #265
Animats wrote: post #14

It is. I generate the Windows executables for a program by cross-compiling Rust on Linux. Then test with Wine. The Rust crates are cross-platform enough that I don't have to special case platforms. This is easier than having a Windows machine. The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. If you dump the legacy OS stuff, it gets easier.

I also cross compile and remote debug windows software on Linux (C and Rust programs). Using gdbserver --multi (extended remote mode) is quite comfortable. The biggest advantage is not having to use different tools for different target platforms. Unfortunately MacOS is more difficult target than Windows. If anyone has tips for compiling and debugging software of MacOS from a Linux host, please do share.

For compiling, I'm pretty happy with https://github.com/tpoechtrager/osxcross.

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

#309

Post by seba_dos1 »

dataflow wrote: post #71

Now try building a "portable" binary that runs on a version of Linux older than yours.

Not that hard. Since it's not a use case that most GNU/Linux software needs to be concerned about it's easy to make mistakes and resources are scarce, but once you know what you're doing it's usually not a big deal (maybe except of some specific edge cases). There's lots of old games on Steam that still work on modern distros and new games that work on older ones (and, of course, there's a lot of them that's broken too - but these days it takes only a few clicks to simply run them in a container and call it a day).

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

#310

Post by nickelpro »

seba_dos1 wrote: post #309
dataflow wrote: post #71

Now try building a "portable" binary that runs on a version of Linux older than yours.

Not that hard. Since it's not a use case that most GNU/Linux software needs to be concerned about it's easy to make mistakes and resources are scarce, but once you know what you're doing it's usually not a big deal (maybe except of some specific edge cases). There's lots of old games on Steam that still work on modern distros and new games that work on older ones (and, of course, there's a lot of them that's broken t…

It's very hard. Incompatible glibc ABIs make this nigh impossible, there's a reason Steam installs a vcredistributable.dll for pretty much every game on Windows. On Linux Steam distributes an entire runtime environment based on an ancient Ubuntu release exactly to circumvent this problem.

Look no further than the hoops you need jump through to distribute a Linux binary on PyPI [1]. Despite tons of engineering effort, and lots of hoop jumping from packagers, getting a non-trivial binary to run across all distros is still considered functionally impossible.

[1]: https://github.com/pypa/manylinux

Post reply on HN