Let say we have loaded a library file (Windows DLL / (SO maybe?)) into buffer by fopen("rb") ...
Is there any clue how to get the proc-address in the buffer?
About GetProcAddress in Windows API ... What is the "proc" stand for? Process / procedure?
Proc-address in the buffer?
Let say we have loaded a library file (Windows DLL / (SO maybe?)) into buffer by fopen("rb") ...
Is there any clue how to get the proc-address in the buffer?
About GetProcAddress in Windows API ... What is the "proc" stand for? Process / procedure?
GetProcAddress gives you the procedure (function) address, yes.
The DLL has a PECOFF format, and if you have MS tools, you can get the "export" table with the dumpbin tool. A .so file is not usable in Windows (unless you write your own tools to support it) as the file-format .
You can find the specs for the PECOFF here:
http://www.microsoft.com/whdc/system...re/PECOFF.mspx
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
XP ... *dying*
Huh?Originally Posted by audinue
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
A terrible complex thing...
I guess it could be as simple as LoadLibrary... but...
XP ... *dying*
If you do LoadLibrary("mydll.dll"), then you can find the process address by GetProcAddress(), it is very simple. Should you then wish to read the content of that procedure address, you can do so by casting the function pointer to a char * [ok, so someone will tell me that's not guaranteed to work on all architectures - but it should work on Windows architectures and the above API calls won't work very well on non-Windows compliant OS's, so I don't beleive it's a huge risk - but it's certainly not portable to all architectures that support C].
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Can I also point out that "just loading" the binary of a DLL will not make it executable - there is a fair bit more involved in loading a DLL - such as:
* relocating any data references,
* loading other DLL's that this DLL relies on (recursively until no further instances are needed).
* calling the DllMain() function to make sure things are initialized.
* setting up per-thread and per-process data for the DLL.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
AAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGHHHHHHH~! (Ooops ... sorry)* relocating any data references,
* loading other DLL's that this DLL relies on (recursively until no further instances are needed).
* calling the DllMain() function to make sure things are initialized.
* setting up per-thread and per-process data for the DLL.
I'm realy realy going to dying!
But, I have my DLL, and I assume that DLL doesn't required any DLL and initialization, could it be simple?
...example please...
If you explain what you ACTUALLY want to do, and why you have a REALLY good reason NOT to use LoadLibrary(), I can perhaps explain how you can achieve that. Just generically describe how to write your own LoadLibrary seems like a bit more time waste than I fancy.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Sorry.
Sorry matsp.
Because of my project is open source, so it's ok if I tell it here...
This is a long story by the way.
I have a new object-oriented concept: every class is a module (dynamic library) and I want to implement it into my new programming language... (~^_^~ )
Why every class is a module ...? I'll descibe it later.
Ok, in scripting language, that support native calls and callbacks to DLL (FBSLv3, AutoIt), could be implemented easily using function cloning (duplicating native function then synchronize the pointer to script function).
But, when we are moving to object-oriented, it's impossible to use function cloning to get the method pointer, because the method itself depend on the object.
Figure this out:
We couldn't do that easily in either in C++ or Delphi, if you mind, take a look the source code of TThread, TForm in Delphi.Code:DLL proc "TestCallBack" as TestCB(pointer methodPtr) in "mylib.dll" class MyClass constructor(number x) this.x = x end constructor private property number x public method void callback print this.x end method end class test1 = new MyClass(10) test2 = new MyClass(20) TestCB @test1.callback TestCB @test2.callback
But, ever tried FBSLv3(closed-source)? I'm very amazed about its method pointer. It's a horrible and unmanaged language, but still cool and fast interpreter anyway.
Back to the topic: We can solve this problem using dynamic-loaded-library when each class is a module, so whenever the class is instanciate, just copy the buffer of the library then get the new method pointer from the proc-address.
Of course there is plus and minus of this. But I will think how to optimize it later.
Phew... Any suggestion? Thank you before... ^_^"
So, you are duplicating an entire class (including all the functions and data) for every time you instantiate a class, so you can get the address of a function, knowing that each function belonging to each class will have a unique address in memory?
If thats the case, why not just use a single function and modify the class pointer (this) before calling the function? That would give you the same thing with a lot less memory usage. I use the same thing in C++ so I can use member functions as DLL callbacks/etc. The function code will exist exactly once (which is fine, as the code itself will never change), but the data for that class will be duplicated as many times as required.
Last edited by Mole42; 07-22-2008 at 03:01 PM.
Means we are still passing the 'this' pointer to the callback...If thats the case, why not just use a single function and modify the class pointer (this) before calling the function?
This is not what I want.
