[Gambas-devel] gb.api

Daniel Campos daniel.campos at ...103...
Mon Apr 25 16:11:42 CEST 2005


>
>
>
>Hi, Daniel.
>
>Good job, but you should have tell before that you were working on that. 
>Because I'm currently adding this feature directly inside the interpreter.
>  
>

Ooops! well, here's a lot of code and ideas you can use in your 
implementation:
http://gambas.gnulinex.org/api :-)) ...

>Declaring a method would be something like that:
>
>[PUBLIC] EXTERN Func(Param1 AS Type1, Param2 AS Type2, ...) As ReturnType IN 
>"Library" WITH "C function prototype"
>
>This is equivalent to your Api.Register method. The C function prototype is a 
>string that will be transformed by the compiler into a static description of 
>the C function.
>
>The function will be called like a normal function.
>
>This is equivalent to your ApiCall.* method.
>  
>
OK...

>I wanted to add a "Struct" class to manage C structure in memory, but with 
>special syntax support from the compiler.
>
>This is equivalent to your ApiPointer class I think.
>  
>
No, this is equivalent to my ApiStruct class, which allows to alloc memory
for a struct, and read and write values from structs, I've not yet 
documented
it, but it is already working...

>I'm not sure that your implementation of ApiCall._unknown is very portable... 
>I think it works on i386, 32 bits ;-) Well, like Gambas one could say ;-)
>
>I'm not sure the way you call functions work everywhere. Is is sure that 
>passing a structure by value is equivalent to pass the arguments one by one ? 
>That the order of arguments will be preserved on another architecture ?
>  
>
Passing a structure works at least for Windows, FreeBSD and Linux, (all
intel 32 bits), and it should work for 64bits/Intel/AMD Linux at least.
My only doubt is what is the order needed for Apple, Sparc, and other 
machines?
It seems it must be the same, as this order is the order provided by the
C standard ABI and gcc, but i'm not sure at 100%... The second problem 
is data
types size, there will be some changes for 64 bits, sure, but easy to 
rewrite
with some #ifdefs... if we could have any machine to test it :-))

>Maybe I should add the same memory & string utility functions you added to the 
>component.
>
>Support for callbacks may be interesting too...
>
>What do you think about that ?
>
>  
>
I've added the ApiPointer  class and all the memory and string functions 
in order
to avoid the problems when trying to use the API from VB. I was a real hell
to manage strings, non-zero terminated strings, memory allocation ,etc, so
it is needed to simplify all stuff: just basic types, and a pointer type 
to deal
with structures, strings, and even objects if we could call C++ libraries...

About callbacks, I have already some code to support them in my code, so
I think I will finish the work in gb.api (just one or two days) to have 
a stable and full
documented version, and then I will leave it in the web page so you can 
use what
you want from the code and "philosophy". I will also add a backport to
Gambas 1.0,  as it is a very easy task to perform. A full callback 
support would need
of a Gambas compiler generating real assembler code, so you would be able to
send real function pointers to the libraries, but at least, with my 
current code, the major
part of libraries are already supported. It is quite important to 
support callbacks, as
it is a practice widely used in all kind of libraries.

Regards,

D. Campos








More information about the Devel mailing list