Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
44  2027 
I disagree. I have been using VB since the first beta was released more than
12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!
I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
I disagree too, VB is not ruined. If you now how to use the new features
(e.g. OO), you can write faster and produce better code in VB.NET.
--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
"BGD" <tb******@hotmail.com> schreef in bericht
news:%2***************@tk2msftngp13.phx.gbl... I disagree. I have been using VB since the first beta was released more
than 12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!
I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Sorry Mate, I don't agree. There's a lot of stuff that you can do in VB.net
with a single line of code that would take you a long time to achieve in VB6
(e.g. Inheritance)
I'll admit, it's a bit trickier to handle forms and stuff because there's no
default instances anymore (there's nothing to stop you creating a shared
default instance though), but for the most part VB.net is a lot more
powerful, if a bit daunting because of the size of the framework.
I don't think you should look at it from the point of view that Microsoft
have ruined VB. In my humble opinion VB.net is *not* the next version of
VB6 - its a totally new language which just happens to share some syntax
with VB6.
Thanks for your thoughts though.
Trev.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Truble <an*******@discussions.microsoft.com> wrote: Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
You being able to write a VB6 app twice as fast as you can write the
equivalent in VB.NET doesn't mean that VB.NET isn't as efficient - it
may well just mean that you're more proficient in VB6.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
It's obvious that you haven't explored VB.NET enough yet to see the
tremendous improvements to the language. Yes, it is true that you may have
to write more code than in the past, but you have so much more control over
applications and classes that this is well worth it.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Well, that's really the thing...MS didn't "convert" anything:
VB.NET is not VB 7, it's a whole new programming language that shares some
of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET is
vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl... Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Actually VB.Net IS VB7 check your install directory.
"Scott M." <s-***@BADSPAMsnet.net> wrote in message
news:uS*************@TK2MSFTNGP11.phx.gbl... Well, that's really the thing...MS didn't "convert" anything:
VB.NET is not VB 7, it's a whole new programming language that shares some
of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET
is vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl... Why use .NET when you're not forced to. Personally speaking I wish MS
had not bothered converting VB into VB.NET :)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
> Actually VB.Net IS VB7 check your install directory.
We all know that version numbers for major applications are nothing but a
marketing tool.
They could have called it ".Net Studio Version 1.0", but then they would
risk loosing the "Brand Name" of "Visual Studio"
The fact that it's called VB7 is trivial. Earlier versions of VB pretty much
had the same underpinnngs(ignoring the change from 16bit to 32bit). VB.Net
is a different product than VB6.
"solex" <so***@nowhere.com> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl... Actually VB.Net IS VB7 check your install directory.
"Scott M." <s-***@BADSPAMsnet.net> wrote in message
news:uS*************@TK2MSFTNGP11.phx.gbl... Well, that's really the thing...MS didn't "convert" anything:
VB.NET is not VB 7, it's a whole new programming language that shares
some of the coding constructs that VB 6 had.
ASP.NET is not "Classic ASP", the similarity in their names is about the
only thing they have in common.
VS.NET is not VS 7.0. While having some of the features of VS 6, VS.NET
is vastly improved and allows for a consitent approach to application
development.
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl... Why use .NET when you're not forced to. Personally speaking I wish MS
had not bothered converting VB into VB.NET :)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl...
> Visual Studio .NET is not more efficient to write than
> VB6. I can write a VB6 App at least twice as fast as
> in .NET. Why did Microsoft ruin the syntax advantage of
> VB6 in .NET?
And I can write a VB.NET or C# app twice as fast as I can in VB6. Why?
Other than the fact that they are both much more productive and the IDE
Rules? Well, because I haven't used VB6 in 2 years and I use C# and VB.NET
every day.
You can't make that statement fairly unless you know .NET thoroughly and if
you did, you wouldn't make that claim.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Can you show me some of your multi-threaded VB6 code? I remember it being a
nightmare. It's a breeze in VB.NET.
What about Windows Services? Can you show me some of those that you wrote?
I seem to remember having to run to C++ for those.
What about Intellisense, attirbutes, Deployment (I don't remember Regsrvr32
being a whole lot of fun)?....
I think you need to use VB.NET some more before you make such wild claims.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Unless you live in a communist country, you aren't forced to do anything,
let alone code in a specifc langauge.
VB.NET and C# are vastly superior to VB6 that's is silly to even argue
about. Only a VB6, 5, 4, 3, 2, 1 Programmer scared to learn something new
could make that claim!
"Adam" <ad**@nospam.com> wrote in message
news:un**************@tk2msftngp13.phx.gbl... Why use .NET when you're not forced to. Personally speaking I wish MS had
not bothered converting VB into VB.NET :)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Amen to that!
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Truble <an*******@discussions.microsoft.com> wrote: Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
You being able to write a VB6 app twice as fast as you can write the
equivalent in VB.NET doesn't mean that VB.NET isn't as efficient - it
may well just mean that you're more proficient in VB6.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
C# and VB.NET are virtually identical if Option Strict is on. Is your
VB.NET app compiled with Option Strict? Everythign I've read said the
differences aren't worth citing, but I'd be interested in finding out if
there are cases where they aren't? What type of app is it?
"BGD" <tb******@hotmail.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... I disagree. I have been using VB since the first beta was released more
than 12 years ago and I love the changes and the fact that it is now a true
object oriented language. I also program in Java, C++ and Delphi, and I
always wished that VB had the object oriented features that the other
languages did, and now it does!
I do most of my programming in C# now and it is a great language. In most
programs C# and VB.NET perform about the same, but I have some application
where C# clearly performs better. It is a matter of chosing the right
tool/language for the right project...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
I think that it is great - but I wish the package and deployment wizard was there.
There is even somthing better than this wizard: Setup Projects! Just add a
new Setup project to your solution, and you can get the same result as the
Package and Deployment wizard (only better :-).
--
Greetz,
Jan
__________________________________
Read my weblog: http://weblogs.asp.net/jan
"Scoooty" <an*******@discussions.microsoft.com> schreef in bericht
news:01**********************************@microsof t.com... I think that it is great - but I wish the package and deployment wizard
was there.
Yeah, the excellent P&DW.
With so big drawbacks that it can be used on simple projects only.
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
"Scoooty" <an*******@discussions.microsoft.com> wrote in message
news:01**********************************@microsof t.com... I think that it is great - but I wish the package and deployment wizard
was there.
Wait till homeland security kicks in ...
"William Ryan" <do********@comcast.nospam.net> wrote in message
news:eM**************@tk2msftngp13.phx.gbl... Unless you live in a communist country, you aren't forced to do anything,
let alone code in a specifc langauge.
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
Because you're proficient in VB6, and not in VB.NET?
Am I sensing a little resistance to change here?
Bad place to be in the technology business. :-)
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
..NET. (: and 1/10 th the size :-)
Roger
Sounds like we've got challenge on our hands (and too much time ;)
How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
2) It must be half the size of the .net version
I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl... Sounds like we've got challenge on our hands (and too much time ;)
How about a stupid wee challenge then? You write a *small* app in VB6 and
I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version
I'm counting the runtime.
I don't think these criteria ar harsh - after all, you claim that you can
write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.
HTH,
Roger
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than VB6.
You can't make a blanket statement like that about anything. But out of
curiosity, why would you say this? VB 6.0 was NEVER known for its
performance or efficiency. Why do you think that MS made most of their apps
in C not VB?
I can write a VB6 App that is at least twice as fast as .NET. (: and 1/10
th the size :-)
This is not a measure of efficiency. The reason VB 6.0 does not requre as
much coding is because it was HDING a lot of cumbersome code in the
background. In some cases, this was helpful (ie. you don't have to worry
about creating an instance of your startup form - VB did it for you). In
many other cases, this is a detrement. What if you wanted to alter the way
VB 6.0 does something that it was HIDING from you? Tough luck, you had to
deal with it.
I'll give you a simple example of this....
If you created a form and placed numerous controls on the form and then at
some point wrote a loop that would iterate over the form's Controls
collection....
The order that the controls would be looked at in the loop would be the
order in which you created them on the form (not their sequential placement
on the form, the sequence was based on what control was CREATED first,
second, third, etc.).
In many cases, developers would use this technique for validating user input
on the form. But it's not very nice if the first control validated is the
6th one down on the form.
In VB 6.0, once the Controls collection is populated, that's it, you can't
alter the sequence of them (unless you delete all the controls and re-create
them or make a control array out of them and re-sequence their Indexes).
In VB.NET all you have to do to change the sequence of the controls is to
look at the line of generated code that adds the controls to the controls
collection (Controls.Add control1, control2, etc.) and re-order the
sequence on that line!
This is but one small example of how, in VB.NET, their may be more code to
deal with, but in return, you get MUCH more control over what is happening
and therefore you can fine tune an application MUCH BETTER than you ever
could before, which results is MUCH BETTER performance.
Also, by having certain general housekeeping functions running in the .NET
Framework, rather than your application (ie. Garbage Collection), your
application doesn't have to have that code in it, which results in more
streamlined programs (the .NET Framework runs in a different thread from the
application you built).
Give .NET a chance. I am a former VB 6.0 / Classic ASP person and I felt
like you did for about 6 months until the "light bulb" went off in my head
and I "got it".
..NET is by leaps and bounds far superior in almost all respects to VB 6.0.
Scott M.
Roger
> Win98/ 64 meg, OK :-)
Shouldn't be too much a problem for a small App. VB6 will have an inital
advantage because of the smaller memory footprint, but once the .net has
been fully JITted, there shouldn't be much difference. Certinly not twice as
slow. I'm counting the runtime.
And what size are all the VB6 support files when you add them together?
(MSVBVM60.dll etc., etc.) Not as big as the .net framework, but imagine you
had to include all the different support files for simple tasks such as
network communication, database access, graphics, remoting etc. etc.
Granted, not all apps use these features, but it's nice to know that they're
already on a machine if you have to change your application to include them.
Why is everyone picking on Truble? I dont actually use VB6
but somebody's got to take his side.
Nobody's picking on Truble. I'm disagreeing with Truble's point of view ;)
Truble shouldn't make such bold statements without expecting someone else to
disagree and make their own bold statements ;)
Trev.
"Roger" <NO****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl... Sounds like we've got challenge on our hands (and too much time ;)
How about a stupid wee challenge then? You write a *small* app in VB6
and I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version
I'm counting the runtime.
I don't think these criteria ar harsh - after all, you claim that you
can write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.
HTH,
Roger
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl...
> Visual Studio .NET is not more efficient to write than
> VB6. I can write a VB6 App at least twice as fast as
> in .NET. Why did Microsoft ruin the syntax advantage of
> VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
Roger <NO****@hotmail.com> wrote: 1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version
I'm counting the runtime.
In that case, are you including the VB runtime and anything that links
against in turn? Are you including the operating system itself, and if
so how much of it? It would make sense to do so, given that a lot of
the .NET framework is a load of libraries which most applications won't
use. (Each application will use some of the framework, very few
applications will directly use most of it.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Roger" <NO****@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Codemonkey" <hu*********@hotmail.com> wrote in message
news:eh**************@tk2msftngp13.phx.gbl... Sounds like we've got challenge on our hands (and too much time ;)
How about a stupid wee challenge then? You write a *small* app in VB6
and I'll try and replicate it in VB .net.
For VB6 to be "better" than VB.net it must meet the following criteria:
1) It must demonstrate a clear performance advantage (i.e. > 20%)
Win98/ 64 meg, OK :-)
2) It must be half the size of the .net version
I'm counting the runtime.
The fact that you would say this clearly indicates that you don't yet fully
understand .NET. The .NET Framework (what you call the runtime) is quite
large, but it contains much of what you would have (in VB 6) had to build
into your application.
Now, in VB 6, when you build all that into your application, it would all
need to execute in the same process (thread) and that was always one of VB
6's biggest drawbacks.
The .NET Framework runs in its own process and allows your application to
run in its own process, so it can execute faster. The fact that the
Framework is 24MB isn't relevant, since much of it is the vast class
libraries that are defined there. By the way, you wouldn't have references
to all those libraries anyway, so you can't count the full 24MB of the
Framework in your little experiment. You'd have to find a way to determine
the size of the libraries that you are using.
I don't think these criteria ar harsh - after all, you claim that you
can write one that is twice as fast and 1/10th the size!
Best Regards,
Trev.
Why is everyone picking on Truble? I dont actually use VB6 but somebody's
got to take his side.
HTH,
Roger
"Roger" <NO****@hotmail.com> wrote in message
news:ul**************@TK2MSFTNGP12.phx.gbl...
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl...
> Visual Studio .NET is not more efficient to write than
> VB6. I can write a VB6 App at least twice as fast as
> in .NET. Why did Microsoft ruin the syntax advantage of
> VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
Scott M. <s-***@BADSPAMsnet.net> wrote: Now, in VB 6, when you build all that into your application, it would all
need to execute in the same process (thread) and that was always one of VB
6's biggest drawbacks.
<snip>
The .NET Framework runs in its own process and allows your application to
run in its own process, so it can execute faster.
Hang on a sec - you need to be very clear on the difference between a
process and a thread. They're quite different things...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Quite simple: They didn't.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
You are correct that one process can be running many threads within it. My
point was that since much of the "grunt" work of a .NET application is done
in its own thread, the main application is not encumbered by the Framework
doing its thing and in a VB 6 application, you would have everything
happening in one thread.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m... Scott M. <s-***@BADSPAMsnet.net> wrote:
Now, in VB 6, when you build all that into your application, it would
all need to execute in the same process (thread) and that was always one of
VB 6's biggest drawbacks.
<snip>
The .NET Framework runs in its own process and allows your application
to run in its own process, so it can execute faster.
Hang on a sec - you need to be very clear on the difference between a
process and a thread. They're quite different things...
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Scott M. <s-***@BADSPAMsnet.net> wrote: You are correct that one process can be running many threads within it. My
point was that since much of the "grunt" work of a .NET application is done
in its own thread, the main application is not encumbered by the Framework
doing its thing and in a VB 6 application, you would have everything
happening in one thread.
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.
If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Scott M. <s-***@BADSPAMsnet.net> wrote: You are correct that one process can be running many threads within it.
My point was that since much of the "grunt" work of a .NET application is
done in its own thread, the main application is not encumbered by the
Framework doing its thing and in a VB 6 application, you would have everything
happening in one thread.
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
Well no, not really. The GC for example runs within the framework and in a
different thread than the .NET application it services. This is beneficial
because when the GC kicks in to do its thing, it does not impede the thread
the main application is running in. This is one of the reasons not to
invoke the GC directly from within a .NET application. If you do, you will
bring the GC's processing into the main application's thread and possibly
reduce its performance.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.
If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Scott M. <s-***@BADSPAMsnet.net> wrote: You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
Well no, not really. The GC for example runs within the framework and in a
different thread than the .NET application it services.
Well, potentially - depending on machine configuration - but that's
very different from giving the impression that the *whole* framework
runs in a different thread. There are *lots* of threads (potentially)
some of which may be running your own code, some of which may be
running "purely framework" code - but you're unlikely to get very far
in *any* thread without running "framework code".
Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
One a single CPU, it makes a difference.
Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception
"Scott M." <s-***@BADSPAMsnet.net> wrote in message
news:#c**************@TK2MSFTNGP11.phx.gbl...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Scott M. <s-***@BADSPAMsnet.net> wrote: You are correct that one process can be running many threads within
it. My point was that since much of the "grunt" work of a .NET application is done in its own thread, the main application is not encumbered by the Framework doing its thing and in a VB 6 application, you would have everything
happening in one thread.
You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
Well no, not really. The GC for example runs within the framework and in
a different thread than the .NET application it services. This is
beneficial because when the GC kicks in to do its thing, it does not impede the
thread the main application is running in. This is one of the reasons not to
invoke the GC directly from within a .NET application. If you do, you
will bring the GC's processing into the main application's thread and possibly
reduce its performance.
*All* the threads in an app are running "the framework", other than
those which entirely run unmanaged code.
If you mean that the GUI thread is easily separated from worker
threads, I agree with you - but that's a very different matter.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> Quite simple: They didn't.
Exactly. Microsoft didn't ruin VB6 at all. VB6 hasn't changed, and most
likley will not change - it will always be VB6 ;) If you don't like VB.net,
then Microsoft hasn't stopped you from using VB6 if you want to.
"Jerry Ham" <Ye********************@Not.com> wrote in message
news:Of**************@tk2msftngp13.phx.gbl... Quite simple: They didn't.
"Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
<di********@discussion.microsoft.com> wrote: One a single CPU, it makes a difference.
Why do so many people think Threads = concurrency on a single proc?`
Probably the worlds largest misconception
Well, threads *do* make it easy *sort* of do two things at once, so
long as one of them is "waiting for something else to happen". Even on
a single processor, correct use of threads is enormously important.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Scott M. <s-***@BADSPAMsnet.net> wrote: You give the impression that "the framework" is running in one thread,
and the application is done in another, why is entirely inaccurate.
Well no, not really. The GC for example runs within the framework and
in a different thread than the .NET application it services.
Well, potentially - depending on machine configuration - but that's
very different from giving the impression that the *whole* framework
runs in a different thread. There are *lots* of threads (potentially)
some of which may be running your own code, some of which may be
running "purely framework" code - but you're unlikely to get very far
in *any* thread without running "framework code".
Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app
to work, but you also had to write additional code for "housekeeping"
purposes and all that code ran in a single thread (usually).
In .NET, there is a very distinct separation between what you have to write
and what is already written into the Framework. And, as is the case with the
GC, you have the ability to put different actions into different threads.
This is a very simple point, but you've been "picking" at the definition of
process and thread, which is useful to understand but not the point of the
original post.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Scott M. <s-***@BADSPAMsnet.net> wrote: Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your app
to work, but you also had to write additional code for "housekeeping"
purposes and all that code ran in a single thread (usually).
In .NET, there is a very distinct separation between what you have to write
and what is already written into the Framework. And, as is the case with the
GC, you have the ability to put different actions into different threads.
This is a very simple point, but you've been "picking" at the definition of
process and thread, which is useful to understand but not the point of the
original post.
It strikes me you've got three points here:
1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand
All those three things are true, but you seem to be conflating them
when they are very separate things.
(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
One a single CPU does it bloody matter , its stop the world anyway. Geez.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m... Scott M. <s-***@BADSPAMsnet.net> wrote: Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your
app to work, but you also had to write additional code for "housekeeping"
purposes and all that code ran in a single thread (usually).
In .NET, there is a very distinct separation between what you have to
write and what is already written into the Framework. And, as is the case with
the GC, you have the ability to put different actions into different
threads.
This is a very simple point, but you've been "picking" at the definition
of process and thread, which is useful to understand but not the point of
the original post.
It strikes me you've got three points here:
1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand
All those three things are true, but you seem to be conflating them
when they are very separate things.
(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon, you're right in what you say, but again, you are missing the point.
Look at the subject of this thread. I'm trying to point out the advantages
of VB.NET over VB 6.0.
In today's world, it is not uncommon to work with more than one processor or
HyperThreaded processors. A VB 6.0 app would have a hard time taking
advantage of this. In .NET, this can be leveraged and is certainly ONE of
the many advantages of VB.NET.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m... Scott M. <s-***@BADSPAMsnet.net> wrote: Basically I'm not at all sure what your argument about comparing .NET
to VB is here, because it seems somewhat confused.
Jon, my point is very simple, but your too close to the fire to see the
flame. In a VB 6 application, you not only had to write code for your
app to work, but you also had to write additional code for "housekeeping"
purposes and all that code ran in a single thread (usually).
In .NET, there is a very distinct separation between what you have to
write and what is already written into the Framework. And, as is the case with
the GC, you have the ability to put different actions into different
threads.
This is a very simple point, but you've been "picking" at the definition
of process and thread, which is useful to understand but not the point of
the original post.
It strikes me you've got three points here:
1) .NET provides good multi-threading capabilities
2) .NET gives a good garbage collection system
3) .NET has a very extensive library which does a lot of things you may
have had to write yourself beforehand
All those three things are true, but you seem to be conflating them
when they are very separate things.
(In terms of GC occurring in separate threads, I believe the "normal"
CLR actually has a stop-the-world GC - it's finalization that occurs in
another thread. A different CLR typically used on multi-processor
machines has a concurrent GC.)
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Scott M. <s-***@BADSPAMsnet.net> wrote: Jon, you're right in what you say, but again, you are missing the point.
Look at the subject of this thread. I'm trying to point out the advantages
of VB.NET over VB 6.0.
Yes, but you're not being at *all* clear about them. Please look over
your posts again - if I can't see what you mean, and I know a fair bit
about .NET, how is someone who *doesn't* know about .NET meant to
understand you?
In today's world, it is not uncommon to work with more than one processor or
HyperThreaded processors. A VB 6.0 app would have a hard time taking
advantage of this. In .NET, this can be leveraged and is certainly ONE of
the many advantages of VB.NET.
Yup, and I never said that multi-threading *wasn't* a significant
advantage over VB6. It's just that the way you've put it, saying that
the framework runs in one thread and the app in another, is completely
misleading.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
On Fri, 5 Dec 2003 17:39:46 -0000, Codemonkey wrote: I'll admit, it's a bit trickier to handle forms and stuff because there's no
default instances anymore (there's nothing to stop you creating a shared
This has been addressed in Whidbey with the addition of the "My"
namespaces.
In my humble opinion VB.net is *not* the next version of
VB6 - its a totally new language which just happens to share some syntax
with VB6.
Totally agree
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
> This has been addressed in Whidbey with the addition of the "My" namespaces.
I've heard rumours about "My" and am a bit skeptical so far. Sorry for going
a bit off topic, but:
1) Why is it only available to VB and not C#? Surely Microsoft doesn't think
us VB programmers are dumber than the C# equivelent ;)
2) Will the "My" namespace be customizable? I'd like to be able to fill the
"My" namespace with things that I personally would use the most, not what
Microsoft thinks I use the most.
Trev.
"Chris Dunaway" <dunawayc@_lunchmeat_sbcglobal.net> wrote in message
news:1u*******************************@40tude.net. .. On Fri, 5 Dec 2003 17:39:46 -0000, Codemonkey wrote:
I'll admit, it's a bit trickier to handle forms and stuff because
there's no default instances anymore (there's nothing to stop you creating a shared
This has been addressed in Whidbey with the addition of the "My"
namespaces.
In my humble opinion VB.net is *not* the next version of
VB6 - its a totally new language which just happens to share some syntax
with VB6.
Totally agree
--
Chris
To send me an E-mail, remove the underscores and lunchmeat from my E-Mail
address.
"Roger" <NO****@hotmail.com> wrote in message news:<ul**************@TK2MSFTNGP12.phx.gbl>... "Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
I wouldn't bet on that. For instance, strings are used all the time
in VB. The VB6 String type is immutable, meaning you can't change it,
let alone append to it. So something like...
for i=0 to 1000
string1 = string1 & string2
next i
is very inefficient since your going to create and destroy 1000 string
variables on every assignment. In contrast, .Net's string types can
grow. .Net also contains a special class called StringBuilder in
which you can even specify an initial size so as to minimize the
number of dynamic memory allocations. In addition, the incredibly
inefficient Variant type has been removed which many VB programmers
mistakeably use.
Most importantly, the thing to remember here is that computers are
running a helk of a lot faster these days since VB6 was unveiled.
Efficiency is not so much a factor these days as stability and
security have recently become. Although VB6 is a great system, it
really needed to be updated. Once a developer finds himself having to
visit the WinAPI just to paint to a window or handle mouse wheel
events, the usability and ease of use of VB sharply diminishes. At
which time, I usually find myself creating an MFC project.
"Dan" <da****@sourcekid.com> wrote in message
news:cb**************************@posting.google.c om... "Roger" <NO****@hotmail.com> wrote in message
news:<ul**************@TK2MSFTNGP12.phx.gbl>... "Truble" <an*******@discussions.microsoft.com> wrote in message
news:06****************************@phx.gbl... Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
With some editing, the poster is correct:
Visual Studio .NET is not more efficient than
VB6. I can write a VB6 App that is at least twice as fast as
.NET. (: and 1/10 th the size :-)
Roger
I wouldn't bet on that. For instance, strings are used all the time
in VB. The VB6 String type is immutable, meaning you can't change it,
let alone append to it. So something like...
for i=0 to 1000
string1 = string1 & string2
next i
is very inefficient since your going to create and destroy 1000 string
variables on every assignment.
CORRECT!
In contrast, .Net's string types can grow.
INCORRECT! In. .NET a String is also immutable (as it was in VB 6.0).
Strings are Reference Types and therefore managed on the heap, unlike the
primitive data types (integer, date, boolean, decimal, etc.) which are Value
Types and managed on the Stack. However, .NET offers the StringBuilder to
use in circumstances like the one you describe above.
.Net also contains a special class called StringBuilder in
which you can even specify an initial size so as to minimize the
number of dynamic memory allocations. In addition, the incredibly
inefficient Variant type has been removed which many VB programmers
mistakeably use.
Most importantly, the thing to remember here is that computers are
running a helk of a lot faster these days since VB6 was unveiled.
Efficiency is not so much a factor these days as stability and
security have recently become. Although VB6 is a great system, it
really needed to be updated. Once a developer finds himself having to
visit the WinAPI just to paint to a window or handle mouse wheel
events, the usability and ease of use of VB sharply diminishes. At
which time, I usually find myself creating an MFC project. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Truble |
last post by:
Visual Studio .NET is not more efficient to write than
VB6. I can write a VB6 App at least twice as fast as
in .NET. Why did Microsoft ruin the syntax advantage of
VB6 in .NET?
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
