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

231–240 of 349 posts

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

#231

Post by 5e92cb50239222b »

cube00 wrote: post #188
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 ~…

It's depressing how fast and responsive MSVC6 runs on today's hardware compared with the current version of Visual Studio.

It started after they ported UI to WPF. Compare VS2008 and VS2010 if you have the time. I remember using both on a cheap laptop when VS2010 first came out, and was simply incomparable.

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

#232

Post by [deleted] »

Animats wrote: post #31
ratww wrote: 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...

[deleted]

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

#233

Post by jcelerier »

josephcsible wrote: post #134
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 ~…

> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?

A quick Google check seems to yield only one CVE in msvcrt.dll in 2012, wouldn't call this "often" especially for a DLL which is likely among the top 5 most used in the world

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

#235

Post by fritigern »

behnamoh wrote: post #210
cpeterso wrote: post #190

Mozilla’s automated builds of Firefox for Windows, macOS, Linux, and Android are all cross-compiled on Linux VMs. Cross-compiling is faster and cheaper, especially because Windows’ file I/O and process launching is so slow.

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

NTFS is Windows' fault.

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

#236

Post by fritigern »

kretaceous wrote: post #182

I mostly agree on the VSCode part. They should put it up front in the README, homepage and maybe a info modal/badge whenever a user installs said extension. But genuinely asking, how else would you 'label' VSCode? "A free and open-source code editor with some optional components that are proprietary"?

I don't get why people like VSCode. I was a happy Atom user for years and found it to be superiour to VSCode in almost every way.

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

#237

Post by jeroenhd »

franga2000 wrote: post #220
pjmlp wrote: post #216

Earlier quoted context omitted.

Not every OS has to be a UNIX clone, we don't need an OS monoculture.

You don't need to implement POSIX in order to not bundle your header files in a 9 GB "SDK" download, which isn't available as a direct URL download and can't be installed without user interaction via the GUI. This is a Microsoft issue, not a Windows issue.

If MS would package just the header files, they'd probably get tons of complaints about compilers complaining about missing libraries, missing dependencies and toolsets not being available.

The Windows SDK is not just a few C++ headers and a bunch of lib files to link against. It has a huge surface area. The documentation and toolsets assumes all API calls from Windows 3.1 APIs to UWP to be available.

The SDK download (ISO format) is 1.1GB in size, requiring a total of 4GB of disk size to install (whether this includes the size of the installer itself is unclear). Big, but not unavoidably so, and you can pick and choose some features. It bundles debugging tools, the application identifier, a certification kit and MSI generation tools along with its headers (which seems fair to me); less than 1GB of extra kit on top of 1.8GB of headers and libraries you probably want as a Windows dev anyway. Just the headers won't leave you with a working dev environment even if you bring your own debugger.

Unlike what some developers seem to think, you don't actually need to download Visual Studio to get the SDK, you can also download it separately from the website [1]. Pick the ISO version and extract the CAB files yourself if you want to manually pick and choose your files.

The SDK ships as an installer but that just makes sense. Ubuntu ships their headers in DEB files as well, for example. You want to be able to add and remove these packages as you upgrade or downgrade your target API levels without having to manually set up a file system hierarchy.

As for non-GUI interaction: `WinSDKSetup.exe /quiet /ceip off /features DesktopCPPx64` will install only the necessary headers and libraries for x64 C(++) development in the default location without sharing data with Microsoft. Found this command line with `wine WinSDKSetup.exe /?`. You can also add, repair, and uninstall packages with the same installer.

[1]: https://developer.microsoft.com/en-us/windows/downloads/sdk-...

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

#238

Post by 5e92cb50239222b »

behnamoh wrote: post #213
a-dub wrote: post #189

Earlier quoted context omitted.

yeah the acceptance of oss is cool but they still ship a lot of weird software and technology... which is fine assuming you can avoid it... but sometimes you can't and then it becomes torturous.

Apple is worse in that regard. Is XCode open-source? Other than Darwin Kernel, is any part of macOS open-source? Did Apple even try to make Swift cross-platform? Is iCloud really comparable to OneDrive? How about Apple's locked and closed-source bootloaders?

Apple gets close to zero usage on desktops outside of the Silly Valley, has almost zero presence on servers, and it's trivial to avoid it (I haven't used their products for years (and very little before that), and personally know only a single macOS user). Windows — not so much. So when they put out yet another crappy technology, you may get tarnished one way or another.

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

#239

Post by jcelerier »

dataflow wrote: post #85
hacker_homie wrote: post #83

Earlier quoted context omitted.

Easy static link everything. I think you meant a GUI application that runs on a version of Linux older than yours.

Statically link everything ? Including glibc?

When trying to statically link everything, glibc is not as much a problem as GPU drivers are if you want binaries that work on more than one system

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

#240

Post by jcelerier »

AndyKelley wrote: post #137
password4321 wrote: post #129

Earlier quoted context omitted.

I was sad to find out "Zig supports only the last three macOS versions". No ncdu2 for me :( https://github.com/ziglang/zig/pull/10232#issue-1064864004

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
Post reply on HN