Live data from Hacker News

Cross-compiling binaries for Windows is easier than building natively

gist.github.com

141–150 of 349 posts

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

#141

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

Not enough. Between path limits and "this file is in use by another program" nonsense I regularly ran into while developing on Windows, I switched away and never looked back.

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

#142
post #20

> Are derived community works, like say the D-language, Dart, or Zig bindings to the win32 API which are generated from those files open source - if Microsoft did not release them as such? Certainly. The source for these bindings is the WinMD file, which is MIT licensed. While it is true that its contents are generated wholly from non-FOSS sources, it doesn't impact end users of the metadata. Microsoft owns the origi…

Although it's a point of pride that someone did manage to get D understanding the recent Win32 API specification extremely quickly (D is ridiculously good at this kind of metaprogramming), the bindings that actually ship with D at the moment are hand-maintained.

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

#143

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

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…

> If you want to build binaries for a distro, build in that distro.

> Compiling on one distro and then expecting it to work on another distro is a foolhardy errand.

This is why Windows, with all its issues, is still relevant in 2022. I got tired of updating my distro and software stopping to work. If you are on happy walled garden land of the main repository you're fine. When you need some specialized software or something that is not being maintained anymore, good luck. And at the end of the day, people just want their work done.

This is why Windows with all bloat, advertising, tracking, security issues (no click RCE in 2022, wtf) STILL is going strong.

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

#144

Earlier quoted context omitted.

Statically link everything ? Including glibc?

> Including glibc? Any reasonable person doing this would use Musl of course.

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

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

#146
post #31
post #22

Earlier quoted context omitted.

Doesn't cargo-bundle do that? I haven't tried to use it to generate .msi files, only for iOS/macOS, but it has the feature!

Cargo-bundle was supposed to do that, but only the Mac part was completed. Nobody ever did the .msi output. I've been trying to get someone interested in doing that. That task needs someone very familiar with the Microsoft ecosystem, which I am not. Discussion in Rust tools forum here.[1] [1] https://internals.rust-lang.org/t/cross-platform-bundling/16...

I wonder if InnoSetup could be a good point of reference for anyone interested. It is in Delphi though, but there is also this guide I found whilst trying to figure out if you could run Inno Setup on Linux:

https://gist.github.com/amake/3e7194e5e61d0e1850bba144797fd7...

Inno Setup was the best and easiest thing for me to ever use but when I was building Windows installers for use from a Windows OS.

Update:

Found this Cargo package rust-msi:

https://github.com/mdsteele/rust-msi

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

#147
post #44
post #21

For me SDK sizes are showstopper. Mingw packages are probably 100-200 Mb total. To build anything native one has to install Windows (20+Gb in modern version and then Visual Studio 40+Gb). Not so easy to fit it all on an SSD drive. Xcode also have this problem now. 8Gb for Xcode 7 is manageable. But why 70Gb for Xcode 11?

I'm cross-compiling Mach engine[0] with Zig, it ends up being a quite small toolchain to cross-compile a game engine (using DirectX, Vulkan, OpenGL, and Metal on respective platforms) from any OS. The Zig toolchain is: * Windows: 61 MiB * Linux (x86): 49 MiB * macOS (x86): 42 MiB * macOS (arm): 38 MiB Zig provides almost everything that is needed to cross compile to those same targets out of the box, including libc a…

Zig's toolchain is awesome; I was very sad to discover they don't support my comfy, ancient MacBook Air.

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

#148

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.

giant blobs is a much faster solution than thousands of individual files. NTFS per-file overhead is significant.

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

#149
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 I've found aka.ms links, referenced in a current Microsoft help page (KB article?), that were broken...

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

#150

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

Yikes, 260 character path names can be a real pain. Please support sensible path names or at least tell me why you can't read or write to a file. Often you just get a "can't write to that file" error message, or worse, "forbidden" so you spend an hour trying to debug the mess that is folder permissions on windows.

I'm not going to convince you to change your tool chain, userbinator, but for the sake of the discussion: Once you have multiple projects going on, with multiple components, and then those components have a small directory structure themselves, you can easily reach 260 characters. Add to that, if theres data coming from another org, a long file name can be very helpful to keep track of what it is (and don't forget 10-12 characters for a date!). And finally, the nail in the coffin: most users don't think about path names, I struggle to get people to not put periods in their filenames which messes with some tooling, how am I going to convince the guy in finance who gave me this data that he should use short file names? Should I modify the file name and make it untracable?

ETA: The "if you have to ask you've messed up", I don't ask, I expect and then get annoyed it broke. I had 10,000 files collected into a folder. Why can every other program tell me the list of files in an instant but windows explorer crashes (the whole desktop environment) because I opened that folder to see it. I'm not meant to do that? Then why can the kernel, the disk, the file system, and all other programs handle it with ease?

Post reply on HN