Proc-address in the buffer?

This is a discussion on Proc-address in the buffer? within the C Programming forums, part of the General Programming Boards category; Let say we have loaded a library file (Windows DLL / (SO maybe?)) into buffer by fopen("rb") ... Is there ...

  1. #1
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489

    Lightbulb 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?

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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.

  3. #3
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    XP ... *dying*

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by audinue View Post
    XP ... *dying*
    Huh?

    --
    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.

  5. #5
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    A terrible complex thing...

    I guess it could be as simple as LoadLibrary... but...

    XP ... *dying*

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by audinue View Post
    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.

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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.

  8. #8
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    * 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.
    AAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGHHHHHHH~! (Ooops ... sorry)
    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...

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by audinue View Post
    AAAAAAAAAAAARRRRRRRRRRRRRGGGGGGGGHHHHHHH~! (Ooops ... sorry)
    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.

  10. #10
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    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:
    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
    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.

    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... ^_^"

  11. #11
    Registered User
    Join Date
    Jul 2008
    Posts
    26
    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.

  12. #12
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    If thats the case, why not just use a single function and modify the class pointer (this) before calling the function?
    Means we are still passing the 'this' pointer to the callback...

    This is not what I want.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Linux raw socket programming
    By cnb in forum Networking/Device Communication
    Replies: 17
    Last Post: 11-08-2010, 07:56 AM
  2. Frame buffer not working
    By Noise in forum Game Programming
    Replies: 1
    Last Post: 02-15-2009, 11:05 AM
  3. Lame null append cause buffer to crash
    By cmoo in forum C Programming
    Replies: 8
    Last Post: 12-29-2008, 02:27 AM
  4. writing a pack-style function, any advices?
    By isaac_s in forum C Programming
    Replies: 10
    Last Post: 07-08-2006, 08:09 PM
  5. Having Buffer Problems With Overlapped I/O --
    By Sargera in forum C++ Programming
    Replies: 0
    Last Post: 02-07-2006, 03:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21