In a bid to improve speed , I am tempted on Windows Xojo to try doing screen updates using a DLL.
I used this method a lot back in the day to speed up a VB3 program with a Delphi-compiled DLL
Xojo has become progressively slower since I started using it (as RB) many years ago, and I wonder if farming out the graphics intensive code will help.
Xojo cant create a DLL, and even if it could, wouldnt be any different.
So using another compiler allows me to at least try something.
Anyone done this before / have a stub piece of code that would act as a starting point?
And how to make it 32/64bit compatible?
You’ll need 2 versions of the dll - one for 32 bit and one for 64 bit
Even Xojo plugins do this one Windows
64 bit systems cant load 32 bit dlls
32 bit systems obviously cant load 64 bit dlls
after that as a long as the dll is pretty plain jane standard and is compiled using the correct dll calling conventions you should be able to just declare into it and use it
Was (and still am) very interested in using C# libraries with Xojo. @eugenedakinwas able to successfully get a C# dll to work with Xojo on Windows, but so far nobody has been able to get one to work with MacOS. It’s a bit above my skill level to understand how to trace/troubleshoot the communication between Xojo and a dll, but I would love to know more about how the communication works and how to “listen” to the communication so that one might be able to determine what the issue might be.
C# was a problem due to the function signatures, I believe
From memory, there is a simpler C-Style fingerprint that passes pointers to basic types or memory locations
But Mac doesnt use DLL …it uses dylibs doesnt it?
For me, Im not worried about Mac
Its fast enough. Not great, but OK
Windows, not so much. I’m constantly disappointed with it.
Its not so much what xojo sends or not
When you use a decalre Xojo will try to “open” the dylib using a system API (called dlopen)
That API is well defined and whats expected for it to work is as well
That API expects the “file” will conform to the normal expectations of a dylib for macOS
If it DOES then dlopen will succeed. And that will also mean the OS can read one of many “tables” that exist in a dylib that tells the OS about what entry points (methods) exist etc
If its not correctly formed there’s nothing that Xojo ever knows because the call to dlopen fails
PureBasic might be of interest to you, it can compile shared libraries for Windows, Linux and Mac. I’ve used PureBasic quite often to make companion utilities for larger projects.
Dylibs use the Mach-O executable format, the format specification is included in the Xcode header file “loader.h”.
App Wrapper checks certain elements in Mach-O files, so I had to write my own parser. I don’t read what functions a dylib exposes, but there is a lot of meta data in a dylib file, so I would expect them to be listed there.
Why not?
Im already using Xojo code and it is too slow.
PureBasic might be able to drive the screen faster.
Won’t know unless I try.
(It certainly was faster to use a Delphi DLL to paint on a VB screen: my only frame of reference at the moment)
I use both dylib and dlls for mac and win respectively but abandoned 32 bit support. We create the DLLs so its easy to see whats available and how it wants it - Norm nails the dylib function reader app though, you can use otool(and theres the win counterpart in visual studio) to snif out the symbols but I would think you can get an api of sorts from most dlls or the header files?