🔒 Locked

Statically linking w/ DLL

Started by roos Feb 16, 2005 at 9:11 PM 4 replies 450+ views

Original Post

Feb 16, 2005 at 9:11 PM

Hi, I am working on a game for Smartphone/PocketPC, and I'd like to be able to distribute it as a single EXE, so that if someone sends the game to their friend or something, they can just send the program without any worries. (No errors about missing files or something) Up til now, all the code for my game has been written from scratch (no external libraries), but recently I converted my graphics code to using a library called GAPI, so I have to link to some Gx.dll file. Since I want to have just one file- the EXE itself- this is bad :) So, does anyone know if there is any good option here? Is it possible to force the compiler to link in the DLL statically so that I don't have to distribute it as a separate file? The DLL file is only 8k in size, so if there is any way to link it in directly, or perhaps include the DLL file in the EXE as a resource and then load the DLL from a resource at run-time, it would be good... Thanks very much, hope my post is not too confusing :) roos

Zipster

Feb 16, 2005 at 9:44 PM

You could always attach the DLL as a binary resource to the EXE.

Erzengeldeslichtes

Feb 16, 2005 at 10:14 PM

:google:

Zipster: How would one load a DLL that's a part of the binary? The platform documentation states that it looks for the DLL in the specified path, application path, system path, etc, but I don't see any way to load a library from within the binary of another? I suppose you could extract it to the app directory...

Zipster

Feb 16, 2005 at 11:31 PM

Yeah you'd have to extract it somewhere first. Yet you solve your distribution problem.

Evil Steve

Feb 17, 2005 at 8:29 AM

There is absolutely no way whatsoever to load a DLL from memory. The way the Win32 PE loader works makes this impossible.
What Zipster is suggesting is that you could add a binary resource to your program, which is gx.dll. When your application starts, you extract that resource to a tempory directory. Something like this (untested code):

// Load the resource //HRSRC hResource = FindResource(GetModuleHandle(NULL),MAKEINTRESOURCE(IDB_MY_DLL),RT_RCDATA);LPVOID* pData = LockResource(LoadResource(GetModuleHandle(NULL),hResource));DWORD dwSize = SizeOfResource(GetModuleHandle(NULL),hResource);if(!pData) {return -1;} // Error, can't load resource// Write the resource to the file //FILE* pFile = fopen("gx.dll","wb");if(!pFile) {return -1;} // Error, can't create filefwrite(pData,1,dwSize,pFile);fclose(pFile);// No cleanup nessecary //

Then, you can use LoadLibrary() and GetProcAddress() to access the functions in the DLL. Depending on how many functions there are, this might be a bit of a pain, since you won't be able to link to the .lib file (Windows will scream about "gx.dll could not be found" as soon as the application starts up)

Another alternative is to make a "stub" program that extracts your .exe and gx.dll using the above method. The stub program can then use CreateProcess() to run your real exe, and then delete the .exe and gx.dll once the process terminates (Use WaitForSingleObject() to wait on the process handle).
That way would allow you to link to gx.dll with your .lib file, and not worry about using LoadLibrary() and GetProcAddress().

Nemesis2k2

Feb 17, 2005 at 9:35 AM

Quote:
Another alternative is to make a "stub" program that extracts your .exe and gx.dll using the above method. The stub program can then use CreateProcess() to run your real exe, and then delete the .exe and gx.dll once the process terminates (Use WaitForSingleObject() to wait on the process handle).

I thought I'd add, I've seen this exact thing done quite a few times. I would suggest this method.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.