What are required changes from 32 to 64 bit assember for calling C++ classes in a dll

[pamen]

Hi
I'm trying to modernize and extend
this nice (and working in 32 bit) prototype module for codejock components

viewtopic.php?p=401483&hilit=skinframework#p401483

I'm a complete newbie to assembler, so I'm fighting with it a bit

in this case in 32 bit the instruction is MOV ECX, (Pointerto C++ class in a dll)
this causes assembler error about quad size mismatch
In 64 bit I would assume it should change to MOV RCX...

how should a function call look like for this situation?
Is there an easier way to call objects in C++ libraries from PB, just as there is an easy way to call C functions via prototypes?

[idle]

Fastcall is only x86
For x64 you don't need to do anything just import and call the functions as normal.

[pamen]

Thank you Idle
But as the functions requires an object (it is C++ with objects), I do not really understand how to translate a
function which supposed to be called on an instance of an object into PureBasic prototype.

for example there is a simple Method in C++
(see original x86 post for details (viewtopic.php?p=401483&hilit=skinframework#p401483) ) :

Code: Select all

COLORREF GetThemeSysColor(int iColorId);

this function needs to be invoked on an live instance of an object, not globally.
The C++ MFC class is in this case

Code: Select all

class _XTP_EXT_CLASS CXTPSkinManagerClass : public CXTPSynchronized

is the one with methods.

so I need first to instantiate CXTPSkinManagerClass somehow and then call methods first (as it is done in the old x86 code).

how do I translate this into PB without ASM in x64?

[idle]

I don't know the call convention should be standard for x64 no need to manipulate the call convention you should be able to use interfaces assuming the c++ classes are pure virtual classes.
If you don't use interface the 1st parameter is a this pointer
Sorry I'm on phone

[pamen]

Thank you.
An example based on the quoted post would be truly appreciated. Not during a phone call, certainly.

[idle]

You should be able to use the interface directly like this on x64

Code: Select all

ImportC #CODEJOCK_LIB
  XTPSkinManager() As "?XTPSkinManager@@YAPAVCXTPSkinManager@@XZ"   ;check the name 
EndImport

;-INTERFACES
Interface ICSkinFramework
  Free()
  
  ApplyColorFilter(clr.l)
  ApplyWindow(hWnd.i)
  EnableCurrentThread()
  EnableThemeDialogTexture.l(hWnd.i, dwFlags.l)
  ExcludeModule(lpszModule.s)
  FreeSkinData()
  
  GetApplyOptions.l()
  GetAutoApplyNewThreads.l()
  GetAutoApplyNewWindows.l()
  GetThemeSysBool.l(iBoolId.l)
  GetThemeSysColor.l(iColorId.l)
  GetThemeSysFont.l(iFontId.l, *plf)
  GetThemeSysSize.l(iSizeId.l)
  
  IsColorFilterExists.l()
  IsComCtlV6.l()
  IsEnabled.l()
  IsWin9x.l()
  
  LoadSkin.l(lpszResourcePath.s, lpszIniFileName.s = "")
  RedrawAllControls()
  Remove(hWnd.i)
  RemoveAll(bDetach.l = #True)
  RemoveColorFilters()
  SetApplyOptions(dwOptions.l)
  SetAutoApplyNewThreads(bAutoApply.l)
  SetAutoApplyNewWindows(bAutoApply.l)
EndInterface

*CSkinFramework.ICSkinFramework =  XTPSkinManager()

or like this

Code: Select all

XTPSkinManager_GetThemeSysColor.l(*this,iColorId.l) As "?GetThemeSysColor@mangledName.... 

[pamen]

Thank you,
Golden.
Will try tomorrow, my time zone tells me to quit fir few hours.

[idle]

Thank you,
Golden.
Will try tomorrow, my time zone tells me to quit fir few hours.

I hope it works, I would test it but I'd have to register to download the sdk.

[pamen]

Invalid Memory access on first call,
declarations are ok, Dll is supposedly 64 and 32 bit (works in VS C++ for 64 ad 32) but maybe the 64Bit has a different name?

How do I get the object/functions names out any tools for that?

Here is the whole test "project" with dependencies (eval) if you would care to see
https://seafile.mandalian.net/f/33d51b0 ... 8933/?dl=1 (link will expire in a day)

[idle]

Im away from pc for the night and have to rebuild a server tomorrow, lots fun.
If you have mingw64 on your system you can use nm -u for dynamic symbols.
But you can probably open the dll with openlibray and Debug the function name.
I can't remember the windows equivalent to nm
I will down load the link in the morning

[pamen]

Thank you, have a good Saturday!

[idle]

link expired

[pamen]

I think not
but please try again and let me know:

https://seafile.mandalian.net/f/33d51b0 ... 8933/?dl=1

or without download:
https://seafile.mandalian.net/f/33d51b097b474aa58933/

[Olli]

How do I get the object/functions names out any tools for that?

Hello !

Please note, you can get several DLL files informations, through the native pureBasic library :

https://www.purebasic.com/documentation ... index.html


You can perform a functions list, of the function names inside a DLL file.

LibraryFunctionName()

-> You have to create a While... Wend loop for that.

Code: Select all

; by skywalk, pureBasic forum
; lightly modified by olli
; debugger must be on
lib=OpenLibrary(#PB_Any,"c:\windows\system32\msvcrt.dll")
If lib
  If ExamineLibraryFunctions(lib)
    While NextLibraryFunction()
      Debug LibraryFunctionName()
    Wend
  EndIf
  CloseLibrary(lib)
EndIf

If the function names of the DLL library have strange symbolic suffixes, we can say the function names are decorated (synonyme : mangled )

The syntax convention of these symbols depends of the root compiler used to compile these DLL files.

Wikipedia.org :: library function - mangled name


So, a first check consists in knowing exactly from which compiler your DLL was created.

Then, you retrieve the mangling convention. And, sometimes, in example, on Microsoft, that is not only an array documention, you can get about mangling convention, but directly a converting function :

Code: Select all

Procedure.S Undec(Name.S)
*Decorated = AllocateMemory(512)
PokeS(*Decorated, Name, -1, #PB_Ascii)
UnDecorateSymbolName_(*Decorated, *Decorated + 256, 256, 0)
ProcedureReturn PeekS(*Decorated + 256, -1, #PB_Ascii)
EndProcedure
; Exemples
Debug Undec("?myFunction@@YAXH@Z")
Debug Undec("?myFunction@@YAXHDC@Z")

Also you have any difference between 32 and 64 bits call conventions.

The cause : more hardware registers on 64 bits CPU so they are used in the arguments.

Two general ways :
1) registers use
2) stack use

If way #2, it will be easy to convert it.
If way #1, it will be hard to convert it. (converting time)

After the call convention, it stays the aspects, of what does the function call itself ? No ever easy to follow the 64 bits converting, if the function calls any other 32 bits sub-functions.

And between the calls, you have the processor instructions which are specific to the bit range : 32 or 64 bits.

So, sometimes, the source code should be presented, and it is the compiler which does the job.

[pamen]

Thank you Olli
Excellent summary.
I did already the dump of mangled functions and tried to declare them / create prototypes as Idle proposed with mangled names.
This just throws for me memory access error / no object at that address...
I do understand the basics after ~35 years of programming.

I do have also all the C++ header files, so theoretically I could just convert the .h files or use them directly as !Include
My real problem is the lack of knowledge in PB to write a call in 64 bit.
in 32 bit it works fine with fastcall using ASM calls to set the object before calling its methods.

I should have also source code if I buy it (Codejock comes with sources as I gather), but for now I have only .h headers.

I desperately need an example related to this specific lib, not generic, I'm lost.