Announcement

Collapse
No announcement yet.

End address of a Proc?

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

  • End address of a Proc?

    Hello,

    don't wondering: additional to PB/DLL I'm using a fine (german) interpreter language called Profan² (www.profan.de). This can take dll's normally but also I would take functions and procs like the old gw-basic-way, means writing the native code in a memory block manually and calling it (getting later only one exe without dll's...). For this it's necassary to extract the proc-code from a dll. Taking CodePtr (or GetProcAddress() ), but how to get the end-address? Does anybody knows this? Thanks for help!

    Regards
    Markus

    ------------------


  • #2
    Markus,

    I'm scratching my head here, wondering why you would want
    the end address of a procedure. All you need to execute
    the prodedure is the starting address in memory.

    Could you explain in more detail why?

    Cheers,
    Cecil

    ------------------

    Comment


    • #3
      Not to mention possible problems with relocation, the embedded PowerBASIC Run-Time Library and it's initialization, etc...

      What a nightmare...

      Markus, maybe I'm missing something here, but I'm afraid I don't see the point of doing this at all...

      I can only guess that PROFAN2 does not support static linking?

      Why not write the whole app in PowerBASIC and #INCLUDE the DLL source code directly into the application? It might just be easier...

      ------------------
      Lance
      PowerBASIC Support
      mailto:[email protected][email protected]</A>
      Lance
      mailto:[email protected]

      Comment


      • #4
        Cecil, Lance,

        thanks for your replies!

        Cecil, calling a function via its address is okay but:

        I don't want to call it out of a dll, but extracting the native code before from the dll and write manually to a memory block for the language Profan²...

        Further, Lance, you are right: Profan² has no static linking and when I'm writing Profan² programs, mostly I take PB-DLL to get more speed and features. Profan² is an interpreter language, very easy to use and to debug, for small things sometimes better than taking PB/DLL (uups).

        But you can't create e.g. callbacks inside Profan² and (the main problem) most of the Profan² users want to create standalone exe's, so: a fine method would be to take native code inside Profan (it's possible to write byte-values in a memory block...) and afterwards calling it with the Profan² aquivalent of Call Dword. I have an example of another programmer making this method and - in this case - it works. I'm writing tools and includes for Profan² and - Cecil - that's the main reason for having a solution to embed nativ (PB/DLL-)Code inside Profan² ;-)

        Lance, I thought about problems cause of the PowerBASIC Run-Time Library but maybe some functions could work. I thougt to give this way a try.

        Thanks!
        Greetings to Knoxville and Auckland

        Markus

        ------------------

        Comment


        • #5
          Markus,

          I think I understand where you're coming from now. I don't
          have the time to get familiar with Profan2 API but if it
          supports the Win32 API, then I would suggest run-time linking
          with the PB dll library and use the GetProcAddress function
          to feed the Call Dword function in Profan. Whether or not
          this is possible, I have no clue.

          Good luck with the interface!!!

          Cheers,
          Cecil

          ------------------

          Comment


          • #6
            Not that I fully understand the need for it, but...

            Code:
            $COMPILE DLL
            
            FUNCTION MyDllFunction (parms) EXPORT AS LONG
            
            yadda, yadda
            
            Label:
            END FUNCTION
            FUNCTION EndofProc () EXPORT AS LONG
            
             FUNCTION = CODEPTR(Label)
            END FUNCTION
            
            $COMPILE EXE
            
            DECLARE FUNCTION GetEndOfMyDllProc AS LONG
            FUNCTION pbMain () AS LONG
            
            
              MyDllProcStart = GetProcAddress ("MyDllFunction")
              CallAddr = GetProcAddress ("EndofProc")
              Call DWORD CallAddr USING GetEndofMyDllProc TO MyDllEndProc
            
            END FUNCTION
            No, I haven't tested it. Might be worth a shot. Maybe someone with a dis-assembler can comment on what happens at the end of a function as shown.

            That, or maybe you may assume the first function in a DLL ends one DWORD boundary prior to the start of the second function in the DLL.

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

            Comment


            • #7
              Markus --

              I hate to see you going down a blind alley...

              IMO it is simply not possible to do what you are describing. You can't just pull a function out of a DLL or EXE as a "binary block" and expect it to function in another program. Even a function that is 100% ASM would almost certainly rely on the PB runtime library. More conventional BASIC code would require lots of references to the RTL, plus Windows core DLLs, among other things. And because PB is so efficient, it does not place redundant copies of those things in the object file. It places references in the file, to point to things outside the actual function.

              Executable files are not the same thing as "static link libraries". You can't chop them up into pieces.

              -- Eric


              ------------------
              Perfect Sync Development Tools
              Perfect Sync Web Site
              Contact Us: mailto:[email protected][email protected]</A>

              [This message has been edited by Eric Pearson (edited June 21, 2001).]
              "Not my circus, not my monkeys."

              Comment


              • #8
                To all: Thank you very much for your reactions.

                The method will fail because of possible references to the PB-RTL, but another peoble reched it.
                I have a fine example but (this wekend) no time to prepare this for you to download and
                explaining Profan² code. I'm trying this next week, not to solve the
                problem, but to show you what I mean...

                Again, thanks to all!

                Best regards,
                Markus

                ------------------

                Comment

                Working...
                X