Announcement

Collapse
No announcement yet.

GetProcAddress Replacement

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GetProcAddress Replacement

    I know I can use GetProcAddress to get a pointer to a function in a dll, and I can use CodePtr to get the address to a function in my exe. But I have a unique situation that I can not solve.
    1. GetProcAddress - Although uses a string for a function, only seems to work with a dll?
    2. CodePtr - Although works for Functions in my Exe, does not allow for a string to be used for the name of the function?
    3. CallByName - Although seen in VB, and found in Jose Roca's forum, comparing the 2 I realize only works on COM objects


    What I am trying to do (and maybe can't be done) is be able to use a string like "CallByName" to call my function at runtime, that is not known at compile time.

    I have tried comparing pointers to match the function as a string to the function itself, but not being the same, the pointers are not the same.

    Googling things I see hints of the PE for a file (compiled as DLL or as EXE) are the same, so I hope that is the answer, but overall, has anyone done something like this???? or know how to do it?? or something I have not thought of yet???
    Engineer's Motto: If it aint broke take it apart and fix it

    "If at 1st you don't succeed... call it version 1.0"

    "Half of Programming is coding"....."The other 90% is DEBUGGING"

    "Document my code????" .... "WHYYY??? do you think they call it CODE? "

  • #2
    You could EXPORT the functions in the EXE, and then similarly call the functions like a DLL call.
    Scott Slater
    Summit Computer Networks, Inc.
    www.summitcn.com

    Comment


    • #3
      ...or make a global table in the main program containing the function name and CodePtr for each such function.

      Comment


      • #4
        What I am trying to do (and maybe can't be done) is be able to use a string like "CallByName" to call my function at runtime, that is not known at compile time.
        I do that in several products; the "name" is stored in a configuration file.

        The only way is GetProcAddress(), which WILL get an address of any EXPORTed function in the "module of interest." (and WON'T find any non-exported procedure)

        However, there is NO way to get the "procedure header" describing the number and data types of parameters.

        MCM
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          Below is an example of the problem I am having. Although the function is exported, I can not find the function via GetProcAddress

          Code:
          #COMPILE EXE
          #DIM ALL
          #INCLUDE "Win32Api.inc"
          DECLARE FUNCTION StartTracePort ALIAS "StartTracePort"() AS LONG
          
          FUNCTION PBMAIN () AS LONG
          LOCAL ModuleHandle AS LONG
          LOCAL FunctionAddress AS LONG
          ModuleHandle = GetModuleHandle("CallFunction.exe")
          'ModuleHandle = LoadLibrary("CallFunction.exe")
          'FunctionAddress = GetProcAddress(hInst, BYCOPY ucase$(FunctionToCall))
          FunctionAddress = GetProcAddress(ModuleHandle, BYCOPY UCASE$("StartTracePort"))
          MSGBOX STR$(ModuleHandle) + $CR + STR$(FunctionAddress)
          END FUNCTION
          
          FUNCTION StartTracePort ALIAS "StartTracePort"() EXPORT AS LONG
               MSGBOX FUNCNAME$
          END FUNCTION
          I have to wonder if its because the exported function is within this exe itself? or if thats the case, wouldn't that also be true if it were in a dll that is mapped into my program's memory space?????

          Either that or I am doing something wrong
          Engineer's Motto: If it aint broke take it apart and fix it

          "If at 1st you don't succeed... call it version 1.0"

          "Half of Programming is coding"....."The other 90% is DEBUGGING"

          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

          Comment


          • #6
            Give me a :doh:, please:
            Code:
            FunctionAddress = GetProcAddress(ModuleHandle, BYCOPY UCASE$("StartTracePort"))
            ...
            FUNCTION StartTracePort ALIAS "StartTracePort"
            MCM
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              :doh::doh::doh::doh:
              Ok that fixed my example, but not my real code. Now I have to find another way to demo my problem, or find the problem in my much larger code

              Thanks MCM, I should have seen the doh syndrome before, but I have been staring at this farrrrr too long.
              Engineer's Motto: If it aint broke take it apart and fix it

              "If at 1st you don't succeed... call it version 1.0"

              "Half of Programming is coding"....."The other 90% is DEBUGGING"

              "Document my code????" .... "WHYYY??? do you think they call it CODE? "

              Comment


              • #8
                Add on another :doh: point (I am really racking up the points today)
                Engineer's Motto: If it aint broke take it apart and fix it

                "If at 1st you don't succeed... call it version 1.0"

                "Half of Programming is coding"....."The other 90% is DEBUGGING"

                "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                Comment


                • #9
                  Yes, you earned that :doh:, BUT.... you also get , as the late Rodney Dangerfield would have said, "One-A-Dese" ===> :arco:

                  Why?

                  Because you - unlike several of your colleagues - DID post sufficient code to diagnose the problem.

                  MCM
                  Michael Mattias
                  Tal Systems (retired)
                  Port Washington WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment

                  Working...
                  X