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

[Olli]

I could not answer again after (I must sleep and work tomorrow).

So, a measurement process you can test.

1) retrieve the program configuration which gave you an error message on x64 (Invalid memory access, it seemed).

2) test the CPU stack register : RSP before, and after a call. The right way should be the same.

Code: Select all

Global.i stackBefore, stackAfter

...
! mov [v_stackbefore], rsp
; your bugged call
! mov [v_stackafter], rsp
...

If you see stackBefore and stackAfter variables are different themselves, lots of chance to know the problem is here.

In this way, the problem will be found and solvable.

And I see idle is waking up when I go to the sleep !!!

Your dung will work soon!!!

[pamen]

Have a good night Olli,
I did not try to port the ASM code, I wanted to simplify and not to use ASM, but let's see what Idle will figure out.
If it works - then my email client will finally not just work as it already does but also look a bit more modern

[idle]

ok It's not complicated but it'll be fiddly if you want to make it transparent to user
the reason you couldn't use the interface directly is simply because it doesn't match the exported functions
easy way call it flat on x64 and import with *this as 1st parameter

Code: Select all

CompilerIf #PB_Compiler_32Bit
  XIncludeFile "SkinFramework.pbi"
CompilerElse
 ; XIncludeFile "SkinFramework64.pbi"
CompilerEndIf

Global Window_0
Global Button_0, Button_1, Text_0, String_0

Procedure InitWindow_0()
  Window_0 = OpenWindow(#PB_Any, 0, 0, 600, 400, "", #PB_Window_SystemMenu)
  Combo_0 = ComboBoxGadget(#PB_Any, 30, 40, 100, 25)
  Checkbox_0 = CheckBoxGadget(#PB_Any, 180, 40, 100, 25, "")
  Date_0 = DateGadget(#PB_Any, 390, 40, 100, 25, "")
  ListIcon_0 = ListIconGadget(#PB_Any, 60, 120, 410, 100, "Column x", 100)
  AddGadgetColumn(ListIcon_0, 1, "Column 2", 100)
  AddGadgetColumn(ListIcon_0, 2, "Column z", 100)
  For i =0 To 200
    AddGadgetItem(ListIcon_0, -1, "Item " + Str(i))
  Next
  Tree_0 = TreeGadget(#PB_Any, 60, 240, 400, 130)
  AddGadgetItem(Tree_0, -1, "ROOT")
  AddGadgetItem(Tree_0, -1, "Something", 0, 1)
  AddGadgetItem(Tree_0, -1, "More", 0, 1)
  AddGadgetItem(Tree_0, -1, "Less", 0, 2)
  AddGadgetItem(Tree_0, -1, "Dummy", 0, 2)
  AddGadgetItem(Tree_0, -1, "Butter", 0, 2)
  Container_0 = ContainerGadget(#PB_Any, 230, 80, 330, 25)
  Checkbox_1 = CheckBoxGadget(#PB_Any, 170, 0, 100, 25, "")
  CloseGadgetList()
EndProcedure

  Debug GetCurrentDirectory()
  SetCurrentDirectory(GetCurrentDirectory())
CompilerIf #PB_Compiler_32Bit =0
  
 #CODEJOCK_LIB = "ToolkitProEval2210vc170x64UD.lib"

ImportC #CODEJOCK_LIB
  XTPSkinManager() As "?XTPSkinManager@@YAPEAVCXTPSkinManager@@XZ" 
  LoadSkin.i(*this,lpszResourcePath.p-unicode, lpszIniFileName.p-unicode) As "?LoadSkin@CXTPSkinManager@@QEAAHPEB_W0@Z"
  SetAutoApplyNewThreads(*this,bAutoApply.l) As "?SetAutoApplyNewThreads@CXTPSkinManager@@QEAAXH@Z"
  SetAutoApplyNewWindows(*this,bAutoApply.l) As "?SetAutoApplyNewWindows@CXTPSkinManager@@QEAAXH@Z"
  ApplyWindow(*this,hwnd.i) As "?ApplyWindow@CXTPSkinManager@@QEAAXPEAUHWND__@@H@Z"
EndImport
  
 Define *CSkin   
 Define lib =0
 Debug "x64"
 
 *CSkin = XTPSkinManager()
  SetAutoApplyNewThreads(*Cskin,1)
  SetAutoApplyNewWindows(*cskin,1)
  my_skin.s = GetCurrentDirectory() + "DXB.cjstyles"
  Debug LoadSkin(*CSkin,my_skin, "")
  
CompilerElse

  Define Skin.CSkinFramework = New_CSkinFramework()
  Skin\SetAutoApplyNewThreads(1)
  Skin\SetAutoApplyNewWindows(1)
  my_skin.s = GetCurrentDirectory() + "DXB.cjstyles"
  Skin\LoadSkin(my_skin, "")
CompilerEndIf

InitWindow_0()

Repeat
  event = WaitWindowEvent()
Until event = #PB_Event_CloseWindow

If lib
  CloseLibrary(lib)
EndIf

[pamen]

Excellent and Splendid, Simple and to the point!
Thank you very much and apologies for not thinking about it earlier.
64Bit works lovely.
When I have a full and tested .pbi I will post it in a separate thread.

Now - I see that this approach does not work with 32 bit, but it would be much easier to have a similar approach, without ASM tricks.
I assume there I must also consider something I missed?

[idle]

I think I created a fastcall patch with a fasm macro, might have been for irrlicht lib but I can remember how it worked.

[pamen]

So you think for 32 bit it is necessary to use ASM?
There is no way to use similar, simpler approach as in 64 bit?
both lib versions are modern, Unicode libs, so i would assume something simple would work, just don't know what.

[idle]

no x86 windows you need to patch it because of the thiscall convention, I will have a look tomorrow if I have time

[pamen]

ok.
Thanks.

[Olli]

@idle

Congratulations, and thank you !

[idle]

@idle

Congratulations, and thank you !

Your welcome

[HeX0R]

Code: Select all

CompilerIf #PB_Compiler_32Bit =0

That's interesting, I thought that would be wrong, I usually use:

Code: Select all

CompilerIf #PB_Compiler_Processor = #PB_Compiler_32Bit

but in fact that constant holds a different value, depending on the compiler used.

[idle]

Lol I don't think I really though about it, I just found it worked much to my surprise

[Fred]

It's described here: https://www.purebasic.com/documentation ... tives.html

[HeX0R]

It's described here: https://www.purebasic.com/documentation ... tives.html

Hmm... not really?

#PB_Compiler_Processor : Determines the processor type for which the program is created. It can be one of the following:
#PB_Processor_x86 : x86 processor architecture (also called IA-32 or x86-32)
#PB_Processor_x64 : x86-64 processor architecture (also called x64, AMD64 or Intel64)
#PB_Processor_arm32 : arm32 processor architecture
#PB_Processor_arm64 : arm64 processor architecture (also called M1 on Apple computers)

I can't see anywhere, that #PB_Processor_x86 has a different value, when a x86 or a x64 compiler is used?
Doesn't that mean "#PB_Compiler_Processor" is completely useless?

[idle]

It's right down the bottom of the page