Migrating Visual Basic Applications? 72
goose69 asks: "I was looking at the various options available to migrate Visual Basic applications on to GNU/Linux ,
as usual the choices were many from Free Solutions like wxWindows, Gambas, vb2py, to proprietary ones like Phoenix, and so on. Unfortunately, Mono was too much with its multiple licenses. I want to know if anyone out there has done a successful migrations from Visual Basic on Windows to any application framework on GNU/Linux."
You may not like it, but.... (Score:5, Interesting)
Makes UI development easy, and I do all of the 'hard working' code in perl.
Depends on the Quality (Score:5, Interesting)
If it was highly specific, low levels of abstraction, high levels of re-typed (or almost re-typed with subtle code differences) structures, then it will be a nightmare. If it was highly abstracted and carefully programmed it should be easy to re-implement.
It is easy to find an equivalent library, it is easy to adapt the constructs of well structured code: as easy as going from pseudo code to pascal in past decades, no matter what the language. But it is hard to go from poorly written source to an adaptable solution: VB shows its pitfalls here, but only so much as C (in this respect, not many others which VB implements poorly, but programming it is not the point, reprogramming it is).
Maturity (Score:5, Interesting)
I think the closest match you're going to find for a serious project would probably be the QT designer. I know it's based around C++, but it is a stable and mature environment, and has a track record of producing real-world applications.
If your VB app was well written, with a decent class structure, it shouldn't be too hard to convert to any OO language, so as long as you have a grasp of C++, the process wouldn't be too difficult.
If the app *isn't* well written, converting it is probably the wrong approach - you should be thinking of re-implimenting it your chosen new language - in other words, take the opportunity of the change in language to improve your code structure; don't carry your old mistakes across into new code.
Migrating (Score:4, Interesting)
OTOH if you want to migrate a business task from VB and are prepared to actually rewrite whole applications use wxWidgets (it's been called wxWidgets for some time already, read this document [wxwindows.org]) with whatever language you want, binding for many common (and not so common) languages exist. Use C or C++, use Ruby or Python or Perl or even use JavaScript
Re:Depends on the Coupling (Score:5, Interesting)
Case in point: I'm currently porting a portion of a PowerBuilder app [88k+ LOC] to Java. Fortunately, the code is not coupled to the interface (other than poping up message boxes for errors, due to PB's lack of exception handling).
My strategy? ~50 regular expressions to translate the syntax between PB and Java, plus ~30 classes emulating the PowerBuilder functions/libraries used by the code. The code quality is the same as it was before, but I had successful test cases running less than 3 weeks after starting the project (including developing the regular expressions and the support classes). If that's all you need, you can stop there.
I got away with this strategy because the code wasn't coupled to the interface. The code *was* tied heavily to the database, but it's much easier to mock up data access than it is to recreate a visual interface.
On the other hand, if you're talking about re-writing or cleaning up the code in the process, that's another story entirely. I've spent the past three months reworking the ported code to use Java idioms, decoupling it from the data layer, and refactoring the "almost re-typed with subtle code differences" sections; if the original code had been higher quality, the project would have been done two months ago.
Re:You may not like it, but.... (Score:3, Interesting)
Re:You may not like it, but.... (Score:5, Interesting)
More info here, I think...
http://www.realsoftware.com/realbasic/guides/port
Appgen as an alternative to VB development (Score:3, Interesting)
Brief comparison:
The Appgen 4GL Development System and Microsoft Visual Basic are both application generators.Visual Basic generates one executable file which runs strictly on the Windows operating system. Appgen creates parameter files which run within the Appgen Run Time engine (Appgen is more like Java in this area). The Appgen Run Time is available for multiple operating systems, such as Windows, Mac OSX, Linux (multiple distributions and UNIX (multiple vendors and versions).
Appgen and Visual Basic both use a screen painter to layout the screen display, and both have screen properties and functions which tie with each screen field.
Appgen 4GL development is fully integrated with the Appgen Database system; VB has no integrated database.
With each screen field, Appgen also has a database property where the user can simply define the data field, type, format. The Appgen Run Time will take care of the file open and close, data fetch, update, and type checking. Visual Basic requires another database engine (ex. Oracle, MS SQL) to have the database ability. The user needs to write all functions to connect to the database, open or close files, and need to write SQL commands in all the fields to fetch and update data.Although Visual Basic can be fully integrated with MS Access to work in a manner similar to Appgen, the Access database limitation on handling large quantities of data significantly reduces the value of this feature.
Appgen runs on multiple platforms with the same set of parameter files. VB applications run only on Windows. Appgen supports linking with C programs, which gives user the power to add-on or incorporate their own functions. http://www.appgen.com/ [appgen.com]Re:COM and other considerations (Score:2, Interesting)
VB had two different "modes": bound database connections and record-set-based connections. Bound connections (live cursors) simplified a lot of development, but tended to be hard-wired to a lot of MS-specific tools and were not as efficient over a trifficy network. It would probably be much easier to port non-bound VB code.
This might help... (Score:3, Interesting)
What about extension modules? (Score:3, Interesting)
What does it take to write extension modules (either GUI or non-GUI) for RealBasic? Do you write them in RealBasic or is there a way to write them in C/C++?
If you do a GUI extension module, does your application become dependent on Windows/OS-X/Linux or does it have some kind of abstraction of the GUI and abstraction of the graphics drawing surface accessible from C/C++?
Re:Maturity (Score:2, Interesting)
Re:Java (Score:3, Interesting)
The only real problem Java has is that there is no good Free JVM. But I expect that will change in the future.
I too expect it will change, but the JVM and class libraries are very tightly coupled, meaning one can't really be complete without the other. Thus, I strongly encourage anyone who can to support Free (as in Freedom) Java efforts like GCJ [gnu.org], Kaffe [kaffe.org], Jikes [sourceforge.net], and probably most importantly GNU Classpath [gnu.org].
Mono (Score:1, Interesting)