Just because I want to include a .DLL in a .EXE means that I'm making a virus??? I dont understand. I'm not trying to hide anything. I'm making an application for my site so I can manage my site. Me and some of my friends "manage" the site together and I think it would be easier if there is only a .EXE to worry about. I dont know hardly anything about C++ and I thought this was a forum to ask questions. I guess I'm wrong. This forum is only for experienced users who know everything. My bad.
stickman,
I'm sorry for the previous posts, i had no right to make assumptions about how you were to use the information posted here, i apologize for that.
I looked around and it seems you are trying to link to a library from MySQL distribution, MySQL distribution is supposed to include a .LIB in there as well, so you can use that for static linking. Now, as far as i know this won't come anywhere near to solving your issues because as far as i know without the source code or the original objects created from the compilation of the .LIB, both with dynamic and static linking the only thing difference will reside in the linking process and the extension of the library file because from my small knowledge in windows programming the .LIB file will have to be deployed with the rest of the application.
Cheers.
Last edited by LinuxCoder; 04-09-2006 at 10:21 AM.
Thanks for the information. Its not that big of a deal to distribute the .DLL with the .EXE. I thought that there were other ways to do this then to distribute the .DLL with the .EXE. I was unable to find the .LIB with the MySQL "distribution" I downloaded; therefore, I wont bother with all this static and dynamic linking stuff.
... Just because of not wanting to use a DLL... you quit an entire project....Originally Posted by stickman
No, I just said I wasnt going to bother with the static and dynamic linking. I'll just include the .DLL with the distribution until I can find a way to link it statically.
Whatever youn say, I still keep my opinion though.
As i stated before i believe static linking is not going to solve the issue of having the library included in the .EXE file. I don't develop for windows anymore but i believe the same principles apply and it's only a question of how the library is compiled, linked and loaded by the application. From my experience if you compile with a static library .LIB you'll need to provide the .LIB in there as well.
If you have two applications using a given DLL library, then the library is loaded when the first application loads it and when the second application tries to load it the application will use the one previously loaded thus they are shared. With static libraries if you run two applications using libmysql.lib then that file will have to be loaded twice in memory, one for each application using it.
This might not be 100% accurate, specially for windows since it's not my developing platform.
From a Windows perspective, static linking combines library routines with the application. The linker will search all libraries for unresolved functions called in the application and if found will copy the corresponding object code from the library and append it to the executable. Static linking does have a tendency to create bloated executables but a library is not needed to accompany the application in order for it to execute properly.
You're totally right, i was not seeing it correctly, just browsed online and noticed that you are totally correct.
My apologies for any misleads i may have caused to stickman, my participations in this thread did not really favour my person
Thanks for the information. I understand this a little better know. Right now, I'm more focused on finishing the project than this. Thanks for your help (and you can think what you guys want to think...I'm only making an application to help manage my site better and my site is like 95% MySQL database driven).
This is the best solution lol:
Dynamic link the DLL in the program. At startup of the program, check if the DLL is in the EXE directory (or windows/system32), if not, make the EXE download the DLL from your website and put it in the EXE directory or the system32 directory. Voila! Only one file to distribute. Hehe.
Well, you cant load the .EXE if the .DLL isnt in the directory (or for me it wont load even if I dont use functions that are in the .DLL). But that is a good idea. I'm going to something like that for an updater (since I'm pretty sure you cant overwrite the current .EXE if its being used, so there has to be an external application that can update the .EXE).
Write a program that goes onto the erm second partys computer that downloads the exe and dll, and then executes the main exe and quits itself, then the main exe deletes the installer exe.... I don't like helping malicious people though and I still hold my case...
Like I said, you can think what you want. I know for a fact that I'm making an application to manage my site. If you think thats malicious, then go ahead and think that. Everything can be considered malicious to some degree. Modifying data is malicious to some degree. But in the context of all your posts, you make it seem like malicious means modifying data without the user's consent. Oh, and one more thing I know for a fact, I hardly know anything about C++ and my abilities to make "malicious" software is non-existent. But why am I wasting my time explaining all this to you?
You have enough information to complete your task.
Either use static linkage (through a static lib), dynamic linkage using LoadLibrary (which I don't recommend in most cases), or use the import library (.lib) from your DLL project and build using that library.
I use the last method and it works great. Problems:
1. Static linkage will increase the size of your exe tremendously since all library code is included in the exe. Since this is for the internet - size may become an issue.
2. Dynamic linkage at run-time using LoadLibrary is a major pain in the arse. You must load the library and then use GetProcAddress to retrieve a function pointer to the function you want, and then call it via the function pointer. It's also inherently unsafe.
3. Using import libraries is simple and does not require using LoadLibrary. You simply place a path to the import library in your compiler, include the correct header, and use the functions/classes as you normally would. Problem is you must re-build the EXE every time you wish to upgrade the application. You cannot just send a new DLL if you change any of the function prototypes. If you keep the same prototypes you can, in theory, change the body of the function code. So you can update the code...but you are limited.
Also the DLL must be in the same folder as the EXE. But this should not be a problem.
For import libraries and DLLs:
In the dll use __declspec(dllexport).
In the code use __declspec(dllimport)
