1

I've been trying for over 15 consecutive hours to find a way to statically compile my Native C++ game in a manner that it doesn't require some DLLs (which I believe to be CRT related).

Users that download my game are complaining of several missing DLLs such as:

VCRUNTIME140.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-timezone-l2-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
(and the list goes on)

My current command line for building is:

/MP /GS /GL /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl
/Fd"Release\vc140.pdb" /Zc:inline /fp:precise /D "WIN32"
/D "_CRT_SECURE_NO_WARNINGS" /D "_WIN32_WINNT=0x0501" /D "BOT_PROTECTION"
/D "CLIENT" /D "FW_GRAPHICS" /D "FW_NET" /D "FW_XML"
/D "NDEBUG" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MT
/Fa"Release\" /EHsc /nologo
/Fo"Release\\Win32\src\%(RelativeDir)\" /Fp"Release\otclient.pch"

Any thoughts?

Alexandre Severino
  • 1,563
  • 1
  • 16
  • 38
  • 1
    Is there any reason to avoid DLLs other than preference? – tadman Jul 26 '17 at 05:59
  • It's preference. But if I can get it down to around 2 or 3 DLL files, I won't mind. I really don't want the users (who are not interested in investigation and only want to click and play) to unzip a folder full of DLL files and have to look around to find the EXE. – Alexandre Severino Jul 26 '17 at 06:06
  • 2
    It's not always possible, at least not using your linker. Dynamic libraries are not intended to be hard linked into your program. Here's [some explanation](https://stackoverflow.com/questions/811720/c-how-to-compile-dll-in-a-exe). What you can do is bake them into your `.exe` file and then do some hackery to extract them from that at run-time. These days it's also super sketchy to deliver as a singular .`exe`. Give people an installer that puts the stuff in the right spot, creates Start Menu items, and registers it for uninstallation. – tadman Jul 26 '17 at 06:09
  • 1
    I can only agree to @tadman. An installer is the clean way to go. – OutOfBound Jul 26 '17 at 07:28

1 Answers1

1

/MT indeed tells the compiler to link the CRT into your executable. However, that's insufficient if another DLL still has a dependency on VCRUNTIME140.DLL. DLL's can depend on other DLL's, even circularly. Windows just loads them in the order encountered, unless already loaded. So if TEST.EXE depends on A.DLL, Windows loads A.DLL. If A.DLL depends on B.DLL, Windows loads B.DLL. If B.DLL depends on A.DLL, it's already loaded.

Next, api-ms-... are new Windows DLL's. They implement the old Kernel32.DLL and similar DLLs. They won't cause a dependency on VCRUNTIME140.DLL. It's unclear how you end up depending on those.

Then there are the other DLL's you don't list. One of those must be causing the problems you see.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • I really don't like having to explain to my users why they have to keep a gigantic set of "api-ms" DLLs just so they can run a simple graphical application. I "solved" my problem compiling my code with GCC Mingw. No "missing DLL" complaints so far. – Alexandre Severino Jul 26 '17 at 18:56