Howdy,
First kudos for this valiant effort. Let me offer an idea. If you were to code as much of the translation/recompilation/runtimes in Java, you would get an instant cross-platform boost as well as take advantage of Java's lack of pointers and general uncrashability. The drawbacks are the speed (which is actually quite good!) and strict security model (actually a plus at deployment time). Just something to consider before you dive in with a C implementation. If you're new to Java, you should know the transition from C and C++ is fairly painless.
One other point, you may want to look at the Gnome website as they are currently writing a VBA (Visual Basic for Applications) port for supporting M$ Office apps. They may already have some groundwork laid to help you with support of normal VB apps.
Ok, last point. As you know, the original VBs were interpreted, much like Java, but on an M$ specific VM. The later VBs are compliled and optimized to native source, leaving only the vestigial vb6.dlls hanging around. The latter binary programs are therefore nearly impossible to convert without a full Windoze implementation, which is where WINE should take over. I did a lot of VB programming (sounds like an AA confession) and found that the VB6 compiled code was typically 2x larger, less stable, and slower than the interpreted for most point-and-click applications. Games and real-time interaction were incredibly accelerated in the compiled version.
I guess my point is, this project can really offer a greatly needed peice of the migration puzzle by implementing an open VB4+ virtual machine (same as direct compiler?) and cross-compiling libraries for later VB source codes.
My two cents. I'd like to help out in testing and bug fixes and will keep an eye on progress. Perhaps a few more of my comments will crop up as your planning continues. I'm not going to add myself as a developer as I don't want to commit myself to your worthy cause until my day job allows me to. Best of Luck,
Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2001-01-23
Hi,
I guess Perl would help developing the project fast. atleast a protype can be easily built with perl/Tk.
I would love to help u guys develop/design. eventhough I can't spend too much time for this but would love to work for this good cause.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you're going to actually do something like this, c++ is the only way to go. Weather it is interpreted or compiled is up to you. You could do well with either of them. There's also a lot of pre-existing stuff in this area that you could use to start. Examples that come to mind are:
I think the thing most people miss when working on projects like this is that a language is only as good as the native API it uses to do the work. With the original visual basic it was COM, with vb.net is .net, and the list goes on. Java tries to blur the line between language and interface, but don't be mislead. Java is actually both.
If I had it to do again,
I would say that building on the Mozilla application framework would be a great start. It's got almost everything you need to build something like this, and it's already there.
Howdy,
First kudos for this valiant effort. Let me offer an idea. If you were to code as much of the translation/recompilation/runtimes in Java, you would get an instant cross-platform boost as well as take advantage of Java's lack of pointers and general uncrashability. The drawbacks are the speed (which is actually quite good!) and strict security model (actually a plus at deployment time). Just something to consider before you dive in with a C implementation. If you're new to Java, you should know the transition from C and C++ is fairly painless.
One other point, you may want to look at the Gnome website as they are currently writing a VBA (Visual Basic for Applications) port for supporting M$ Office apps. They may already have some groundwork laid to help you with support of normal VB apps.
Ok, last point. As you know, the original VBs were interpreted, much like Java, but on an M$ specific VM. The later VBs are compliled and optimized to native source, leaving only the vestigial vb6.dlls hanging around. The latter binary programs are therefore nearly impossible to convert without a full Windoze implementation, which is where WINE should take over. I did a lot of VB programming (sounds like an AA confession) and found that the VB6 compiled code was typically 2x larger, less stable, and slower than the interpreted for most point-and-click applications. Games and real-time interaction were incredibly accelerated in the compiled version.
I guess my point is, this project can really offer a greatly needed peice of the migration puzzle by implementing an open VB4+ virtual machine (same as direct compiler?) and cross-compiling libraries for later VB source codes.
My two cents. I'd like to help out in testing and bug fixes and will keep an eye on progress. Perhaps a few more of my comments will crop up as your planning continues. I'm not going to add myself as a developer as I don't want to commit myself to your worthy cause until my day job allows me to. Best of Luck,
Bill
Hi,
I guess Perl would help developing the project fast. atleast a protype can be easily built with perl/Tk.
I would love to help u guys develop/design. eventhough I can't spend too much time for this but would love to work for this good cause.
If you're going to actually do something like this, c++ is the only way to go. Weather it is interpreted or compiled is up to you. You could do well with either of them. There's also a lot of pre-existing stuff in this area that you could use to start. Examples that come to mind are:
Gnomebasic
Shorthand (very promising)
Bbasic
Mod_GB
Gambas
I think the thing most people miss when working on projects like this is that a language is only as good as the native API it uses to do the work. With the original visual basic it was COM, with vb.net is .net, and the list goes on. Java tries to blur the line between language and interface, but don't be mislead. Java is actually both.
If I had it to do again,
I would say that building on the Mozilla application framework would be a great start. It's got almost everything you need to build something like this, and it's already there.
http://www.mozilla.org/why/framework.html
Lots of good stuff there.
I would love to see this project move forward. I can think of several uses for it that I would have.