vb4linux-dev — ML for VB4Linux project developers

[VB4Linux-Dev] compiler

[Abhijit P. <abh...@ma...>]

I am assuming that the syntax analysis will be taken care in the IDE
itself...like on M$ Platform...

pls confirm this Mike....I am NOT implementing the syntax checker in the
compiler.

Abhijit Paithankar

Re: [VB4Linux-Dev] (no subject)

[Luke-Jr <Mi...@an...>]

k... C, right? Just make a folder in the CVS when you feel like it's
ready for upload...
Been having to deal with Windoze lately as this stupid computer I built
refuses to boot off of CD-ROM... Anyone happen to know how with a BX133
RAID motherboard?

Abhijit Paithankar wrote:
> 
> I am starting off with the vb2c compiler today....pls send me any last
> minute suggestions.
> 
> ab
> 
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

[VB4Linux-Dev] (no subject)

[Abhijit P. <abh...@ma...>]

I am starting off with the vb2c compiler today....pls send me any last
minute suggestions.

ab

[VB4Linux-Dev] VB.NET Help Files....

[Luke-Jr <Mi...@an...>]

Well, bad news... VB.NET doesn't seem to use .HLP or .CHM... Maybe I'll
be able to get raw HTML versions of the help files and upload them
somehow.... As for VB.NET itself, it's taking 6 minutes to convert a
basic VB5 program on a 266 MHz.... (Well, 2 hours running under VMWare
where everything is times 20)
I'll see what I can do as far as extracting stuff from the help...
*sigh*

-Luke-Jr

Re: [VB4Linux-Dev] OCXs

[James C. <ja...@st...>]

> 
> I checked some .dll files...they were starting with "MZ" and so do the OCX
> files.
> Now what does this mean?

This means that the files are just like normal .exe files. At the start of
a .exe file there are a couple of information headers (except for .com or
.sys files which are pure machine code.) They contain info about the
linker used, the timestamp, etc and most importantly, the start of the
machine code. Quickview reads this info when 'quickview'ing a DLL or EXE.
I read an article on MSDN on deciphering this info but i have no idea in
which section. I might have a hard-copy and will put it on my web-page if
i find it. It might be useful, you never know.

 > 
> Apart from the OCX / DLL support in VB, we could come up with
> support for the GNOME Object Model (bonobo) and KDE's KOM, or other
> technologies based on CORBA.
>

I haven't a clue how to use KOM, COM, or bonobo. 
 
> ab
> 
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 

RE: [VB4Linux-Dev] OCXs

[Abhijit P. <abh...@ma...>]

I checked some .dll files...they were starting with "MZ" and so do the OCX
files.
Now what does this mean?

Apart from the OCX / DLL support in VB, we could come up with
support for the GNOME Object Model (bonobo) and KDE's KOM, or other
technologies based on CORBA.

ab

Re: [VB4Linux-Dev] OCXs

[Martino S. <ms...@ti...>]

----- Original Message -----
From: "James Cooper" <ja...@st...>
To: "VB4Linux Project" <vb4...@li...>
Sent: Wednesday, November 22, 2000 11:15 AM
Subject: [VB4Linux-Dev] OCXs


> I'm lead to believe that OCX's are basically glorified DLL's.
>
> To see if they are, open one up in a text editor and check if the first
> two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
> Portable in PE means that the file is portable among the Windows family
> of OS's, not different OS's or processor architectures.

Perfect.

> Perhaps someone could try messing around with one in VB:
> As far a i know, DLLs all have one function, called DllMain(). (Even if
> you do not write this function when you are creating a DLL in VC++, an
> empty one is automatically compiled anyway). You can think of this as a
> constructor in Java. When the DLL is loaded, the OS calls DllMain (just
> like it calls WinMain in applications). I'm sure there are some API
> functions to get the functions a DLL exports but i don't know what they
> are, GetProcAddress() i think). For example gdi32.dll exports
> CreateCompatibleDC, so the code should be something like this:
>
> (Function names are not necessarily correct!)
> Dim hModule as Long
> Dim lpProc as Long
>
> hModule = LoadModule("c:/windows/system32/gdi32.dll");
> lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
> ...

This is correct if you have a Common DLL written by C. You get the proc
address and use it,
but the OCX use the COM interface (like CORBA) to share objects to any
application that request them.
Beside this, you must know the objects that the OCX share. If you don't
know, the OCX share, with a common interface, a Type Library (.TLB), that
have stored the object definition.


P.S.: I don't know if my english is plain. I'm sorry.

>
> Note: this is completely useless in VB as VB cannot Call pointers!
>
> All this is just off the top of my head, check out msdn.microsoft.com
> for better info.
> Hope this helps somewhat.
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Re: [VB4Linux-Dev] OCXs

[Scott B. <js...@go...>]

On Wed, 22 Nov 2000, James Cooper wrote:

> I'm lead to believe that OCX's are basically glorified DLL's.
They are.

> 
> To see if they are, open one up in a text editor and check if the first
> two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
> Portable in PE means that the file is portable among the Windows family
> of OS's, not different OS's or processor architectures.
Thats correct.

> 
> Perhaps someone could try messing around with one in VB:
> As far a i know, DLLs all have one function, called DllMain(). (Even if
> you do not write this function when you are creating a DLL in VC++, an
> empty one is automatically compiled anyway). You can think of this as a
> constructor in Java. When the DLL is loaded, the OS calls DllMain (just
> like it calls WinMain in applications). I'm sure there are some API
> functions to get the functions a DLL exports but i don't know what they
> are, GetProcAddress() i think). For example gdi32.dll exports
> CreateCompatibleDC, so the code should be something like this:
A point dug out of this blurb....  I would not try and keep binary
compatibility between the OS platforms.  To me, the goal of this project is
to have a VB like system you can recompile your VB code on Linux or some
other Unix like OS, we want to use Wine, not be it.  Past that, you may
want to think about a VM, but I think most of this is beyond the scope of
this project, at first anyway.

> > 	(Function names are not necessarily correct!) 
> 	Dim hModule as Long
> 	Dim lpProc as Long
> 
> 	hModule = LoadModule("c:/windows/system32/gdi32.dll");
> 	lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
> 	...
> 
> Note: this is completely useless in VB as VB cannot Call pointers!
For this, all we will do is generate the load .so function for the
specified function.

scott

[VB4Linux-Dev] OCXs

[James C. <ja...@st...>]

I'm lead to believe that OCX's are basically glorified DLL's.

To see if they are, open one up in a text editor and check if the first
two characters are 'MZ' or 'PE' (i can't as i'm running linux only).
Portable in PE means that the file is portable among the Windows family
of OS's, not different OS's or processor architectures.

Perhaps someone could try messing around with one in VB:
As far a i know, DLLs all have one function, called DllMain(). (Even if
you do not write this function when you are creating a DLL in VC++, an
empty one is automatically compiled anyway). You can think of this as a
constructor in Java. When the DLL is loaded, the OS calls DllMain (just
like it calls WinMain in applications). I'm sure there are some API
functions to get the functions a DLL exports but i don't know what they
are, GetProcAddress() i think). For example gdi32.dll exports
CreateCompatibleDC, so the code should be something like this:

	(Function names are not necessarily correct!)
	Dim hModule as Long
	Dim lpProc as Long

	hModule = LoadModule("c:/windows/system32/gdi32.dll");
	lpProc = GetProcAddress(hModule, "CreateCompatibleDC");
	...

Note: this is completely useless in VB as VB cannot Call pointers!

All this is just off the top of my head, check out msdn.microsoft.com
for better info.
Hope this helps somewhat.

RE: [VB4Linux-Dev] VisualBasic.NET Beta 1

[Abhijit P. <abh...@ma...>]

> -----Original Message-----
> From: vb4...@li...
> [mailto:vb4...@li...]On Behalf Of Luke-Jr
> Sent: Tuesday, November 21, 2000 10:57 PM
> To: vb4...@li...
> Subject: [VB4Linux-Dev] VisualBasic.NET Beta 1
> 
> 
> Just got an email from Microsoft saying they've shipped it to me!
> I'll be uploading the VB.NET help files soon (unless VB.NET is currently
> undocumented...)
> Yippie! ;-P
> 

:))))))))))))

[VB4Linux-Dev] VisualBasic.NET Beta 1

[Luke-Jr <Mi...@an...>]

Just got an email from Microsoft saying they've shipped it to me!
I'll be uploading the VB.NET help files soon (unless VB.NET is currently
undocumented...)
Yippie! ;-P

RE: [VB4Linux-Dev] (no subject)

[Scott B. <js...@go...>]

What would have to happen if you want this to really work is:

1 - Use Wine or some other api layer to use the Windows OCX/DLL bins.
    This would stick you pretty much into a Intel hole.  *You*
    could write a 386/486/Pentium emu to dig you out of this, but that
    adds a lot to the project.

2 - Support only OCX'x/DLL's that can be recompiled with the VB4LNX 
    system.  
    This does limit you on some things, but it keeps you more portable,
    and makes the code a lot less to deal with.

3 - Wine support and OCX/DLL recompiles. (A little of 1 & 2)
    This solves the most problems, and keeps the code to a minimum.

I think 3 is the KISS choice.  Just a thought or two...

scott

On Tue, 21 Nov 2000, Abhijit Paithankar wrote:

> how portable is it?
> and if it is portable executable, it should be in binary format....which
> means it is readily usable !
> 
> 
> > > ya...Linux versions of VB OCX or DLLs would be good...
> > > any idea of what exactly an OCX is...I mean...fileformat information?
> > >
> >
> > PE (Portable executable) I think.
> >
> 
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 
> 

RE: [VB4Linux-Dev] (no subject)

[Abhijit P. <abh...@ma...>]

how portable is it?
and if it is portable executable, it should be in binary format....which
means it is readily usable !


> > ya...Linux versions of VB OCX or DLLs would be good...
> > any idea of what exactly an OCX is...I mean...fileformat information?
> >
>
> PE (Portable executable) I think.
>

Re: [VB4Linux-Dev] (no subject)

[Martino S. <ms...@ti...>]

----- Original Message ----- 
From: "Abhijit Paithankar" <abh...@ma...>
To: <vb4...@li...>
Sent: Tuesday, November 21, 2000 4:17 PM
Subject: RE: [VB4Linux-Dev] (no subject)


> ya...Linux versions of VB OCX or DLLs would be good...
> any idea of what exactly an OCX is...I mean...fileformat information?
> 

PE (Portable executable) I think.

RE: [VB4Linux-Dev] (no subject)

[Abhijit P. <abh...@ma...>]

ya...Linux versions of VB OCX or DLLs would be good...
any idea of what exactly an OCX is...I mean...fileformat information?

> -----Original Message-----
> From: vb4...@li...
> [mailto:vb4...@li...]On Behalf Of Luke-Jr
> Sent: Tuesday, November 21, 2000 6:41 PM
> To: vb4...@li...
> Subject: Re: [VB4Linux-Dev] (no subject)
> 
> 
> Well, the /BEST/ way to do this would be to make a pre-emulator which
> makes a Linux version of any DLL or OCX and then I can simply run all the
> Visual Basic.NET DLLs and OCXes thru it... Whether this is possible tho,
> is a different thing... Also, I'm pretty sure all the VB DLLs and OCXes
> are okay to distribute cuz usually they'd be useless...
> 
> abh...@ma... wrote:
> 
> > > could we leverage the Tcl/Tk debug environment for our
> > > debugging program if
> > > we code vb2c in Tcl/Tk? any idea how? In that case it could be
> > > of help...
> > >
> > > Well coding it in a higher level language like Tcl would give you a
> > > speeder turn around in development time as you know (and more people
> > > could support it).  We could write hooks in C (in the support libs we
> > will
> > > need anyway) to help with debugging and could generate the calls for
> > them
> > > on the fly in Tcl from the debugger (It would be easier for "code
> > > injection" with it), so yes it could help.
> > >
> > > There are a couple of other options for debugging.  We could
> > > generate a.out
> > > or elf stubs section with the debugging symbols and write and
> > > extension for
> > > gdb.  This would take more time tho.  We could also write a VM and
> > have
> > > hooks into it for debugging.
> >
> > I think it would be the best to code debugger in C.
> >
> > vb apps in design stage would use pre-existing .so files to run in a
> > virtual environment where the debugger would be present. Once we have
> > to release the vb app, we shall then put it thro vb2c.
> >
> > Also, about using wine libs...looks OK on the surface, but can we
> > emulate only a specific dll or OCX using wine?
> > Also, when we want to emulate them, we'd need to have them
> > first...which means we need to have M$ VisualBasic installed on the win
> > partition first...before VB4Linux can use the OCX files...which is not
> > what should be.
> > ...which could mean that we have to have native OCX files....
> >
> > ---------------------------------------------------------------
> > This Message was Powered by Xcel Communications
> > Sign up for your FREE EMAIL account today at http://www.mailroom.com
> > Give your FAX machine an email address http://www.faxroom.com
> >
> > _______________________________________________
> > VB4Linux-Dev mailing list
> > VB4...@li...
> > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 

Re: [VB4Linux-Dev] (no subject)

[Luke-Jr <Mi...@an...>]

Well, the /BEST/ way to do this would be to make a pre-emulator which
makes a Linux version of any DLL or OCX and then I can simply run all the
Visual Basic.NET DLLs and OCXes thru it... Whether this is possible tho,
is a different thing... Also, I'm pretty sure all the VB DLLs and OCXes
are okay to distribute cuz usually they'd be useless...

abh...@ma... wrote:

> > could we leverage the Tcl/Tk debug environment for our
> > debugging program if
> > we code vb2c in Tcl/Tk? any idea how? In that case it could be
> > of help...
> >
> > Well coding it in a higher level language like Tcl would give you a
> > speeder turn around in development time as you know (and more people
> > could support it).  We could write hooks in C (in the support libs we
> will
> > need anyway) to help with debugging and could generate the calls for
> them
> > on the fly in Tcl from the debugger (It would be easier for "code
> > injection" with it), so yes it could help.
> >
> > There are a couple of other options for debugging.  We could
> > generate a.out
> > or elf stubs section with the debugging symbols and write and
> > extension for
> > gdb.  This would take more time tho.  We could also write a VM and
> have
> > hooks into it for debugging.
>
> I think it would be the best to code debugger in C.
>
> vb apps in design stage would use pre-existing .so files to run in a
> virtual environment where the debugger would be present. Once we have
> to release the vb app, we shall then put it thro vb2c.
>
> Also, about using wine libs...looks OK on the surface, but can we
> emulate only a specific dll or OCX using wine?
> Also, when we want to emulate them, we'd need to have them
> first...which means we need to have M$ VisualBasic installed on the win
> partition first...before VB4Linux can use the OCX files...which is not
> what should be.
> ...which could mean that we have to have native OCX files....
>
> ---------------------------------------------------------------
> This Message was Powered by Xcel Communications
> Sign up for your FREE EMAIL account today at http://www.mailroom.com
> Give your FAX machine an email address http://www.faxroom.com
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Re: [VB4Linux-Dev] (no subject)

[Luke-Jr <Mi...@an...>]

Eventually....

abh...@ma... wrote:

> VB4Linux should be able to work with CVS.
>
> ---------------------------------------------------------------
> This Message was Powered by Xcel Communications
> Sign up for your FREE EMAIL account today at http://www.mailroom.com
> Give your FAX machine an email address http://www.faxroom.com
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

[VB4Linux-Dev] (no subject)

[<abh...@ma...>]

VB4Linux should be able to work with CVS.




---------------------------------------------------------------
This Message was Powered by Xcel Communications
Sign up for your FREE EMAIL account today at http://www.mailroom.com
Give your FAX machine an email address http://www.faxroom.com

[VB4Linux-Dev] (no subject)

[<abh...@ma...>]

	

> could we leverage the Tcl/Tk debug environment for our 
> debugging program if
> we code vb2c in Tcl/Tk? any idea how? In that case it could be 
> of help...
> 
> Well coding it in a higher level language like Tcl would give you a
> speeder turn around in development time as you know (and more people
> could support it).  We could write hooks in C (in the support libs we
will
> need anyway) to help with debugging and could generate the calls for
them
> on the fly in Tcl from the debugger (It would be easier for "code
> injection" with it), so yes it could help.  
> 
> There are a couple of other options for debugging.  We could 
> generate a.out
> or elf stubs section with the debugging symbols and write and 
> extension for
> gdb.  This would take more time tho.  We could also write a VM and
have
> hooks into it for debugging.

I think it would be the best to code debugger in C.

vb apps in design stage would use pre-existing .so files to run in a
virtual environment where the debugger would be present. Once we have
to release the vb app, we shall then put it thro vb2c.

Also, about using wine libs...looks OK on the surface, but can we
emulate only a specific dll or OCX using wine?
Also, when we want to emulate them, we'd need to have them
first...which means we need to have M$ VisualBasic installed on the win
partition first...before VB4Linux can use the OCX files...which is not
what should be.
...which could mean that we have to have native OCX files....





---------------------------------------------------------------
This Message was Powered by Xcel Communications
Sign up for your FREE EMAIL account today at http://www.mailroom.com
Give your FAX machine an email address http://www.faxroom.com

Re: [VB4Linux-Dev] about WinAPI

[Muhammed B. <muh...@on...>]

Luke,

Hi... I'm really sorry I have not been participating actively in the
project. I just got a new job and i have been put on a new project which
is taking too much of my time. So right now I have no choice but to opt
out of the project. 

I'm really sorry about it !! and I wish you all the best on the project
!!


Muhammed !


---- Luke-Jr <Mi...@an...> wrote:
> Yea... After we get the basics for the language made and have OCXes
> and
> DLLs emulated or pre-emulated I think we can use the original Kernel.Dll
> and stuff... Although to distro them would prolly be illegal so we
> might
> just remake a native Linux ".so" or similar...
> 
> Abhijit Paithankar wrote:
> 
> > any idea how we could reuse the existing WinAPI for VB?
> > _______________________________________________
> > VB4Linux-Dev mailing list
> > VB4...@li...
> > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev
> 

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

Re: [VB4Linux-Dev] about WinAPI

[Luke-Jr <Mi...@an...>]

Yea... We're going to be using a bunch of Wine anyway it seems...

P.S. Fix yer clock! Unless it really took 2 hours for this to get thru,
which is doubtful... ;-P

Scott Beasley wrote:

> On Mon, 20 Nov 2000, Abhijit Paithankar wrote:
>
> > any idea how we could reuse the existing WinAPI for VB?
> linking with the Wine libs to me, would be the easiest.
>
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Re: [VB4Linux-Dev] about WinAPI

[Luke-Jr <Mi...@an...>]

Yea... After we get the basics for the language made and have OCXes and
DLLs emulated or pre-emulated I think we can use the original Kernel.Dll
and stuff... Although to distro them would prolly be illegal so we might
just remake a native Linux ".so" or similar...

Abhijit Paithankar wrote:

> any idea how we could reuse the existing WinAPI for VB?
> _______________________________________________
> VB4Linux-Dev mailing list
> VB4...@li...
> http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev

Re: [VB4Linux-Dev] about WinAPI

[Scott B. <js...@go...>]

On Mon, 20 Nov 2000, Abhijit Paithankar wrote:

> any idea how we could reuse the existing WinAPI for VB?
linking with the Wine libs to me, would be the easiest.

RE: [VB4Linux-Dev] Debugging

[Scott B. <js...@go...>]

On Mon, 20 Nov 2000, Abhijit Paithankar wrote:

> > > There should be two states a program can be in, Debug and Release (just
> > > like VC++). While the program is in Debug, it would compile to bytecode
> > > and an interpreter runs this code. This should make debugging facilities
> > > a bit easier to program. When the programmer wants to Release his/her
> > > program to the public, he/she selects 'Make <program name>' from a menu
> > > (as in VB) and the program is natively compiled and debug info in the
> > > source code is ignored (VB ignores Debug.Print statements when it is
> > > Make-ing the program). There is also another Basic project (KBasic)
> > > being developed at the moment, perhaps the bytecode should be compatible
> > > with that?
> 
> there is definitely a point in this...
> if we could have the program to run in debug environment(pre-vb2c) before it
> is released (VB2C), it would help faster development and lighter code at
> design-time....also the parsing VB2C and compiling with gcc would take a lot
> of time everytime at design-time.
> 
> > I was thinking to make a shell, that interprets the code for the
> > debugging... it is the worst idea?
> 
> this is same as a reverse interpreter...
> 
> > Tcl is not Tk in this case (Tcl is the scripting language and Tk is the
> > windowing Tool Kit)  Tcl, Tk and Python are quite portable though, as
> > portable as perl even.
> 
> could we leverage the Tcl/Tk debug environment for our debugging program if
> we code vb2c in Tcl/Tk? any idea how? In that case it could be of help...

Well coding it in a higher level language like Tcl would give you a
speeder turn around in development time as you know (and more people
could support it).  We could write hooks in C (in the support libs we will
need anyway) to help with debugging and could generate the calls for them
on the fly in Tcl from the debugger (It would be easier for "code
injection" with it), so yes it could help.  

There are a couple of other options for debugging.  We could generate a.out
or elf stubs section with the debugging symbols and write and extension for
gdb.  This would take more time tho.  We could also write a VM and have
hooks into it for debugging.

scott

RE: [VB4Linux-Dev] Debugging

[Abhijit P. <abh...@ma...>]

> > There should be two states a program can be in, Debug and Release (just
> > like VC++). While the program is in Debug, it would compile to bytecode
> > and an interpreter runs this code. This should make debugging facilities
> > a bit easier to program. When the programmer wants to Release his/her
> > program to the public, he/she selects 'Make <program name>' from a menu
> > (as in VB) and the program is natively compiled and debug info in the
> > source code is ignored (VB ignores Debug.Print statements when it is
> > Make-ing the program). There is also another Basic project (KBasic)
> > being developed at the moment, perhaps the bytecode should be compatible
> > with that?

there is definitely a point in this...
if we could have the program to run in debug environment(pre-vb2c) before it
is released (VB2C), it would help faster development and lighter code at
design-time....also the parsing VB2C and compiling with gcc would take a lot
of time everytime at design-time.

> I was thinking to make a shell, that interprets the code for the
> debugging... it is the worst idea?

this is same as a reverse interpreter...

> Tcl is not Tk in this case (Tcl is the scripting language and Tk is the
> windowing Tool Kit)  Tcl, Tk and Python are quite portable though, as
> portable as perl even.

could we leverage the Tcl/Tk debug environment for our debugging program if
we code vb2c in Tcl/Tk? any idea how? In that case it could be of help...