In the first Vulcan versions, PCall was not supported, so this code would not have worked:

PCall( ptrFunction, @strWinOsVersionInfo )

There was only a function PCallNative to use (knowing the return type):

PCallNative<int>( ptrFunction, @strWinOsVersionInfo )

Only later also support for PCall was added inofficially to the Vulcan runtime because it was used very often in the VO SDK. It can not be used when the function pointer is defined in a local, but it needs to be defined in a global (like it was used in the VO SDK). To call a function dynamically with a locally defined function pointer, the PCallNative function is needed. In the X# runtime the development team changed the behavior and used another approach, so they recommend to use again PCall.

The following was stated by a member of the development team:

A delegate is created by the compiler and the parameters for the delegate have to be determined by the compiler . In the case of PCallNative it looks at the actual arguments to “guess” the types. The return type is then the type as specified in the code. In the case of PCall it copies both the parameter types and return value of the function in the declaration to the delegate. The compiler then emits the code to use the native function pointer and call this with the managed delegate. For this reason I would recommend using PCall because the function name used in the declaration gives you full control of the parameter types in the delegate.

Please see major details in the X# Forum discussion: www.xsharp.info/forum/public-product/752-voxporter-icon-naming-problem