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
I’ve done that with RUST dlls
Was (and still am) very interested in using C# libraries with Xojo. @eugenedakin was 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.
I find them both quite a bit too slow. But, if you only want windows, and are good with C# then you have the solution!
yeah a C# Dll on macOS doesnt seem to be a properly formed dylib which is why it doesnt load
I just wish there were a way to get the skinny on what the dylib and Xojo sends/receives and what is expected!
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
Good info. Now…
How does one “look inside” a dylib to see what it’s expecting? How does one edit a dylib’s “configuration”?
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.
in terminal the command
file will examine it lightly and tell you what file type it is (executable, text file. dylib and architecture)
in terminal the command
otool has a pile of options for dumping out relocation tables, symbol tables and a ton of other info
and much more simply in terminal
nm -gU <path to dylib>
will list entry points
For use with Xojo Projects?
If so why not just use Xojo code as part of the project?
Would the PureBasic libraries be faster than compiled Xojo code in the project itself?
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?