xsharp.eu

Wolfgang,

PCall needs a typed function pointer. PCallNative can work with an untyped function pointer. The parameter to PCall can either be a local, an instance variable or a (Static) global.

The compiler needs to be able to find the function definition because it uses that function definition as template for the delegate it creates.

Robert

Hi Robert,
I am not sure if I understand this fully.
If PCall needs a typed function pointer, it cannot be used with a dynamically loaded DLL, because there will be no typed function pointer.
Is this true?
Thank you very much for your patience!
Wolfgang

Hi Wolfgang,

Try using a dummy function defined in your main code, which has the same parameters and return type with the one you will call from the dynamically loaded dll, I think this should do the trick.

The reason why your code does not work in vulcan, is that as I said PCALL() was not originally and never officially supported in vulcan, it was only patched to work in specific circumstances (found in the VOSDK) later. So in vulcan it does not work when the function pointer is typed in a LOCAL, it needs to be on a GLOBAL instead. That's because this is how PCALL() is/was used in the SDK, at least in most cases.

In X#, we decided to be more compatible with VO (as usual!) also in this aspect, so as Robert said he added support for typed function ptrs also in LOCALs, instance vars etc.

Chris

Hi Chris,

thank you very much for the explanation, it is not clear to me (I hope to understand it now correctly).

I have modified again the text in the documentation: https://docs.xsharp.it/doku.php?id=vo_to_net:pcall, and I hope it is now correct and understandable.

In my current migrated VO code I will need to leave PCallNative() because I have no global function pointers.

Wolfgang

Oh, i see now that there are several things mixed: I do not have a vulcan compiler. My intenson was that my posted pcall / pcallnative code compiles:

1. with X# using the vulcan runtime

and

2. with VO

regards
Karl-Heinz

Hi Karl-Heinz,

VO is the easiest one <g>. The problem I see now (at least for my own code) that I will need the version with the Vulcan runtime for a limited time.

Please let me know if you think that I have specify it better in the docs page.

Wolfgang

Hi Wolfgang,

Just one correction, that issue does not have to do with the runtime, it's just a compiler thing. Only when using the vulcan _compiler_ you will not be able to use PCALL() with LOCAL function PTRs, but if you use X#, then you can use PCALL() fine in any case and no matter what runtime you are using.

Chris

Hi Chris,

ok, thank you. I will change the page accordingly.
So to use PCall() and PCallNative() we don't need any runtime, but the compiler itself resolves the call.

Please correct me if I'm wrong: PCallNative() does not need anything special - it needs only that the return type is specified, so it is the simplest call (and of course the one with the most risk to do something wrong).
PCall() needs a correct declaration of the prototype of the called function, and generates code from it. But since also PCall() assumes something, it has some risk.

The best option to call a function from a dynamically loaded DLL is to define a delegate, assign the function pointer to it and call then the delegate.

In VO, dynamically loading DLLs and executing function from it was interesting to make the application loading times shorter, but in .NET thanks to its lazy loading this is not more necessary.

Executing functions dynamically is only needed when you are not sure that the functionality is installed, or if you are using different versions dependend on some other parameters like OS version or 3rd party DLL version.

Wolfgang

Hi Wolfgang,

wriedmann wrote: ok, thank you. I will change the page accordingly.
So to use PCall() and PCallNative() we don't need any runtime, but the compiler itself resolves the call.

Ah, yes, should had noted that PCall() and PCallNative() are not real functions, defined in a dll, they are pseudo-functions ("intrinsic" is the correct term I think) that are handled directly by the compiler. Same as TypeOf(), SizeOf(), ),_And(), _Or(), _Not(), PCount() etc, those are all translated to executing special code by the compiler, they do not exist as real entities.

wriedmann wrote: Please correct me if I'm wrong: PCallNative() does not need anything special - it needs only that the return type is specified, so it is the simplest call (and of course the one with the most risk to do something wrong).
PCall() needs a correct declaration of the prototype of the called function, and generates code from it. But since also PCall() assumes something, it has some risk.

The best option to call a function from a dynamically loaded DLL is to define a delegate, assign the function pointer to it and call then the delegate.

In VO, dynamically loading DLLs and executing function from it was interesting to make the application loading times shorter, but in .NET thanks to its lazy loading this is not more necessary.

Executing functions dynamically is only needed when you are not sure that the functionality is installed, or if you are using different versions dependend on some other parameters like OS version or 3rd party DLL version.

I agree, in .Net using PCALL() and PCallNative() is very rarely if ever needed, in .Net we have the tools we were missing in VO (interfaces, delegates, events etc) to implement similar functionality in a safe way. Using PCALL() and PCallNative() will never be safe really, because you can easily use the wrong params in PCallNative() or use the wrong function signature for PCALL() and the compiler cannot know about it to warn you, you will found about it at runtime only. But yeah, I guess you could say PCALL() is "safer", because you at least can completely specify yourself the signature of the function, instead of letting the compiler find out from the params you use.

Chris

Hi Chris,

IMHO PCall() and PCallNative() are needed only for code that needs to be compatible to VO.

For all other purposes the .NET functionality should be used.

But at least in my VO projects there are really a lot of such calls - in the project where I'm currently working there are 190 PCall() calls.

Wolfgang