Thread: [VB4Linux-Dev] (no subject)
Status: Planning
Brought to you by:
luke-jr
From: Abhijit P. <abh...@ma...> - 2000-11-12 09:13:51
|
Apart from the OCX problems, I still am confused about implementation of DLLs and ODBC drivers. what we can do is, create a library that would emulate the VB environment and translate the messages received from the VB applications and translate them into messages that Linux API can understand. All programs would run inside this emulated environment. As for the compiler, even that could run under the environment so that we can directly use all the Win controls. |
From: Abhijit P. <abh...@ma...> - 2000-11-14 10:07:45
|
just to get things clear for everyone. this is what we plan to do. 1. We plan to provide an interface such that whatever OCX, ActiveX controls are available or will be available in the future, will just be 'imported' at design-time [we might need to emulate this-->Wine could be of help] and NOT re-written. This shall take care of keeping updating every time new control comes up. 2. A program that would use the same BASIC language as input or rather the same code used by ppl to develop VB apps on M$ platform, interpret the code to C and then just use gcc to compile. This would produce native Linux programs. |
From: <abh...@ma...> - 2000-11-21 11:31:02
|
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 |
From: Luke-Jr <Mi...@an...> - 2000-11-21 12:27:53
Attachments:
Mike.vcf
|
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 |
From: <abh...@ma...> - 2000-11-21 11:30:06
|
> 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 |
From: Luke-Jr <Mi...@an...> - 2000-11-21 13:11:14
Attachments:
Mike.vcf
|
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 |
From: Abhijit P. <abh...@ma...> - 2000-11-21 15:17:49
|
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 > |
From: Martino S. <ms...@ti...> - 2000-11-21 16:18:50
|
----- 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. |
From: Abhijit P. <abh...@ma...> - 2000-11-21 17:11:46
|
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. > |
From: Scott B. <js...@go...> - 2000-11-21 21:48:12
|
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 > > |
From: Abhijit P. <abh...@ma...> - 2000-12-10 07:26:30
|
I am starting off with the vb2c compiler today....pls send me any last minute suggestions. ab |
From: Luke-Jr <Mi...@an...> - 2000-12-12 12:39:11
|
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 |
From: Luke-Jr <Mi...@an...> - 2000-11-14 13:25:01
Attachments:
Mike.vcf
|
Well, emulation of Windows seems to cause things to take longer to load... Maybe we can `emulate' everything during compile-time and have 100% Linux-compatible binaries be written which is the result of what emulation would make the code be? The binaries would probably have some wasted data that's not used, but with a little optimization we could probably fix that too... Abhijit Paithankar wrote: > Apart from the OCX problems, I still am confused about implementation of > DLLs and ODBC drivers. > > what we can do is, create a library that would emulate the VB environment > and translate the messages received from the VB applications and translate > them into messages that Linux API can understand. All programs would run > inside this emulated environment. > > As for the compiler, even that could run under the environment so that we > can directly use all the Win controls. > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |