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

321–330 of 349 posts

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

#321

Post by switchbak »

navjack27 wrote: post #205
downut wrote: post #87

Earlier quoted context omitted.

Yeah, given the sheer cpu/ram/m.2 power of what even a tiny NUC provides, with modular, replaceable monitor(s)/keyboard/mouse/USB(3/C/Thunderbolt)/HDMI etc, for less than a Mac, I am unable to understand the appeal of a laptop. And I use a i7/64GB/1TB NUC for traveling! I use a twice as powerful Ryzen rack server for my office dev box. 5m extension cables so the noise is in a closet. I have no problems with external…

I got the cheapest M1 Mac Mini when it came out. I got two m.2 NVME drives hooked up to it (1.92TB & 1TB) and a 1TB SATA SSD and a 64GB microSD card along with the built in 250GB drive. No issues. Never have ram issues either with the 8GB. I can compile stuff. Code. Have tabs in my browser. Do stuff in Logic. Edit video. Emulate old computers and systems for games. Dosbox. Parsec to my Windows desktop. Do pretty much…

8GB ram, only Apple could pull that off. What is it, 2008?

My work stack is tight on 32gb (yeah, it is what it is), that simply wouldn't fly for me. 8gb, especially with all the memory used by the os on MacOs, there's just no way.

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

#322

Post by jrm4 »

munchler wrote: post #27
jrm4 wrote: post #5

Microsoft's days as a 'primary' desktop operating system are numbered. The OP doesn't seem to understand this, but even Microsoft itself does, which is why most of its major moves the past few years haven't been improving its own desktop, but positioning itself to control "open source" the best it can. More people within the MS ecosystem should understand this.

One can argue that desktops are no longer the primary computing environment, but I don't think there's any evidence that Windows is about to displaced within the desktop world. What are you proposing will become the primary desktop OS? Some Linux flavor of the month? MacOS? Neither seems at all likely in the foreseeable future.

There won't be a "primary" and people will perhaps not pay much attention to which it is, any more than they pay attention to e.g. what Javascript framework their favorite site is using.

I've come to realize while there may never be a "year of the Linux Desktop," there will likely be "years of Linux Desktops" -e.g. Ubuntu, but then also SteamOS, ChomeOS, maybe Android if you're being REALLY inclusive, etc.

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

#323

Post by jrm4 »

zie wrote: post #191
jrm4 wrote: post #5

Microsoft's days as a 'primary' desktop operating system are numbered. The OP doesn't seem to understand this, but even Microsoft itself does, which is why most of its major moves the past few years haven't been improving its own desktop, but positioning itself to control "open source" the best it can. More people within the MS ecosystem should understand this.

I agree with everything but the "controlling open source" bit. I think what they are actually doing is trying to create new platforms they can control, because that's a great business model. Open source, via Github is just a small piece of the pie they want. Think MS teams/Office365, Linkedin, Gaming, Github, etc. These are platforms they are interested in controlling and deriving revenue from.

I don't think what you and I are saying conflict from a business point-of-view, but I think also it would be naive to "wave away" the incentive for MS to continue EEEing.

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

#324

Post by speed_spread »

tedunangst wrote: post #144
melissalobos wrote: post #107

Earlier quoted context omitted.

> 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".

But honestly, they really shouldn't.

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

#325

Post by dblohm7 »

Slartie wrote: post #51
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.

> The only current headache is that there's no pure Rust bundler, to make ".msi" or ".msix" installer files. I have set up a toolchain based on Wix, running via Mono and Wine on Linux, for the purpose of packaging some rather complex .msi files in a commercial software project. Has been running on the Linux-based CI servers of that project for 10 years straight now, with the only change having been that the entire ch…

> I have set up a toolchain based on Wix, running via Mono and Wine on Linux, for the purpose of packaging some rather complex .msi files in a commercial software project.

That’s exactly how I rigged up building our MSIs at Tailscale.

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

#326

Post by dblohm7 »

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.

https://m.youtube.com/watch?v=qbKGw8MQ0i8

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

#327

Post by pjmlp »

indymike wrote: post #319
pjmlp wrote: post #292

Earlier quoted context omitted.

> Mobile is almost all IOS and Android... and mostly but not all devs use Macs due to xcode. Indeed and trying to use UNIX for mobile apps won't bring you far. > The only places that Windows seems to persist are developer markets where tooling choices are limited to Windows (games, medical, embedded) or corporate standards dictate tooling. The remaining 99% of the market where UNIX GUIs don't matter.

I use macos to make mobile apps every day. Last I looked its bsd unix. Also ios and android are unixes too.

How much UNIX do you think powers your beloved XCode implementation based on AppKit and Objective-C?

Android uses the Linux kernel, nothing on the userspace is UNIX. Tomorrow it can use Fuchsia's Zircon and no one will notice.

I cannot find any reference to Objective-C, Swift, UI Kit, CoreData, Metal, OpenGL ES,... on POSIX standard specification.

"POSIX has become outdated", page 6

https://www.usenix.org/system/files/login/issues/login_fall1...

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

#328

Post by colinfinck »

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 project. We are talking about a compiler here that doesn't even support the C++98 standard, let alone all the basic features for writing safe software (stack cookies, _s APIs, smart pointers - just to name a few).

When I needed reliable self-contained binaries and backwards compatibility, I switched to VS2019's clang-cl compiler and ported their libc++. Together with winpthreads from the mingw-w64 project, this enabled me to write software using even C++20 features, but still maintain compatibility down to Windows NT 4 from 1996. If you're interested, it's all documented here: https://colinfinck.de/posts/targeting-25-years-of-windows-wi...

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

#329

Post by SergeAx »

delta_p_delta_x wrote: post #320
SergeAx wrote: post #245

Earlier quoted context omitted.

It may be not intuitive, but tools tend to be better because they are open source. My personal problem with Pylance or ssh tools is that they are not working with VS Code based forks. That means that VS Code is not that open source as it trying to look like. And this is suspicious for me.

> tools tend to be better because they are open source This is not true in general. It isn't even true for programming tools. Paid/non-OSS IDEs (JetBrains suite, Visual Studio) are often better in many ways than their FOSS equivalents (Eclipse, Qt Creator, etc). Other examples: office programs (MS Office vs LibreOffice), digital AV workstations (Adobe suite, Da Vinci Resolve vs Kdenlive, ShotCut, etc), 3D editors (Bl…

I didn't mean that all OSS tools are better than proprietary/commercial, this is not true obviously. I mean that making tool OSS usually makes it better.

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

#330

Post by pjmlp »

int_19h wrote: post #307
jeroenhd wrote: post #275

Earlier quoted context omitted.

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

.NET Framework 4.8 will start being legacy, when Forms and WPF finally work end to end on Core runtime.

Heck the designer still has issues to render most stuff on .NET 6.

Post reply on HN