
What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
It's described here: https://www.purebasic.com/documentation ... tives.html 

Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Hmm... not really?Fred wrote: Tue Sep 12, 2023 3:56 pm It's described here: https://www.purebasic.com/documentation ... tives.html![]()
I can't see anywhere, that #PB_Processor_x86 has a different value, when a x86 or a x64 compiler is used?#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)
Doesn't that mean "#PB_Compiler_Processor" is completely useless?
{Home}.:|:.{Dialog Design0R}.:|:.{Codes}.:|:.{History Viewer Online}.:|:.{Send a Beer}
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
It's right down the bottom of the page
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
This short recall of Fred is real.
#PB_Compiler_32bit is a logical value (0 or 1) (last list in the doc page)
It is not the way of
#PB_Processor_x86
which is one of the values that #PB_Compiler_Processor may be, if the compiler works on a 32 bits x86 system.
I am going to rest. Nice time to you !
#PB_Compiler_32bit is a logical value (0 or 1) (last list in the doc page)
It is not the way of
#PB_Processor_x86
which is one of the values that #PB_Compiler_Processor may be, if the compiler works on a 32 bits x86 system.
I am going to rest. Nice time to you !
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Damn... I mixed up #PB_Processor_x86 with #PB_Compiler_x86, sorry for the disturbance, I'll shut up from now on
{Home}.:|:.{Dialog Design0R}.:|:.{Codes}.:|:.{History Viewer Online}.:|:.{Send a Beer}
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
I will immediately stop posting silly questions like these as they obviously cause psychological damage afterwards.
Promise.
Promise.
S.T.V.B.E.E.V.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll

(me) : << use the native library... maybe... >>
(paman) : << but I already use that ! I have more than 30 years of professionnal computing in my mind... And this mail box is more ugly than your... >>
(me) : << ok, ok... oop... oop... uh... problem of polymorphism, maybe ? >>
(paman) : << but... there is no polymorphism there ! 34 years, 34 years ! >>
--> there are not silly questions. And I think each subject, about interactions between pureBasic and other languages, is as epic as useful.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Here is the still very ugly result of your help.
Thanks Idle - appreciation!
And Ollie - once I understand your sense of humor, I will revert.
(forum does not load that in preview, so link instead)
Image 1: https://freeimage.host/i/JHEui5F
Image 2: https://freeimage.host/i/JHEuPJ1
I did not have time to make my own skin design, when I do, will post it .
Thanks Idle - appreciation!
And Ollie - once I understand your sense of humor, I will revert.
(forum does not load that in preview, so link instead)
Image 1: https://freeimage.host/i/JHEui5F
Image 2: https://freeimage.host/i/JHEuPJ1
I did not have time to make my own skin design, when I do, will post it .
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Take your time, to build a "before/after" picture. (Added : I found several links under the image stock page, you used)pamen wrote:I did not have time to make my own skin design, when I do, will post it .
Pass the humour of my recent synthesis of a fake dialog, and consider your question is VERY interesting.
The answer is also very interesting.
This shows pureBasic is compatible with lots of external interfaces.
Note also that the polymorphism is doable on pureBasic, but requires a pre-compiling time. This feature can be created by a homemade IDE tool. But it will be certainly in an other specific subject.
one of your pictures : (before)

(after)

Last edited by Olli on Sat Sep 16, 2023 4:22 pm, edited 1 time in total.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Looks good.pamen wrote: Fri Sep 15, 2023 6:39 pm Here is the still very ugly result of your help.
Thanks Idle - appreciation!
And Ollie - once I understand your sense of humor, I will revert.
(forum does not load that in preview, so link instead)
Image 1: https://freeimage.host/i/JHEui5F
Image 2: https://freeimage.host/i/JHEuPJ1
I did not have time to make my own skin design, when I do, will post it .

Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
I have such brain latency, that I did not understand the two pictures were a "before/after" comparison !
I edited my previewing message.
@pamen
If you quote my last message with your picture, you could see the several markup used to show the images, in the editing scope. The second image is the bbcode suggest link content presented in the image host site.
Looks already better.
I edited my previewing message.
@pamen
If you quote my last message with your picture, you could see the several markup used to show the images, in the editing scope. The second image is the bbcode suggest link content presented in the image host site.
Looks already better.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Hi Olli
Your humor has no end.
Actually they are obviously both "after" pics , but I agree the first is ugly af.
Thank for bb code I was to lazy to look at it.
When I get to understand window handling (in another post) I may post much more interesting UIs with much, much less money involved.
Your humor has no end.
Actually they are obviously both "after" pics , but I agree the first is ugly af.
Thank for bb code I was to lazy to look at it.
When I get to understand window handling (in another post) I may post much more interesting UIs with much, much less money involved.
S.T.V.B.E.E.V.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
I suppose you are talking about the interface you use to modify your mail box presentation, an interface software which not free.
I apologize for the out of context picture titled "before".
It seems that it would be a suggest view on Linux, and you wanted to present a crossplatform result.
I prefer wait your own image presentation, now you know the images can be showed. Just the "bbcode" is used, but not more general HTML standard.
And after that, I will insert a right erratum text in my message, and I will insert a link too, to your definitive demonstrative presentation.
Also, to create a mail emitter/receiver, I remember old subjects which were okay to do this. I remember also, there is a problem of encryption, and a problem of provider standard.
That is a choice : create and update all the standardized mail provider on the market, or choose an interface which updates and follows the evolving standards of the SMTP.
I apologize for the out of context picture titled "before".
It seems that it would be a suggest view on Linux, and you wanted to present a crossplatform result.
I prefer wait your own image presentation, now you know the images can be showed. Just the "bbcode" is used, but not more general HTML standard.
And after that, I will insert a right erratum text in my message, and I will insert a link too, to your definitive demonstrative presentation.
Also, to create a mail emitter/receiver, I remember old subjects which were okay to do this. I remember also, there is a problem of encryption, and a problem of provider standard.
That is a choice : create and update all the standardized mail provider on the market, or choose an interface which updates and follows the evolving standards of the SMTP.
Re: What are required changes from 32 to 64 bit assember for calling C++ classes in a dll
Olli: I don't have such considerations with email.
I use my email client now for 6 months now for work (so it has to have signatures, SMIME, HTML and so on) and for private correspondence every day.
The screenshots are not mock ups.
Accounts connected to MS Exchange, Gmail, Outlook.com, Kerio Mailserver and Standard Linux IMAP(S)/SMPTP(S)
supports TLS 1.3, 1.2, SSL, All authenticeatin methods (MD5CRAM...) and also allows for tunneling of all mail traffic via SSH.
It has PFX/SMIME support for signage and encryption standards compatible with Outlook or newer (some RSS padding is not yet implemented in MS products). No I did not write it all, I'm using a cross platform component, which I also use since 10+ years for .NET.
I was annoyed with Outlook, Thunderbird and others mostly because of poor search capabilities and lack of MacOS/Linux client and lack of support for transferring address book changes, not up-to date security protocols, lack of SSH tunnel and address book inefficiencies (merge people, assign specific accounts to specific email addresses of the same person so replies are always to correct email etc.)
So last December I started learning PureBasic, which I liked before, but never used.
That is why I still have newbie questions 9 months is good for a baby, but not to be proficient in a language.
If PureBasic would support Haiku - that would be my dream (my 3rd daily driver is Haiku now)
Now it works on Mac Win and Linux (well, if the Webkit is the right one, otherwise I get sometimes display issues with HTML mails).
On Mac and Linux I do not see any need for "skinning" - only support for color change notification - OS provides good UI.
On Windows -PureBasic Controls are not matching the OS (Windows Fault, not PureBasic)
I wrote first my own Toolbars and buttons, but to do it correctly and pixel-perfect and working for all controls - that is a work for 6 months alone.
All code from the forum and related sites has deficiencies (either drawing has pixels in the corners, relies on secondary message pumps, which do not work with BindEvent or are simply buggy or do not follow standard OS keyboard shortcuts oand so on)
So - for now I see only a good skinning engine can be a partial solution for the GUI to look modern and match the (Windows) OS at least to a degree.
I'm also trying to use much easier and cheaper one - but we (developer and myself) are stuck on PB Windows not being released after WM_CLOSE.
viewtopic.php?t=82458
I use my email client now for 6 months now for work (so it has to have signatures, SMIME, HTML and so on) and for private correspondence every day.
The screenshots are not mock ups.
Accounts connected to MS Exchange, Gmail, Outlook.com, Kerio Mailserver and Standard Linux IMAP(S)/SMPTP(S)
supports TLS 1.3, 1.2, SSL, All authenticeatin methods (MD5CRAM...) and also allows for tunneling of all mail traffic via SSH.
It has PFX/SMIME support for signage and encryption standards compatible with Outlook or newer (some RSS padding is not yet implemented in MS products). No I did not write it all, I'm using a cross platform component, which I also use since 10+ years for .NET.
I was annoyed with Outlook, Thunderbird and others mostly because of poor search capabilities and lack of MacOS/Linux client and lack of support for transferring address book changes, not up-to date security protocols, lack of SSH tunnel and address book inefficiencies (merge people, assign specific accounts to specific email addresses of the same person so replies are always to correct email etc.)
So last December I started learning PureBasic, which I liked before, but never used.
That is why I still have newbie questions 9 months is good for a baby, but not to be proficient in a language.
If PureBasic would support Haiku - that would be my dream (my 3rd daily driver is Haiku now)
Now it works on Mac Win and Linux (well, if the Webkit is the right one, otherwise I get sometimes display issues with HTML mails).
On Mac and Linux I do not see any need for "skinning" - only support for color change notification - OS provides good UI.
On Windows -PureBasic Controls are not matching the OS (Windows Fault, not PureBasic)
I wrote first my own Toolbars and buttons, but to do it correctly and pixel-perfect and working for all controls - that is a work for 6 months alone.
All code from the forum and related sites has deficiencies (either drawing has pixels in the corners, relies on secondary message pumps, which do not work with BindEvent or are simply buggy or do not follow standard OS keyboard shortcuts oand so on)
So - for now I see only a good skinning engine can be a partial solution for the GUI to look modern and match the (Windows) OS at least to a degree.
I'm also trying to use much easier and cheaper one - but we (developer and myself) are stuck on PB Windows not being released after WM_CLOSE.
viewtopic.php?t=82458
S.T.V.B.E.E.V.