Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

> 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 chain has been packaged into a Docker container a few years ago when that became fashionable.

WiX is great. I have been using it for over a decade to package an internal application. It's all driven by a simple text file which I liked over Microsoft's packaging offerings.

It's another example where the free tools are better than Microsoft's.

Except it's also Microsoft's.

The Windows Installer XML Toolset (WiX) is owned by Microsoft.

It's not. It's an open source project (aka owned by no one) that started at Microsoft. The person who created WiX left Microsoft to create Firegiant, which is the primary contributor to its continued development and maintenance.

Open source does not mean "owned by no one". It means the owner or owners have licenced their intellectual property to you under the terms of an oss license.

Which offerings? Are there any?

I only know about other proprietary non-MS solutions like InstallShield, which also generate .msi files but use their own proprietary way to define the installation process, with the benefit/disadvantage (depending on what you want to do specifically) of being on a higher abstraction level than WiX, which is more or less a direct resemblance of the internal Windows Installer data structures.

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

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

NSIS is not a substitute. It's good for shipping to home users, but msi installers are essential for enterprise software distribution.

That's what you think.

In my enterprise, a big one, I shipped only NSIS installers. Much easier to use, and better user experience also.

I've worked at several enterprise software publishers, and they all used NSIS to package and distribute their software to enterprise end users.

You can use .exe installers as well.

It is only a bit more work

https://activedirectorypro.com/deploy-software-exe-using-gro...

> Then test with Wine.

I tried doing that, and then found that my test suite passes on real Windows but fails on Wine, because it uses APIs which Wine doesn't implement correctly (or at all).

Which APIs are those? A bug filed at https://bugs.winehq.org/ might get some attention.

Waiting on this one.[1]

It's rather impressive that the whole Rend3->WGPU->Vulkan chain for 3D graphics works under Wine, because that's all bleeding-edge stuff. It's only that full screen won't work. Wine reports "fullscreen true stub!", so it's something not implemented yet, rather than something broken.

[1] https://bugs.winehq.org/show_bug.cgi?id=53115

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++)

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 ardour we use QEMU VMs, running GUI-free for non-interactive builds, and with a GUI for ... interaction. Easy to create, and as long as you have lots of memory and cores, nice and responsive/fast. Set a startup item in the non-interactive VMs so that a minute or two after they come up, they start the build. In our case, they upload to ardour.org when complete. The interactive ones are just .. well, they're just macs running in their own window, do what you want with them.

There is the Julia package https://github.com/JuliaPackaging/BinaryBuilder.jl which creates an environment that fakes being another, but with the correct compilers and SDKs . It's used to build all the binary dependencies

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

The linked post actually does not mention any specific problem compiling binaries for Windows.

What did not work for you specifically?

I did a similar thing, but I only ever compiled windows versions using Github actions.

Good news is winget will soon support single binaries so that is one option.

Can you link to info about this? I can't find much in a quick Google search

https://github.com/microsoft/winget-cli/issues/182#issuecomm...

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

> Found this Cargo package rust-msi.

I looked at that crate. That lets you read and write .msi files, but those are just containers. It doesn't help you set up the rather complicated contents required. Someone who's into the Windows ecosystem could probably use it to do the limited things cargo-bundler does. The neat thing about cargo-bundle is that it only needs the info from the Cargo.toml file to drive the bundling process. Most Windows installer builders involve manually constructing Windows-specific XML files.

Ah I see. Honestly if I knew Rust better I wouldnt mind taking a stab at the project but I am cozy with dotnet currently. I love building systems tools but very little work I apply for does just that. It is a shame companies dont invest more into R&D.

The Rust part of this isn't that hard. cargo bundler already has a place where the .msi output generator is supposed to go. The reading of the cargo.toml file and the writing in .msi format is already written. It's just generating the Microsoft-specific content for the .msi file that's hard. That takes Microsoft platform expertise.

Reply on news.ycombinator.com