Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Microsoft Programming IT Technology

Microsoft Remains Firm On Ending VB6 Support 796

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."
This discussion has been archived. No new comments can be posted.

Microsoft Remains Firm On Ending VB6 Support

Comments Filter:
  • mono? (Score:1, Interesting)

    by CodeYoddler ( 674760 ) on Wednesday March 16, 2005 @06:44PM (#11958881)
    Isn't this mono's purpose?
  • 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'

  • Good Riddens (Score:3, Interesting)

    by Cruxus ( 657818 ) on Wednesday March 16, 2005 @06:45PM (#11958905) Journal

    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.

  • by filmmaker ( 850359 ) * on Wednesday March 16, 2005 @06:45PM (#11958908) Homepage
    From the petition [com.com] 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.
  • by sisukapalli1 ( 471175 ) on Wednesday March 16, 2005 @06:47PM (#11958926)
    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?

  • Sign the Petition (Score:4, Interesting)

    by Joe Jordan ( 453607 ) on Wednesday March 16, 2005 @06:47PM (#11958927) Journal
    For those of you that wish for Microsoft to continue developing classic VB, Sign the Petition! [classicvb.org] It's too popular a language to just toss aside and break everyones existing code.
  • by Anonymous Coward on Wednesday March 16, 2005 @06:47PM (#11958928)
    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.
  • Re:Huh? (Score:2, Interesting)

    by RonnyJ ( 651856 ) on Wednesday March 16, 2005 @06:49PM (#11958962)
    Microsoft != continued support
    Microsoft != F/OSS


    F/OSS == continued support ...right?
  • Financial Services (Score:3, Interesting)

    by Giant Robot ( 56744 ) on Wednesday March 16, 2005 @06:49PM (#11958963) Homepage
    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.
  • by plover ( 150551 ) * on Wednesday March 16, 2005 @06:54PM (#11959042) Homepage Journal
    Just because they use a name containing the word Basic means that lots of people who otherwise might be afraid of writing a program will approach it, thinking "hey, I remember learning Basic in high school math." That doesn't make them developers any more than owning a hammer and chisel makes one a sculptor.

    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.

  • by DarkEdgeX ( 212110 ) on Wednesday March 16, 2005 @07:12PM (#11959294) Journal
    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.

    My feeling is that they'll only continue to support the Win32 version until they believe enough people have moved to the .NET version and then you can kiss the native code gen goodbye.

    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).
  • Re:Meet The Forkers (Score:2, Interesting)

    by Anonymous Coward on Wednesday March 16, 2005 @07:14PM (#11959311)
    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.
  • by PepeGSay ( 847429 ) on Wednesday March 16, 2005 @07:27PM (#11959478)
    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.
  • by Mustang Matt ( 133426 ) on Wednesday March 16, 2005 @07:52PM (#11959789)
    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.
  • Re:Good Riddens (Score:1, Interesting)

    by Anonymous Coward on Wednesday March 16, 2005 @07:54PM (#11959805)
    And VB.NET and C# both perfectly fill this gap. Both support visual designing the UI and have a nearly identical event system. Really the biggest difference between VB5/6 and VB.NET is that Forms are now actually treated like classes instead of implicit static instances.

    Microsoft is listening to the complaints being made by the MVPs and they're working on simplifying VB.NET while extending it's functionality. Edit & Continue will make it's comeback this year in VS2005. There will also be optional built in support for those implicit static Form instances that violate the Hell out of OOP. VB.NET is also getting generics, overloaded operators, and **FINALLY** unsigned data types.

    I was a VB6 developer for 4 years. I had no real beef with the language as it certainly fit it's place. VB.NET is simply VB6 done right, with a massive class library that lets you do more without having to resort to API calls. Toying in API inevitably causes GPFs, which the VB6 IDE can't handle in debugging mode because it interprets the code instead of compiling and attaching to a process, causing the IDE to crash and all unsaved work lost. VB.NET also has freethreading, something VB6 can't do at all because of TLS issues.

    At this stage in the game it was simply time to clean up. Will some people be left behind? Sure. But we've seen this before, like when VB1 came out and it wasn't identical to QuickBasic. We were all thankful for it. Or when VB4 joined the 32-bit world which caused some poorly written apps that made 16-bit assumptions to break. We were all thankful for it. Or when MS decided to forego their own incorrect legacy to make Visual C++ considerably more standards compliant. We were all thankful for it.

    Let them bitch and moan. When a programmer no longer has the ambition or the passion to absorb new technologies then they are obsolete and should be recycled into basic chemicals anyway. Or they should just find a job maintaining old crap, without Microsoft's direct support, like they've likely been doing now for the past 8 years.
  • by EmbeddedJanitor ( 597831 ) on Wednesday March 16, 2005 @08:02PM (#11959882)
    Microsoft's "stop supporting IE6, Win98 etc" mindset is wrong. So is the "don't need VB" one.

    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.

  • by buckhead_buddy ( 186384 ) on Wednesday March 16, 2005 @08:02PM (#11959886)
    I'm a Cocoa developer, but I don't really see why Carbon should go away. It has a different orientation to objects than Cocoa does, but (unlike old versions of VB) killing Carbon off wouldn't make the people who hate Cocoa like it any more. There doesn't seem to be as much new developer interest in Carbon, but it's capable of evolving just as the Mac OS does. After all, much of Carbon could be reduced to wrappers around Core Foundation code.

    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.

  • Fantasy v. Reality. (Score:4, Interesting)

    by DerekLyons ( 302214 ) <fairwaterNO@SPAMgmail.com> on Wednesday March 16, 2005 @08:14PM (#11960006) Homepage
    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/
    Which is why a high demand product (Mozilla Firefox) is having problems getting developers.
  • by Crouchy ( 7129 ) on Wednesday March 16, 2005 @08:15PM (#11960016)
    >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!"

    Hmm, I have seen a lot of crap C code (or C++ code for that matter).. I have seen a lot of well structured VB6 programs (just because you don't write well structured VB code, don't expect us to be like you). Problem is a lot of people get paid for programming VB and are self taught, so they don't use all the features (I fall under this category, as University only taught C/C++/Miranda/Prolog/etc). Fortunately over the last three years of work I have learn't a lot of nice programming techniques in VB, so yes I will be sad when it is ended as a product.

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

    No, this is not the case for me (as I know C/C++, etc and get paid to write in it). It is the thousands of lines we have invested in VB6, our customers who have written applications using our dlls have invested. I personally prefer VB6 to VB.Net and C# to VB.net. We as a company are looking at still buying VB6 for customers who need to develop code to customise systems we sell, alas they are getting rare as hens teeth.

  • QBASIC horror story (Score:5, Interesting)

    by DrJimbo ( 594231 ) on Wednesday March 16, 2005 @08:26PM (#11960155)
    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.
  • by Kiryat Malachi ( 177258 ) on Wednesday March 16, 2005 @08:36PM (#11960253) Journal
    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.
  • Re:Meet The Forkers (Score:2, Interesting)

    by innosent ( 618233 ) <jmdority&gmail,com> on Wednesday March 16, 2005 @08:47PM (#11960360)
    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.
  • by Cuthalion ( 65550 ) on Wednesday March 16, 2005 @09:12PM (#11960613) Homepage
    As an application developer for Windows, I am delighted that Microsoft is going to stop supporting Win98, because that means people will migrate away from it, and I too can stop supporting it.

    Supporting win98 for any internationalized product is a tremendous headache and timesink, and deprecating it does benefit the other platforms - it allows Windows programs to be simpler and cheaper to write, while keeping the same or more functionality.
  • Re:VB Alternatives (Score:2, Interesting)

    by dalesmatrix ( 626123 ) on Wednesday March 16, 2005 @09:27PM (#11960751)
    REAlbasic is pretty cool, works as advertised. It's great to write something then have it work on PC, OSX and linux as native EXE's. Has a nice VB like GUI and decent language.

    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.

  • by tepples ( 727027 ) <{tepples} {at} {gmail.com}> on Wednesday March 16, 2005 @09:38PM (#11960862) Homepage Journal

    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.

  • by ray-auch ( 454705 ) on Wednesday March 16, 2005 @10:03PM (#11961066)
    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.
  • by pcmanjon ( 735165 ) on Wednesday March 16, 2005 @10:24PM (#11961220)
    I know that the parent _must_ be a joke, but I must indulge! ;-)

    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 .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.
    Example: Instead of saying If x 400 Then ... End If with a signed integer.
    I could simply do: if (x > 400) { ... } with an unsigned integer
    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...
  • by dooglio ( 313304 ) on Thursday March 17, 2005 @12:20AM (#11961979) Homepage
    The following link is a good read. The author describes how this M$ trend of obsoleting platforms will hurt them in the long run:

    http://www.joelonsoftware.com/articles/APIWar.html [joelonsoftware.com]

    The dumping of VB6 really underscores how Microsoft no longer cares about being backward compatible.

  • by WGR ( 32993 ) on Thursday March 17, 2005 @02:15AM (#11962566) Journal
    Many of your examples seem to be places where C/C++ allow you to create program errors where VB does not. Yow show many places where you as a bit-picking programmer try to gain nanoseconds at the expense of security and good code. C has a string strage convention that inexorably leads to buffer overflows without significant programmer overhead. A language that automatically checks buffer size won't (and the check is built in to the x86 architecture so has very little overhead).

    VB is not a very good language either. Try Delphi as a language that has all the advantages of VB in creating a GUI and has a fast development cycle, while it generates good code and is written in a structure manner that better models the problem with forcing one to program at the bit level for high level problems (say set manipulation) like C/C++.

  • Re:Meet The Forkers (Score:3, Interesting)

    by crazyphilman ( 609923 ) on Thursday March 17, 2005 @02:17AM (#11962581) Journal
    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.

  • Re:Meet The Forkers (Score:3, Interesting)

    by Cee ( 22717 ) on Thursday March 17, 2005 @03:14AM (#11962862)
    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 [microsoft.com]. It worked for me...
  • Re:Meet The Forkers (Score:2, Interesting)

    by bampot ( 814270 ) on Thursday March 17, 2005 @05:36AM (#11963282)
    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.

UNIX is many things to many people, but it's never been everything to anybody.