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."
Problem with the licencing????? (Score:5, Insightful)
Anybody read this? http://www.mono-project.com/FAQ:_Licensing [mono-project.com]
Uses 3 common licences from the GNU/Linux world, GPL, LGPL and MIT/X11. Don't you use X? Don't you use the linux kernel? Does the licensing trouble you?
I really didn't understand this, Mono is one of the clearest (and most convienient) in licensing terms....
COM and other considerations (Score:5, Insightful)
A lot of VB code is mostly glue tying together COM components, such as UI elements, database libraries (ODBC/OLEDB), etc..
There is nothing exactly like COM in the Linux/UNIX world, although large projects such as KDE, Gnome, and Mozilla do have rough equivalents if you are willing to rely on them for part of your functionality. Also, much of what Linux lacks in terms of COM is more than compensated by the existence of rich CLI tools that are designed to be tied together with a "glue" language such as shell, Python, Perl, etc.
My approach has generally been to enforce separation between data, business logic, and presentation to the greatest extent possible. This way, any component can be replaced or migrated to another dev tool or platform if needed.
Postgres is a great back-end database, and the only Free one I can recommend for most serious apps. Middle-tier / business logic components can be written in pretty much any language that can communicate with both the database and the front end. I like to prototype in Python and then possibly port to C++ later when/if there's a need.
The front end is the biggest challenge. The Qt and wxWidgets libraries are extremely well regarded and mature, and there are form builder utilities for both, which approximate (but IMO don't exactly equal) the ease of the Windows forms designers. For reporting, numerous PDF generation tools exist although I don't have a lot of experience with any of them, and most will not have the "drag and drop" interface you may be used to from Crystal or Access, but once you get used to writing code that generates output, I find it's a lot more productive than "drag and drop" anyway.
Most VB code isn't particularly object-oriented (especially since until .NET, VB did not support implementation inheritance). As such, a good multiparadigm language like Python, which supports but does not require OOP, seems like a very good choice.
Packaging will be an issue. Not all of your target users will have identical operating systems, libraries, or locations for common files. You will need to use some combination of Ant, Make, Autoconf, and similar tools in order to distribute your software in such a way that it can be easily compiled and installed by end users (if appropriate) or whomever else your target market may be.
Good luck!
Re:You may not like it, but.... (Score:5, Insightful)
to be fair I haven't used VB since VB 6, so I have no idea what
Java (Score:4, Insightful)
The only real problem Java has is that there is no good Free JVM. But I expect that will change in the future. But in the meantime, the Sun JVM is available for most interesting platforms. Java code is pretty easy to write, and maintain, it's well understood by lots of people, it's proven to work well on large workloads, and it has good open-source and proprietary support.
Mono is the obvious choice (Score:4, Insightful)
Seriously, they're an MS shop who is used to using Visual Studio. The most natural, non-painful migration is to write code using C# and Gtk# or possibly winforms (depending on the maturity of Mono's effort) in Visual Studio on Windows and just copy the binaries or re-compile on Unix until such time that MonoDevelop or some other IDE is mature enough to use.
These are VB guys we're talking about. They're just going to laugh at you if you throw them in front of a Unix workstation and tell them to fire up Emacs or Vim.
Re:best answer, likely (Score:3, Insightful)
Sometimes you don't have any choice. PHB says "I hear VB is better for programming than Excel.." Before you can get your jaw off your chest, you're committed to using VB.
About the best you can do then is write the interface in VB and do all the heavy lifting in DLLs written in C/C++. - I've actually done this before just so I could meet the requirement of "using VB for the project".
Re:Appgen as an alternative to VB development (Score:3, Insightful)
I'm always suspicious of a company that posts a website and wants you to arrange a visit from a salesdrone in order to get a price, or even a "ballpark estimate".
Maybe it's just me.
Re:anti-mono troll (Score:3, Insightful)
the Mono Project is an incredible benefit to the open source community. We don't need pointless trolling about its licensing on Slashdot.
Re:COM and other considerations (Score:3, Insightful)
I guess I'm assuming that portability is an issue: Linux users aren't all on x86 platforms, and there are other free *n*xes besides LSB-compliant distributions of Linux. If you care about supporting anything other than x86 Linux, then releasing anything other than source ends up being a LOT of work.
Not to want to start a Gentoo flamefest here, but I'm impressed with how easy it is to work with Gentoo ebuilds (and *BSD ports). You really end up not having to do much packaging at all: the scripts are smart enough to do virtually all of the work for you, at the price of having to spend a little time compiling. I wish it were possible to retrofit RPM- or .deb-based systems with something like this, not to replace RPM or apt necessarily, but to augment it - to provide a nice way to compile and install software from source even if it is not already "packaged" in the traditional sense. From the little bit I've seen of autopackage, it looks like it may fit the bill.
Your point that some business domains may benefit from a highly standardized language is well-taken, but unfortunately most dynamically typed, very-high-level languages are not ANSI/ISO standards. Nonetheless they are highly useful for getting things done that you just can't do as quickly (or reliably) in C or C++, unless you're a much better coder than most people tend to be. And even if the final production version needs to be C++ or Ada or whatever, you still can prototype in a higher-level language, tweak until ready, then rewrite in that standard language with the benefit of a working and highly flexible prototype.
I'm certainly not saying that packaging is an insurmountable problem, or that there aren't similar problems releasing for Windows; it's not, and there are. But the issues do exist and are a little bit different. Much like Linux itself: better than Windows in many ways; possibly worse in a few others; but definitely different.