Slashdot Mirror
Microsoft Remains Firm On Ending VB6 Support
An anonymous reader submits "CNet reports that
Microsoft is remaining firm an ending support for VB6, despite a petition
and many requests from its developer community.
If only VB were a F/OSS project instead of a proprietary customers could be assured of continued support as long as there was demand.
Are there any good F/OSS implementations of VB out there for customers to migrate to? One can only hope that enlightened groups like
the Agility Alliance would warn about the risks of using such software that can be end-of-lifed even while they're in heavy use."
Isn't this mono's purpose?
http://codeus.info
I know this will get modded Troll, but if you just look at these 3 simple points, you will see the VB has a lot to offer modern programmers.
1. It is faster to develop an application in VB than any other Language
Microsoft has built in a number of wizards to make building complete application templates with a few clicks. I have built (and sold) many applications which took less than 4 hours to develop - these include a webbrowser, email client, contacts database, file searching tools and a image viewer.
If I had tried to do this in C, C++, or even java it would have taken weeks.
2. Visual Basic is more secure as a language
There are NO pointers to worry about and all low level stuff is handled by the windows VBRUN.DLL's. This makes VB applications MORE secure than any other application, because it is physically impossible to get buffer overruns (the cause of 98% of all security problems)
3. You earn more money using VB
Face it - as much as we all like using Linux, there simply are not that many jobs available for C/Linux coders. Most of the jobs are for large corps or government and they almost always go with Visual Basic for the client and Java for the servers.
You shouldnt ignore Visual Basic as a language, and it definitely doesnt make VB coders any less skilled than C coders - if anything, I think we are a little stronger, as we have the courage to admit that we like this 'toy language'
Pre-.NET Visual Basic was far from the best programming language. Its support for object-oriented programming constructs was half-hearted at best. VB6 was released in 1998; people should be moving on by now, or they should have used a better tool in the first place.
On vit, on code et puis on meurt.
From the petition against Microsoft's decision:
"By providing a new version of a COM-based Visual Basic within the Visual Studio IDE, Microsoft will help maintain the value of its clients' existing code, demonstrate its ongoing commitment to the core Visual Basic language, and greatly simplify the adoption of VB.NET by those that wish to do so."
Supposedly the beefing up of VB was in response to the industrial capabilities of Java. Ironically, if MS alienates enough developer partners by cutting of support for VB 6, those folks may end up heading toward Sun or IBM anyway.
I Want To Believe
MSFT has VBA (VB for Applications) that is being used by many people that I know (Word Processing, Spread Sheets, Geographic Information System, etc). Does the decision to stop supporting VB6 impact VBA?
S
For those of you that wish for Microsoft to continue developing classic VB, Sign the Petition! It's too popular a language to just toss aside and break everyones existing code.
Lotus (IBM) will be protecting and developing Lotusscript (which is a VB language clone) into version 7 and beyond. And Notes applications from version 3 can still be used with the current version 6 clients and servers.
Microsoft != continued support
...right?
Microsoft != F/OSS
therefore,
F/OSS == continued support
I work as a quant in an investment bank, and believe me, huge trades (i'm talking about billion dollar derivative trades) are booked into Excel and rely solely on VB/VBA scripts to function properly day to day.
If VBA ceased to work tomorrow, there may very well be chaos in the financial markets causing some huge operational mistakes and huge losses. You cannot imagine how deeply dependent global banks are to excel and VBA.
If Microsoft wants to appear serious about having customers develop decent code, pulling them off VB 6 is a good start.
A person becomes a good programmer through education and lots of experience. A good programmer can write good code in virtually any language. (Conversely, a weak programmer can write Visual Basic code in any language.) This cry for "keep our precious VB6" sounds suspiciously like the whining "because C is too hard!"
There is still one valid reason for keeping it alive, however. Many people are still writing code for legacy hardware that isn't capable of running the .NET framework. And to that end, Microsoft's decisions should not automatically mean an increase in Intel's stock price. But wanting Visual Basic to last forever simply because they don't want to learn a better language is not going to gain my sympathy.
John
Unfortunately Borland isn't the way forward either. Delphi 8 shipped as a .NET-only product, and while Delphi 2005 finally shipped with a new Win32 version, many at Borland have said that a move to Win64 isn't in the cards.
.NET version and then you can kiss the native code gen goodbye.
My feeling is that they'll only continue to support the Win32 version until they believe enough people have moved to the
No, the real solution for VB coders looking for native apps and not MSIL crap is to move towards C/C++. Even Microsoft is offering 64-bit versions of their C++ compiler in Whidbey/VS2005 (VS2005 will ship not only with an AMD64 C++ compiler but also with an IA64 (Itanium) C++ compiler; previously all you got was an x86 compiler).
All I know about Bush is I had a good job when Clinton was president.
Ok probably nobody will read this but here it is,,,
"Personally, I would rather look for a replacement software..."
Ok, your opinion is of course respected and you may even speak for the majority. However, note that if you thought differently you still have no choice... you have to follow where the monopolist goes. The market does not decide, it is the controlling party that makes the decision, in this case the Microsoft corporation. In short, there might be demand, but there can be no supply.
That's why F/OSS software is needed. As long as there is demand, there will be supply. Pure capitalism at its best. Assurance of perpetual competition with low entry cost to market that works so that society, as a whole, benefits.
Ok, I am simplifying a bit here but I think most people get my point.
Just because it is "open" does not mean it is actually safe either. It means it has the *ability* to be code checked it says nothing about the quality nor the thoroughness of any checking that has actually been performed.
I learned a lot of basic concepts on it. Then I moved to classic ASP VBScript, then I moved to ASP Jscript. Then to php and I haven't looked back.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
This is unfortunately a mindset that extends into many OSS arenas too. Some Linux kernel projects refuse to support any backporting. Of course you *can* do this yourself, but you're on your own.
Many organisations have a large installed base of legacy systems which are doing just fine as they are. Sometimes these folk need a minor software tweak to add a very small feature. It is unrealistic to expect these people to upgrade their entire system or rewrite their application in C# or whatever. Same goes for some kernel projects. Quite a few systems (and embedded products) are based on more mature kernels like, say, 2.4.18. Changing to 2.6.x is not realistic for these people.
Open source is not the answer in itself. Forking brings pain.
Engineering is the art of compromise.
If anything, Apple appears to have been making toolbox independent additions to the Mac with Core Foundation. They add procedural code as a base below the higher level toolboxes. Then spend the time to perfect the higher level API's while also working out the bugs and implementation details in the Core. All three areas keep advancing.
True, most of Carbon's functionality is already available in Core and Cocoa, but the transition cost and learning curve are the bigger problems. Old developers don't want to make that jump yet. Fortunately, it appears that keeping Carbon around keeps the toolbox development healthier and requires just a bit of abstraction in its development for two different object-oriented development models.
Many moons ago, I got called in to put out fires in a project that had a DOS based computer in part of the feedback loop of an industrial cutting machine. If the feedback wasn't fast enough the loop would open and things would break.
The software was written in QBASIC, which had just recently come out. I needed double precision (32 bit) integers for the control loop. QBASIC had this type built-in. Problem was that when I switched to 32 bit integers the program ran about 1,000 times slower and things in the real world got broken.
I couldn't figure it out. After carefully checking and re-checking my code, I did an assembly level debug. Turns out the brainiac billionaires at Microsoft had decided to "save" about 10 minutes of programming time by using floating point double precision for all their 32 bit calculations, even though 32 bit add and subtract were either already part of the machine language instruction set or took just two or three instructions at worst case. Instead, for every math operation the 32 bit values were converted to double precision floats, the calculation was done in floating point and then the answer was converted back to 32 bits. To make matters worse, the hardware didn't have a floating point co-proccessor (because the designer knew that no floating point calculations were needed) so all the floating point stuff was done in software emulation. Of course, there wasn't a word or a warning about this in any of the manuals.
Once I figured out the problem (morons had written the 32 bit integer support) I was able to write my own 32 bit routines in QBASIC that were 100's of times faster than Microsoft's built in routines, even without dipping down into assembly and taking advantage of the carry flag.
Quick Basic indeed! If it were any quicker it would be running backwards.
We don't see the world as it is, we see it as we are.
-- Anais Nin
You joke, but we still use a P-166 running a custom QBASIC app to do certain verification tests on some of our older ICs.
---
Mod me down, you fucking twits. Go ahead. I dare you.
(I read with sigs off.)
But you missed the point, partially. Rewriting a product in a new language from existing code costs very little, and rewriting from the design document (you DO have an accurate design document, right?), also costs very little, and will probably create a better final product (depending on the quality of the design document). Transposing code from one language to another simply requires a person or team of people that are familiar with both languages (which for VB and VB.NET won't be difficult, or expensive. VB/VB.NET developers are cheap, for a transition like this, freshman comp sci students will probably do, at $10-$15/hr). Creating a project from a final, up-to-date design document requires fewer people, and they only need to be familiar with the target language and your design standards. (Maybe sophomore/junior CS students, but fewer man-hours of them). The design phase of your project should be the most expensive, if it's not, you didn't do it correctly. Once the design is complete, implementation and testing are cheap.
--That's the point of being root, you can do anything you want, even if it's stupid.
I guess the thing you'll run into is that no-one's hiring RB developers (as far as I can tell), cause nobody has heard of it...Sometime you have to ask yourself if it's worth investing the time learning one of the lesser known tools (even if they are excellent), given that your employment opportunities are so small. just my 2c.
But I don't think I have seen an actual exploit for the Pentium bug in the wild - not to mention a security exploit that would endanger the whole system.
That's because it was worked around so quickly at the OS level. But had the patches not come so quickly, it would have been possible to put F0 0F C7 C8 as the payload of a virus or worm, causing easy denial of service.
MFC, ATL and CRT source all include build scripts / makefiles (just checked) - MFC is the only one I have actually built before (so I absolutely know that one is complete).
All installed with either the compiler or the platform sdk (not sure which) afaik. For example, MFC is in \Program Files\Microsoft Visual Studio\VC98\MFC\SRC for vc6.
Some MSDN licensing does (or did) give rights to modify and distribute-modified MFC libraries, subject to requirements that you install it so it can't conflict with "real" MFC dlls - can't recall the details (it's been a while). Alternatively you can modify and statically link. So in MFC case at least (not sure about crt or atl - never needed to do it) you can fix bug in library, create statically linked version, submit patch to maintainers etc.
I think F/OSS has lots of real advantages. Claiming (eg. further up thread) that F/OSS is better because you can't audit libc on Windows is just plain false - and I don't think making false claims helps F/OSS.
I know that the parent _must_ be a joke, but I must indulge! ;-)
.NET) all to be SIGNED. This doesn't matter if you're only using integers for (bitwise AND/OR/XOR/NOT) binary operators, but for alot of other instances, I'm sure you can think of several, UNSIGNED integers would be nice biggrin.gif. ... End If with a signed integer. ... } with an unsigned integer
1. VB has the option to enable or disable automatic integer overflows and array index bound checking. In some instances it might seem like a good thing to have these turned on, however, you don't always need to. Lets say for instance, it's all internal, meaning, you know the size of your array, pretty static environment, but it auto checks all this for you. That right there is 'OVERHEAD'! Because in a client for something, you might need to check these things, you might not, but better to check them manually than to needlessly do so automatically for instances when it's not necessary.
2. VB forces a function to be Public (Program Wide) inorder to multi-thread it or even point to it (what limited pointer access VB does have). In C++ I can point to any function, sub routine, public/private/protected/virtual/static/extern, YOU NAME IT! Obviously you can't retrieve the location in RAM to something private from outside of a class without a property, but atleast I can point to a function within a class in C/C++!
3. Along the lines of #2, since VB only supports 'AddressOf' pointing to a function in the rare chance an API might use it, you can't use 'AddressOf' in your own code to 'CALLBACK' to a Sub/Function of your own program (keeping in mind 'AddressOf' only works on 'Module Public' Subs/Functions). There's indirect ways to 'CALLBACK' to a VB sub/function (SetWindowLong) and filtering wMsg(s) sent to that window. However, that requires API, and C/C++ supports 'CALLBACK's natively!
4. VB forces all integers (however many bytes they are 1, 2, 4, possibly even 8 byte integers in
Example: Instead of saying If x 400 Then
I could simply do: if (x > 400) {
How/Why? Simple, normally the binary form of a negative number is 0x80 - 0xFF, or 0x8000 - 0xFFFF, or 0x80000000 - 0xFFFFFFFF. So when the number isn't signed, it's actually alot greater than the highest possible signed positive value.
Example: signed 1 byte integer -128 50 rather than if x 50. Yes I'm aware you can toggle that sign bit, however, why bother if you don't have to in a better language blink.gif?
Since C/C++ don't have built in bound checking on arrays, unsigned counters are very handy! If the lowest value is 0, and all arrays start with index 0, you can 'safely' assume the minimum bound index is 0, thus, you don't have to check your counter for being 'less than 0'. You only have to check 1 bound, the maximum, so your counter doesn't request an index 'out of bounds'.
5. One thing I like about C/C++ is I can define a constant array, even by a custom struct or "User Defined Type" for you VB people. In VB the best you can do is make a string with a delimitive value like a comma "1,2,3,4,5" and once the program starts Split() it tongue.gif.
FireBot mentioned you can use resources in VB! True, that you can, but you still have to use API to retrieve from a resource, and this is all about using only 'standalone' functionality of the languages (I know there are VB functions that retrieve resource information, but even they boil down to API).
6. With C/C++ I can actually use REAL STRINGS! I have a choice of Unicode (2 bytes per character) or ANSI (1 byte per character). In VB it's strictly Unicode, and you have to use this annoying conversion method built into VB to convert Unicode into a "Byte Array". Can we say 'OVERHEAD' yet?
7. There's several APIs VB cannot use, because it'll crash the VB IDE, such as Create Thread. Even if you follow the specs on using it, proper use still crashes the VB IDE...
This fucks a lot of people. At my shop, we have a lot of legacy apps which use COM+ services (mostly 3-tier client-server and ASP apps). We've been a Win2K shop so far, and we should be able to hold out for a while, but sooner or later we're going to have to wade hip-deep into our legacy code and re-write for VB.Net.
I started out as a C++ and Java programmer and took up VB6 after the tech crash (to pay the bills). I know VB6, VB.Net, and Java, and I think VB.Net is a straightforward clone of Java -- there's almost no similarity to VB6 at all. Microsoft's porting tool is almost useless for any REAL application. We're looking at a ground-up, OOP redesign of everything our shop uses. Plus testing. Plus retraining of all our users. Plus figuring out a whole new security model, vis-a-vis the web services. It's going to be PAINFUL.
I'm really, really not looking forward to that.
Farewell! It's been a fine buncha years!
Uh oh! New machines come with Windows XP - can't get approval to get Win2k any more. And guess what: The good old VB 4 app won't run under XP.
This might help. It worked for me...
HA! How about an 11-year old VB3 app? My company supports a product written in 16-bit Visual Basic (the version from circa 1993)
The application currently runs quite happily on NT4, communicating with an Oracle database over 16-bit SQL*Net. They recently upgraded all their workstations from NT4 to XP, however the program doesn't work due to the multitude of 3rd party 16-bit libraries etc.
We suggested they convert one of their existing NT machines to NT Terminal Server on their LAN. Install the application and the Oracle database on that, bingo. Instant legacy application support, that should work for a long time to come.
Maybe not perfect but cheaper than a re-write.