# How can I make my C++ game which installs its own DLL files?

Example: Minecraft is the same single .exe from the moment it's downloaded. Installations occur fairly quickly (very painless) for the selected version.

My case: I have a C++ game which uses the following libraries: - SFML - GLAD - GLEW - GLM - ASSIMP

How can I make my game a single .exe which installs these libraries in the directory I want, if they're not there on execution, and also executes the game? (presumably that's how I imagine it should work).

I think I already made my point, but in essence I want the game to be a single .exe managing all external dependencies.

• This sounds like static linking, where the libraries you need are built into your executable itself and not linked dynamically at runtime. ie. It has no external dependencies, beyond say the graphics driver, because it's internalized all of them. Apr 7, 2020 at 1:03
• I expected this answer, but still need people's go at answering the actual need. I already linked SFML statically to my Visual Studio project, but I'm clueless on linking the rest statically. If there's some trick for linking any library statically I'd appreciate info on it. SFML for example required a precompilation flag to be set on VS and some component to be unticked in CMake (which I'm pretty clueless about). All I can guess is that each library is a diferent world for static compiling. Maybe I should ask about each one individually Apr 7, 2020 at 1:25
• Sorry we can't be more helpful, but this is simply part and parcel of the pain of writing native code. You either find a way to make it work, or work around it. And yes, you will need to treat your linkage problems on a library by library basis. In some cases, people are known to skip a library altogether when it causes them too many problems. Good luck - and as you say - check on e.g. GitHub for each lib. Apr 7, 2020 at 19:17
• Static linking would do this for you without needing to install them at all. Apr 7, 2020 at 21:55

According to this article by Microsoft, the first place where Windows will look for DLL files is always the directory with the .exe file that requested them. So you don't actually need to install the DLL files. You can just put these files into the same directory as the game executable.

• That doesn't seem clean enough for what I asked. Actually, I already have 2 dll's in the current executables directory I'd like to have somewhere else. Imagine downloading minecraft to your desktop and having 2 dll files lying beside the .exe Apr 7, 2020 at 12:58
• @Mithrandir Why? Apr 7, 2020 at 12:59
• Sorry, just edited my answer :) Apr 7, 2020 at 13:00
• @Mithrandir Putting DLL files next to your game exe is common practice to avoid conflicts with other versions of the same library being installed in the Windows system directories. And it also allows copy&paste installation. Apr 7, 2020 at 13:01
• @Mithrandir people shouldn't be installing programs to their desktops, there's something about making it easier for the casual non-technical user to do the wrong thing that doesn't sit right with me. Maybe all you need is an installer? Apr 7, 2020 at 16:46

There are multiple topic to discuss here.

• "portable" do I mean cross-platform executable = Cross platform portability
• How can I make my game a single .exe which installs = Easy to distribute

## Cross platform portability

• Try to wrap platform-specific functionality in your "Game engine" layer as much as you can. Never let game code touch platform specific function directly such as input, file, etc. That's what SFML or SDL, or today major game engine like Unity or Unreal has been doing.
• You are already using middle layer such as SFML, fine, that save you lots of OS code. But you still have to take caution if your game code access anything directly from, let say <Windows.h>, that would be another challenge to cleanup.
• For true portability to completely different hardware such as console/mobile, even access to OpenGL should be hidden behind another layer. Because OpenGL still has some difference on mobile. Or even console has their own graphics API.

## Easy to distribute

• You cannot completely ignore DLL, some basic library such as libpng zlib allow you to do static linking which merge code into your exe. Thus not requiring extra DLL.
• But some library has different license model such as LGPL will require any program (or game in your case) that statically linked to it be "Open sourced", unless you use it as library (DLL).
• Some bigger commercial library only has to be distributed with DLL such as FMOD.
• To distribute, for starter, study your middle ware and library each, how can you deploy with them?
• For instance, something like GLEW has an option to static link thus skipping glew32.dll.
• Even for SFML itself has an option to link statically, Read more from this old thread. To search more, your keyword would be something like sfml deploy.

If you compile the application with the Visusal C++ compiler and link the runtime library dynamically you'll have to ship also the C++ redistrubitions. If you also link SFML dynamically you'll have to ship the SFML dlls too ofcourse. If you ship everything that's needed it should run on all (newer = XP >) Windows systems.

• For an example playground, try some free game in itch.io see how people distributing game in their zip file. (Again, your SMFL will has its own way to distribute) try other people game package and see what feel best for you.
• But for rule of thumb, you should ship any DLL included in your working EXE folder

## Related on Stackoverflow

• As far as I'm aware, a library made with GPL is only a problem if you are making a program specifically to complement a GPL library, like creating a UI for a command-line program. It makes no difference how the libraries are linked (statically or dynamically). Apr 7, 2020 at 10:37
• @TomTsagk I mean LPGL. The lesser GPL. It has different license term, if your link it dynamically (put it as DLL and ship with your program) or link it statically. Apr 7, 2020 at 18:25
• @Mithrandir "You cannot completely ignore DLL" means you cannot avoid (shipping) DLL with game forever. Sure unless your game is very small and can static link to every libs. Then sometime later when your game depends on more lib, you might find the one that cannot static link, I gave an example such as FMOD. the popular sound engine. That's mean if you have to ship DLL, you have to. Apr 7, 2020 at 18:30

It seems like you're over-thinking your requirement when all that you really need is just a simple installer.

Among other thing, an installer can:

• Check system requirements.
• Resolve library dependencies.
• Ensure correct library versions.
• Make sure everything goes in the correct folder.
• Make sure that the whole thing co-exists peacefully with other programs on the computer.

• Verifying and repairing the installation, if required.
• Launching the game.

Traditionally these functions would be a separate program - often called a launcher - but there's no reason why they can't be rolled into the same program as the installer.

One hallmark of a robust system is that it should be simple and obvious to do the right thing, but more difficult to do the wrong thing: if you're fighting against the system then you're probably doing it wrong. An installer can help you achieve this, particularly for non-technical end-users.

Note: I added new answer (for completely new unrelated approach) as OP had update his/her question significantly

Aside from shipping DLL normally or do an Installer. Another way to create single EXE in hacky way is using App packer

## What is it?

It just create new EXE which encapsulate other resource you would like to pack.

This gives similar result to GameMaker's Standalone EXE option, with all assets packed inside, and probably its dependency (DLL) too.

## Potential issue

There might be compatibility issue later, GameMaker itself even trying to phase this feature out.

Not possible natively. The utility that GM used to pack single .exe exports is slowly being depreciated by Microsoft.

single executable's don't work on every platform. Microsoft changed the tool so that something built on windows 8 (and above probably) don't work on anything below that. It's not our tool, we just use the MS one. So this is a horrible choice for a standard tool.

Again, I want to point that, for sane/normal solution, you should normally ship DLL with game exe you distributed. I just give out this answer to let you aware of such approach.

• Now I aware that community tends to down vote on blackmagic approach or something that contrast their believe, OK, here we go.... Apr 7, 2020 at 20:19
• I'm not sure what you mean. I don't see any negative-score answers from you, and no downvotes anywhere in this thread. :/ Apr 7, 2020 at 20:53
• Good to know this, thank you. Apr 7, 2020 at 21:04