End address of a Proc?

[Markus Kemnitzer]

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

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

[Cecil Williams]

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

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

[Lance Edmonds]

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>

[Markus Kemnitzer]

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

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

[Cecil Williams]

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

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

[Michael Mattias]

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

$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

[Eric Pearson]

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

[Markus Kemnitzer]

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

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