Load a DLL embedded in a file
Hi all.
I'm loading dynamically a DLL using LoadLibrary and GetProcAddress to get functions.
This work very fine.
Now, I want to embedded that DLL into a pak of my own. So the informations I have, is the offset position in the pak file of my DLL.
The DLL is in there at it's total integrity.
I'm wondering if there is not a windows call to acheive this? Similar to LoadLibrary, but which let me specify the filename (As now) AND an offset position where it starts in it.
Thanks :)
Hum that's complicated :|
I've tried his library, and it doesn't load it. I pass the exact same file in *data and can't load it.
There is really no simple "win32" way of doing this??
I've tried his library, and it doesn't load it. I pass the exact same file in *data and can't load it.
There is really no simple "win32" way of doing this??
If you know the offset position, how hard could it be to write it out to a temporary file?
Quote:Original post by Mike.Popoloski
If you know the offset position, how hard could it be to write it out to a temporary file?
It's easy, but I don't really like the idea.
Because if the app crash (Shouldn't) but let say. The user will have all the DLL in the folders! Hax issue, ergonomic issue.
And I can have multiple module with the exact same name.
It's the pak name that change, but inside I have mainWin32.dlh for example.
So I would have to increment and name the files this way:
01~.tmp
02~.tmp
03~.tmp
I really don't like the idea ;)
Better solutions?
Just out of curiosity why do you need to have a dll embeded into a pack file?
(Sorry for not being helpful. The temp file sound like a good idea to me too)
Edit: Ok,
All packs have different names? You could try to create a temp file using FILE_FLAG_DELETE_ON_CLOSE, and name your file like yourPakName.mainWin32.dll ?
Stills sounds like a hack though.
JA
(Sorry for not being helpful. The temp file sound like a good idea to me too)
Edit: Ok,
All packs have different names? You could try to create a temp file using FILE_FLAG_DELETE_ON_CLOSE, and name your file like yourPakName.mainWin32.dll ?
Stills sounds like a hack though.
JA
Quote:Original post by janta
Just out of curiosity why do you need to have a dll embeded into a pack file?
because if we want to distribute the pack let say in a web player. We have only one file to get (like an swf) and we can include both .dll and .so (for linux and mac) into this pack :)
There are lot more reason too.
If you're only reason is that you don't want the user to see the DLL, you should really rethink your design. If it is only "hidden" by an offset, you really won't be able to hide anything that you deem to be important.
In fact, in your situation I would have an unpacker utility that would take a big PAK file downloaded from the server and unpack it into the application folder. Then, you could easily load all the files from disk, probably speeding up load times. Besides, you really can't hide anything client side. If it's on the client's computer, it can be discovered.
In fact, in your situation I would have an unpacker utility that would take a big PAK file downloaded from the server and unpack it into the application folder. Then, you could easily load all the files from disk, probably speeding up load times. Besides, you really can't hide anything client side. If it's on the client's computer, it can be discovered.
Ya that's true, it's more for Practical and esthetic's.
One pack is practical. If the app crashes, you have temp files left all over :S...
That's the only issue here.
I think I'll do that anyway :(
One pack is practical. If the app crashes, you have temp files left all over :S...
That's the only issue here.
I think I'll do that anyway :(
As I said, I think that FILE_FLAG_DELETE_ON_CLOSE (see CreateFile) would allow you to create a file that automatically deletes itself when no more handles refer to it (which happens when you program crashes) You should check it out.
However, I think it would not work in case of a power failure. You program needs to terminate (in any way, correctly or crashing) for this to work (I think...)
JA
However, I think it would not work in case of a power failure. You program needs to terminate (in any way, correctly or crashing) for this to work (I think...)
JA
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement