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

[Jean-Francois Perreault]

Hi !

Benoit Minisini wrote:

>On Friday 18 March 2005 17:44, Jean-Francois Perreault wrote:
>
>>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)
>
I agree, VB code to Gambas code is the cleanest way to do this

>>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 agree gambas is already a very capable language
I was refering to external calls to libraries and gettings pointers to 
variables, strings, object, and subroutines

>>
>>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 ?)
>
>
yes , most API calls can be implemented classes and functions  in a 
component
in the case of a VB to Gambas code conversion this is probably the 
safest way to do it
it would be the safe way to do an api call

but direct access to libraries offer a degree of flexibility that can 
never be achieved via a component

one of the problem is that there are libraries that will not have a 
component

>>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.
>
>
that's great, this is a step in the right direction
but for component distributed as independant binary packages, you must 
have the same
version of gambas installed as the one used to compile that component , 
if you compiled
gambas yourself you can't use those binary package and if you compiled 
gambas yourself
without a certain component , you can't add a component later on without 
recompiling
gambas entirely, right?

>>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.
>
>
that's a very interesting feature !
you mean like I make a project , in my project I make a component , I 
take my project , tar it , send it to gambasforge
and anyone running a version of gambas >= than mine can just hit F5 and 
run ?
where gambas takes care of compiling and using the component I just made ?

that would make single-use component practical , it's just as good as 
direct library access

>>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.
>
>
does that mean that if direct library access was possible , callback are 
not possible ?
or that there's no clean way to convert vb code that uses that into 
gambas code , at least not without a specially designed component ?

SetWindowLong was just an example , I'm sure many libraries out there also use callbacks 

I used the win32-api here because that's the only one I know (to an 
extent) , I'm sure the same principles apply to most libs

>>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!
>
in this case , portability is the programmer's responsability
I can make my gambas project unportable by hardcoding unix paths , then 
it won't work on windows
the same if I were to directly use the win32 api , I shouldn't expect it 
to work on linux
but if I used direct library access on SDL , portability wouldn't be 
compromised
off course if used the SDL component it would be a lot cleaner but the 
SDL component cannot do everything you can do with direct access to the 
SDL api

I shouldn't expect my project to be portable if I used a library that is 
only available for linux

for example DirectFB (http://www.directfb.org/)
"DirectFB is a thin library that provides hardware graphics 
acceleration, input device handling and abstraction, integrated 
windowing system with support for translucent windows and multiple 
display layers on top of the Linux Framebuffer Device."

that will never run on windows (well , it's probably technically 
possible , but there's no point , this is for lightweight applications 
without a X server)
if direct lib access was possible , I could make use of this right now 
and probably have a working demo by tomorrow
even if there was a gb.directfb component , it still wouldn't work where 
DirectFB doesn't
the component would only be a wrapper that can do sanity check , it 
would not act as an abstraction layer like gb.qt or gb.gtk (it could but 
that's not the point)
so in that light I see making a component an obstacle rather than a feature
if I were to make a component , before my program would work on "any 
computer with gambas installed" I would need to write , test it , make 
sure it's usable for production use by others , then post it , wait for 
it to be included in the cvs , then wait for the next gambas release , 
then wait for most binary distribution to propagate the new version of 
gambas containing my component , then hoping the distro on the target 
machine has compiled my component (probably not , it would add DirectFB 
as a dependency to gambas) , my program might finally run

I estimate that this would take , even on a "cutting edge" distro like 
gentoo , about 2 weeks -minimum- , (right now the "stable" version of 
gambas with gentoo is 1.0.2 , but the 1.0.4 ebuild has been available 
since march 12)
on debian the official is still 1.0 and redhat 0.97 ? (I could be wrong 
with those number , but they do lag behind quite a bit)
and the "mainstream" binary builds wouldn't have my component , 
requiring my target user to manually recompile gambas

since it is this much trouble to use "some random external lib" , it 
quite effectively limits the abilities of the gambas programmer to the 
components available a couple versions ago

and this raise the bar to experimenting with new libs
for example , I just opened freshmeat.net and on the front page there is 
a post about libieee1284

I could probably use that , I have just received IEEE1284 transceiver 
chips from Texas Instrument
if I could just read their interface documentation at 
http://cyberelk.net/tim/libieee1284/interface/index.html
and start playing with it right away I would have nothing to envy from 
other languages

I can understand why you don't want to allow direct access to external libs
it's not safe, the gambas interpreter , can't sanity check API calls all 
the problems of unsafe languages (like C) would apply , buffer overflows 
just to name one

it circumvent the entire component system, the need for components would 
be less pressing and maybe this would mean less programmers would work 
on new components if they could just access the lib s directly , also 
since the API are a lot harder to work with that the sugar-coated 
component interface , that would raise the bar for beginners which isn't 
a good thing

so there should be a way to make that feature a "advanced programmer 
only" feature , with a rather high "cost of use" , so that it's use 
doesn't become rampant
it's still a hack versus using a component and should be used as such , 
only minimal documentation should be available for this and it should 
not be reference in any example that isn't explaining this feature

you don't want something like this
--
newbie:  how can I use the PC speaker ?
helpful-stranger: just use direct API calls to libpcspeaker, take a look 
at my code demonstrating this hack at 
http://example.com/gambas-hacks/pcspeaker
--

if direct lib access is ever implemented it should not be too accessible 
to the beginner
it should only be used when there is no alternative and it is -really- 
appropriate

...

I'm curious , Benoit , do you have other reasons for not allowing direct 
API call to work ?

>
>Here it is. Did you read the OpenOffice/PDF document I posted on this 
>mailing-list ?
>
I just did , it's interesting but actually I don't have a real interest 
in using VB code,
I don't have tons of leftover VB code at this time , all that I have is 
proof-of-concept
code that mostly demonstrate the win32 api

I just used this discussion to point out the need for external lib 
access , which is a big deal for me since
I have a hard time using C. gambas is really the ideal language for me , 
basic is the only
language I've used a lot (I started on a C64) but the only problem I 
have with gambas is hitting
limitations that can only be worked around with a component and I can't 
do that since I don't
know C enough

but even then, I do think that gambas is very powerful as it is , I just 
miss my hacking tools a bit
btw, I suggest you to read (or at least skim through) this book on vb 
hacking

http://vb.mvps.org/hardcore/

I don't think it will teach you anything new about how vb works, but 
maybe it could give you an idea of my motivation for using vb hacking tools

bye !

Jean-Francois Perreault