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

171–180 of 349 posts

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

#171

Post by ripley12 »

charcircuit wrote: post #169
ripley12 wrote: post #139

Earlier quoted context omitted.

> This is not even true. It is absolutely true. The CLI-first `dotnet watch` was pretty much done (I was using it in preview for months beforehand), and it was cut to promote hot reload as a Visual Studio feature. Source: I'm the person who raised the initial GitHub issue about the dotnet watch change, and I talked to multiple Developer Division employees off the record. It was a deeply unpopular move that came from…

So it's the public word of someone from the .NET team versus your unnamed sources. It sounds like there was a communication issue as from the blog post the reason given behind removing it wasn't to drive sales of Visual Studio. It sounds like if their team had more resources it wouldn't have been cut which invalidates the point of them using it to promote VS.

That post by Scott Hunter was a way to save face after Liuson backed down. It is absolutely not truthful about the original reason for removing dotnet watch, and was widely criticized as such at the time. Please trust me on this; the whole dotnet watch drama consumed my life for a good week when it happened.

If you want a source from the .NET team, Miguel de Icaza has since quit Microsoft and is able to be more open about what's going on: https://twitter.com/migueldeicaza/status/1537178691218046976

Even during the dotnet watch drama, he was willing to endorse a very critical take at odds with the public line: https://twitter.com/migueldeicaza/status/1451902388290392073

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

#172

Post by usrn »

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 used to do this using mingw on a raspberry pi for course work that needed Windows exes in college.

The official dev tools are really frustrating (except the debugger, I like gdb but it kind of sucks with c++)

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

#173

Post by lostmsu »

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 linked post actually does not mention any specific problem compiling binaries for Windows.

What did not work for you specifically?

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

#174

Post by kretaceous »

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…

> Microsoft has never really "got" the idea of URLs

I immediately thought of Teams links.

At least make another URL shortener like teams.ms and pass the URL through it before giving it to me.

I wonder if I it's possible to create a file in Windows named after a MS teams link as it's so long.

Is it so difficult to generate a short UUID?

Zoom does it with numbers.

Google Meet does it better with hyphen separated 10 letters so you can even read it out or just remember for 5 seconds before typing it elsewhere.

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

#175

Post by ranger_danger »

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?

Both static and dynamic linking to a newer runtime (as they are versioned) will break backwards compatibility. For newer OS features you need, you can always GetProcAddress() the needed functions at runtime instead. The real downside to staying on VC6 is all the compilers' ancient optimizations, or lack thereof.

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

#176

Post by MereInterest »

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

My issue with the 260 character limit is that it can easily be reached through normal usage, and can lead to some really strange behavior.

* File cannot be moved into a subfolder.

* Folder can be renamed, after which a file contained within it is inaccessible.

* File on a network drive may be accessible by some users, but not others. For example, one user may access the drive with the longer network name, while another has mapped the network drive as Z:\. A filename may exceed the 260 character limit for the first user, but not for the second.

* Cannot delete a folder, because it contains a file with a long name.

My experience may be biased due to using a program that recorded metadata in a filename, taking the majority of the 260 characters available in just the filename, but with the number of failure modes, I still don't think it is reasonable to have such a small limit.

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

#177

Post by [deleted] »

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?

[deleted]

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

#178

Post by ranger_danger »

ajvs wrote: post #110
dataflow wrote: post #85

Earlier quoted context omitted.

Statically link everything ? Including glibc?

AppImage is sufficient.

nope, it still requires at least the glibc version that the appimage was compiled against. snaps, flatpaks nor appimage solve the long-standing glibc versioning issue that plagues portable Linux binaries. the closest I've seen to fixing this issue is https://github.com/wheybags/glibc_version_header

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

#179

Post by anotherevan »

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.

NSIS (Nullsoft Scriptable Install System)[1] can be compiled[2] for Linux if that's any help. I use that to prepare the install .exe package for a Java based program for one of my clients.

[1] https://nsis.sourceforge.io/Main_Page

[2] E.g.: https://aur.archlinux.org/packages/nsis / https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nsis

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

#180

Post by naikrovek »

userbinator wrote: post #82
akelly wrote: post #77

Earlier quoted context omitted.

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

That's Microsoft being (the new, not the old) Microsoft... they seriously fucked up the MSDN documentation when it was migrated to docs.microsoft.com, so I'm not surprised that a similar thing happened to the blogs: https://news.ycombinator.com/item?id=20351358

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