Geeks With Blogs

Neat Stuff Read all my hurricane entries While you are here, visit the Geeks With Blogs main feed
Links Status of the Navy
Channel 9

.NET Hobbyist Programmer Staying Confused in a Busy World

Update 12/30/2010: While it was amusng for six-and-a-half years, I have closed comments on this post.  Move along...  Move along...

Recently, Eric Gunnerson posted code on how to create an array with a non-zero lower bound.  Paul Vick brought up the AndAlso and OrElse operators which are new to VB.NET.  This got me to thinking of the state of affairs way back in 2001 when .NET was still in its beta phase.

Three years ago, Visual Fred was the derisive name given to VB.NET 2002 by VB6 programmers who did not like the changes to the then forthcoming programming language.  The VB6 programmers of the time had the sentiment that it really wasn't VB anymore, and perhaps should have been given a different name.

Microsoft did that when it created C#, but it kept VB as is.  Much the same sentiment was probably voiced when people moved from C to C++ or from C++ to C#.  Admittedly, my memory is hazy here.

I scanned through the list of concerns/complaints (reproduced below) with three years of hindsight to see if all the fuss really mattered.  From my point of view, it didn't.  Many of the items listed have simple substitutions in .NET.  My evaluation is tempered by the fact that I did not have a huge investment in existing programs to maintain and upgrade.  I have just one big one (EDR) out there in VB6.  I thought at the time that both the discussion and the list was a bit overstated.  I recall that several developers said they would no longer use VB and would switch to Delphi.  (Hmmm, isn't Delphi object-oriented Pascal?  It seems strange that people would switch away from OO VB to OO Pascal.)

This list comes from Karl Peterson's website.  From the numerous nots in the list, you can guess Karl's position in the argument.  Since there are so many ways to do things in .NET, the ultimate implication of the changes were not much.  Several of the listed items were peeks into the behind-the-scenes way that VB6 did business.  Everyone knows that it is a Bad Thing to continue to assume undocumented behavior will continue to be supported.  They were convenient methods for a slick piece of code, or a small optimization, or even the only way to achieve a goal.

I guess much of the furor was because many of the items listed changed or removed many a favored programming feature.  In the intervening years, we have found many ways of doing the same thing a different way.  This implies that we have learned something in the intervening time.  I see that as a good thing.  Plugging away at the Same Old Thing, while potentially putting food on the table, is not continually emotionally satisfying, nor does it provide for keeping up with changing customer requirements.

As for the array issue mentioned above, it appears as #7 in the list below.  The implementation is easy and can be adapted as required.  The forthcoming VB 2005 will support generics which will make it even easier.

Popular myth has Microsoft's products achieving maturity at version 3.  This happened with VB3 and again with VB6.  The forthcoming Whidbey release will be called VB 2005, but it is essentially VB9.  Perhaps it will be time for the new .NET to be considered mature.


  1. VarPtr is not supportedavailable.
  2. StrPtr is not supportedavailable.
  3. ObjPtr is not supportedavailable.
  4. As Any is not supported for API Declares.
  5. Use of ByVal/ByRef directly within API calls is not supported.
  6. Private class variables are not private to the class instance.
  7. Arrays may not have a lower bound other than zero.
  8. Dynamic arrays are not allowed within structures (UDTs)
  9. Arrays are not declared using the upper bound. (Addressed in Beta2)
  10. Option Base is not supported.
  11. Variants are not supported. Object is now the default data type.
  12. Currency is not supported.
  13. Dates are not stored internally as Double values.
  14. Longs are not 32-bits; they are 64-bits.
  15. Integers are not 16-bits; they are 32-bits.
  16. True, coerced to an Integer, is not -1, but is 1 instead. (Addressed in Beta2)
  17. The Imp and Eqv operators are not supported.
  18. Fixed-length Strings are not supported.
  19. DefInt, DefLong, et al., are not supported.
  20. Dim may not always create procedure-level variables.
  21. Redim will not create arrays not already declared.
  22. Local variables are not necessarily visible (in scope) throughout a procedure.
  23. VarType is not supported.
  24. Empty is not supported.
  25. Null is not supported.
  26. IsEmpty is not supported.
  27. IsMissing is not supported.
  28. IsNull is not supported.
  29. IsObject is not supported.
  30. Let is not supported.
  31. Core language constants do not have a "vb" prefix (vbRed becomes Red).
  32. Terminate will not fire when an object's last reference is released.
  33. Object finalization code will not execute in a predictable order.
  34. Implicit object creation is not delayed until first reference.
  35. Public object variables are not safe from alteration when passed as parameters.
  36. Can not expose Property procedures with mixed visibility (Friend Set/Public Get).
  37. Procedure parameters are not by default passed ByRef anymore.
  38. ParamArray arguments are not passed ByRef anymore.
  39. Property parameters may not be passed ByRef anymore.
  40. Implements is not implemented the same, so must be rewritten.
  41. Static is not supported as a procedure level modifier.
  42. Use of As New does not force auto-reinstantiation when an object is released.
  43. Parenthesis are not optional when calling procedures.
  44. Set is not supported for object assignment.
  45. Parameterless default properties are not supported.
  46. Default values for Optional parameters are not optional.
  47. Code is not compiled to native, thus making decompilation much easier.
  48. Resource files have changed format and old ones are not supported.
  49. LSet is not supported.
  50. RSet is not supported.
  51. UDTs are not Types, but are called Structures instead.
  52. UDTs are not by default contiguous blocks of memory, but are objects.
  53. Enums will not be recognized unless fully-qualified.
  54. While/Wend loops are not supported.
  55. GoSub/Return is not supported.
  56. On/GoTo is not supported.
  57. On/GoSub is not supported.
  58. Line numbers are not supported. Labels may be numeric.
  59. Erl is not supported.
  60. The MsgBox function is not supported.
  61. The DoEvents function is not supported.
  62. The Date statement is not supported.
  63. The Time statement is not supported.
  64. And, Or, XOr, and Not are not bitwise operators. (Addressed in Beta2)
  65. Comparison operators are not evaluated before logical operators. (Addressed in Beta2)
  66. Sqr is not supported.
  67. Sgn is not supported.
  68. Atn is not supported.
  69. The String function is not supported.
  70. Control arrays are not supported.
  71. The native Forms collection is not supported.
  72. UnloadMode detection is not offered, as QueryUnload is history.
  73. ListBox controls do not offer an ItemData property.
  74. ListBox controls do not offer an NewIndex property.
  75. Windowless controls are not supported.
  76. Image controls are not supported.
  77. Shape controls are not supported.
  78. Line controls are not supported.
  79. OLE Container controls are not supported.
  80. Label controls will not have a Caption property.
  81. The Tag property is not supported. (Addressed in Beta2)
  82. The ToolTipText property is not supported.
  83. The TextHeight property is not supported.
  84. The TextWidth property is not supported.
  85. Setting a Timer control's Interval to 0 does not disable it.
  86. Top-level menus may not be used as context menus.
  87. Old forms using vbPixels for Scalemode will not upgrade correctly.
  88. DDE is not supported.
  89. Circle is not supported.
  90. Cls is not supported.
  91. Line is not supported.
  92. PSet is not supported.
  93. Point is not supported.
  94. AutoRedraw is not supported.
  95. PrintForm is not supported.
  96. Scale is not supported.
  97. The Name property for forms and controls is not exposed at runtime. (Addressed in Beta2)
  98. Print will not include a linefeed at the end of a line.
  99. File I/O will not be compatible, at all, and must be rewritten.
  100. Printer object methods are not automatically upgraded and must be rewritten.
  101. Clipboard object methods are not automatically upgraded and must be rewritten.
  102. The Err object is not shared between managed (.NET) and unmanaged (ActiveX) code.
  103. The App object is not shared between managed (.NET) and unmanaged (ActiveX) code.
  104. Screen.MousePointer does not have a direct replacement.
  105. Webclasses are not supported.
  106. DHTML projects are not supported.
  107. UserControl projects are not supported.
  108. ActiveX Document projects are not supported.
  109. The IDE Extensibility Model is not backwardly compatible.
  110. Run->Break->Edit->Continue development is not supported.
  111. The Immediate window will not work in Design mode.
  112. SDI will not be an option in the IDE -- MDI or nothing.
  113. Debug.Print is not supported.
  114. Debug.Assert is not supported.
  115. Data binding with DAO is not supported.
  116. Data binding with RDO is not supported.
  117. ...
  118. ...
  119. ...
Posted on Tuesday, April 20, 2004 4:42 PM Programming | Back to top

Comments on this post: Recalling Visual Fred

# re: Recalling Visual Fred
Requesting Gravatar...
Hi, Mark: Thought I'd mention that I posted a VB.NET implementation of Eric Gunnerson's array technique on the new VB FAQ blog:
Left by Phil Weber on Apr 21, 2004 2:17 PM

# re: Recalling Visual Fred
Requesting Gravatar...
I hate to nitpick but Pascal was my first language. Pascal itself, not Delphi, is OO.

I consider Delphi "Visual Pascal" but not in the way I consider Visual Basic an extension of Basic. Basic was never OO as a language, yet Pascal is.

Delphi is very fun and there's a lot a VB programmer can do with it. I dabbled some with VB before I really got into programming and the transition to Delphi was painstakingly easy. I'm now transitioning to C# which is roughly the same learning curve as from VB->Delphi. There's a ton of similarities between Delphi/Pascal and C#.
Left by Jeremy Brayton on Apr 21, 2004 4:59 PM

# re: Recalling Visual Fred
Requesting Gravatar...
Jeremy: You are correct, but my intent was to gloss over the finer points of the relationships and concentrate on the OO nature of the two (Delphi and VB.NET). Why dump a non-OO language as it is being updated to be OO for a completely new OO language. I never thought those discussions made sense.
Left by Mark on Apr 21, 2004 5:52 PM

# re: Recalling Visual Fred
Requesting Gravatar...
>Three years ago, Visual Fred was the
>derisive name given to VB.NET 2002
> by VB6 programmers

This is incorrect. A MS employee suggested Visual Fred might have been a better name for VB.Net, given its lack of similarity to Visual Basic.
Left by birchr on Jan 10, 2005 7:08 PM

# re: Recalling Visual Fred
Requesting Gravatar...
It seems like MS wants to make the language less important than the IDE, that way they only have one product to maintain. I guess we didn't realize how good we had it with VB6.

This is progress?

screen.mousepointer = vbDefault

System.Windows.Forms.Cursor.Current = System.Windows.Forms.Cursors.Default
Left by Disgruntled on Apr 05, 2005 4:25 PM

# re: Recalling Visual Fred
Requesting Gravatar...

You mean
#using System.Windows.Forms


Cursor.Current = Cursors.Default

not so very different - most UI components of a forms app will have the #using line at the top anyway.
Left by George on Jun 21, 2005 6:19 AM

# re: Recalling Visual Fred
Requesting Gravatar...
Get over it people...times chage, tools change, customer requirements change. VB6 is a dinosaur long in search of extinction. Thank god Microsoft killed it. Now if only they would kill off BASIC, period
Left by Manuel on Aug 13, 2005 9:22 AM

# re: Recalling Visual Fred
Requesting Gravatar...
Not only did Microsoft kill off VB6, they killed off VB, period, and they did so starting with VS2002 (a truly *wonderful* product - but who uses it any more?)
VB was always a RAD tool not an OOP tool, and every version since VB6 takes us further and further from that - it is absurd to call VB.NET "BASIC" as it very clearly is not. Visual Fred was the right idea, or maybe "B#". If I wanted to program Java, I'd use Java, not Microsoft's rip off product.
And since 2002, the .NET framework is still unsuitable for use with any app that requires a stable foundation - how long are we supposed to wait? And if .NET is so great, why does Microsoft not practice any form of dogfooding with it? No, even Microsoft has no .NET-based software, which tells me all I need to know - if the authors don't use it themselves, they must KNOW something!
Left by NoMoreVB on Jan 13, 2006 12:40 PM

# re: Recalling Visual Fred
Requesting Gravatar...
"Much the same sentiment was probably voiced when people moved from C to C++. Admittedly, my memory is hazy here."

Well, mine isn't, so let me explain.

C++ is a superset of C and that meant C programs upgraded without changes. VB.NET is not a superset of VB6 so upgrading takes about 5% to 10% of the original effort to write the original program. Why should we have to spend that sort of money, just so Microsoft can save by harmonising on one runtime?
Left by Mark on Feb 23, 2006 8:42 AM

# re: Recalling Visual Fred
Requesting Gravatar...
VB6 still makes our team a ton of money. It may be dead to you - but we're having a blast and plan to use it as far into the future as possible. That ole' saying that DOS was dead - but we still have users using it also!

VB.Net (in 3 flavors) - all different from each other - when will the final product be ready?
Net, 2003,2005???

I must admit we are slowly learning VS2005 - (not without a few cus-words) - and as lost as we are in this new language - we realize that with enough trial & error - we might get some point to where we know if what we are typing actually does something!

The VB.NET language is greek,
The help file is of little help - which refers you to other topics which you know nothing about also - which refers you endlessly to knowwhere! Great! Let's get started.

Left by YongYe Meeks on Mar 13, 2006 11:04 PM

# re: Recalling Visual Fred
Requesting Gravatar...
Does anyone remember going from BasicA or GWBasic and those compilers to QuickBasic and then to Visual Basic? Embrace the .Net path to 2005 like we did Visual Basic back when and you'll come to realize a longer and easier future in this industry. Or not... But when was the last time you heard of product development being done in QuickBasic? Besides which, this thread is about two years only already. ;-)
Left by old fart on Mar 19, 2006 2:18 PM

# re: Recalling Visual Fred
Requesting Gravatar...
Yea ... my eternal blog entry. I've done all the Microsoft Basics, including VB-DOS. I like the new VB, but then, I do not have a pile of code out there making money. I do support one middling size VB6 app, but there is no db behind it -- it's all text files. I'd love to move it on, but there is little drive for that just yet.
Left by Mark on Mar 19, 2006 5:27 PM

# re: Recalling Visual Fred
Requesting Gravatar...
Change is good, but this is ugly. WithVB6, a down and dirty app took minutest to write and made clients happy. OOP is for programmers who have's not a RAD tool...

Frankly, I'm afraid to get too tied to 'intrinsic' OOP libraries...God know when and how they'll change...databinding was a good thing, until they changed all of the controls at one point...

Oh well, back to the book.
Left by tr on Apr 28, 2006 1:46 PM

# re: Recalling Visual Fred
Requesting Gravatar...
>But when was the last time you heard of product development being done in QuickBasic?

still have a ton of apps running in quickbasic pds 7.1 video shops and service management software. some of the staff have said to me that they prefer the dos console apps to shiny window apps as the they had higher throughput on apps 100% used by keyboard rather than the keyboard mouse combo used by windows databases.
Left by moylan on Nov 10, 2006 5:23 AM

# re: Recalling Visual Fred
Requesting Gravatar...
From what I have seen and used I know that this is not the 'basic' I fell in love with back in BasicA (the IBM version; the one with the chip requirment) all the way to Visual Basic 6. (Yes, I use DOS still on my new shiny sony vaio 2g duo) I am an Open Source Developer and I do have code in VB6. To upgare (as we all have done in the pass) to the new VB would mean major rewrite of main code. It might just be easyer to code it afresh. From my point of view the magic has been lost, but maybe it is the 'can't let it die this way' dream in my brain that makes me think to my self... maybe there is a new type of magic over the hill? As the old saying gos "Two steps forward, one step back" Maybe VF will become VB again some day... until then I will still love and use VB6(SP6) where and when ever I can.
Left by Cip2 on Dec 16, 2006 4:50 AM

# re: Recalling Visual Fred
Requesting Gravatar...
I'm sitting here, earning my money with programming in VB6.
It'll be so in 2009 i think.
DEAD? Not really ;-)
Left by SK on Nov 04, 2008 8:23 AM

# re: Recalling Visual Fred
Requesting Gravatar...
I was totally annoyed with VB.NET at first having used VB6 for ages.
Recently, having worked with VB.NET for years, I worked two months on a VB6 app for maintenance.

I simply could not *believe* how many things you could *not* do in VB6 which are so easy in .NET these days. No constructors, no dialogresults, no variables local to loops, no boolean shortcircuits, no shared eventhandlers, the list goes on and on.

I can not recall my early anger at all, I'm afraid.
Left by Tinnderbox on Feb 04, 2009 9:38 AM

# re: Recalling Visual Fred
Requesting Gravatar...
I moved to delphi because borland/imprise/embarcadero did incremental upgrades to the language (much like early vb) and never massively broke my projects

I do program nowadays in .net using C#, wasnt that hard because the framework its similar to the delphi vcl and the ambient to java the two other languages i had used at the time

But vb5 and 6 where good enought, even now... some times i feel i can do things more easily if i where using vb. Things that people say wheren't posible using classic vb, in fact are simple to do... Constructors? just mark the class public not creatable and return instances from one constructor function in a global multiuse factory class. shared eventhandlers? define a event_controler interface, define event_listener class for every control you care (having implements event_controler interface) add your controls to some collection of event_listener class

I did have a home build vb6 framework, and to date havent found something i couldnt do using vb6 with a little delphi help (or freewares: multi-threading -> DirectCOM.Dll; asm -> ThunderVB Add-In; RPC -> wodBeep.Ocx, etc)
Left by Aging Coder on Feb 07, 2009 12:00 AM

# re: Recalling Visual Fred
Requesting Gravatar...
You see, what is being destroyed here is not a language really, but a simple concept. With the advent of BASIC came, for the first time in the history of the programming world, the element of reasonably human choice! For the first time people could program their computer in a way similar to how they would, say, write a letter to a friend. This is not just about syntax constructs or what works 'better'. BASIC is the most human-readable language on the face of the earth! This sold to millions, and is STILL selling, because it gives many more users A CHOICE! History has proven, when you tamper with that, you lose exponentially, and Microsoft WILL lose. I just hope, for their sakes, it isn't too greatly before they come to their senses.

As for me, I totally agree with the aging coder. I will not totally depend on any Microsoft tool for anything! When I found out that BASIC was still not yet a standard (ISO or otherwise), almost NINE years after it's creation, I knew the writing was on the wall. I did what any forward-thinking developer would have done, and started to look into ways to maximize on my investment as best and as independently of Microsoft as possible. I started to look into breaking the habit of depending on active x and anything that had to do with the registry and started making my applications to just depend on the vb-runtime by building my own class libraries. Now I work on eliminating the need for even that. Why? because the syntax construct still works and I still love it; it is MY choice! Years after vb6 came out people were, and still are, finding out the amazing capabilities of this tool. I am one of those people who love this language construct and will continue to love it. When they find a way to break the old code totally, I will make the full move to Delphi or Powerbasic, and when they break the old way altogether (by removing things like the Win API) I will move to a next OS (RealBasic, etc). For my own use I'm seriously looking into building my own compiler or even my own OS as not one of these corporate bodies can be trusted. This is about choice people, choice!
Left by TruthTheoryAndFact on Mar 06, 2009 4:08 PM

# re: Recalling Visual Fred
Requesting Gravatar...
I truly hope that that Microsoft never kills off all of the variants of BASIC.

What a scary thought; without a BASIC variant to denigrate, all of the "real programmers" out there might start picking on assembly language.
Left by ibsteve on Dec 24, 2009 4:40 PM

# re: Recalling Visual Fred
Requesting Gravatar...
I think that the complaints about Visual Fred at the time were very apt and still are. The problem was that the language was redone by people who did not understand and respect it, with the result that there were a lot of incompatibilities that were stupid and unnecessary. There's *still* no excuse for the removal of support for arbitrary array bounds, a feature that Fortran (a high-performance, multi-paradigm language) has had for years. That I can write a class to support that myself completely misses the point; it was a first-class feature of the language and the only reason it was removed was because of bunch of C and Java zealots were unable to wrap their limited understanding around the idea of why it might be useful.

Ten years later, I've started using VB.NET, and there's an awful lot to like about it, but the whole kerfluffle could have been avoided if the upgrade had been handled properly---by people who respected the language, the heritage that led it to be different from the C-heritage languages, and who were interested in guarding those features even as all the useful capabilities were added.
Left by Craig on Sep 21, 2010 8:58 AM

Comments have been closed on this topic.
Copyright © Mark Treadwell | Powered by: