VB 6.0 and .net
in [Visual Studio]
|
Prev: rsidll32
Next: Run executable from memory/ram?
From: Tony Proctor on 15 Jun 2005 11:09 I would add a bit to the section on ".NET has better garbage collection than VB6" Michael. The whole .Net garbage collection scheme seems to revolve around the idea that it's only memory that's being disposed of, or reclaimed. Within this limitation, it works well and is more efficient that the referenced-counted COM scheme. However, as soon as you have other types of resource that should be released on object destruction (e.g. locks, kernel objects, channels, visual elements such as hourglass cursors, etc) then the non-deterministic nature of that destruction means such classes may no longer function reliably. The issue of "deterministic finalisation" is one I hope .Net will address properly at some point. Tony Proctor "Michael B. Johnson" <mjohnson(a)veribox.net> wrote in message news:35d0b1pgh85seku23s3c36fumjnglnjmcf(a)4ax.com... > On Tue, 14 Jun 2005 17:01:59 -0400, "CadAd" > <Harmon.Scott_RemovýThýs_(a)BETADesign.com> wrote: > > >What is the difference between Visual Basic 6.0 and Visual Basic .Net? I'm > >looking to get started in Visual Basic and don't understand? > > With everyone else piling on behind .NET, let me give you an alternative view. > > Historical Context: The .NET language is a significantly changed API from the > VB6 environment - Microsoft ripped the rug out from under those of us who, > through hard work, helped it get where it is today. This is hardly the first > time they've done that. Since this is a clear pattern, I can hardly recommend > you invest your time, sweat and tears into something that is only going to > change radically in 5 years, perhaps far /less/. Microsoft is working overtime > to compel people into a subscription model of software, away from software > licensing because this way they can ensure a higher barrier-to-market, as well > as increase revenues. The fact that this is at the expense of their customer and > their customer's security is of no consequence to the Microsoft Corporation and > their board. By investing in .NET, you help perpetuate this and aid its spread. > I think that in the long run, Microsoft is going to lose to Open Source > software. > > Technical Info: .NET has a number of concepts that can be harder for a beginner > to absorb, such as overloading, polymorphism. However, if you know C++ or Java, > these will comfortable, familiar concepts. The .NET API, being proprietary and > closed, is going to be incompatible with anything else you'll ever work on - > it's been intentionally designed by Microsoft to be that way so they can call it > their own intellectual property. (There is an open-source product called "Mono" > that many would say would allow .NET apps to run on the Linux operating system, > but my view is that Microsoft will come down on them like a load of bricks > destroying their work via patent/copyright/trademark/other lawsuits.) Different > versions of .NET (version 1.0 compared with 1.1) are incompatible with each > other. My company has run into problems sometimes installing the framework and > getting them to work well. Each time Microsoft releases a different .NET > framework (read API), you'll have to completely re-engineer your applications > and get your clients to download yet another 20 Megabyte run-time. Do you enjoy > life on the bleeding edge? > > VB6 has the virtue of simplicity and a large, solid existing code-base to draw > upon. It is well-known. Many volunteers (like those in this newsgroup) will take > the time to help you if you show willingness to learn and regular, decent > manners. There are cases where a Web Service will be easier to write in ..NET, > but there are many many cases where, in my judgement, more commonly needed > solutions are /easier/ to deliver in VB6. Obviously, I disagree with the > assertion that it's "faster to develop in .NET". > > If you are looking to be employed in the near future in the corporate world, > you'll probably be compelled to slave under .NET. Otherwise, you will be better > off learning and using VB6. VB6 is simple yet capable, it's reasonably fast, it > /works/ and it doesn't require tons of RAM. > > Some of the differences between .NET and VB6: > * Radically different APIs > * .NET has better error handling, in some ways - but does nothing you can't > already accomplish in VB6 - but it may not be as pretty. > * .NET is a memory hog in my view. The IDE is big and slow, too. It takes a > great deal of disk space. Don't install it on an old computer or it won't be > useable, whereas VB6 may do quite well. > * .NET provides for inheritence, VB6 does not. Inheritence can be complex and > easily misused by beginners. > * .NET has better garbage collection than VB6, but this isn't much of an issue > for beginners. Conversely, .NET prevents you from freeing memory when /you/ want > it freed up. > * .NET provides better multithreading than VB6, which generally is "stuck" in > Apartment threading. This won't be any issue at all for a beginner, in fact, you > might want to stay completely away from threads at the very beginning. > * .NET applications start slow because they seem to require a lot more > initialization. Once they get up, they seem to run ok. > * It may be harder to buy a copy of VB6 than it is to buy a copy of .NET. > * VB6 is stable and won't be changing much. .NET is /still/ fluid and you can > expect even more change. > * VB6 is very like VBA and VBScript - if you've got MS Office '97 or 2000 or > 2003, the VB6 language is just like the Office automation you already have. You > could even conceivably use MS Word or MS Excel or MS Access to help learn VB6. > * In .NET, you can't use the controls that work for prior versions of VB. If you > need to use COM components, you're going to have to use an additional layer to > access them. Conversely, VB6 can't use .NET assemblies whatsoever. (No loss.) > > I hope this provides a more objective evaluation on which to base your decision > than the prior posts that are the moral equivalent of "doood, like, yu know, > .NET is just kewl! And, like, dood, those VB6 guys are all loosers, okaaay?" > > Finally, if you must go the .NET route, you've got to consider whether in fact > you should use C# or VB.NET. If you must go .NET, give C++ some serious > consideration - because for experts, it is a better more powerful language than > C# and VB.NET, especially given it's 100% compliance with the STL. If you're not > willing to invest in C++, then maybe you /should/ give VB6 or Delphi some > /serious/ consideration. > _______________________ > Michael B. Johnson
From: CadAd on 15 Jun 2005 15:04 Thank you all for your input. It is very helpful. Scott "Tony Proctor" <tony_proctor(a)aimtechnology_NoMoreSPAM_.com> wrote in message news:d8pgbh$73t$1(a)reader01.news.esat.net... >I would add a bit to the section on ".NET has better garbage collection >than > VB6" Michael. The whole .Net garbage collection scheme seems to revolve > around the idea that it's only memory that's being disposed of, or > reclaimed. Within this limitation, it works well and is more efficient > that > the referenced-counted COM scheme. However, as soon as you have other > types > of resource that should be released on object destruction (e.g. locks, > kernel objects, channels, visual elements such as hourglass cursors, etc) > then the non-deterministic nature of that destruction means such classes > may > no longer function reliably. The issue of "deterministic finalisation" is > one I hope .Net will address properly at some point. > > Tony Proctor > > "Michael B. Johnson" <mjohnson(a)veribox.net> wrote in message > news:35d0b1pgh85seku23s3c36fumjnglnjmcf(a)4ax.com... >> On Tue, 14 Jun 2005 17:01:59 -0400, "CadAd" >> <Harmon.Scott_RemovýThýs_(a)BETADesign.com> wrote: >> >> >What is the difference between Visual Basic 6.0 and Visual Basic .Net? > I'm >> >looking to get started in Visual Basic and don't understand? >> >> With everyone else piling on behind .NET, let me give you an alternative > view. >> >> Historical Context: The .NET language is a significantly changed API from > the >> VB6 environment - Microsoft ripped the rug out from under those of us >> who, >> through hard work, helped it get where it is today. This is hardly the > first >> time they've done that. Since this is a clear pattern, I can hardly > recommend >> you invest your time, sweat and tears into something that is only going >> to >> change radically in 5 years, perhaps far /less/. Microsoft is working > overtime >> to compel people into a subscription model of software, away from >> software >> licensing because this way they can ensure a higher barrier-to-market, as > well >> as increase revenues. The fact that this is at the expense of their > customer and >> their customer's security is of no consequence to the Microsoft > Corporation and >> their board. By investing in .NET, you help perpetuate this and aid its > spread. >> I think that in the long run, Microsoft is going to lose to Open Source >> software. >> >> Technical Info: .NET has a number of concepts that can be harder for a > beginner >> to absorb, such as overloading, polymorphism. However, if you know C++ or > Java, >> these will comfortable, familiar concepts. The .NET API, being >> proprietary > and >> closed, is going to be incompatible with anything else you'll ever work > on - >> it's been intentionally designed by Microsoft to be that way so they can > call it >> their own intellectual property. (There is an open-source product called > "Mono" >> that many would say would allow .NET apps to run on the Linux operating > system, >> but my view is that Microsoft will come down on them like a load of >> bricks >> destroying their work via patent/copyright/trademark/other lawsuits.) > Different >> versions of .NET (version 1.0 compared with 1.1) are incompatible with > each >> other. My company has run into problems sometimes installing the >> framework > and >> getting them to work well. Each time Microsoft releases a different .NET >> framework (read API), you'll have to completely re-engineer your > applications >> and get your clients to download yet another 20 Megabyte run-time. Do you > enjoy >> life on the bleeding edge? >> >> VB6 has the virtue of simplicity and a large, solid existing code-base to > draw >> upon. It is well-known. Many volunteers (like those in this newsgroup) > will take >> the time to help you if you show willingness to learn and regular, decent >> manners. There are cases where a Web Service will be easier to write in > .NET, >> but there are many many cases where, in my judgement, more commonly >> needed >> solutions are /easier/ to deliver in VB6. Obviously, I disagree with the >> assertion that it's "faster to develop in .NET". >> >> If you are looking to be employed in the near future in the corporate > world, >> you'll probably be compelled to slave under .NET. Otherwise, you will be > better >> off learning and using VB6. VB6 is simple yet capable, it's reasonably > fast, it >> /works/ and it doesn't require tons of RAM. >> >> Some of the differences between .NET and VB6: >> * Radically different APIs >> * .NET has better error handling, in some ways - but does nothing you > can't >> already accomplish in VB6 - but it may not be as pretty. >> * .NET is a memory hog in my view. The IDE is big and slow, too. It takes > a >> great deal of disk space. Don't install it on an old computer or it won't > be >> useable, whereas VB6 may do quite well. >> * .NET provides for inheritence, VB6 does not. Inheritence can be complex > and >> easily misused by beginners. >> * .NET has better garbage collection than VB6, but this isn't much of an > issue >> for beginners. Conversely, .NET prevents you from freeing memory when > /you/ want >> it freed up. >> * .NET provides better multithreading than VB6, which generally is >> "stuck" > in >> Apartment threading. This won't be any issue at all for a beginner, in > fact, you >> might want to stay completely away from threads at the very beginning. >> * .NET applications start slow because they seem to require a lot more >> initialization. Once they get up, they seem to run ok. >> * It may be harder to buy a copy of VB6 than it is to buy a copy of .NET. >> * VB6 is stable and won't be changing much. .NET is /still/ fluid and you > can >> expect even more change. >> * VB6 is very like VBA and VBScript - if you've got MS Office '97 or 2000 > or >> 2003, the VB6 language is just like the Office automation you already > have. You >> could even conceivably use MS Word or MS Excel or MS Access to help learn > VB6. >> * In .NET, you can't use the controls that work for prior versions of VB. > If you >> need to use COM components, you're going to have to use an additional > layer to >> access them. Conversely, VB6 can't use .NET assemblies whatsoever. (No > loss.) >> >> I hope this provides a more objective evaluation on which to base your > decision >> than the prior posts that are the moral equivalent of "doood, like, yu > know, >> .NET is just kewl! And, like, dood, those VB6 guys are all loosers, > okaaay?" >> >> Finally, if you must go the .NET route, you've got to consider whether in > fact >> you should use C# or VB.NET. If you must go .NET, give C++ some serious >> consideration - because for experts, it is a better more powerful >> language > than >> C# and VB.NET, especially given it's 100% compliance with the STL. If > you're not >> willing to invest in C++, then maybe you /should/ give VB6 or Delphi some >> /serious/ consideration. >> _______________________ >> Michael B. Johnson > >
From: Frank Adam on 15 Jun 2005 17:59 On Wed, 15 Jun 2005 20:50:08 +0100, Richard Cole <ispcrco(a)hotmail.com> wrote: >On Tue, 14 Jun 2005 17:01:59 -0400, "CadAd" ><Harmon.Scott_RemovýThýs_(a)BETADesign.com> wrote: > >>What is the difference between Visual Basic 6.0 and Visual Basic .Net? I'm >>looking to get started in Visual Basic and don't understand? > >Scott > >I work in VB6 at work & .NET (usually embedded) at home. > >They are 2 different languages based around the an old language (let's for >the sake of argument call it Dartmouth BASIC), I suppose a bit like most >European languages are Latin based, but however there are multiple >extensions to basic BASIC in both languages. > >VB6 is simpler to learn for the beginner but .NET is probably the way to go >because it has a future (assuming MS ignore the 'keep supporting VB6' > LOL. When COM hit the dev PCs it was also "the future", remember ? Just how many futures can our old brains take !? ;-) The 2005 beta certainly looks and feels ok now. If only i could get my head around what's where in the frigging class trees, i'd be rocking. It's a struggle to hunt down stuff, the model is just a bit too vast for anyone to just jump in and start producing, IME & IMO. Time will probably cure that though. To think that we used to joke about "Universe" being the base class of everything.. well, dotnet has gone and done it. :) -- Regards, Frank
From: Tom Shelton on 15 Jun 2005 18:13 In article <d8pgbh$73t$1(a)reader01.news.esat.net>, Tony Proctor wrote: > I would add a bit to the section on ".NET has better garbage collection than > VB6" Michael. The whole .Net garbage collection scheme seems to revolve > around the idea that it's only memory that's being disposed of, or > reclaimed. Within this limitation, it works well and is more efficient that > the referenced-counted COM scheme. However, as soon as you have other types > of resource that should be released on object destruction (e.g. locks, > kernel objects, channels, visual elements such as hourglass cursors, etc) > then the non-deterministic nature of that destruction means such classes may > no longer function reliably. The issue of "deterministic finalisation" is > one I hope .Net will address properly at some point. > > Tony Proctor Tony, While I agree that the loss of deterministic finalization is a bit of a bummer, it is not the end of the world. There are well defined patterns for dealing with such resources - implementing IDisposable. By implementing this interface, you give a hint to developers that they need to deal with this class in a special manner. Basically, calling Dispose on this object before it is not longer needed. Typically, in VB.NET (current) it looks like: Dim disposableObject As New MakeSureYouKillMe () Try disposableObject.DoCoolStuff () Finally disposableObject.Dispose () End Try Obviously, this isn't as clean or as safe as the deterministic clean up of VB6's ref counted objects. In C# and VB.NET 2005, the syntax is much cleaner: Using (disposableObject As New MakeSureYouKillMe ()) disposableObject.DoCoolStuff () End Using using (MakeSureYouKillMe disposableObject = new MakeSureYouKillMe ()) { disposableObject.DoCoolStuff (); } This is essentially syntactic sugar for the above try/finally block since it behaves in the same manner. The objects dispose method is called when you leave the block - even if by an exception. -- Tom Shelton
From: Tony Proctor on 16 Jun 2005 05:10
The reference-counted objects is really a consequence of COM's object model Tom. You said "VB6's" below. Anyway, I get your point, but certain resource elements need that "clean and safe deterministic clean up" that's not really there. It may not be a big issue on its own, but it is another obstacle to portability that may require a re-assessment of a previous design, and so needs a mention in lists such as the one I responded to. Tony Proctor "Tom Shelton" <tom(a)YOUKNOWTHEDRILLmtogden.com> wrote in message news:DK1se.2466$jA6.25169(a)news.uswest.net... > In article <d8pgbh$73t$1(a)reader01.news.esat.net>, Tony Proctor wrote: > > I would add a bit to the section on ".NET has better garbage collection than > > VB6" Michael. The whole .Net garbage collection scheme seems to revolve > > around the idea that it's only memory that's being disposed of, or > > reclaimed. Within this limitation, it works well and is more efficient that > > the referenced-counted COM scheme. However, as soon as you have other types > > of resource that should be released on object destruction (e.g. locks, > > kernel objects, channels, visual elements such as hourglass cursors, etc) > > then the non-deterministic nature of that destruction means such classes may > > no longer function reliably. The issue of "deterministic finalisation" is > > one I hope .Net will address properly at some point. > > > > Tony Proctor > > Tony, > > While I agree that the loss of deterministic finalization is a bit of a > bummer, it is not the end of the world. There are well defined patterns > for dealing with such resources - implementing IDisposable. By > implementing this interface, you give a hint to developers that they > need to deal with this class in a special manner. Basically, calling > Dispose on this object before it is not longer needed. Typically, in > VB.NET (current) it looks like: > > Dim disposableObject As New MakeSureYouKillMe () > > Try > > disposableObject.DoCoolStuff () > Finally > disposableObject.Dispose () > End Try > > Obviously, this isn't as clean or as safe as the deterministic clean up > of VB6's ref counted objects. In C# and VB.NET 2005, the syntax is much > cleaner: > > Using (disposableObject As New MakeSureYouKillMe ()) > disposableObject.DoCoolStuff () > End Using > > > using (MakeSureYouKillMe disposableObject = new MakeSureYouKillMe ()) > { > disposableObject.DoCoolStuff (); > } > > This is essentially syntactic sugar for the above try/finally block > since it behaves in the same manner. The objects dispose method is > called when you leave the block - even if by an exception. > > -- > Tom Shelton |