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

Question

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.

Answer 1

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.

Answer 2

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

• How to play a SFML game on another computer

Answer 3

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.

Other functionality an installer might help you with might include:

• Verifying and repairing the installation, if required.
• Managing add-on content.
• Managing updates.
• 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.

Answer 4

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

• BoxedApp (Commercial product)
• Appacker (Github project)

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.

• Reddit on Can we still create standalone executables (no zip) in Game Maker 2?

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

• GameMaker's forum site

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.