An interesing thought

[doppler]

Would it be possible to create a DLL out of qb64 code to use in other Window languages ?  I have seen huge DLL's so size should not matter or will it.

I have nothing in mind at this time.  It's just a passing thought.

[Jack]

@doppler
I think that it may be possible
in Options->Compiler settings in the C++ Linker Flags add -shared
then compile the following function by using F11

Code: (Select All)

Function addl123456789& (x As Long, y As Long)

    addl123456789 = x + y

End Function

it creates an executable but with functions exported, unfortunately QB64 uses C++ not plain C so the symbols are mangled
the above function is exported as _Z18FUNC_ADDL123456789PiS_
the reason why I added the numbers 1 thru 9 to the function name was so that I could be sure to spot it in the exports
to test you would rename the exe thus produced to a dll

let me see if I can call the exe renamed to a dll from QB64, it's doubtful but I will give it a shot.
I'll be back

[Jack]

it actually works  

Code: (Select All)

_Title "FakeDLL-test"

$Console:Only

_Dest _Console

Option _Explicit



Declare Dynamic Library "addl"

    Function addl& Alias "_Z18FUNC_ADDL123456789PiS_" (x As Long, y As Long)

End Declare



Dim As Long x, y, z

x = 123

y = 456

z = addl(x, y)

Print z

579

Press any key to continue

[Jack]

don't forget to remove the -shared from the linker options so that QB64 can make proper executables

[Pete]

I remember making fake dll's with QuickBASIC YOu had to break up large apps back then, so at one point, I just tweaked a couple of things and renamed some of the compiled .exe extensions as .dll. Worked like a charm. I'd like to say I miss those days... but I really don't!

Pete

[doppler]

Interesting.  When I actually have a use or somebody I know does.  I can refer back to this thread.
Thanks

[Jack]

I tried the simple example with double and _Float and they work ok but I could not get a function or sub that returns or modifies a string to work, after a few seconds it silently crashes, if I find a solution to that I will post it here
<edit> changing the function and its parameters to a different type say from long to double will also give a different mangled function name by the C++ compiler
and different C++ compilers could possibly mangle names differently, hopefully the g++ compiler will produce the same name mangling across versions

[luke]

You won't be able to pass strings as you expect. QB64 functions expect to receive a string descriptor, but DECLARE LIBRARY functions are sent a pointer to the character data.

You could have your function receive an _OFFSET, but you won't be allowed to change the length of the string (and you will need to supply the length as a separate parameter).

[Jack]

thank you luke
but I don't understand why the following works as a whole program but not if the function alone is compiled with the shared option and then used as a dll

Code: (Select All)

Dim As String a, b, c

a = "Hello"

b = " World!"

c = adds(a, b)

Print c



Function adds$ (x As String, y As String)

    adds = x + y

End Function

like the following, assuming that the function alone is saved as addl.bas and compiled with the shared option and then renamed from addl.exe to addl.dll

Code: (Select All)

Declare Dynamic Library "addl"

    Function adds$ Alias "_Z18FUNC_ADDSP3qbsS0_" (x As String, y As String)

End Declare



Dim As String a, b, c



a = "Hello"

b = " World!"



c = adds(a, b)

Print c

[DSMan195276]

`Declare Library` is designed for calling external C and C++ functions, not QB64 functions. The `String` argument is passed as a `char *` in C++, not as the internal String representation (`qbs *`) that the QB64 runtime uses (this is what Luke was getting at). There's nothing you can do, it's just not going to work like you want. Array's aren't allowed either for a similar reason.

I would add that I personally wouldn't bother trying to use this for anything 'serious' as there's large problems you'll run into if you put non-trivial functions into the dll. The QB64 runtime (`libqb` and various other parts) ends up compiled both into your dll and the new exe you link against it. The result is roughly two separate instances of the runtime in your program which will not interact correctly. Even a simple `Print x` will not work from the dll, and lots of actions will probably cause your program to blow up. (Not to mention, the "runtime" is not always the same. We compile the runtime differently depending on the needs of your program so the runtime in the dll will likely not match the one used by the exe).

To make a dll like this you would need to make significant modifications to `qbx.cpp` along with the build logic so that the generated C++ functions get compiled separately from the runtime (and the runtime is excluded from the dll). That would get you closer to what you're looking for because then you could link against that `dll` and it would make use of the runtime provided by the exe (you'd still have the problem with `String`s and Arrays, but in theory `Print x` would work).