Re: Orx Wrapper Hurdles
- Posted by ghaberek (admin) Aug 23, 2021
- 794 views
Hello all,
As I was writing the wrapper for Orx I came across the most obvious hurdle. The init and execute functions needed for Orx are not in the Orx DLL as they are called as Inline functions and not exported to the DLL. So without those, Orx won't start even with other commands that have init functions. There may be a way with ifdef statements, but I haven't tried yet. If anyone could help or has a solution, please let me know. Otherwise I'm not sure how feasible this wrapper may be to continue.
I mentioned this in your original thread: https://openeuphoria.org/forum/136281.wc#136281
Two major hurdles I'm seeing here:
- Calling convention: Most of the library functions are declared using the fastcall convention, which Euphoria isn't currently built to handle (we only support stdcall and cdecl). It's possible this might only be the case when compiling the library statically so that it's embedded into the resulting executable and the shared library might still be using stdcall or cdecl. I haven't dug through the code enough to tell yet. The good news is that all those different conventions only affect x86 and on x64 there's just "the x64 calling convention" so it should work fine if you stick to 64-bit Euphoria (which you should!).
- Inline functions: Some functions of the library are declared inline which means they're always compiled directly into the executable and don't get exported (or even compiled into) the shared library. You could either unmark these as inline and rebuild the library or reconstruct them directly in Euphoria. Unfortunately the orx_Execute function is marked inline, and it's literally the first function you need to bootstrap a program.
Obviously you've solved the calling convention issue, great job! It looks like these functions are declared with both static and orxINLINE which is a bit problematic. The orxINLINE is guarded in an ifndef block so defining that as blank (-DorxINLINE) should stop it from inserting inline everywhere, but there's no corresponding orxSTATIC and the static keyword is just used directly in the code. So if you wanted to fix this you'd have to copy the ifndef block for orxINLINE to orxSTATIC and then do the same trick of defining it as blank.
My recommendation would be to just rewrite these functions directly in Euphoria. It seems like they're marked static and inline because they're small, so doing so shouldn't be difficult. Doing this will also give you the benefit of allowing the interpreter to inline the routines, keeping with the intent of the original code. The default behavior is to inline routines of 30 IL bytes. You can override this with with inline. So if you can figure out how many IL bytes these routines use (using dis.ex maybe?) then you can manually tweak that value in the wrapper file.
-Greg
