Will Microsoft’s forthcoming Vista OS support legacy applications written in VB6? Microsoft plans to answer that question in detail about a month from now, a timeframe that happens to coincide with the one-year anniversary of a petition from developers asking for better support of the traditional VB environment during the emerging .NET era. But for now, MS is willing to say that when Vista goes out the door, Microsoft will extend mainstream support for the VB6 runtime by another six or seven years, through the end of the Vista lifecycle. The same won’t be true, however, for the VB6 development environment, which left mainstream support for extended support in mid-2005.
I have never tried VB.NET but I know _many_ VB6 users that still swear by VB6 and refuse to upgrade to VB.NET. Many of the VB6 users I know that did upgrade to .NET ended up just migrating to C# for the most part.
People will probably keep bugging MS to maintain VB6 support until they figure out why people are so afraid of VB.NET and fix it.
“People will probably keep bugging MS to maintain VB6 support until they figure out why people are so afraid of VB.NET and fix it.”
I think people are “afraid” of VB.NET (really, .NET in general) because it is significantly different from VB6. The operative word there is “different”. People, in general, try and avoid change like the plague, regardless if it’s for the better. Whether or not .NET is “better” is entirely subjective (although I personally believe that there is no point in considering VB6 over VB.NET — and while you’re at it, just go to C# 😉
As far as I can tell, VB.NET is not broken per-se, although some of the “fixes” over VB6 are questionable at best — case in point the AndAlso and OrElse keywords — if you’re gonna take to the time to fix the lack of logical short circuiting in VB, at least fix it, as opposed to providing some lame work around (I presume this was done for backwards compatiblity, but that doesn’t make sense given how different the two are). But I digress…
I think people are “afraid” of VB.NET (really, .NET in general) because it is significantly different from VB6. The operative word there is “different”. People, in general, try and avoid change like the plague, regardless if it’s for the better.
If I spend all of my time learning new languages, then I won’t have time to do my job, will I? If I know VB6 inside and out and am an acknowledged guru on it, why would I want to stop using it and become a neophyte on VB.NET? The human mind (even mine;) has limited capacity. How realistic is it to expect someone to gain and retain expertise in six different assembly languages, C, C++, C#, Visual BASIC, VB.NET, Python, Java, REBOL, Delphi, and dozens of SDKs and libraries?
If VB.NET is really that superior to VB6, then it will be embraced because it improves productivity, reduces coding errors, produces faster apps, etc. Telling people “use it because it’s the latest thing” is not going to sit well with many.
That’s the thing, it’s not an upgrade, it’s a downgrade, a huge step backwards. With a huge runtime library, and .NET being a scripting language ….. What company in their right mind would use it, except for web scripting?
I should actually explain myself better, because I definately do not want to be a troll!
I am a VB 4 -6 “er” all these years. However, at my day job, I use C#. At home, I use either VB6, Aurora, PB, and other languages.
Now, I may have a “state worker mentality”. But I figure, if it works, and can be easily maintained, then why change it? Plaese noticed, I put “easily maintained” in there. We have programs at my day job that uses Clipper5, and DBase III files. These suckers are so old, that hardly anybody nowdays know how to maintain them. Therefore we will rewrite them in a modern language.
In the case of Visual Basic and .NET, VB6 isnt old. Everybody can read the code and understand it. With Microsoft trying to enforce .NET and remove support for all older languages. It just does not make sense to me.
Out of all of .NET, only C++ can write “unmanaged code”. AKA, no huge .NET runtime library required, and it is a programming language, not scripting. In other words, harder then hell to reverse engineer (gotta know ASM), if it was managed, then all you have to do is look at the script (MSIL), and voila! You .. have .. everything.
I know that both the government and Microsoft like the “Security through obscurity”, but that is 100% proven BS (unfortunately). It doesnt work in real life, and it doesnt work for .NET.
VB6 works. For those who have used it for years, and know their way around it .. well, it just works. It does everything you need it to, and even when it doesnt, you can find libraries that will do it for you (Much like the age old language c/c++).
IMO, I have a sneeky feeling that the only reason VB.NET exists is to placate us VB users. Or else it wouldn’t be there at all. I wonder if it’s the same for VC++.
The runtime libraries are a huge issue, but then again, they come with Vista, and is part of the windows update. Same with VB runtime libraries. So that is pretty much a non issue. The lack of security is huge, however.
let alone a scripting language. C#, C++, VB, etc. are languages that run on the .Net runtime platform, and they aren’t scripting languages either. I guess Python runs on .Net now, you might call that a “scripting” language.
According to the definitions of scripting and programming/coding, they are, indeed, scripting language
http://www.dictionary.com
While .NET is great for certain projects, I still think that a lot of developers would love a RAD tool that targets native Win32. Unfortunately, MS no longer provides a tool like this. Delphi and C++ Builder seem like perfect alternatives, but who knows where their future lies.
Delphi and C++ Builder seem like perfect alternatives, but who knows where their future lies.
Probably straight down the crapper. Borland wants to get rid of them and I can’t see any companies really wanting to invest in a platform that is, if not in decline, definitely not growing. Somebody will probably make money supporting all the shops that can’t afford to port to .net, but that’ll be it.
It’s not a matter of affording to adopt .NET, it’s matter of wanting to adopt .NET. There are a huge number of small ISVs and other development shops that will not write their apps in .NET for deployment reasons. It isn’t the size of the download either.
It’s not a matter of affording to adopt .NET, it’s matter of wanting to adopt .NET. There are a huge number of small ISVs and other development shops that will not write their apps in .NET for deployment reasons. It isn’t the size of the download either.
I assume you “deployment reasons” more or less means targetting machines that don’t have the run time installed? That’s a fair enough point, although I’d still lump that in with “can’t afford”, maybe give it the more general description of “aren’t currently able to switch”.
Still, the number of new projects in this area (read: new sales of win32 dev tools) is going to be dwarfed by the projects moving to .net so the win32 market is not going to grow.
Hi, IMHO a very interesting RAD to generate native Win32 applications is Lazarus, founded on FreePascal (practically, Delphi).
The projects is growing well and it’s open source, so there are maybe less possible future commercial problems about it wherever the market goes for the shake of the fashions of the moment.
Advantages:
– open, as said;
– free, download it and use it!
– multiplatform; it’s very trivial to port a NATIVE application from other target operating systems;
– powerful language, that means: good performances of the applications (if well written you see few difference with well optimized ASM code, apps will not eat up your memory), you can write nearly every kind of program with ease (with or without GUI);
– nice RAD environment, you can really easily drag and drop GUI elements as you were painting, then edit them definition in an user friendly panel or directly code (with good code completition functions)… or you can do everything direcly coding, as you like. It’s a pleasure working in it.
– guys behind Lazarus and FreePascal really did a GREAT work documenting the language, documentation is comprehensive and well written.
– the RAD works well even on slower machine; you will not have to wrestle with makefile and since Pascal languages has a single pass compilation even the compilation is really fast.
– if you learn Pascal, maybe you will enjoiy another nice program (on Windows), InnoSetup, that creates setup and is very powerful to script in Pascal!
Disvantages:
– compared to .NET, Eclipse, NetBeans etc… maybe it may rely on a smaller community for the moment;
– you have to strip and UPX executables if you want them of a decent size (6 MB becomes easily 400-500KB);
– some platform specific “bells and whistles” (like i.e. transparence and gui elements theming) should be used directly trough o.s. API (however, there is a nice plugin to install to use in lazarus applications XP native elements, buttons etc…)
http://www.lazarus.freepascal.org/
http://www.lazarus.freepascal.org/
Thanks for pointing lazarus out. I liked Delphi a lot when I used to work with it so, although I’ve never tried Lazarus, I’m inclined to think it’s a good idea. I think it could be a good place to do app development, particularly for companies that want to push out business-specific desktop tools on non windows platforms. C/C++ may be doable for that area, but kind of brutal.
To the list of disadvantages, though, I’d add that it’s not a managed runtime. I don’t expect everyone to agree with that and I don’t think it’s as big a deal on *nix where mono isn’t quite as far as .net on windows. But I think being managed is important for security among other things and although I’m not normally a fan of microsoft, I think they’ve made a really good move with .net.
“To the list of disadvantages, though, I’d add that it’s not a managed runtime.”
I recognize that the concept of managed runtime has very good points for achieving better computing security (and managing it with lessen efforts), however I think that a panacea or a silver bullet jet doesn’t exist in that field.
Many awful thinks (like i.e. blanking the password, or shuffling the wrong s-boxes, or explicitly writing to unsafe locations sensitive data thinking that it’s non sensitive) can still be done unwillingly (and pass unobserved) regardless the means used to develope.
However, even without a managed runtime Pascal-like languages are less error prone to errors than C-like, avoiding a lot of very common errors (assigning variables, handling data structures and so on) that may result in horrible security problems (fixable or non fixable with managed runtime paradigm), sacrificing some “purity” (and being hated by purists) and (a bit of) flexibility.
i.e. assign “a==b”, it is valid in pure C-style and is logically valid even if embedded in “if a==b”, but obviously it’s quite useless and easily harmful => in Pascal you may have “a:=b” but you will not be allowed to assign it in “if a:=b”.
However, I hope that as Pascal greatly accepted the object oriented paradigm and turned into Delphi, and now I can use it in oo and not oo “flavour”, in the future Pascal family may even greatly integrate the managed runtime concept and become even a better (or more complete, depends from points of view) tool for developers.
Some hints about Lazarus for any people interested:
– you can integrate ASM code in FreePascal code, if you really need even faster applications;
– as reported before (this is one of the most asked thing in the forum), executables are very big (starts from about 6 MB) but you can strip them to about 1MB and UPX them to 4-500KB without problems (in Win32 version of the rad you should find those executables, to be used from command line, in the subfolder of lazarus folder);
– to use XP native graphic elements (buttons, radiobox, progress bar, etc) and to easily customize the icon of the executable you can use the free component winxpstyle.lpk developed by Violin Iliev
http://www.lazarus.freepascal.org/index.php?name=PNphpBB2&file=view…
I recognize that the concept of managed runtime has very good points for achieving better computing security (and managing it with lessen efforts), however I think that a panacea or a silver bullet jet doesn’t exist in that field.
Of course, nothing’s ever a security silver bullet but that’s not a justification for not using a managed run-time
Security isn’t the only thing either. Although performance isn’t there on par with native languages yet, it has the potential to exceed because of the dynamic analysis that can be done on running code.
However, even without a managed runtime Pascal-like languages are less error prone to errors than C-like,
Absolutely. That’s why I said that I think this is a good idea for application development on *nix. To be fair though, there are still pointers and you can blow your foot off pretty easily with inline asm.
Inline asm always scared me from a portability perspective too. If you’re targetting something at the open source world, you’d better have a darn good reason for limiting yourself to a single architecture (or forcing porters to figure out how to rewrite for theirs). Or is Lazarus limited to x86 anyways?
Am I the only person who doesn’t sit well with being told what language I should be writing things in? I’m sure there’ll be some kind of other support for VB6 when the time comes for it to “die”, but if people want to write in it, why kill it?
Am I the only person who doesn’t sit well with being told what language I should be writing things in? I’m sure there’ll be some kind of other support for VB6 when the time comes for it to “die”, but if people want to write in it, why kill it?
They’re not killing it. According to the headline, it’ll be around for at least another 6-7 years. But I doubt you’ll see any future versions of it, and I say good riddens. Trying to hack the Win32 API to get any decent functionality out of it was about as pleasent as having my balls crushed by a wooden mallot.
It’s hard to build momentum for a platform if people are satisfied with the one they have. On the other hand I see no reason to expect Microsoft to break VB6 programs, since it isn’t clear how they could do that without breaking other Win32 programs, unless intentionally trying to do so. There are lots of little programs written in VB that no one wants to rewrite if there’s no compelling reason to do so.
And so should COM… I have programmed extensive in VB from 4 to 6 and I don’t miss it at all. I hate the way COM uses the registry and nobody I knows of does understand wholy the different compartment models, or VB’s (lack) of support of them. I like C# and I liked classic C. I never was fond of C++, It was not a good low-level language as C nor a clean powerful OO language; I have done some limited programming in Java, and while very similar to .net I find C# syntax slightly superior and its framework (class library/Namespaces) easer. My (limited) experience is that Java frameworks (class library/Namespaces) to be too ‘overengineered’.
I didn’t read the article, but the summary posted here seems like the right path. MS would be seriously stunting vista adoption if they didn’t support the huge amount of stuff that is apparently written for vb6. On the other hand, I think that all applications development should be done on managed language platforms if at all possible and simply not putting the effort into making a new vb6 development environment seems like an easy way to promote that idea.
…but essentially no VB6, I’m curious if the new version of Office doesn’t figure into the deicision somehow.
VB6 apps are the majority of the commercial apps developed for small businesses around the world (you know, the kludgy, badly programmed ones that crash now and again).
And MS has a long record of bending backward to provide compatibility with past products.
Did anyone really thought Vista would not run VB6 apps? Get real!
Inline asm always scared me from a portability perspective too. If you’re targetting something at the open source world, you’d better have a darn good reason for limiting yourself to a single architecture (or forcing porters to figure out how to rewrite for theirs). Or is Lazarus limited to x86 anyways?
Assembler inside the compiler is a huge advantage for portability compared to external assembler code, since it removes MASM/TASM/GAS/NASM issues, which prevents many existing code from being ported to other operating systems.
This won’t help you of course when you need to target another CPU like the PowerPC. However, our experience is that projects that start ports to other operating systems will ultimately port to all targets Lazarus supports, often replacing assembler code with Pascal code.
However, the real issues are not assembler code, but platform API’s. On Windows you want native Windows controls, on Linux GTK or QT. The Lazarus team has fought hard to solve this problem and is one of the first software development tools to have solved this problem.
Lazarus currently concentrates on desktop operating systems (Linux, Windows, FreeBSD and MacOS currently), which run on i386 and PowerPC hardware. However, since the compiler can handle a load more processors it is trivial for the Lazarus team to add more processors and operating systems.