Slashdot Mirror
Visual Basic on GNU/Linux
jeevesbond writes "The Mono Project announced that it has developed a Visual Basic compiler that will enable software developers who use Microsoft Visual Basic to run their applications on any platform that supports Mono, such as Linux, without any code modifications."
See also: "Ballmer repeats threats against Linux" thread below.
Care about privacy? Read this!
VB (up to 6) and VB.NET are completely different animals. Mono is .NET basically for the rest of us.
Now, there are good reasons why VB6 code can't be migrated to .NET, but in most cases, where the environment allows, move the code over. Outside of WINE, I don't think you'll ever really get legacy VB to work on Linux in any meaningful way.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Visual Studio is an IDE, and is tied to Windows. Visual Basic 8 is a language tied to .NET. The Windows.Forms group of classes is fairly Windows-specific, but that doesn't mean it can't be implemented on other systems.
tasks(723) drafts(105) languages(484) examples(29106)
Interested in Free Open Source High Quality Zero-Hassle Basic on Linux? Try Gambas. Honestly now, aside from a nice proof of concept I consider this VB to Mono thing somewhat pointless. There are better Tools for easy GUI RAD.
We suffer more in our imagination than in reality. - Seneca
as long as the libraries are written in .net or are cross platform it is not an issue. Consider that for web apps for example there is not really a need for any non-.net libraries in most cases.
RealBASIC is cross platform and *very* compatible with existing VB code.
LOAD "SIG",8,1
LOADING...
READY.
RUN
Yes, this does run on OSX Intel.
Our compiler and runtime are written entirely in portable CIL code that later gets translated into native code on each platform by the Mono JIT.
I believe you are referring to Microsoft's Visual Basic for applications (which is what Office uses) and which is an older version of the language which they are unable to port on its current shape (their stuff was an older version of the compiler that predated the CIL bytecodes).
Miguel
We have been able to run code compiled with Microsoft Visual Basic for a very long time (1.0 was supported for a few years with the old runtime, and 2.0 has been supported for a few months with our new runtime).
But there were a few problems, ASP.NET for example would requite a compiler on the host to compile VB.NET-based ASP.NET pages. ASP.NET works by translating special commands and tags into your language and mixing your code with the resulting output with a technology called "CodeDOM".
So this particular scenario (ASP.NET with VB) was not supported due to the lack of a compiler.
This also allows Windows developers to do their work on Linux directly without having to use two machines to develop.
Miguel.
Either the quote is wrong, or I had was distracted when I said so.
The runtime was developed entirely by Mainsoft, with some help from us in a few areas. Microsoft was not involved in this process, am sorry for the miss-understanding.
The runtime and compiler were pretty much done before I was aware of any discussions between Novell and Microsoft. The major change since September has been that the compiler became self-hosting on Linux (compiles itself, and compiles its own runtime) and that we have had a chance to go from a research project to a product (of course, we will keep improving it)
Miguel.
Apparently you've managed to miss the past 15 years of processor development. The 486 was the last processor to actually execute x86 instructions. Since then all intel x86 processors run an x86 virtual machine on a RISC CPU.
So, yes, both C++ and Fortran share the x86 VM. Also, C# shares the x86 VM because CLI bytecode is never executed, only x86 code. It just delays the compile to x86 til runtime.
The road analogy is poor though. Programming languages don't have a "capacity" for the number of users.
Not to split hairs, but the pentium ran x86 as well, it differed from the 486 in that it had two integer pipelines. It wasn't until you got to OOE capable processors that RISC was the norm (e.g. P6 and above). Whenever you see "micro" or "macro" operations in the description that's not x86.
Oddly enough, the move is to make more and more x86 instructions single ops again to try and free up pipeline slots. They're still using the CISC to RISC approach in both camps, but the decoding is becoming more 1-1 then anything else.
Tom
Someday, I'll have a real sig.
It's not about who "has" the runtime, it's about who *distributes* the runtime.
.NET.
.NET.
.NET because Microsoft stopped distributing Java. Quite a familiar formula for Microsoft really see: Internet Explorer versus Netscape.
So yes, it's entirely up to *Microsoft* to decide whether or not to distribute a Sun compatible Java or an in-compatible Java clone like
Originally Microsoft went with a Sun compatible Java, but then as Java started to become popular they tried to break the Sun licensing terms by making an incompatible version of Java that would lock people into using Windows.
When the court ruled against Microsoft they decided to drop Java support altogethor (effectively killing desktop Java). Then they ripped off the Java language and runtime by making a windows only version AKA
But this is old news, my point was merely that anyone who wanted to use a modern Java like language to develop desktop apps and deploy onto Windows had to flock to
Amiga Basic was written by Microsoft. The basic on the C64 was as well.
No, they won't suddenly stop working but customers who use your VB6 applications expect to keep moving forward technologically. So when they install Vista, or SQL Server 2005 or whatever, and suddenly your VB6 application doesn't work as expected, you could be in real troublem since Microsoft may not fix it. Also companies may not even buy your product any more, knowing that Microsoft will not be supporting or enhancing the language you have used.
Why is their discontinuation of VB so terrible for companies that use the language?
Well aside from the possible failure of VB6 libraries etc, to work properly on future operating systems, companies who's products use VB are also not really able to enhance them. What happens when everyone is releasing 64 bit versions of their applications? VB6 is 32 bit. And what happens when people start selling competing products that can use multiple cores? Since Microsoft no longer supports VB6, it certainly won't be improving the multi-threading features. An what happens if Visual Studio 6 has problems running on future operating systems?
Basically once a proprietary language like that is dumped, you are in real trouble. It's not like you can just shift over to a new vendor. If Microsoft dumped their C++ product, at least you have the possibility of moving your code over to Borland products, or even some open source efforts.
The only option is really to do a total rewrite, and that is something that many companies do not have the time or finances to do.