5

I've been thinking recently about being an end-user who wishes to download one of my own projects and use it on a perfectly average machine. Having an equal background in Unix as well as Windows, I know that package management on Unix makes it FAR easier for the programmer to make it easy for the end-user. If a package is required, it's simply required, and all the required libraries are just there.

However, it's a different story on Windows. I have a project that I store on GitHub that is basically a C++ GUI application to interface with the Wii Remote. Nothing much. However, early on, I separated some of my initial project into a separate library project, because I could foresee that it would be useful to do so. The end result of all this is that I have the actual application project on GitHub, which requires both some wxWidgets DLL files and the DLL from my separate library project, which in turn requires a boost DLL file (threading) and the wiiuse DLL file, none of which the normal user is going to have on their computer, much less their PATH. I could take ALL those DLL files, zip them up, and put them with the application, but I'd have to remember to replace my separate library DLL file whenever I did work on the library.

Anyway, what is the common approach for dealing with this on Windows? Are there installer tools that can help me with the kind of issues described above?

Improve this question

2 Answers 2

Reset to default
6

It's actually not a different story on Windows. You'd typically create an installer for your application. The user runs the installer, the application gets installed. That's it.

There's two main approaches to use on Windows.

You can use Windows Installer, which is the installer service that runs on Windows and installs .msi files (kind of like .rpm's or .deb's). In this case, the file you distribute is not an executable per se. This is actually the 'recommended' method of installation on Windows. There's a couple of different tools you can use to create installation packages for this. WiX is one that comes to mind, but there are others.

The other option is to create a self-contained installer. This is your typical 'setup.exe'. You can use tools such as the excellent InnoSetup to create these kinds of installers.

When you do make the installer, install the DLL files into the application's directory. It'll be the easiest for you. Windows will search the local directory first when loading DLL files. This prevents conflicts that might arise when the same DLL file is installed multiple times on the machine.

Improve this answer
4

GrandmasterB's answer is on the mark, I'd just like to add...

begin rant

...that if the end-user has to know anything about what modules, DLLs, libraries, etc. your software uses in order to install it successfully, the installation is a user-experience failure

end rant

The (Windows) end user wants to download one file, double-click it, and have the installation proceed to success with as little interaction as possible - all the default settings and values should "just work" for the typical Windows machine. That may mean more work for you - a lot more work, depending on how complex your software installation is - but a much better experience and greater chance of success for the end user.

Improve this answer
1
  • True. There are also many security and proprietary concerns as well. From the original poster's question, I cannot discern if this is a 'hobbyist' project, or if it is 'professional' work.
    – JosephDoggie
    Sep 12, 2022 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.