imagine you are happy
you accomplished something with SDL, on Windows. an usable program
how do you run your program in other computers?
I’m on Windows, but I use MSYS2 to develop
I’ve obtained advice on Linux specifically already, I’m interested in Windows exclusively for now
like, can I just send the final executable to people? but I know it won’t work.
I can’t run the executable on my own computer. from inside MSYS2 it works fine, of course, but if I go to the folder where the executable is using the file explorer, and I double-click it, it fails with two errors: SDL2.dll and libomp.dll are missing. what do? where are they? are there other DLLs I should ship? is there an automated way of gathering those DLLs? some procedure of some sort?
let’s say I have all DLLS? what about antivirus from other computers? I once tried copying an executable I created to my dad’s computer, and Windows Defender deleted it. how can I make sure antivirus won’t delete authoral SDL executables that are inside a thumb drive or downloaded from Internet? I heard about signing, how does this work?
an installer… that’s boring. I don’t want to think about installers yet. I just want another person to double-click the executable on their own computer that is not mine, and have things work
When it comes to test or demo programs, all you need is an archive file (e.g. zip) that contains the game’s executable file, the dll libraries required for its operation, and files with game resources (graphics, sounds, etc.). After unpacking the game files from the archive, the game can be launched without any problems in Windows.
I don’t know what it is, but the only thing needed to create a program for the Windows platform is a compiler that will generate an executable file for a given architecture (i.e. executable file for x86-64 architecture).
Yes you can.
So don’t do it.
If your game requires additional dlls to run (e.g. SDL dll), you should provide them along with the rest of the game files. The dll files should be in the same directory as the exe file.
The Windows operating system, when running a program that uses external dll libraries, itself checks the established locations where these libraries may be located. First, it looks for them in the same directory as the program’s executable file, and if they are not there, it checks other known locations (e.g. the %SystemRoot%\system32 directory). If it does not find these libraries anywhere, an error is generated (such as the one you saw).
To avoid such problems, you should provide the required dll libraries together with the game files (as I said above). Counting on the fact that these libraries are already on the user’s system is naive.
This could be a false positive, but not necessarily. If you are certain that your executable is not malicious, you can always submit it to Microsoft for analysis and they will review it, confirm that there are no issues, and add its signature to the signature database so that in the future it will not be considered malicious.
Once you have a game ready to ship to users, you then digitally sign the executable so that its origin is publicly known. Digitally signed files are treated differently by Windows - it does not warn the user about the potential threat when such a file is run. The OS, depending on the system settings, may display a prompt during startup that displays the certificate owner’s details to inform the user.
If you want to know more, search for code signing.
If you want to provide users with a game, you should provide it in the form of an installer. An installer is a regular program that usually has all the game files in its resources. During installation, these files are unpacked from the resources and copied to a directory selected by the user. The installer also performs other necessary actions, e.g. adds program data to the system registry (so that it appears on the list of installed programs), creates shortcuts (on the desktop or in the Start menu), etc., etc.
There are ready-made tools for creating installers, a short list of them can be found here: List of installation software. But since the installer is a normal windows program, you might as well make it yourself.
You can easily provide test versions in the form of a zip archive, but remember to provide all files required for the game to run, i.e. not only the exe, but also any necessary dll files (e.g. SDL dll) and assets.
flowCRANE’s reply covers shipping well. I’ll try to cover MSYS2 specific ponts:
If they come from packages you installed with pacman, you should find them in current prefix ($MINGW_PREFIX/bin).
To find all libraries you need to ship along with executable you can utilize ldd: ldd myfile.exe. You only need to ship libraries that are located inside msys2 installation directory, no need to ship Windows system libraries.
I forget what it’s called but for a long time now there’s a program that compresses files (think zip folder) but puts it in a self extracting exe. IDK if anti-viruses block it but I remember it being easy.
Another problem I remember is sending my friend builds and chrome would block it because it saw the exe inside a zip. The solution was to put a password on it and I think there was an option to hide filenames and it ran fine. This IIRC was in the windows 7 days. I rarely boot windows 10/11 because it’s been more annoying than linux
One more thing that few people remember. If you publish a demo/tester for the Windows platform and in a form without an installer (e.g. in the form of an archive with all the game files), remember that such a version should not save any data on the disk and in the user’s system registry. Test programs should not litter the user’s system, and if they do, then at most in the directory for temporary files. This is good practice, with respect for the user.
If I publish a demo, it is a zip archive with all the necessary files to run the demo and it does not save anything. And instead of to a file, I redirect the logs to the console, which is allocated by the game process during the game startup. All game files are read-only.
