I am normally a webdeveloper but now I had to make a Desktop-app. It'll be my first Desktop-app for real use. It is a GUI-app using Gtk-rs. On Unix developing and running the application goes smoothly, but because for some reason a few people still decide to use the s***tty operating system called Windows I just wasted two days getting my app to compile on Windows.
The problem was that Gtk and Glib needed to be installed, I had to do a lot of weird stuff like installing Mingw-through Msys2 and configuring pkg-config to make it work on Windows.
But I do NOT want my end-user to go through all this to install my application. So I was wondering how I could solve this? Statically linking Gtk into my binary does not seem a solution, I was thinking about the following:
I'll make a separate really basic application that downloads the compiled binary from my server together with the DLL's required for Gtk and Glib. That application will just place the folder of those files in C:/Program Files or something and add it to the startup-registry and add a desktop-icon. This way the user does not have to go through the hassle of manually moving the files from his download-folder and getting the DLL-files.
Is this the best way to deploy a desktop application?
Rather than creating your own installer program that tries to place things in the right folder, it's much better to use something that goes through the official installer mechanism for Windows.
That way your users get nice things like, for example, being able to uninstall your program cleanly without leaving random files or registry entries around.
Your best bet is to use something like the WiX Toolset. This gives you a way to specify dependencies that must be installed and set up any registry entries you need. It also gives you a *.msi or a setup.exe which provides an installation flow your users will be very familiar with.
To be fair, that's more an issue with the Glib ecosystem being written in C, which has a terrible story around dependency management and build systems, especially when it comes to cross-platform support.
Why? Usually, you should try and make your binaries self-contained anyway.
Couldn't you just package up all the required files in a zip and then tell the user not to delete the DLLs? I've seem that approach work for quite a few applications.
I've looked at this in the past, and my recollection is that this is not recommended, not supported, extremely difficult to pull off (Gtk depends on a ton of external files, and doesn't make static prebuilts available), and is practically untenable for non-[L]GPL compatible code.
I had a project for which I wanted to add a nicer UI (currently using a hand-rolled TUI). Gtk was out of the running specifically because I couldn't build a self-contained executable. [1]
I remember trying to get cairo to build once, and getting trapped for days in a constant cycle of "the instructions say pkg-config should work for the dependencies, but it doesn't and the instructions are outdated and nothing works". I believe I gave up in the end and used something else.
Gtk (and libraries in that orbit) don't generally build easily on Windows. That's not Windows' fault.
Also, Linux is not a drop-in replacement for Windows. Hell, I have hardware right next to me that 100% does not work on anything but Windows.
Definitely what @Michael-F-Bryan said. An msi or installer is fine. Please, please, please do not try and engineer your own solution to the problem. You will get it wrong. Just from what you've described, when I'm installing software, I don't want it installing to C:\Program Files, I don't want it running on startup without notice, and I definitely don't want a desktop icon.
Best of luck dealing with the unreasonable demands of your pesky Windows users.
No, having something that unpacks itself, runs the temporary program, then has to manage cleaning up afterwards every single time its run was not something I was willing to deal with. âŠī¸
Literally almost nothing in the FLOSS ecosystem builds cleanly on Windows out of the box. Surely that must not be everything else's fault?
This reminds me of the ancient joke about a bloke driving around listening to the radio in his car, when the news spot suddenly announces: "Warning! The police recommends everyone to temporarily stay off road A1 because an idiot is driving in the wrong direction."
The guy scratches his head, shrugs, and says to himself: "An idiot?! All of 'em idiots are going the wrong way!"
Now back to the topic, Windows' native toolchain is about as conforming to the C standard as a BASIC interpreter from the 80s was. It's missing key parts, changes the signatures and/or the behavior of core functions, and the whole ecosystem wants the developer to forcibly depend on proprietary Microsoft stuff, to a degree that it's not even funny. It's almost like the OS is actively hostile against building anything that is not written in Microsoft's own C or C++ dialect. It's absolutely no wonder stuff doesn't build.
Heck, even macOS is easier to get stuff done from a developer's perspective just because it at least provides some foundational POSIX libraries in a way that's half-consistent with what everything else expects. Most developers I know prefer to work on one of the Unix-y systems not because they are prettier or even superior in terms of security or performance, but because of the sheer pain of getting anything compile under Windows.
