CODEWITHSUNDEEP
c++windowsdlldeploymentmingw
fcad3d
fcad3d

Reputation: 23

dll in c++, WINDOWS deployment / dependency's (mingw-w64 )

Background: I'm programming a plugin (basically a dll) for an x64 application. More specifically this x64 WIN application comes with a "plugin manager" (a dll) that loads and unloads 3rd party plugins (like mine). My plugin is written in C++ and I decided to compile it with mingw-w64. As IDE I've choosen Code::Blocks. I tried to avoid MS tools since later I need to deploy "the same" plugin on Linux and MAC (but that's another story lets focus on Windows for now).

Challenge: There is one severe issue I can not resolve reliable with my knowledge/skill level, although I really worked hard in days of researches and tests: Dependency on WINDOWS dll's. I must assure that this plugin runs on all WINDOWS versions from 7 to 10 (x64 only however). The shipment of MS redistributables should be avoided since not practical in this case. Apparently a static linking of the c-runtime library "MSVCRT.dll" seems to be neither allowed by copyright nor a reliable solution since there seam to be many different releases on the various WIN versions. Although Microsoft describes it as "known dll" I'm not sure which version is available where and which version is able to run on a certain Win version. And if a certain MSVCRT.dll runs, does it have enough "functionallity" for my plugin? (To high for me)

The question: In your professional opinion what's is a reliable way to assure stability for my plugin on WINDOWS 7 to 10 (x64) in terms of Windows dll dependency's? Are there other pitfalls I should worry about in the context of this dependency's on deployment.

Additional info: Dependency walker_x64 (what a handy tool!) in this development stage of the plugin shows me dependency's on:

On my computer (Windows 7 x64), MSVCRT.DLL shows version 7.0.7601.17744, OK, works. But if the customer has, say, a Windows 10 machine, freshly installed (not many MS redistributable versions available), will it work reliably?

I know that similar questions have been discussed before, especially on the c-runtime library "MSVCRT.dll". Many of them before WIN10 however. The newlib idea (http://sourceware.org/newlib/) for example, 6years ago. Mingw-w64 ships with archives called: libmsvcrt.a / libmsvcrtXXX.a. Is there a way with those?

I've read all I could find but I have to admit that now I have more doubts and questions than answers... Your prefessional advice is appreciated. Thank you.

Upvotes: 2

Views: 819

Answers (1)

Serge Goncharov
Serge Goncharov

Reputation: 527

You may rely on presence and stability of at least the following dynamic libraries: kernel32.dll, msvcrt.dll, user32.dll, gdi32.dll. They are system libraries, present in C:\Windows\System32\ folder after the clean OS installation, and created by Microsoft as user API to interact with OS. MinGW library libmsvcrt.a (as well as non-static MS libraries) have no actual processing code but are just wrappers to call these DLLs from system folder.

Upvotes: 1

Related Questions