×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Migrating Visual Basic Applications?

Cliff posted about 9 years ago | from the from-dogs-to-penguins dept.

Programming 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

72 comments

Who cares (-1, Troll)

Kaamoss (872616) | about 9 years ago | (#12138156)

Who cares...VB is quite possibly the worst language ever...horibly inefficent code and utterly simple syntax. Why not re code it in a real language like C++? :)

Depends on the Quality (4, Interesting)

Uber Banker (655221) | about 9 years ago | (#12138305)

It depends on the quality the VB was written in.

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).

Re:Depends on the Coupling (5, Interesting)

scottsevertson (25582) | about 9 years ago | (#12138537)

Even poor *quality* code can be *ported* easily to another platform/language, but only if the code is not highly coupled to the interface.

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:Depends on the Coupling (-1, Flamebait)

Anonymous Coward | about 9 years ago | (#12139804)

Java si teh suck... y use it?!?!!!

You may not like it, but.... (4, Interesting)

numbski (515011) | about 9 years ago | (#12138194)

RealBasic 5.5+ [realbasic.com] does a large portion of the work involved for you. Simple applications port right over to Windows, Mac, and Linux (thus FreeBSD).

Makes UI development easy, and I do all of the 'hard working' code in perl.

Re:You may not like it, but.... (2, Interesting)

atomic-penguin (100835) | about 9 years ago | (#12138802)

Funny, I can't seem to find their Linux version of RealBasic.

Re:You may not like it, but.... (5, Interesting)

Omega996 (106762) | about 9 years ago | (#12138863)

I'm not sure there's a version of RealBASIC that actually runs on Linux. I think it's more like a compiler target. Maybe with their next version (should be out soon) there'll be something that actually allows Linux dev on Linux.

More info here, I think...

http://www.realsoftware.com/realbasic/guides/porti ngvisualbasic/ [realsoftware.com]

Re:You may not like it, but.... (1)

Tablizer (95088) | about 9 years ago | (#12139294)

There is a blurb suggesting that some cross-platform features are still in beta.

Re:You may not like it, but.... (4, Informative)

ikilledmidnight (872689) | about 9 years ago | (#12139498)

the linux version of the IDE isn't out yet and is going to premier with the new version of realbasic (RealBasic 2005) realbasic has been able to conpile for linux from about version 3/4. some screenshots from Realbasic 2005: IDE [realsoftware.com] , IDE 2 [realsoftware.com] , compiled app [realsoftware.com]

Re:You may not like it, but.... (5, Informative)

lordDallan (685707) | about 9 years ago | (#12139485)

The about to be released version [realsoftware.com] of RealBasic does allow the IDE to run on Linux and is written in RealBasic.

This implies that its Linux support will be more robust than the current version's.

Also, if you have a VB 6 license, you can get a free RealBasic Standard for Windows license [realsoftware.com] through April 15th.

One thing to look out for if your writing a RealBasic application for Linux is DB support. There are many database plugins for RB but I've had issues getting some of them to work properly on Linux (though it's been awhile since I've tried so things may have improved).

Anyway, if you're a licensed VB6 user, you probably have a Windows machine, so why not get the free RB license and give it a whirl. It is a "better basic" than VB6, mostly because it's a real OOP environment and is actively being worked on by a company that lives or dies on it being a good product.

HTH

Re:You may not like it, but.... (5, Insightful)

ikilledmidnight (872689) | about 9 years ago | (#12140050)

I personally prefer RB over VB for a number of reasons, including:
  • unlike VB you don't have to have certain DLLs installed etc, the apps are self contained
  • It's cross platform from the same code (Windows 98 and onwards), OS 9, OS X, Linux (Redhat SuSE, I dunno about any others)
  • I find the IDE, far more intuitive and less cluttered and not so 'Windows 95'
  • The help system is FAR better
  • theres way more default controls, for example theres a TCP socket in RB you don't have to import the winsock dll to add TCP capabilities


to be fair I haven't used VB since VB 6, so I have no idea what .net is like, but thats the way I see things anyway...

Re:You may not like it, but.... (0)

Anonymous Coward | about 9 years ago | (#12203832)

(really late I know, found this in meta-mods)

unlike VB you don't have to have certain DLLs installed etc, the apps are self contained

Even in VB6 this isn't a problem, the runtime is bundled with all OS releases after Windows 98 and will be in Longhorn.

The .NET runtime is bundled with server 2003 and will be bundled with Longhorn. It's a recommended update on Windows Update on all other platforms, and chances are you'll install it with some app or other sooner or later.

What about extension modules? (2, Interesting)

Latent Heat (558884) | about 9 years ago | (#12142584)

I poked around the RealBasic site and didn't get too many leads on this.

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:What about extension modules? (3, Informative)

ikilledmidnight (872689) | about 9 years ago | (#12142742)

you have to write them in C/C++ theres a realbasic plug in sdk avaliable to download here [realsoftware.com]

theres a dated plug in writing example here [mactech.com] which'll give you a rough idea of how it all works, RB plug-ins are only platform specific if you use platform specific code, if you use active x for example, it becomes a windows specific plug-in.

Re:You may not like it, but.... (1)

jsprat (442568) | about 9 years ago | (#12147225)

I'd like to add that RealBasic announced [realsoftware.com] just today that they are offering a free RealBasic license to anyone who holds a VB6 license, up to 3 per physical address.

There's a utility to convert a VB6 project to RealBasic as well as a migration guide.

I've downloaded and installed, but haven't taken the time to review it yet.

Maturity (4, Interesting)

Spudley (171066) | about 9 years ago | (#12138501)

It comes down the maturity of the development environment. For all its many faults, VB is a mature platform. Gambas is not. If you're planning to release an application for use in the real world, Gambas is not a choice you should be considering. No matter how tempting it may be for a VB developer, if you're serious about using it, at least wait until v1.0 is ready.

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.

This might help... (2, Interesting)

leonbrooks (8043) | about 9 years ago | (#12140054)

...thanks, Naken [naken.cc] . I'd like to see VB2Ruby one day, please, if any of y'all have some free time.

Gambas version = 1.04 (0)

Anonymous Coward | about 9 years ago | (#12140526)

Then it's ready, right?

Re:Maturity (2, Interesting)

indifferent children (842621) | about 9 years ago | (#12142608)

On Linux, I use Java with the free NetBeans IDE as a VB 'replacement'. It has a drag-and-drop form designer that will automatically tie control-events to your functions (it writes an empty stub method for you). It uses Swing, and is a good bit slower than C++ (partly Swing's fault, largely Java's fault), but likely as fast as VB. This will be more like a re-write than a simple port, but it uses a more 'popular' platform than any of the Basic solutions that have been mentioned, and is probably easier and more portable than the C++ solutions.

Re:Maturity (1)

slapout (93640) | about 9 years ago | (#12166029)

For all its many faults, VB is a mature platform

That's what I keep telling people about .Net
They started over from scratch (at least on the VB part.) So you're starting out with a still maturing product.

Re:Maturity (1)

raindog2 (91790) | about 9 years ago | (#12180582)

Actually, Gambas 1.0 was released back in January; the current stable release is 1.0.4.

In the unstable 1.9 tree there's working support for ODBC, Gtk (in addition to and code compatible with the Qt support), full screen and windowed SDL, perl-compatible regular expressions, a VB form importer (just the form, not the code yet), support for components which themselves are written in Gambas, and a bunch of other awesome stuff. I wouldn't use the unstable tree for production code yet, but the 1.0.x series is quite stable and mature.

Granted I've been porting VB applications to Gambas longer than probably any other American developer, but I have an awful lot of Gambas code in production. Some of it's been deployed for over a year and hasn't broken yet even though I developed it before the release of 1.0.

Migrating (4, Interesting)

Anonymous Coward | about 9 years ago | (#12138502)

If you want to migrate a single application from VB use Gambas. The languages are quite similar which will make the transistion much quicker and doesn't need as much new knowledge.
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:Migrating (0)

Anonymous Coward | about 9 years ago | (#12139656)

Yeah but wxWidgets sucks. It's got all the bloat of QT combined with the complexity and stupidity of MFC plus all the bugs bloat and weirdness of the real GUI API that it is using.

I don't even consider it a true cross-platform toolkit as there are all sorts of interdepedancies and limitations depending on what platform you are running in. You application turns into an #ifdef hell of spaghetti code. Just look at the examples if you don't believe me.

Problem with the licencing????? (5, Insightful)

TsEA (109514) | about 9 years ago | (#12138505)

Excuse me, but I really can't understand the phrase: "Unfortunately, Mono was too much with its multiple licenses."
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....

Re:Problem with the licencing????? (3, Informative)

atomic-penguin (100835) | about 9 years ago | (#12138922)

Also note that mono is meant for Visual Fred [catb.org] not Visual Basic.

Re:Problem with the licencing????? (1)

stratjakt (596332) | about 9 years ago | (#12148218)

Run the upgrade wizard in VStudio.Net to get your VB.Net project: compile under mono.

The problem is, mono isn't close to supporting winforms. So you're rewriting your entire GUI no matter how you slice it.

COM and other considerations (5, Insightful)

Joey Vegetables (686525) | about 9 years ago | (#12138660)

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:COM and other considerations (1)

jd (1658) | about 9 years ago | (#12139245)

I believe there are closed-source ports of COM for Linux. DCE was recently open-sourced as well, which arguably does everything COM does and more. If high performance is not an issue, CORBA is also a good bet, with the ACE ORB being one of the more frequently mentioned.


For clusters, the optimal solution is to use OpenMOSIX and Distributed Shared Memory to provide some of the more useful features. DSM is vastly under-utilized in Linux applications and it might be a good idea if it made its way into the official kernel in a way that wasn't tied to any specific clustering mechanism, or indeed to clustering per-se at all.


For COM-like mechanisms in the GUI, I think it's the Free Desktop project that's developing such systems. Last I heard, the mechanisms developed exceeded those currently used by Gnome or KDE, so it's worth looking to see what is there.

Re:COM and other considerations (2, Interesting)

Tablizer (95088) | about 9 years ago | (#12139367)

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...

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.

Re:COM and other considerations (1)

NullProg (70833) | about 9 years ago | (#12139668)

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.

Just a minor complaint with your post.

Packaging is not a issue if he/she chooses the correct runtime environment. POSIX/LSB compliance should be the goal. Source code distribution is only required if the author uses GPL (and derivatives) code. Other than that he/she can distribute in binary only form.

Would you really recommend Python/Ruby/Java etc. when none are ANSI/ISO approved? He/She might wind up in the same situation when someone hijacks the language.

Food for thought.
Enjoy.

Re:COM and other considerations (2, Insightful)

Joey Vegetables (686525) | about 9 years ago | (#12142779)

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.

Re:COM and other considerations (1)

NullProg (70833) | about 9 years ago | (#12161027)

What a intelligent response. Here I was giving up on slashdot due to the signal to noise ratio lately :)

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.

I deal with SCO/NCR/OS2/AIX/Windows/Linux binaries. No issues when your POSIX/ANSI compliant. Compiler/linker issues yes, no runtime problems other than the TCP/IP stack on Win9x hosts.

Thanks for the good response.
Enjoy,

best answer, likely (-1, Troll)

XO (250276) | about 9 years ago | (#12138691)

Don't use BASIC to begin with.

If it's too late for that, well.. sorry about your luck. Maybe now is the time to invest in writing for a platform that you can easily move with?

Re:best answer, likely (2, Insightful)

Anonymous Luddite (808273) | about 9 years ago | (#12140642)

>> If it's too late for that, well.. sorry about your luck.

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".

Stupid (-1, Flamebait)

hexghost (444585) | about 9 years ago | (#12138740)

Hi Slashdot!

I've been assigned a task that involves taking our proprietary, shitty out of date codebase and converting it into some newfangled F/OSS system! Since this involves the words F/OSS and (insert /. favorite scripting language here) I know you'll post my story. My question is, has anyone in the /. crowd done this before, preferably with a detaild step by step how-to blog showing how? Also, what brand deoderant will get the the chix at the local linux users group?

Re:Stupid (0)

Anonymous Coward | about 9 years ago | (#12145884)

Also, what brand deoderant will get the the chix at the local linux users group?

none

PHP + Apache + web browser (-1, Flamebait)

Anonymous Coward | about 9 years ago | (#12138822)

running locally works great, and means that you are truly cross platform.

Re:PHP + Apache + web browser (0)

Anonymous Coward | about 9 years ago | (#12139456)

Web browsers for real GUI's? Aaaaaaaaaah! I want my combo box, tabbed windows, grid control, and tree browser widgets without crashy JavaScript implementations.

Re:PHP + Apache + web browser (1)

ispeters (621097) | about 9 years ago | (#12141371)

Try Sydney [sf.net] then. The SourceForge page is a little out of date because I've been busy with school/work, but we've done a lot of work at Navtech recently (that's been the work bit of my excuse) to improve Sydney for the live web application we've built on top of it. It gives you combo boxes, tabbed windows, a table widget (a grid control would be an obvious extension to this) and a tree widget, amongst other things, and the Javascript's not crashy.

Other interesting features: cross-browser (works in Moz, IE, Safari, and (probably) Opera--no it doesn't work in Lynx, Emacs, etc.), keyboard support (you can navigate the tree and table widgets with the arrows, etc.), robust library code for managing data-presentation separation, custom context menus, unit test framework modelled after JUnit, and a source cruncher and a server-side include manager for speeding up downloads. I can't remember if any of these features are still only in the Navtech repository, but all the recents in-house improvements will be in the public repository before the end of April, maybe before the middle of April, depending on my final exam schedule.

Sydney works. We've built a complex web application on top of it that consists of more than 90,000 lines (3,000,000 characters) of Javascript (according to `find . -name *.js | xargs wc -l -c`) and several tens of thousand lines of Perl.

Ian -- Sydney maintainer

Re:PHP + Apache + web browser (0)

Anonymous Coward | about 9 years ago | (#12149375)

And when the user disables Javascript?

Re:PHP + Apache + web browser (1)

ispeters (621097) | about 9 years ago | (#12149448)

It doesn't work. It's not intended for "web pages" that I fully agree should be completely accessible and gracefully degrade. Syndey is intended to be an application framework. Applications come with minimum system requirements, and Sydney's list includes "JavaScript is turned on".

Ian

What version of VB? (-1, Offtopic)

amliebsch (724858) | about 9 years ago | (#12138856)

Are you talking about VB 6.0? VBA? VBScript? VB.NET?

If VB.NET, the best solution is to learn to live with Mono licensing, because unless P/Invoke is used, porting is as simple as compile-->run.

ASP Clone (2, Informative)

Tablizer (95088) | about 9 years ago | (#12139317)

Are you talking about VB 6.0? VBA? VBScript? VB.NET?

If VB-script (ASP), then Sun Microsystems has an ASP clone that used to be under ChilliSoft IIRC. It uses Java bytecode I beleive.

Yes (1, Informative)

Anonymous Coward | about 9 years ago | (#12138990)

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."

It's VBScript, rather than VB, but FogBugz [joelonsoftware.com] has been automatically translated from ASP/VBScript to PHP. IIRC, some of the trickier problems were resolved through a hack that relies on Hungarian notation.

Appgen as an alternative to VB development (3, Interesting)

apgdev (873377) | about 9 years ago | (#12138997)

Consider using Appgen as an alternative to VB, offering a single set of developed code that can then run on a variety of OS platforms.

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:Appgen as an alternative to VB development (3, Insightful)

innocent_white_lamb (151825) | about 9 years ago | (#12141781)

Consider using Appgen as an alternative to VB

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.

anti-mono troll (1)

rnd() (118781) | about 9 years ago | (#12139457)

rediculous anti-mono troll. use mono, it's better than Microsoft and free enough for a lot of people.

Re:anti-mono troll (1)

Random Guru 42 (687672) | about 9 years ago | (#12139878)

Actually, on Win32 Mono isn't as good as Microsoft .NET. Of course, on all other platforms, it is superior.

Re:anti-mono troll (2, Insightful)

rnd() (118781) | about 9 years ago | (#12142390)

uh, give it time... the 1.16 release (current) includes sse optimization for math and even more optimizations.

the Mono Project is an incredible benefit to the open source community. We don't need pointless trolling about its licensing on Slashdot.

To answer your question (3, Funny)

larry bagina (561269) | about 9 years ago | (#12139716)

Someone out there has done a successful migrations from Visual Basic on Windows to any application framework on GNU/Linux.

Java (4, Insightful)

Mr. Shiny And New (525071) | about 9 years ago | (#12140167)

You could always consider Java. Java has lots of support in the Open Source world. The Eclipse IDE is pretty nice. JBuilder, while not Free, has a decent GUI editor (never looked for one for Eclipse, so I don't know if it has one) that can approximate the drag-and-drop approach of VB. Java can do pretty much anything you need it to do, and it's cross-platform. Performace with a modern VM is not a problem.
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.

Re:Java (2, Interesting)

Joey Vegetables (686525) | about 9 years ago | (#12142800)

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] .

Re:Java (2, Informative)

cybergrue (696844) | about 9 years ago | (#12145490)

Eclipse has the "Visual Editor" plugin too create GUI's. Its now part of the standard plugins, so you can download and install it from inside Eclipse using the add/update software menuitem in the help menu. The VE does takes a while to learn, and still needs a bit of polishing, but its definately useable. I just completed a small project for school using it, and after I learned how to use it, it was the easiest Java GUI that I had ever put together.

Multiple Licenses? (0, Redundant)

aCapitalist (552761) | about 9 years ago | (#12140393)

Bahahaa. Mono's multiple licenses are too much? Let's see. The compiler is GPL, the runtime is LGPL, and the libraries are MIT/X11.

Let's hope this guy's boss doesn't know about this post and realize that he can't hold 3 simple concepts in his head at one time.

Mono is the obvious choice (4, Insightful)

aCapitalist (552761) | about 9 years ago | (#12140470)

But the compiler being GPL, the runtime being LGPL, and the libraries being MIT/X11 are too much for this guy too handle.

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.

not mature, but interesting (0)

Anonymous Coward | about 9 years ago | (#12140945)

Banteng [bantengproject.org] seeks to deliver a platform that would make it easy to develop an application that runs on Windows, Linux, and Mac OS X. The language is JavaScript and the toolkit is Eclipse.org's SWT. And thanks to GCJ - it doesn't require Java.

Mono (1, Interesting)

Anonymous Coward | about 9 years ago | (#12143408)

If you can stand to wait until Mono has gotten the WinForms [mono-project.com] is done, then afaik, you will be able to write a single app that runs on both win32 and linux(using GTK/Gnome I assume).. Or so I've been lead to believe

okay...a question (0)

Anonymous Coward | about 9 years ago | (#12158180)

Why the hell where you using VB to start with. I would never dream of using VB for *IMPORTANT* applications...it's plain retarded...

Let me introduce you to this little known programming Lang...its name is C..look it up... works great!

But if you really want to port that VB app and want all the same functionabilty of it...let me recommend Javascript...

Re:okay...a question (1)

goose69 (865492) | about 9 years ago | (#12172119)

well i am not a VB guy not even doze, this is for a company and they are ready to move on to GNU/Linux only an only if there existing applications work. I think somebody has to take the responsibilty and get the job done after all its a matter of converting few hundread desktops to GNU/Linux. i dont want to miss such an opportunity to learn ....

When I grow up I want to be a script kiddie (0)

Anonymous Coward | about 9 years ago | (#12179270)

But for now, I wan't to learn how to bring down my company from the inside by convincing someone that a stupid idea makes sense, like taking working applications and converting them to something marginal on a different platform that no one in the enterprise uses.

Re:okay...a question (0)

Anonymous Coward | about 9 years ago | (#12192545)

If they want the apps to "just work" then you might have a look at wine (or maybe even the commercial version, which probably has much better support. You might be lucky - probably not but it shouldn't take you long to find out.
Another option would be to run a virtual machine, seeing as you already have the winders licences. VMware can probably be got quite cheaply if you get lots of licences, or something like bochs might already do everything you need.
Cheers

VB.NET brings you the power of CLR libraries (1)

Carl Rosenberger (449479) | about 9 years ago | (#12179957)

Many people in this thread have come up with alternatives to VB.NET. Here is a very strong argument for VB.NET and for the .NET platform in general, whether you want to run on Mono or on MS:

Since Java and C# are very similar, just about all the important open source Java libraries are being ported to C#. Once on C#, they are available for all CLR languages - also for VB.NET.

Some examples:
http://www.db4o.com/ [db4o.com]
http://bbooprevalence.sourceforge.net/ [sourceforge.net]
http://nhibernate.sourceforge.net/ [sourceforge.net]
http://nant.sourceforge.net/ [sourceforge.net]

Strong libraries is what make up the power of a programming language.

Unfortunately, there isn't. (1)

Spy der Mann (805235) | about 9 years ago | (#12181961)

I've been searching for it for YEARS, but no, there's no Open Source RAD for Linux that is compatible with C++. Much less with Visual Basic.

(Check out this link for Differences between Gambas and VB [binara.com] )

My advise is to rewrite your app using C# and then move it to Mono. Sorry, can't think of anything else.

Re:Unfortunately, there isn't. (0)

Anonymous Coward | about 9 years ago | (#12188400)

It's called Qt.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...