[Gambas-devel] Re: Gambas and Visual Basic (plain text version)

Benoit Minisini gambas at ...1...
Tue Mar 22 12:47:04 CET 2005


On Friday 18 March 2005 17:44, Jean-Francois Perreault wrote:
> Hi,
>
> Richard Stallman wrote:
> > As I tried to say before, directly compiling VB source code in Gambas,
> > Java,
> > or any other bytecode does not solve the big problems: calls to external
> > Windows DLLs, use of ActiveX controls and objects, use of ActiveX
> > automation.
> >
> > I understand this part, but I disagree with the conclusion. Just
> > because this won't solve all the problems is no reason not to do it.
> > Solving part of the problem is better than nothing, Every long journey
> > starts with a single step. This can be the first step.
> >
> > I think the ReactOS developers are writing replacements for many Windows
> > DLLs. That would be a second step. Eventually we will do it all.
> >
> > If you do the part of this job that you can straightforwardly do,
> > it will be a great start. So how about it?
>
> first , I'd like to say that if gambas is going to be involved in
> running VB code, the only way this should happen would be to
> "re-compile" VB code straight into gambas code , targeting the gambas
> bytecode , isn't an optimal solution because there are "better" bytecode
> for that purpose , while gambas is great, it's internal bytecode wasn't
> necesarily designed for this so if a bytecode was to be targeted ,
> parrocode , or the (not as quickly moving as people think target) java,
> are probably better target just because they are more
> general/all-purpose than gambas is (what with being developped
> exclusively for the gambas language)

This is right. But I think that old VB programmers want to port their old 
projects to free OS, AND to open their projects in a VB-like environment 
(Mono/GAMBAS)

>
> if it's going to re-interpret vb code into gambas code , every native vb
> function that gambas doesn't have or behave the same as in vb will have
> to be decomposed into simpler gambas functions , not unlike how a C
> compiler decompose each statement into a lot of simpler asm commands (I
> guess)
>
> but that doesn't solve the problem that there are some things gambas
> just can't do

I think there is not a lot of things GAMBAS can't do and VB can.

>
> I think this is what the original poster was trying to say , the problem
> with gambas is that it can't directly access arbitrary functions in a
> lib or dll
>
> so the problem isn't that the windows API isn't available on the target
> environment, it's that it's innacessible even if it was available , at
> least in the way vb does it
>
> gambas need components to bridge between system supplied API and gambas
> interpreted code and judging from previous answer on that subject from
> Benoit , at least for now it is impossible to access outside functions
> like VB does
>
> for example ..
> VB has the Lib and Alias keywords for use while declaring a function
>
> Lib specifies the dll (or lib if this could work with other OSes) and
> Alias give the name of the function in that dll
> a declaration is like this
>
> Declare Function lopen Lib "kernel32" Alias "_lopen" (ByVal IpPathName
> as String, ByVal iReadWrite as long) as Long
>
> it seems that it is the nature of interpreted language to have this
> limitation
> PERL , PHP , Python , apparently all need some special code to bridge
> that gap in the intepreter between the system and the running code
>
> so this is why I guess , vb code cannot run 1:1 on gambas , or any other
> interpreted environment , some code might run (pure vb only) but never all
>
> but this might only be true with vb6 , I don't know if vb.net only runs
> inside that .net framework (an interpreter ?)
> if it does then I suppose getting that code to run would be the mono
> project's job more that gambas'
>
> but if vb.net code is running inside an interpreter then I suppose this
> mean vb.net also cannot access external dlls without some patchwork code
> ? I don't think they would do that because that greatly limit what the
> language can do , maybe some code run natively while some other parts
> run in the .NET interpreter , if that is the case , to run under linux ,
> it would be the job of both mono and wine (via winelib) , still not
> gambas' job
>
> it would be great if there was a way to dynamically access functions
> inside external dlls without the need for any special interface code ,
> then it could be possible to run vb code in gambas on windows at least
>

I don't want to let Gambas program access external functions in libraries 
without using a component - I'm a bit scared of that :-)

But I think maybe it is possible to use Wine libraries to replace calls to 
DLLs by calls to Wine libraries (making Wine libraries some Gambas 
components ?)


> on linux (and macos), it would still be the system's job to supply the
> windows API and other libraries but at least the code could run mostly
> as-is
>
> the problem with components is that they can only be added to the gambas
> interpreter at the of compilation of the interpreter it self , that make
> adding components without recompiling gambas impossible , if it was
> possible to "plug-in" any component into any live gambas installation ,
> then the component could be distributed with the application or
> distribued via a centrallized system not unlike PHP's PEAR and PERL's
> CPAN and others

In the soon coming 1.9.4, components sources are splitted in many source 
packages.

Note that in stable version, components can already be distributed in 
independant binary RPM packages.

>
> just that would be a big step forward in programmer (and user) usability
>
> but if that was possible then I guess it would be then possible for the
> gambas interpreter to dynamically generate components based on
> instructions in the running gambas code and then we could have a working
> Lib and Alias keyword for our SUB and FUNCTION
>
> in the case of Declare Function lopen Lib "kernel32" Alias "_lopen"
> (ByVal IpPathName as String, ByVal iReadWrite as long) as Long
> the interpreter could just, on the fly generate a kernel32 class module
> with a lopen function , so I guess there is something infeasible about
> this , because that would mean the other interpreted language could work
> without special "components" too .... but still the other interpreters
> allow to install those component after the compilation of the
> interpreter (they are not "built-in" to the interpreter) , so I guess
> the key here would be to generate components , on the fly , at run time
> then reload the interpreter with those new components , or dynamically
> insert them (like kernel modules ?) ?
>
> in any way , I can only come to the conclusion that something in this
> method is not possible , or else there would be no need for CPAN/PEAR
> and the others, I'm sure much better engineers than I, have worked on
> this problem and it must be impossible because of the existance of
> CPAN/PEAR ....
>

For me, it is a translation problem (replace _lopen with something that does 
the same thing). Wine is sort of translation project (at runtime).

> this also points out another problem with gambas , not as pressing , but
> since every lib is going to need a component before it is used , many
> components will be created , at some point it will not be practical for
> all of them to be bundled with the gambas interpreter , so they will
> need to be separate , also to avoid "DLL HELL" problem , a central
> repository will need to be created , and a tool to easily download and
> install individual components on a live gambas installation (even if
> this require recompiling the interpreter) without that , when gambas
> start getting bundled with the major distros you'll have the default
> component installed and if you want more you need to re-install gambas
> by hand , since the user won't bother doing that if it's not easy
> enough, that would mean for gambas programmers that the default
> components are the only components they can use because their audience
> don't have and won't install extra components , this is also why a
> single programmer won't bother make a single-use component for his
> applications , because then his application will only run on his
> workstation
>

I don't want DLL hell. This is why I want to centralize every component in a 
unique tree, and that all components in one tree has the same version number: 
gambas1, gambas2, ...

>
>
> if creating components on the fly is possible --  if there can be a Lib
> and Alias keywork to FUNCTION in gambas , I suppose the reason it does
> not exist now is that it would not work at all times right now
>

Note that from 1.9.4, it will be possible to create components directly in 
Gamnbas.

> in the case of Function lopen Lib "kernel32" Alias "_lopen" (ByVal
> IpPathName as String, ByVal iReadWrite as long) as Long
>
> it would be no problem becase all the arguments are ByVal , which is the
> default way gambas passes variables
>
> but for some (many?) function it is not so easy
>
> first some functions require just the pointer to variables so the called
> functions can write to it , there is no ByRef keywork with gambas
> also if there was , there is no garantee that the variables are stored
> in a way that the called function expects
>
> (if it wants a CHAR array you can't give it a string (even a native
> gambas string) because those are internally stored as utf-8 while the
> called function is going to expect 1 byte per character ASCII , and
> there is no garantee that strings in gambas are contiguous or
> uncompressed or etc.. we don't know how gambas stores strings (well .. I
> don't) and we can't make assumptions about that, and one thing is sure
> is that however strings are stored it is highly unlikely that the called
> function will know how that strings are stored and how to manipulate them)
>
> assuming native byte arrays are stored the same way they are elsewhere
> we could use that instead , then there would need to be a way to get the
> pointer to that byte array , in VB, if the ByRef keyword didn't exist
> and ByVal was the default way of passing variables  , then the VarPtr()
> function would be used , VarPtr is a function that return the pointer to
> any "standard" variable (there is also StrPtr , that return a pointer to
> the unicode string you ask it and ObjPtr for the pointer to object and
> User Defined Types (another feature I would love to see in gambas ,
> making a class is overkill when you want a UDT , how come we don't have
> UDTs ?! that's just weird I can't find a reason why we don't have them !
> oh well...))
>
> if we had those special function , and assuming that at least native
> byte arrays are stored in memory the same way it is with other languages
> when most API would become accessible
>
> but there is at least another special case that wouldn't work , callbacks
> from memory there is this very important windows API that uses callback
>
> Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd
> As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
>
> that function if I remember correctly serves to intercept all events of
> a "window"  the last argument is a pointer to a subroutine
>
> in vb to use that API you have to use the AddressOf function
>
> like this
>
> SetWindowLong(hwnd, GWL_WNDPROC, AddressOf WindowProc)
>
> AddressOf returns the pointer to the function , now the only way this
> could possibly work in gambas in the dynamically run-time created
> component scenario is if subroutine are stored in memory as machine
> executable code (if I understand correctly a JIT compiler like gambas
> compiles the subroutines and functions into executable at run-time using
> the bytecode , but I don't know if all the code is turned into machine
> code when the program start or just as the code is about to be executed
> (and discarded afterwards or kept in a cache , but not kept in whole in
> memory in a static location)) if it's not possible to give it the
> pointer to the real subroutine then there should be a way to tell the
> interpreter to listen for events at a certain address and when an event
> comes it would then fire the real sub-routine
>

For such case, Gambas can't emulate this behavior. But I think Wine DLL can. I 
need a Wine specialist that could tell what is possible and what is not.

> well anyway , direct "component-less" access to function in arbitrary
> DLLs and libs is certainly #1 in my gambas wishlist , I'd be really
> interested to hear how this could be done or why it's impossible
>
> with that I could even do ioctls and finish my joystick class ! ;)
> which btw , can easily handle 500+ events at less then 5% CPU usage on
> an athlon 1800+ and with only 0.002 second latency (only if I use native
> variables however , classes (like string array classes) eat 100% real
> quick (but latency is a bit better however , but at that cpu cost it's
> irrelevent))
>

If I let Gambas projects access external shared libraries directly, I can say 
"good bye" to the portability!

>
> I hope to hear some comments on this , from anyone!
>

Here it is. Did you read the OpenOffice/PDF document I posted on this 
mailing-list ?

-- 
Benoit Minisini
mailto:gambas at ...1...




More information about the Devel mailing list