0

Friends of Stack Overflow

I request your assistance.

I am working on a project in native-C (all files are *.c or *.h) that has a base client program and can be improved with modules. The thought process is to have the base client be small and easy to download, much like a game launcher, and extra functionality would be unlocked when needed/requested. Imagine a new tab magically appearing once you've subscribed to Gold Tier.

I'd like do this modularization with DLLs; which I've been able to successfully do... to some extend. Currently, the Client can request the Module DLLs but, they are HUGE because the DLLs use a lot of the same functions that the main client uses... so I have to compile the DLLs with the same headers. And I can't find a way to force the DLLs to use the Client's pre-compiled libraries instead of the libraries being recompiled into the DLL as well.

Example:

  • Base Client is compiled with json.c that allows us to create and read json.
  • DLL must also be compiled with json.c because it also needs to create and read json.
  • Can I just compile a skeleton DLL and let the DLL use the json.c from Base Client?

This is a duplication of code that is unfairly bloating my DLLs. Is there a way to compile my DLLs WITHOUT linking them to the local json.c file, leaving them unresolved, and allowing them to resolve with the Base Client once they are loaded into the Base Client's memory space?

I've been thinking of making a CommonDependencies.dll and tossing it into a InterProcess Communication (IPC) Page File via CreateFileMapping but... the Base Client AND every Module DLL would have to reach into that CommonDependencies IPC Location and do a "LoadLibrary" and "GetProcAddress" on every single function that CommonDependencies has. That gets tedious to code and isn't very future proof, if we need to update CommonDependencies in the future.

Another stackoverflow post (Sharing a global/static variable between a process and DLL) suggested a cross-module stingleton but I'm not quite sure that I followed the process... nor do I know if that is the right course-of-action for me.

I looked at using a *.lib file thinking that maybe compiling the lib file with each Module DLL would somehow magically point to where the CommonDependencies DLL is in the client memory... but I really doubt that it is that magical.

What I really want is for my unlinked DLL to pull all of its dependencies from the libraries that the Base Client has... dynamically.

Any ideas?

Richard Critten
  • 2,138
  • 3
  • 13
  • 16
Stryker2k2
  • 108
  • 9
  • 1
    How is this different from the most basic DLL usage? Only link `json.c` into the base client, not into the modules. `__declspec(dllexport)` in the client, and `__declspec(dllimport)` in the modules. No? – HolyBlackCat Jul 10 '23 at 21:25
  • For some reason, dllimport didn't really cross my mind. You might be on to something. – Stryker2k2 Jul 10 '23 at 22:00
  • I'm working of a proof-of-concept with `dllimport` but I can't even get a DLL to compile in GCC without getting `undefined reference` errors. And `--unresolved-symbols=ignore-all` isn't helping. – Stryker2k2 Jul 11 '23 at 17:56
  • 1
    You should probably post a new question about your attempt. Include the compiler command and a [mcve]. – HolyBlackCat Jul 11 '23 at 18:03
  • Will do. Thank you for being my sounding board and letting my mind come up with different options. I need to solve this DLL compilation thing before I come back to the `dllimport` issue :) – Stryker2k2 Jul 11 '23 at 18:14

0 Answers0