loading a dll

[stefanhendriks]

another question , this is purely out of interest for a wild idea i have.

Is it possible to load a dll that is already loaded?

Ie, lets explain my wild idea, as for example HL2.EXE , it provides a metamod style for plugins. Lets say i write a plugin that is able to read out entity lists, player data, etc.

Now i want a seperated EXE program to read this data and also get back to the dll. So kind of like what a BOT DLL would do , but then in a form of an EXE file. Lets say you could make a real-time 2d viewer of the HL2 game... would it be possible. Or is this just stupid?

VIEWER.EXE -> hooks into plugin_viewer.dll -> retrieves info?

or would that make it a 'double hook' ? :S

i am just tossing around here!

[@$3.1415rin]

You can't load a dll into memory twice, but you can use the dll from several different programs. the use of a dll is the fact, that you can have code which is needed by more than one program in your memory, and all use them, thus providing better locality for caching e.g. besides the fact that you need less memory.

so it should be possible to load the dll a second time, but then it'd have another data segment, because it's in another process. therefore it won't be easy to access the data from the HL2 process. In a perfect OS, there isnt any way to do this but interprocesscommunication which has of course to be supported by both sides. Of course this security issue isnt seen as important at all on win9x machines, but on newer OS including linux its hard work, and definately hacking, not coding any more

[stefanhendriks]

Sounds to complicated for me heh.

In that case it would be just simpler to inheret a program into the dll and make it export data to a file so the exe program (seperated viewer) reads that file. And in fact, in that case it should not be too hard even.

[Lazy]

Wouldn't it just be easier to use sockets instead of reading/writing files back and forth?
Should be easy enough and you can conserve bandwidth by only sending values that have changed rather than worry about delays, ect when reading a file.

Added: You could also just use the file to write the address of your data and then use Read/WriteProcessMemory to access it from the other program.

[stefanhendriks]

sockets? for a program that is on the server already? dunno, i am not an expert on that field.

[@$3.1415rin]

writing a plugin and sending the data over sockets ( pipes, or however they are called on other OS ) would be definately the way to go. why do you wanna know that btw, stefan ? why do you need to load a dll twice then ? you just need to wrte a plugin to get the data out of there ...

[sfx1999]

Can you spawn a new program and pass parameters somehow? Or can you use threads?

[stefanhendriks]

someone , long ago though, proposed another bot architecture. Where you had one EXE file (aka like Cheating Death) you run before you start any game. And when the game starts, the EXE file 'hooks' into that game somehow.

And then the fun begins, as you can simply add bots externally , but server-side ofcourse. THis way you could realize a similiar bot-brain -> interface thingy, though you can completely write the brain seperated and the interface too.

Its just too complicated to me imo. I'd rather do it the compilish way (ie, include a different interface.cpp to compile another bot dll).

[Lazy]

You can do that on win32, all you need to do is inject a dll into that application using WriteProcessMemory and CreateRemoteThread.
Another way is to find a dependency of the dll and make a proxy of it, that way windows will automatically load your dll into the program's address space and you can go from there.
I'm not sure about this 100% because I think steam has a way of knowing when you do that, for example I was going to add a clock in-game so I could play fullscreen and be able to track the time.
I got my dll loaded and hooked LoadLibrary but after a while it would just die without any warning, after that I just gave up and put a real clock next to my monitor

[stefanhendriks]

Lazy, why aren't you a heck of a bot-coder? You seem to have some pretty good knowledge about this stuff!