VOXporter - Icon (?naming?) problem

More
4 months 1 week ago #1 by Karl-Heinz
VOXporter - Icon (?naming?) problem was created by Karl-Heinz
i have a number of icons, but only a icon named "Delete.ico" causes a problem.

the VO code:

CLASS IconDeLete INHERIT Icon
RESOURCE IconDeLete Icon D:\VOImages\Delete.ico
METHOD Init(kLoadoption, iWidth, iHeight) CLASS IconDeLete
SUPER:Init(ResourceID{"IconDeLete", _GetInst()},kLoadoption, iWidth, iHeight)
RETURN SELF

is translated to:

CLASS IconDeLete INHERIT Icon

CONSTRUCTOR(kLoadoption, iWidth, iHeight)
SUPER(ResourceID{"IconDeLete", _GetInst()},kLoadoption, iWidth, iHeight)
RETURN SELF

END CLASS

but the created entry in the rc file is:

IconDeLete Icon D:\VOImages\65536.ico

of course, when i manually change 65536.ico to delete.ico it compiles.

regards
Karl-Heinz

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #2 by robert
Replied by robert on topic VOXporter - Icon (?naming?) problem
Karl Heinz,

This probably happens because there is a define DELETE in VO with the value 0x00010000L

The Transporter finds this define and replaced the name in the resource with the value of the define.
We will have a look at this and will try to fix this for the next build.

Robert

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #3 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
Yes, this is fixed now. Karl Heinz, if you need a quickfix for this please let me know, it's easy to send it.

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #4 by Karl-Heinz
Replied by Karl-Heinz on topic VOXporter - Icon (?naming?) problem
Hi Chris,

no hurry, i can wait - currently i´m playing with the hardcore stuff - Pcall , extension methods, delegates ;-). My first goal is to change only things that are absolutly neccessary. i´ve tried Pcall and PCallNative and both work. Maybe Wolfgang can update his Pcall articel ?

docs.xsharp.it/doku.php?id=vo_to_net:pcall

The attached zip contains two files ( start.prg and funcs.prg ) that use Pcall and PcallNative to call RtlGetVersion() .The only change that needs to be made in existing code is to type the Pcall function ptr. But such things are already used in the vo sdk sources ( std_dlg.prg ) and if the VO compiler would have forced us in the past to use a typed ptr only, it would already be there ;-)

BTW. what´s the difference between PCall and PCAllNative ? It´s clear that PCall wants a typed pointer, while PCallNative doesn´t ? Which one is recommended to use ?

regards
Karl-Heinz
Attachments:

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #5 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
Hi Karl-Heinz,

PCallnative() was introduced in vulcan as a replacement to PALL() and I'm pretty sure PCALL() was originally not meant to be supported at all, all PCALL() calls were supposed to be converted to PCAllNative(). But what I think happened, is that Don Caton (who originally wrote the biggest part of vulcan) realized down the way that PCALL() is used extremely often, especially in the VOSDK code and he did not want to make so many dozens of changes, so he eventually added support to the compiler for PCALL() as well :)

We added support for PCALL() in X# as well, and the way it works is that it derives the return type of the function from the code. So in the case of your sample, the compiles sees you have

LOCAL hFunc AS __GetRealOsVersion PTR

so it goes to the definition of this function:

STATIC FUNCTION __GetRealOsVersion( struOS AS _winOSVERSIONINFOEX) AS DWORD PASCAL

and it sees that the return type is DWORD, so it does not require you to explicitly provide it, with PCallNative().

Other than that, the function type in the LOCAL declaration is ignored, the local is actually emitted in the binary as

LOCAL hFunc AS PTR

So, in general, I'd say it's probably better to use PCallNative(), as this is cleaner I think, but then again, if you have lots and lots of PCALL()s, I don't think it's really important to go through changing all of them...

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago - 4 months 1 week ago #6 by robert
Replied by robert on topic VOXporter - Icon (?naming?) problem
Chris,

Sorry to interrupt, but it actually works differently. 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.
Vulcan works differently. I uses an IL instruction that is not available in /supported by Roslyn.

Robert

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.
Last edit: 4 months 1 week ago by robert.

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #7 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
Robert,

Ah right, vulcan used calli, had forgotten about that, thanks. Yeah about the X# implementation I just didn't go into the implementation details of creating a delegate etc.

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #8 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
Hi Karl-Heinz,
I will update the documentation later today.
Wolfgang

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #9 by Karl-Heinz
Replied by Karl-Heinz on topic VOXporter - Icon (?naming?) problem
Hi Chris and Robert

thanks for your valueable inside views !

I think i´ll do it that way:

FUNCTION GetRealOsVersion( dwMajor REF DWORD  , dwMinor REF DWORD , dwBuild REF DWORD ) AS LOGIC  PASCAL  
LOCAL struOS IS  _winOSVERSIONINFOEX
LOCAL hFunc AS PTR    // <----- no typed ptr required. Works on both sides ( VO and X# )
LOCAL lOk AS LOGIC
 

	
	IF ( hFunc := GetProcAddress(  GetModuleHandle( String2Psz ("Ntdll") ) , String2Psz ( "RtlGetVersion" ))) != NULL_PTR 
		
			struOS.dwOSVersionInfoSize:= _SIZEOF ( _WINOSVERSIONINFOEX )
			
			#IFDEF __XSHARP__
			
			IF PCALLnative <DWORD> ( hFunc , @struOS ) == 0
				
			#ELSE
			
			IF  DWORD ( _CAST , PCALL ( hFunc , @struOS) )  == 0			
			
			#ENDIF 	
			
				dwMajor := struOS.dwMajorVersion
				dwMinor := struOS.dwMinorVersion
				dwBuild := struOS.dwBuildNumber
			
				lOk := TRUE  
				
			ENDIF 	
		
	ENDIF		
	
RETURN  lOk 

So there´s no need to declare any additional functions. The only change would be to add a #ifdef directive


BTW. Ok, this is nonsense, but it works :-)

IF ! PCALLnative <LOGIC> ( hFunc , @struOS )
:woohoo:
ENDIF

regards
Karl-Heinz

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago - 4 months 1 week ago #10 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
Hi all,

I have now changed the page in the docs project:

https://docs.xsharp.it/doku.php?id=vo_to_net:pcall

but I don't think it is correct because I'm not able to compile this code using the Vulcan runtime:
local ptrHandle as ptr  
local ptrFunction as ptr
ptrHandle := GetModuleHandle( String2Psz( "ntdll" ) )
ptrFunction := GetProcAddress( ptrHandle, String2PSZ( "RtlGetVersion" ) )
PCall( ptrFunction, @strWinOsVersionInfo )
Only the code using PCallNative works:
PCallNative<int>( ptrFunction, @strWinOsVersionInfo )

Wolfgang

P.S. I cannot use the X# runtime in this project yet as I would need the VO compatible class libraries
Last edit: 4 months 1 week ago by wriedmann.

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #11 by robert
Replied by robert on topic VOXporter - Icon (?naming?) problem
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

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #12 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.

More
4 months 1 week ago #13 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 6 days ago #14 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.

More
4 months 6 days ago #15 by Karl-Heinz
Replied by Karl-Heinz on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.

More
4 months 6 days ago #16 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.

More
4 months 6 days ago #17 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 5 days ago #18 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.

More
4 months 5 days ago #19 by Chris
Replied by Chris on topic VOXporter - Icon (?naming?) problem
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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
4 months 5 days ago #20 by wriedmann
Replied by wriedmann on topic VOXporter - Icon (?naming?) problem
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

Please Log in or Create an account to join the conversation.