Visual Basic on GNU/Linux 383
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."
Patents (Score:5, Informative)
Re:Uuuhh.. sure... (Score:3, Informative)
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.
Re:Uuuhh.. sure... (Score:3, Informative)
Gambas (Score:2, Informative)
Re:Terrific (Score:4, Informative)
Re:Um... (Score:3, Informative)
Re:OS X Intel? (Score:5, Informative)
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
Re:Patents (Score:3, Informative)
So, no, there should not be any problems with the distribution of it.
The only obstacle now, is a good Linux IDE for writing the code.
Re:I don't get it (Score:5, Informative)
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.
Re:Worrying trend... (Score:5, Informative)
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.
Re:OS X Intel? (Score:5, Informative)
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.
Re:OS X Intel? (Score:5, Informative)
The road analogy is poor though. Programming languages don't have a "capacity" for the number of users.
Re:OS X Intel? (Score:4, Informative)
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
Re:OS X Intel? (Score:3, Informative)
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
Re:OS X Intel? (Score:3, Informative)
Re:OS X Intel? (Score:3, Informative)
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.
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.