Geting on the bus, not under it...

I've seen some comments recently regarding some people's feelings about the VB6 to VB.NET "transition." Phrases like "throwing [us] under the bus" gets used a lot. Or that .NET "broke the natural progression" of VB.

I'm wondering. Am I the only one that doesn't feel betrayed? I don't understand where this hostility comes from. Maybe it would have been better had MS simply just stopped work on VB all together. At least then that would eliminate all of the C#/VB debates. Oh, but then VBers would feel left out in the cold.

I've got it! Just stop all development in languages. Just freeze them. What ever features you've got right now, that's all you're going to get. Nothing more.

-tg

... I don't feel betrayed, even when I was doing all that vb6 work (until 2004 when I transitioned to vb.Net) I kept thinking "man this whole language could use a good scrubbing".

Then 2004 hit and I actually took a .net class @ my local college. Since then I've dabbled with vb6 only a small handful of times, but mostly I'm all vba (Access 2003/2007) and vb.Net (VS 2003+). Even the Access VBA stuff I do is small time, nothing major.

Oh and those vb.net/c# debates is just fluff, other than c# pointers, they're the same thing just different syntax. I do prefer vb.net over c# but that's because of the IDE, I like how the vb.net IDE works compared to the c# IDE, but that's just tool, not the language thing.

I completely dropped VB6 back at 2002. At the time, I was finding myself doing a lot of ugly hacks to work around its many limitations. I was relieved when I understood how VB.Net worked. What I loved the most was the added layer of abstraction the framework provided over the Windows API. In truth I still have to go to the API directly but this has long become the rare exception and not the norm. With VB6 you needed the API to do all sorts of things. I don't have anything against the Windows API in particular, I just find that the model it presents to callers is in direct conflict with the goal of having a consistent framework that you use to build business applications with code that's easy to maintain.

Having said that, I can understand why so many people felt betrayed by the changes made by Microsoft. It's because the VB6-way of doing things died a quick and messy death. If you think about it, nothing works the same way in VB.Net as it did in VB6.

Forget about the sheer number of changes that were made and focus on the fundamentally different view of the world that the .Net framework introduced and adopted. All of the sudden VB6-minded people had to struggle just to make sense of even the simplest VB.Net program. Only the syntax remained the same and even there changes frustrated VB6 users to no end. To make matters worse, the VB6 project converter was a piece of junk - to be fair to Microsoft, there wasn't any way to convert VB6 code to VB.Net code in a way that adopts the ways of the framework and produces readable code at the same time.

Forms stopped appearing magically out of thin air. New data types where introduced and old ones changed. Syntax changes were introduced in the damnest places. Arrays stopped working as expected. Full-blown OOP and threading features became available and could be now used (and misused). "As New" worked differently. File I/O was supposed to be done through System.IO and not by using the old methods. Code compiled to IL, which was considered a threat to intellectual property. And what the heck is a garbage collector anyway?

Again, in all fairness to Microsoft, my humble opinion is that VB.Net is in a totally different league than VB6. However, VB.Net is not the next version of VB6 but a totally new language that just has a lot of syntactical similarities with VB6. It was the only way to have a VB in the Microsoft arsenal. VB6 could never fit into the framework, it did a lot of its magic in the background - out of reach (good because you couldn't lay your hands on it) and out of touch (bad because you couldn't lay your hands on it).

A new framework, a new paradigm and a new language. A lot of people felt that they were left out in the cold - especially those that didn't have another solid language like Java or C under their belt. Put this fact together with the ridiculous and idiotic job ads that searched for "candidates with at least 3 years experience in .Net" back in 2003 and you get a lot of frustration - hence the use of such strong words as "betrayed".

While I agree with almost everything you said, there was one point that I didn't quite understand: "Arrays stopped working as expected." What was the change there? I felt that I was using VB6 style arrays back in 2003 (though I dropped them as soon as the List showed up in 2005). The only change that comes to mind was that in VB6 you could have 1 based arrays.

That's the change I'm referring to Shaggy. Back then, I was in the habit of using 1-based arrays, and I guess that's also true for other people. When .Net was introduced, you could not have anything else other than 0-based arrays. In addition, the conversion wizard changed 1-based arrays to use some bizarre class from the compatibility namespace that made things look totally ridiculous.

Quote:

---

Originally Posted by Shaggy Hiker

While I agree with almost everything you said, there was one point that I didn't quite understand: "Arrays stopped working as expected." What was the change there? I felt that I was using VB6 style arrays back in 2003 (though I dropped them as soon as the List showed up in 2005). The only change that comes to mind was that in VB6 you could have 1 based arrays.

---

In vb6 you can do things like this:

Code:

---

Dim MyArr(1 to 10) As String

---

Which produces a String(), the LowerBound = 1, the UpperBound = 10, Length = 10. You can't do that in .Net (thank god).

Also the form designer in the IDE has support for control arrays, where it would generate the complete array of labels for you and you can loop the array in the code behind if you want to, in .Net you need to declare and populate an array of a control manually to get that effect and it'll have nothing to do with the form designer either.

Those are the two array changes I can think of between vb6 and vb.net

Control arrays were cool but I never really mourned their demise. As indicated by the signature of a forum member that I now forget, it's easy to do in VB.Net what you want without control arrays. Arrays with explicit bounds stung me a little bit more because I used them a lot.

To me, that's a minor thing. And something that was a long time in coming. As far as I know, only VB had 1-based arrays by default. All other languages were 0-based (which is as it should be). And I don't think it's something to get all out of sorts over.

And regarding the converter.... I remember when .NET first came out, I was at a conference and some one asked about a converter. The response then is the same as it is now - it's crap. It doesn't really convert, it points out obvious problem areas, and creates wrappers around other areas (like ADO). The recommendation - Don't use the converter and just simply re-design and build the application like new development. And that came right from the guys that made .NET. The only reason they added a "converter" for VB was because people were expecting one. But there's no possible way to cover everything and get an accurate conversion... so they opted for marking up the code with warnings instead.

I still fail to see the fundamental "problems" (alleged) that VB.NET has that makes resist it.

-tg

Circa 1975 - Honeywell Assembler - GMAP - 0 Based array

Code:

---

ARY                  BSS        100 - 100 words of storage i.e. an array

                LDX0        0, DU - load offset into the index register
LoadA                LDA        ARY, X0 - load item into A
                ALS        1        - multiply by 2
                STA        ARY, X0 -store it back
                ADX0        1, DU - increment index register
                CMPX0 99,DU
                TNZ LoadA

---

Look at all this junk stuck in my head, sad, really sad. ;)

Other languages had arrays that could be based on things other than zero. PL/I had them (:eek: I just gave away my age just like dbasnett :eek:). I also loved Pascal (and Delphi), in which you could declare a subtype like:

Code:

---

var
subType: '1'..'9'

---

and then you could declare an array indexed with subType. True, you can live without something like this just as you can live without 1-based arrays. But it's convenient. Likewise, you can live without the VB For loop and just have the While loop but I can imagine that a lot of people would be angry if Microsoft decided to throw away the For loop to make the language simpler.

The irritation resulting from making such a code-breaking change was not because of the change itself but because of the attitude of Microsoft as perceived by users. 1-based arrays were extensively used and, in making such a change and numerous others like it, Microsoft made sure that code would break left and right. It was really no big deal to add support for 1-based arrays to the .Net framework. Or, if that seems a bit like going too far, the VB compiler could generate behind the scenes the necessary IL in order to let VB keep 1-based arrays. The reason they didn't do it is because the C#-minded people in charge of designing .Net didn't see this particular VB-ism as worthy of assigning resources to implement it. I don't really blame them for not understanding the importance of not introducing such a change but it seems that no VB-minded people were present in the .Net team or the new VB compiler design team.

To take another example, look at the way the declaration of properties has changed. In VB6 you had something like:

VB Code:

Public Property Let MyProperty(ByVal vData As String)
    mvarMyProperty = vData
End Property
 
Public Property Get MyProperty() As String
    MyProperty = mvarMyProperty
End Property

This was instantly broken by the new VB.Net syntax. I could never figure out the reason behind this particular change because it has nothing to do with the .Net framework.

For a company that has given new meaning to the words "Backward compatibility" the scope and breadth of such breaking changes were unheard of. I guess that the .Net framework introduced so many changes making a deep break with the past that VB6 people would just appreciate it if Microsoft focused a bit more on not also breaking the easy stuff.

It's like you said about the project converter. They knew it was crap and any decent VB programmer would understand that it wasn't worth the effort necessary to implement it in the first place. Wouldn't it be better to put these resources to good use by trying to let VB.Net keep some of its features that weren't incompatible with the framework instead of just wasting them on the project converter? But instead they choose to make no effort at all to let VB programmers keep at least some of their conveniences so they could focus on understanding all the really hard stuff introduced by the .Net framework.

I hope I'm not misunderstood - I'm a big fan and active supporter of the .Net framework. But I happened to know and work with several people that loved VB6 and I understand their point of view, even if I don't embrace it.

Quote:

---

I'm wondering. Am I the only one that doesn't feel betrayed?

---

No, but some people will complain about anything !

I thought us developers were supposed to be technical people who embraced change but it seems that some people will always pine for how it used to be !

As far as i am concerned a large majority of the changes in .Net are a lot better then how it used to work in VB6.

Quote:

---

Originally Posted by ntg

To take another example, look at the way the declaration of properties has changed. In VB6 you had something like:

VB Code:

Public Property Let MyProperty(ByVal vData As String)
    mvarMyProperty = vData
End Property
 
Public Property Get MyProperty() As String
    MyProperty = mvarMyProperty
End Property

This was instantly broken by the new VB.Net syntax. I could never figure out the reason behind this particular change because it has nothing to do with the .Net framework.

---

Personally, I'd take this:

Code:

---

Public Property MyProperty() As String
  Get

  End Get
  Set ...

  End Set
End Property

---

Over vb6 properties any day, if only for it to force both the Get and the Set to stick together. With vb6 having the Get and Let part of the properties be separate blocks of code, it led to all kinds of problems because the Let's would be in one part of the file and the Get's where in another part... no one really ever knew where the part(s) where.

Quote:

---

Originally Posted by NeedSomeAnswers

I thought us developers were supposed to be technical people who embraced change but it seems that some people will always pine for how it used to be !

---

I wood pine knot! I am not board!

I actually used 1-based arrays all the time I was in VB6. They did have their uses (the item count was the same as the maximum index). That off by one error has traditionally been one of the biggest in programming.

Personally I always used 0 based arrarys any way.

Quote:

---

Originally Posted by JuggaloBrotha

Personally, I'd take this...Over vb6 properties any day.

---

But imagine if you have a VB6 production application that you decide to migrate to VB.Net. You have to refactor almost everything in order to make a decent migration. Or you scrap most of your original code and start over. But you can't copy-paste even the most basic of your business classes without having to rewrite your properties. It's a major annoyance.

I totally agree with you. I like the new property declaration syntax better. But it does not contribute anything to the language or a developer that was disciplined and had their declarations right in VB6 in the first place (and you had to be very disciplined with VB6 if you were doing production-grade development otherwise you were in for a lot of surprises). It's only a matter of syntax which to me is directly equivalent to a matter of preference. And back in 2001 it was obvious that Microsoft valued their preferences more than those of the many VB6 developers (who where their end users by the way). That is really the core point made by a lot of VB6 developers back then.

At the risk of being a bit off topic, I'll illustrate the feeling by using a more recent example: Windows 7. I've tried it since the first beta and installed all sort of applications on it without any problems. I think that Win7 is a very strong Windows release and I've been counting the days until it was made available in MSDN. I burned the brand new image on a brand new DVD, made a backup of my XP box and went on with the brand new install.

After making excellent progress without any hint of an issue with the Windows install I started installing my standard application set. No problems until I reached VS.2003 (which I had not tried with the beta). One of our customers has a software system developed in VS.2003 for which they pay us tens of thousands of Euros of annual maintenance and obviously I needed to be able to provide support. Surprise, surprise: FrontPage Server Extensions were not supported in Windows 7 (if this has changed since the release of Windows 7, someone please let me know). Without FPSE, I had no way to use any ASP.Net applications that were part of the VS.2003-based system. That left me with the following options:

• Use a virtual machine for the ASP.Net solutions. Not a real choice, because it would mean I would have to seriously alter the entire system build and use a virtual machine.
• Use a virtual machine to do all development and debugging for the old system. Great choice, but I can also do that by installing Debian and not Windows 7. Oh yes, I forgot to mention that I could do the same without installing anything over XP, where's that pre-install backup?

In this situation, I was frustrated by a simple fact: FPSE was supported in Vista (not initially, but eventually it was). Since Windows 7 has a lot of code in common with Vista I think it would be trivial to also support FPSE in Windows 7. I've read that even Visual Studio 6 is supported in Windows 7.

I can hear the argument. Why not migrate the old system to VS.2008 and .Net 3.5 already??? I'd just love to do that since we're using VS.2008 for all other solutions and VS.2003 is an anachronism in the company workshop. But before I embark on this conversion of tens of thousands of code lines, I would need to persuade two people: my boss and my client. My boss will ask me questions like how many man-days it's going to take and how will the company profit by this. I will try to fake an estimate and indicate that code will be more maintenable so we'll eventually save time in support incidents and feature enhancements (although I won't be able to tell him exactly how much). My client will ask me how much money they will save by installing the new release and what is the break-even point at which the cost of testing and re-installing is less than the additional revenue that will be provided by the new release. This is a question to which I cannot provide an answer based on an infrastructure-based upgrade - to me, an upgrade to .Net 3.5 is a seriously good thing but to my client this is just an infrastructure upgrade.

So I find myself in a great fix until my client decides to upgrade - that will happen at 2013 when extended support for .Net 1.1 ends, they did the same when support expired for .Net 1.0.

Personally, I didn't feel betrayed. I found VB.NET much more powerful than VB and such minor things as option base 1 and control arrays didn't spoil anything. I bought a $15 book about .net framework and resolved nearly all issues about transition from vb6 to vb.net. I watched gradual progression of the BASIC language from MSX basic (Z80 processor) to GWBasic to QuickBasic to VB2.0 then came later versions 3, 4, 5 and finally - VB6. In fact I found it much more difficult to switch from VB5 to VB6 than from VB6 to VB.NET.
I got used to changes I guess. Hard life has forced me to switch to Pascal/Delphi, then to VC++, but I still love BASIC for its simplicity. To beginners that started with VB6 I suggest to study Win32API because everything Windows does it does with its own API. Once you understand how windows works the selection of language will be merely a matter of preferrence.
.NET Framework has raised the RAD concept to the heights unthinkable before. With CLR you can even develop your own languages with as much so calles syntaxic sugar as you want so I always welcome changes.

ntg, If you'd had used Vista, you would have been aware of the no VS 2003 support and a lack of FPSE a few years ago, it's nothing new to Win7.

That being said, I do have a Win7 Computer now that has a CPU that has Virtualization support so I can install the XP Mode (yes it's a VM, but it's a fully integrated VM). I haven't tried installing VS 2003 in XP Mode yet, I'll have to find the DVD (haven't used it since early 2006) but I'd think it would work since that's the point of XP Mode.

cicatrix, I had minor issues going from vb6 to VS 2003 (.Net 1.1) but those all got resolved pretty quickly once I understood how .Net works. Now I have issues when I go back to a vb6 app and try to remember what api call's I'd need because in .Net I rarely ever have to go to the API to do simple things. Also vb6 could really, really use the 'AndAlso' and the 'OrElse' keywords for short circuit logic.

Quote:

---

Originally Posted by JuggaloBrotha

ntg, If you'd had used Vista, you would have been aware of the no VS 2003 support and a lack of FPSE a few years ago, it's nothing new to Win7.

---

Obviously I never used Vista, it was a horrible release until the service packs arrived. But Googled posts like this indicate that FPSE were supported in Vista, hence my disappointment.

Quote:

---

Originally Posted by JuggaloBrotha

That being said, I do have a Win7 Computer now that has a CPU that has Virtualization support...

---

Yeah, virtualization is great. A colleague installed Ubuntu and then used VMPlayer for his working environment in which he spends a lot of his time, using Ubuntu for his e-mail client and surfing. I never really understood how his working experience was enhanced by working in a sandboxed VM.

Quote:

---

Originally Posted by ntg

Obviously I never used Vista, it was a horrible release until the service packs arrived. But Googled posts like this indicate that FPSE were supported in Vista, hence my disappointment.

---

Not in the RTM and SP1 didn't add it when I tried, I doubt SP2 has added support for it since it's still listed as "Not supported" by Microsoft.

Quote:

---

Originally Posted by ntg

Yeah, virtualization is great. A colleague installed Ubuntu and then used VMPlayer for his working environment in which he spends a lot of his time, using Ubuntu for his e-mail client and surfing. I never really understood how his working experience was enhanced by working in a sandboxed VM.

---

It keeps your development away from the core computer. As in if you install random software on a computer and your work environment is in a VM then whatever is installed wont effect your work environment. It's much cheaper than maintaining two computers at the hardware cost of running potentially two whole OS's on one workstation.

The XP Mode is different than traditional VM's (though I don't know what all VMware can do, so correct me if I'm wrong) because XP Mode is a VM environment that's fully integrated in the Win7 OS, so instead of starting up XP in a VM window complete with it's own desktop, start menu, etc the XP Mode program is right in the Win7 taskbar like any other program and XP Mode kicks in when needed instead of you explicitly starting XP, so on and so forth.

Quote:

---

Originally Posted by JuggaloBrotha

Not in the RTM and SP1 didn't add it when I tried, I doubt SP2 has added support for it since it's still listed as "Not supported" by Microsoft.

---

Quote from this link.

Quote:

---

Microsoft and Ready-to-Run Software have released a new version of the FrontPage 2002 Server Extensions (FPSE 2002) for Windows Server 2008 and Windows Vista.

---

Quote:

---

Originally Posted by ntg

Quote from this link.

---

That's actually a good thing to know, though this means either it was released after Vista SP2 or MS didn't include it with either of the Service packs, which would be that surprising.

Ready-to-Run maintains FPSE.... at least that's they way I understand it. Microsoft no longer supports it (at least not directly - I wouldn't be surprised to find out they lend a helping hand from time to time). You can get FPSE from R-t-R. But it's no longer part of the Win install.


Back on topic... so basically it confirms what I suspected, that people are kivitching because they don't want to have to re-write their code to work properly in .NET. I think it was time VB had gotten an overhaul anyways. And I don't think some of the things that can be done with VB now would have been easily incorporated into VB Classic. I don't blame them for scrapping it and starting new. Not only that, but it makes it easier for VB to keep up with the changes being done .NET.... can you IMAGINE what kind of effort would have been involved to give something like VB6 LINQ? Or Lambdas for that matter?

-tg

Quote:

---

Originally Posted by JuggaloBrotha

That's actually a good thing to know, though this means either it was released after Vista SP2 or MS didn't include it with either of the Service packs, which would be that surprising.

---

Vista SP1 was released at 3/18/2008. SP2 was released at 5/25/2009. FSPE support for Vista was added at 4/9/2008 which puts it before the release of SP2.

Edit: Sorry for going wildly off topic techgnome, I posted before I saw your last.

These discussions go nowhere for several reasons. Some of them quite legitimate and others totally emotional.

The question I have is why there continue to be so many new programmers trying to pick up VB6 from scratch. The VB6 related forums are jam-packed with total newbie questions. Add to the mix so many "Where can I buy/steal VB6?" questions from newb-wannabees.

While I believe there are cases where a VB6 solution is superior to any .Net solution (and this is where arguments start) I just can't see why there are so many people trying to learn VB6 from scratch today. The rank newcomer will almost never be working on projects that benefit from classic VB's strengths that early in their career - and most of these seem to be students or hobby programmers anyway.

Not trying to start an argument, but I AM curious as to what areas you found superior in VB6. I used that language for several projects, but I don't feel that I really got into the dusty corners of the language, so I wouldn't be surprised to find that there were areas I had not trod.

Perhaps the noob in VB6 reflect some perception that VB6 is user friendly while .NET is a 'real' language. That perception was certainly around among some segments throughout the VB4-VB6 days (C/C++ was the 'real' language, and .NET may have joined that rank, which would be interesting). On the other hand, perhaps it is just that some rank newcomers are more rank than others.

Most of the real "advantages" have nothing to do with the language and almost everything to do with the runtime environment.

Some are as simple as "runtime deployment" issues. Another may be the ability to run on Windows back to Windows 95. There are a lot of edge cases where performance matters, particularly process initiation and memory consumption. Use in COM+ scenarios is a lot lighter weight than .Net's System.EnterpriseServices wrapper. DCOM has much better performance than Web Services and Remoting (and WCF has begun moving back to DCOM and Pipes for some transport scenarios because of this). VB6 "portable apps" can be created using reg-free COM based on the VB6 runtime being part of the OS now. Lots of things in the Framwork are just wrappers over COM which in turn wraps system APIs, so .Net adds more indirection and inefficiency.

The list goes on and on, and each point could be argued back and forth. There is no point though, the arguing has been done for years and gets us nowhere. VB6's biggest problem is that it is still stuck in 1998. The language as it exists there isn't really its strength, it seriously needed further evolution that it never got.

VB6 has lots of problems. I won't claim it doesn't.

I haven't even gone into the issue of supporting existing VB6 applications, classic ASP applications using DLLs written in VB6, etc. Those are obvious points and have already been mentioned.


I'm beginning to wonder if some of the VB6 newbies might be coming from diploma mills hoping to focus students on a perceived market for people to help convert legacy VB6 applications to .Net, Java, etc. There is no question that tons of old VB6 is still being used. I suspect a lot of this will end up being eventually discarded or replaced rather than ported to another programming toolset though.

Either that or there are schools out there using Win9x PCs for teaching yet, so VB6 might be all they can handle?

Hmm, re-reading the original post here...

Most of those issues date back to 2001 through 2005. You must be reading a lot of old posts or blog entries or something.

Any "throwing under the bus" happened a long time ago.

That was kind of my point... so WHY is there still this backlash? I still see it today... the same day I posted this, it was right after some one had mentioned feeling like MS threw them under the bus with the break from VB6. (I'd go look it up, but it's irrelevant) .NET has been around for sometime now, so why is there STILL this under the buss mentality? I've come to the conclusion that hard core VB6 developers (the ones still clinging to it because they WANT to, not because they have to) aren't a happy bunch unless they are complaining about something(how the heck do you think default form instances made its way BACK into the language after being removed? One step forward, one-half step back). When VB6 ruled, it was that VB6 wasn't OOP-y enough... now that it is, it's too OOP-y. I will conceed on FW size arguments... It would be nice if I didn't have to install the full FW... just include the bits I need.

Maybe I'm being stupid. Maybe I'm being close minded... But I just don't get it. I'm going to go put my soap box away now and try to ignore the Negative Neils...

-tg

Well, I was using VB6.0 from when I started learning programing (self taught) in 1998 then 2007 got sick of it and took a break. However, now I am starting to get back n to the habit but I'm having a hard time migrating to vb.net I still prefer vb6. What is the difference in the code between the two languages anyway, from the code point of view? I know that .net allows you use components without having to import/reference them because a lot of them are include in .net. However, the code seem much more complicated than it did in vb6.0 why is that? Also is there an idiots guide to converting code from vb60 to vb.net without using the conversion tool?

Quote:

---

Originally Posted by Nightwalker83

What is the difference in the code between the two languages anyway, from the code point of view? I know that .net allows you use components without having to import/reference them because a lot of them are include in .net. However, the code seem much more complicated than it did in vb6.0 why is that?

---

I'm not trying to be sarcastic here but, to paraphrase the words of the wise Ben Parker, with great power comes great complexity. And the .Net framework is indeed very powerful. I understand that VB.Net seems too complex at first but you are now experiencing the well-known feeling of reading programs in a language that's alien to you. You need to try to get into VB.Net in order to understand the order of the things it does. And obviously any attempt to learn a .Net language implies that you'll immerse yourself in the .Net framework as well.

Quote:

---

Originally Posted by Nightwalker83

Also is there an idiots guide to converting code from vb60 to vb.net without using the conversion tool?

---

Any quick-and-dirty conversion guideline would ignore the complexity of the framework and the fact that old VB6 code would need refactoring in order to take advantage of the framework's benefits. So, in a nutshell, no there is not and can never be an idiots guide to converting.

I think that the number of noobs on the VB6 forums can be explained by the fact that VB6 and VBA are very similar. VBA comes with MS Office which is widespread and 'free to take'.
I am breathlessly waiting for the time when MS Office will be built on .NET Framework.

Nice thread, I actually agree. Although going back to when I made the move from VB6 to VB.net all the bad 'Press' it had made me way more nervous that I should have been.

Essentially VB6 is a lanuage which uses common english commands and allowed people to put apps together quickly (Hiding as much complexity from the user as possible - that isnt a dig.). VB.net took the simplicity of VB6 and plonked it on top of a decent framework which didnt allow you to do all of the things that Vb6 did (Well not as simply in terms of Form1.Show etc) - this was a big change but not enough to really be worried about. However like with anything, people dont like change.

Quote:

---

Originally Posted by cicatrix

I think that the number of noobs on the VB6 forums can be explained by the fact that VB6 and VBA are very similar. VBA comes with MS Office which is widespread and 'free to take'.
I am breathlessly waiting for the time when MS Office will be built on .NET Framework.

---

I was hoping Office 2010 dropping vba in favor of .Net was more than just talk. Apparently it was just talk, however I did notice that the next Mac edition of Office is slated to not include apple script support.

Quote:

---

Originally Posted by JuggaloBrotha

I was hoping Office 2010 dropping vba in favor of .Net was more than just talk. Apparently it was just talk, however I did notice that the next Mac edition of Office is slated to not include apple script support.

---

They would have to rewrite the office to get full advantage of the .Net Framework. It's no small a task. Office is built on the COM technology.

This is a screenshot I captured a few seconds ago. Very often, in VB Forums, the number of users connected to the VB6 section exceeds the number of those who are visting the .NET one. This is happening in the year 2010, i.e. more than ten years after the last version of VB6 was released.

There must be a reason for it.

In my view, one of the most important reasons is that there are many types of software that do not need the power of the .NET Framework to be developed. Why on earth should a programmer make his software depend on a huge sort of virtual machine when he could get the same results in VB6? You don't need a main battle tank to kill a fly!

If you add to this problem -- the deployment of your software is not a secondary issue at all! -- the fact that byte code obliges you to use an obfuscator, it doesn't take much to understand the reason why today VB6 is still alive and kicking, to the disappointment of MS.

Esposito- You are the only person I have encountered who has a demonstrable reason to object to byte code implementations, though there are probably plenty of other people with the same issue. I would guess that the vast majority of us have nothing to protect in our code. The data can be worth protecting, but the code itself is not. The point behind producing byte code is the dream of write once, run anywhere, which Java made a serious run at, and nobody has been wholly successful at. Still, the dream remains, and a language that produces a byte code intermediate is the only viable alternative.

As for the framework, VB6 required one, too, it was just smaller. Is that a big deal? To some people it is, but not to all that many. There aren't many people using PCWrite as a word processor because the modern ones include HUGE amounts of extra junk with them. Bloat isn't a great thing, but as memory prices head steadily downwards, it also is nearly insignificant and getting less all the time. I thought I was cool when my first computer had a 44MB HD in it (lots of computers still had NO HD). Now, I'm not sure that I am more amazed that I have a 500GB drive in my new computer, or that it may not be enough (and certainly wouldn't be if I was seriously into downloadable media). Basically, complaining about absolute size has become entirely silly. The VB6 runtime was too huge to run in computers twenty years back, now it is considered tiny. The .NET runtime was outrageous ten years ago. Now it is pretty small, and will soon be considered tiny, as well. Complaining about that is like spitting into the wind: It gets you nowhere and other people laugh at you.

As the framework gets built into the OS, it will become no burden at all. Meanwhile, if the VB6 runtime is removed from the OS (and rumors abound with every new OS version), it will be THAT which will be the burden.

Quote:

---

The point behind producing byte code is the dream of write once, run anywhere, which Java made a serious run at, and nobody has been wholly successful at. Still, the dream remains, and a language that produces a byte code intermediate is the only viable alternative.

---

Microsoft has no serious intention to let developers produce software for other operating systems. They are not so stupid as to risk losing their monopoly.

Quote:

---

The data can be worth protecting, but the code itself is not.

---

You need to protect your code because your software could be cracked. This used to happen to my programs until a few years ago.

Quote:

---

The .NET runtime was outrageous ten years ago. Now it is pretty small, and will soon be considered tiny, as well. Complaining about that is like spitting into the wind: It gets you nowhere and other people laugh at you.

---

The size of the .NET runtime is still outrageous. Downloading hundreds of megabytes just to test your software could bring a lot of potential customers to look elsewhere for something less time consuming.

Quote:

---

As the framework gets built into the OS, it will become no burden at all.

---

A new version of the Framework is released, more or less, every two years. You will always have to cope with this deployment issue if you want to stay updated.

Quote:

---

Meanwhile, if the VB6 runtime is removed from the OS (and rumors abound with every new OS version), it will be THAT which will be the burden.

---

True. That's why I have been working hard to migrate all of my VB6 software to Delphi for more than two years.

By the way, the screenshot below (which I took a few seconds ago) shows the number of visitors to the VB6 general section against the VB.NET one in another very popular forum dedicated to Visual Basic (xtremevbtalk.com). The ratio is 104 to 46. Needless to say, 104 is the number of those visiting the VB6 pages.

Quote:

---

Originally Posted by esposito

The size of the .NET runtime is still outrageous. Downloading hundreds of megabytes just to test your software could bring a lot of potential customers to look elsewhere for something less time consuming.

---

Only if you're still using older OS's in which the entire thing has to be downloaded. I only needed the 40Mb 3.5 FW to download and install for my Vista comp when I bought it. With Win7 I only needed SP1 which was even smaller. I think the entire vb6.5 runtime is 30MB, but even that comes pre-installed in Windows. So the FW size isn't that much more for the latest FW if you're starting from Vista/7. XP on the other hand was released before .Net 1.0 was out so you're SOL if you're doing fresh installs of XP these days.

Quote:

---

Originally Posted by esposito

A new version of the Framework is released, more or less, every two years. You will always have to cope with this deployment issue if you want to stay updated.

---

With the FW stacking each new FW is less than 60MB, is that really a big deal?

Quote:

---

Originally Posted by esposito

True. That's why I have been working to migrate all of my VB6 software to Delphi for more than two years.

---

Last I'd heard Delphi is migrating towards C#, the two companies that two of my friends work for are migrating from Delphi to C# now instead of using Delphi to migrate their apps to C# next year.

Quote:

---

Only if you're still using older OS's in which the entire thing has to be downloaded.

---

If you produce software for the general public (as I do) and you are willing to reach as many customers as possible, you'd better take care of those who are still using XP, i.e. the majority of PC users worldwide.

Quote:

---

Last I'd heard Delphi is migrating towards C#, the two companies that two of my friends work for are migrating from Delphi to C# now instead of using Delphi to migrate their apps to C# next year.

---

This is absolutely false. Delphi exists in two different versions. One is designed for the development of native software and one for .NET based applications.

The figures of people viewing the VB6 forums still shock me. Commercially VB6 IS dead. However there are always going to be legacy apps around and I understand a small percentage of developers still need to use it, however that doesnt explain them figures.

Quote:

---

Originally Posted by Pino

The figures of people viewing the VB6 forums still shock me. Commercially VB6 IS dead. However there are always going to be legacy apps around and I understand a small percentage of developers still need to use it, however that doesnt explain them figures.

---

I wish those figures could make MS wonder why so many VB6 users are reluctant to switch to .NET.

The truth is, .NET is nothing new. Java has been around for decades and many of those who produce native software and never found it convenient to use Java will never consider .NET an alternative to VB6.

Quote:

---

Originally Posted by esposito

I wish those figures could make MS wonder why so many VB6 users are reluctant to switch to .NET.

The truth is, .NET is nothing new. Java has been around for decades and many of those who produce native software and never found it convenient to use Java will never consider .NET an alternative to VB6.

---

No Disrespect but "them people" are such a small minority. If you spoke to 90% of people viewing the VB6 board they wouldnt know what you were talking about.

So I still cant figure out why so many people are using VB6. I cant think of a valid reason (For the masses), other than reluctance to change.

MS are in a loose loose situation here, although more people would be annoyed if the langauge didnt develop and change.

I think this forum has either alot of ranked content for VB6 or has a very die-hard member base.

http://stackoverflow.com/questions/tagged/vb6
http://stackoverflow.com/questions/tagged/c%23

Much higher percentage there. Maybe forums like this that are still activley supporting VB6 discussions are attracting vb6 users from other forums who arnt that interested anymore

Quote:

---

Originally Posted by Pino

No Disrespect but "them people" are such a small minority. If you spoke to 90% of people viewing the VB6 board they wouldnt know what you were talking about.

So I still cant figure out why so many people are using VB6. I cant think of a valid reason (For the masses), other than reluctance to change.

MS are in a loose loose situation here, although more people would be annoyed if the langauge didnt develop and change.

---

Reluctance to change was never significant when MS released newer versions of VB. It only took a couple of years at most to see the majority of VB users switch to the latest version. I'm firmly convinced that the explanation of this reluctance has only one name: the Framework Deployment Hell!

There IS no framework deployment hell. We work ONLY in .NET, and there has never been even a single complaint.

However, it would be nice to see a native compiler option for .NET. They exist commercially, I believe, but not as part of VS, currently. That would solve your problem with obfuscation, and wrapping the frameworks into the OS, as is happening, would remove the other difference between VB6 and .NET. It seems to be a simple option. Byte code programs are intended to run anywhere, but that's not how most people work. Offering the option to compile to native seems like a simple enough change. However, it would be an onerous change unless that really had something to do with why people still use VB6, and I frankly doubt that is a reason for the vast majority.

Quote:

---

There IS no framework deployment hell. We work ONLY in .NET, and there has never been even a single complaint.

---

A lot of people don't like complaining. They just stopped using VB and switched to either Delphi or RealBasic. Others will use VB6 until MS breaks compatibility with 32-bit native software.

I remember I was happy to switch from VB3 to VB4 and enthused about the possibility to compile in both 16 and 32 bits. When VB5 came out I bought it right away and never went back to VB4. Some years later, I could not see any significant changes iin VB6 and so I decided to stick to VB5, though I sometimes played around with the newer version. When VB.NET was released I immediately understood that it was time for me to look elsewhere: it was the most counterproductive tool I could use to develop my native software.

Quote:

---

Offering the option to compile to native seems like a simple enough change. However, it would be an onerous change unless that really had something to do with why people still use VB6, and I frankly doubt that is a reason for the vast majority.

---

If this is not the reason, how is it possible that some software houses make money selling conversion tools (Thinstall for one) which cost hundreds -- if not thousands --- of dollars?

Quote:

---

Originally Posted by esposito

In my view, one of the most important reasons is that there are many types of software that do not need the power of the .NET Framework to be developed. Why on earth should a programmer make his software depend on a huge sort of virtual machine when he could get the same results in VB6? You don't need a main battle tank to kill a fly!

---

Funny you mention that. I remember when in the late 90s people were frustrated about having to distribute MSVB runtimes along with their projects. And it confused many end-users when something like 'VBRUN300.DLL not found' happenned.

.NET Framework is included in Vista and Windows 7 distribution by default so there is nothing to worry about.
I think that Windows.Forms will be the last programming platform for PC, the programming industry slowly moves towards the online applications. Take Google Chrome OS, for example, I understand it relies heavily on being online. The days when we will run our software on remote servers are not that far I think. ASP.Net/Java are far more promising programming platforms than Windows.Forms.

"I think that Windows.Forms will be the last programming platform for PC, the programming industry slowly moves towards the online applications."

When I started in this business it was all online, and then those two guys in California started a revolution. For some time the pendulum has been swinging back, but how far will it go until we re-learn the reasons for moving the power outward.

Quote:

---

Originally Posted by esposito

A lot of people don't like complaining. They just stopped using VB and switched to either Delphi or RealBasic. Others will use VB6 until MS breaks compatibility with 32-bit native software.

---

That points clearly irrelevant. If they had stopped using VB altogether, it would have no impact on the relative numbers in a forum, it would simply decrease the total number.

Quote:

---

When VB5 came out I bought it right away and never went back to VB4. Some years later, I could not see any significant changes iin VB6 and so I decided to stick to VB5, though I sometimes played around with the newer version.

---

Ya. I moved to VB6 right away, but not for any particular reason. Those two were so similar that VB6 could have been called VB5.1. I would guess that it was called VB6 largely for sales reasons.

Quote:

---

When VB.NET was released I immediately understood that it was time for me to look elsewhere: it was the most counterproductive tool I could use to develop my native software.

---

In your case that would be true. You wouldn't be doing much web development or web services, either, and you certainly aren't doing any multithreading in VB6, so you wouldn't have seen any benefit from that.

Quote:

---

If this is not the reason, how is it possible that some software houses make money selling conversion tools (Thinstall for one) which cost hundreds -- if not thousands --- of dollars?

---

Frankly, I would say that the point supports my statement more than it undermines it. I am aware that those companies exist, and I thought the price was in the thousands rather than the hundreds, though I admit that I have never looked. They are not seeing much volume at that price. If they were selling tens of thousands of copies, the cost would be way down. After all, as you well know, development is virtually the entire cost for software. The cost to produce a unit is near zero. Therefore, to recoup the cost of the package as a whole, you either have to sell many units at a low price, or just a few units at a high price. Companies who expect that there will be few buyers, but VERY motivated buyers, will charge a higher price because they have to recoup cost from a small user base. Therefore, the high price of these packages suggests that there are few buyers.

Of course, there is always a different interpretation to the relative numbers: VB6 has more questions because it is harder to learn for the existing pool of users (this could be read in two ways).

[QUOTE=dbasnett;3709894those two guys in California [/QUOTE]

C'mon, admit it: You just said that because you can't spell the other Steve's name, either.

J-o-b-s ;)

Quote:

---

Originally Posted by Pino

However there are always going to be legacy apps around and I understand a small percentage of developers still need to use it, however that doesnt explain them figures.

---

Sure it does. My personal legacy nemesis is COBOL and I was forced to learn it once. There's still a huge amount of production COBOL code, Gartner estimated that there were 200 billion lines of COBOL in worldwide usage. Someone needs to maintain it and even use COBOL to make enhancements in existing code. Such penetration is also the reason for the .Net COBOL compiler. These unfortunate developers will definitely show up somewhere in some statistics or forums.

It's something like that with VB6 - it was hugely adopted (I've read estimations of 6 million end-users) and this ensured that there will be lots of people that need to use it for a long time and not just a small percentage of developers. How else would you explain the fact that it's a dead-end unsupported language, part of an IDE replaced for almost a decade which is dated five releases back from the upcoming VS 2010 but still has a noticeable share amongst developers?

Actually there are a lot more componaies selling Cobol systems than just the .Net flavors too.

Often they use their own proprietary "Cobol VMs" instead of compiling to native code, in order to get portability among Windows, various Unix platforms (Sparc, Intel/AMD), etc. Sort of the Java "write once" concept but with more control over libraries and environment than Java has. However there has been major product consolidation in this space via acquisitions over the past several years, so there are fewer such companies now than 5 years ago.

Quote:

---

Originally Posted by ntg

I'm not trying to be sarcastic here but, to paraphrase the words of the wise Ben Parker, with great power comes great complexity. And the .Net framework is indeed very powerful. I understand that VB.Net seems too complex at first but you are now experiencing the well-known feeling of reading programs in a language that's alien to you. You need to try to get into VB.Net in order to understand the order of the things it does. And obviously any attempt to learn a .Net language implies that you'll immerse yourself in the .Net framework as well.

---

Yeah, I will hopefully be learning vb.net when I go back to school next month. I took a break of about 6 six years and now I want to learn vb again.

Quote:

---

Any quick-and-dirty conversion guideline would ignore the complexity of the framework and the fact that old VB6 code would need refactoring in order to take advantage of the framework's benefits. So, in a nutshell, no there is not and can never be an idiots guide to converting.

---

Ah ok, I doubt there is even a list of the changes between the code used in the two versions, like having the code to preform the same job lying side by side on the page. So we could see the difference in the two languages and the way they use the code. Like the documentation ActionScriptCheatSheet where it lists both versions and have they preform the same function/action.

You could make something like that for some concepts, but the VB6 would leave lots of areas blank.

Quote:

---

Originally Posted by Shaggy Hiker

You could make something like that for some concepts, but the VB6 would leave lots of areas blank.

---

Ah, guess I going have to stress myself out with trying learn vb.net trying to forget everything I know about the coding in VB6.0. It is not going to be easy.

Edit:

Quote:

---

Originally Posted by techgnome

Geting on the bus, not under it...

---

It is spelt getting you missed the second t.

Quote:

---

So I still cant figure out why so many people are using VB6

---

I think the answer is a lot simpler, VBA (which is basically VB6) is still part of all Microsoft Office products.

If Microsoft were to implement VB.Net inside it's office products instead i think you would see a fall in VB6 use.

Also As Windows 7 / Server 2008 etc. becomes more prevalent in the business world i think this will also have a direct bearing on VB6 use, as not only do VB6 apps look terrible on Windows 7, i know from a couple of legacy apps we have written in VB6 that we are coming across more and more problems validating these old programs against newer operating systems.

Quote:

---

Originally Posted by NeedSomeAnswers

Also As Windows 7 / Server 2008 etc. becomes more prevalent in the business world i think this will also have a direct bearing on VB6 use, as not only do VB6 apps look terrible on Windows 7, i know from a couple of legacy apps we have written in VB6 that we are coming across more and more problems validating these old programs against newer operating systems.

---

Yeah, I was surprised to hear that Microsoft were still supporting VB6.0 for Win7. I would have thought Win7 would be a .net only system.

Quote:

---

Originally Posted by Shaggy Hiker

That points clearly irrelevant. If they had stopped using VB altogether, it would have no impact on the relative numbers in a forum, it would simply decrease the total number.

---

Like me, they may still have to maintain their old software developed in VB6. That could be the reason why they still visit this forum now and then.

Quote:

---

Frankly, I would say that the point supports my statement more than it undermines it. I am aware that those companies exist, and I thought the price was in the thousands rather than the hundreds, though I admit that I have never looked. They are not seeing much volume at that price. If they were selling tens of thousands of copies, the cost would be way down. After all, as you well know, development is virtually the entire cost for software. The cost to produce a unit is near zero. Therefore, to recoup the cost of the package as a whole, you either have to sell many units at a low price, or just a few units at a high price. Companies who expect that there will be few buyers, but VERY motivated buyers, will charge a higher price because they have to recoup cost from a small user base. Therefore, the high price of these packages suggests that there are few buyers.

---

I think what you said can be easily contradicted. MS are selling millions of copies of Office but in spite of that its price is still shamefully high.