Can Someone Change My Mind About .NET?

Mike P. <an*******@discussions.microsoft.com> wrote:

I come from the world of C++ programming, and I'm used to writing
programs that are actually executed by the CPU, and that run with
some semblance of performance. I have taken the time to explore this
.NET thing, and found that not only do .NET applications run
extremely s-l-o-w-l-y, but the various .NET languages amount to
nothing more than interpreted script languages. It is the common
language run-time that actually executes your implementation.
1) They're not interpreted. They're JIT-compiled. This is a huge
difference.
2) They don't run extremely slowly. What makes you think they do?
Certainly Windows Forms take a while to start up, and the
performance of those isn't as good as it could be - but that's
not true of the whole of .NET. What in particular are you finding
is running very slowly?
I deeply resent this move toward "managed" code, and I'm disappointed
that the new Avalon user interface system in Longhorn will use only
.NET facilities. Is this an indication that subsequent versions of
Windows will allow ONLY interpreted applications?
Certainliy not, as .NET isn't interpreted to start with.
Does anyone else share my feelings about this situation? Can anyone
put forth some reason that I should feel better about embracing .NET,
when it is so alien to me?

My guess is that you're trying to write .NET code as if it were normal
C++, rather than embracing .NET idioms. Writing code as if it were for
another platform is always going to give you nasty problems such as
performance and reliability.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #2

Mike P. <an*******@discussions.microsoft.com> wrote:

I come from the world of C++ programming, and I'm used to writing
programs that are actually executed by the CPU, and that run with
some semblance of performance. I have taken the time to explore this
.NET thing, and found that not only do .NET applications run
extremely s-l-o-w-l-y, but the various .NET languages amount to
nothing more than interpreted script languages. It is the common
language run-time that actually executes your implementation.
1) They're not interpreted. They're JIT-compiled. This is a huge
difference.
2) They don't run extremely slowly. What makes you think they do?
Certainly Windows Forms take a while to start up, and the
performance of those isn't as good as it could be - but that's
not true of the whole of .NET. What in particular are you finding
is running very slowly?
I deeply resent this move toward "managed" code, and I'm disappointed
that the new Avalon user interface system in Longhorn will use only
.NET facilities. Is this an indication that subsequent versions of
Windows will allow ONLY interpreted applications?
Certainliy not, as .NET isn't interpreted to start with.
Does anyone else share my feelings about this situation? Can anyone
put forth some reason that I should feel better about embracing .NET,
when it is so alien to me?

Jul 21 '05 #3

Mike P.

Jon

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote an HTTP proxy server in Visual Basic .NET. Then I wrote an identical program in MFC. The MFC program ran many times faster. When I tested them both with Internet Explorer as the client, I saw no noticeable change in IE's performance when using the MFC proxy, while there was a serious degredation in performance with the .NET proxy

And what about the fact that you can view the code for any program just by using the disassembler utility? Am I forced to buy a multi-thousand dollar obfuscator package if I want to make a commercial app

Thank you

Jul 21 '05 #4

Mike P.

Jul 21 '05 #5

Mike P. <an*******@discussions.microsoft.com> wrote:

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote
an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested
them both with Internet Explorer as the client, I saw no noticeable
change in IE's performance when using the MFC proxy, while there was
a serious degredation in performance with the .NET proxy.
Without seeing your code, I can't say what's wrong - but chances are
it's in your code rather than in .NET itself. One thing to check to
start with - do you have Option Strict On at the top of all your code?
If not, some or all method calls will be performed with reflection,
which *is* horribly slow - and unnecessary.

It shouldn't come as a surprise though - you can't expect to
immediately write the same quality of code on a new platform as on one
you're intimately familiar with. It takes a little while to get back up
to speed. That's not a reflection of the platform itself, however.

If this proxy is small enough to post, we could see if we can see
what's wrong. I may well not be able to contribute very much myself,
being a C# programmer rather than a VB.NET programmer. I would be able
to spot *some* potential flaws, but not all. Fortunately, there are
plenty of very competent VB.NET users in this newsgroup who could help,
I'm sure.
And what about the fact that you can view the code for any program
just by using the disassembler utility? Am I forced to buy a
multi-thousand dollar obfuscator package if I want to make a
commercial app?

See http://www.pobox.com/~skeet/csharp/faq/#obfuscation for reasons why
I think obfuscation is sufficient. There are already free obfuscators
around (I believe) and my guess is that more and more of them will
spring up, and get better and better - this is what has happened in the
Java space, certainly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #6

Mike P. <an*******@discussions.microsoft.com> wrote:

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote
an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested
them both with Internet Explorer as the client, I saw no noticeable
change in IE's performance when using the MFC proxy, while there was
a serious degredation in performance with the .NET proxy.
Without seeing your code, I can't say what's wrong - but chances are
it's in your code rather than in .NET itself. One thing to check to
start with - do you have Option Strict On at the top of all your code?
If not, some or all method calls will be performed with reflection,
which *is* horribly slow - and unnecessary.

It shouldn't come as a surprise though - you can't expect to
immediately write the same quality of code on a new platform as on one
you're intimately familiar with. It takes a little while to get back up
to speed. That's not a reflection of the platform itself, however.

If this proxy is small enough to post, we could see if we can see
what's wrong. I may well not be able to contribute very much myself,
being a C# programmer rather than a VB.NET programmer. I would be able
to spot *some* potential flaws, but not all. Fortunately, there are
plenty of very competent VB.NET users in this newsgroup who could help,
I'm sure.
And what about the fact that you can view the code for any program
just by using the disassembler utility? Am I forced to buy a
multi-thousand dollar obfuscator package if I want to make a
commercial app?

Jul 21 '05 #7

> I come from the world of C++ programming, and I'm used to writing programs
that

are actually executed by the CPU, and that run with some semblance of performance. I have taken the time to explore this .NET thing, and found that not only do .NETapplications run extremely s-l-o-w-l-y, but the various .NET languages amount to nothing more than interpreted script languages. It is the common language run-time that actually executes your implementation. Tests with C# here suggests that we have almost the same speed of our MFC
programs.
The JIT compiler needs time to compile the interediate language into native
cpu code, and that explains why the .NET program starts up slower, but if
you create the program with .NET design phylisophy and not MFC like
phylisophy, then it should reach the same speeds.
I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user interface system in Longhorn will use only .NET facilities. Is this an indication that subsequent versions of Windows will allow ONLY interpreted applications?
The biggest advantage if .NET is that it will improve security issuses since
the security is integrated into the code.
An OS based on .NET code will be far less vunerable for the current types of
worms and virusses. And I think the rest of the world would prefer an little
bit more secure windows that crashes less than a incredible fast computer.

Also note that, .NET programs will run faster compared to conventional
executable in the future since the Windows core is beeing replaced by pure
..NET technology.
It is the transition between managed and unmanaged that takes lots of time.
So it explains why .NET programs now are still a little bit slower since the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.
Does anyone else share my feelings about this situation? Can anyone put forth some reason that I should feel better about embracing .NET, when it is so alien to me?

I understand the you completely that itis very confusing learning to program
in a .NET way, but you have to trust all the people here that it is the way
to go for future operating systems and programming languages. But it has a
steep learning curve as the technology matures.

Jul 21 '05 #8

> I come from the world of C++ programming, and I'm used to writing programs
that

are actually executed by the CPU, and that run with some semblance of performance. I have taken the time to explore this .NET thing, and found that not only do .NETapplications run extremely s-l-o-w-l-y, but the various .NET languages amount to nothing more than interpreted script languages. It is the common language run-time that actually executes your implementation. Tests with C# here suggests that we have almost the same speed of our MFC
programs.
The JIT compiler needs time to compile the interediate language into native
cpu code, and that explains why the .NET program starts up slower, but if
you create the program with .NET design phylisophy and not MFC like
phylisophy, then it should reach the same speeds.
I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user interface system in Longhorn will use only .NET facilities. Is this an indication that subsequent versions of Windows will allow ONLY interpreted applications?
The biggest advantage if .NET is that it will improve security issuses since
the security is integrated into the code.
An OS based on .NET code will be far less vunerable for the current types of
worms and virusses. And I think the rest of the world would prefer an little
bit more secure windows that crashes less than a incredible fast computer.

Also note that, .NET programs will run faster compared to conventional
executable in the future since the Windows core is beeing replaced by pure
..NET technology.
It is the transition between managed and unmanaged that takes lots of time.
So it explains why .NET programs now are still a little bit slower since the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.
Does anyone else share my feelings about this situation? Can anyone put forth some reason that I should feel better about embracing .NET, when it is so alien to me?

Jul 21 '05 #9

If possible, post your core network loop. I have not seen perf issues with
the network classes. Naturally, it will probably be a little slower then
calling win32 and winsock directly, but should not get the results you
describe.

--
William Stacey, MVP

"Mike P." <an*******@discussions.microsoft.com> wrote in message
news:7D**********************************@microsof t.com...

Jon,

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested them
both with Internet Explorer as the client, I saw no noticeable change in
IE's performance when using the MFC proxy, while there was a serious
degredation in performance with the .NET proxy.
And what about the fact that you can view the code for any program just by using the disassembler utility? Am I forced to buy a multi-thousand
dollar obfuscator package if I want to make a commercial app?
Thank you.

Jul 21 '05 #10

Jon,

Thank you for your thoughtful reply.

One reason that I believe .NET apps run very slowly is that I wrote an HTTP proxy server in Visual Basic .NET. Then I wrote an identical
program in MFC. The MFC program ran many times faster. When I tested them
both with Internet Explorer as the client, I saw no noticeable change in
IE's performance when using the MFC proxy, while there was a serious
degredation in performance with the .NET proxy.
And what about the fact that you can view the code for any program just by using the disassembler utility? Am I forced to buy a multi-thousand
dollar obfuscator package if I want to make a commercial app?
Thank you.

Jul 21 '05 #11

> It is the transition between managed and unmanaged that takes lots of
time.

So it explains why .NET programs now are still a little bit slower since the Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.

That would be cool if that was the case. However I don't think that is so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api, why
would it be any faster then a comparable method in native win32? Maybe the
same, I don't see how faster. That would be nice however if wrong.

--
William Stacey, MVP

Jul 21 '05 #12

> It is the transition between managed and unmanaged that takes lots of
time.

So it explains why .NET programs now are still a little bit slower since the Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.

Jul 21 '05 #13

No, the windows core in LH is unmanaged Win32/64, and is here to stay for a
long time.

Willy.

<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...

I come from the world of C++ programming, and I'm used to writing
programs

that
are actually executed by the CPU, and that run with some semblance of

performance.
I have taken the time to explore this .NET thing, and found that not only

do .NET
applications run extremely s-l-o-w-l-y, but the various .NET languages

amount to nothing
more than interpreted script languages. It is the common language

run-time that actually executes your implementation.

Tests with C# here suggests that we have almost the same speed of our MFC
programs.
The JIT compiler needs time to compile the interediate language into
native
cpu code, and that explains why the .NET program starts up slower, but if
you create the program with .NET design phylisophy and not MFC like
phylisophy, then it should reach the same speeds.
I deeply resent this move toward "managed" code, and I'm disappointed
that

the new Avalon user
interface system in Longhorn will use only .NET facilities. Is this an

indication that subsequent
versions of Windows will allow ONLY interpreted applications?

The biggest advantage if .NET is that it will improve security issuses
since
the security is integrated into the code.
An OS based on .NET code will be far less vunerable for the current types
of
worms and virusses. And I think the rest of the world would prefer an
little
bit more secure windows that crashes less than a incredible fast computer.

Also note that, .NET programs will run faster compared to conventional
executable in the future since the Windows core is beeing replaced by pure
.NET technology.
It is the transition between managed and unmanaged that takes lots of
time.
So it explains why .NET programs now are still a little bit slower since
the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.
Does anyone else share my feelings about this situation? Can anyone put

forth some reason that I should feel better about
embracing .NET, when it is so alien to me?

I understand the you completely that itis very confusing learning to
program
in a .NET way, but you have to trust all the people here that it is the
way
to go for future operating systems and programming languages. But it has a
steep learning curve as the technology matures.

Jul 21 '05 #14

No, the windows core in LH is unmanaged Win32/64, and is here to stay for a
long time.

Willy.

<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...

I come from the world of C++ programming, and I'm used to writing
programs

that
are actually executed by the CPU, and that run with some semblance of

performance.
I have taken the time to explore this .NET thing, and found that not only

do .NET
applications run extremely s-l-o-w-l-y, but the various .NET languages

amount to nothing
more than interpreted script languages. It is the common language

run-time that actually executes your implementation.

Tests with C# here suggests that we have almost the same speed of our MFC
programs.
The JIT compiler needs time to compile the interediate language into
native
cpu code, and that explains why the .NET program starts up slower, but if
you create the program with .NET design phylisophy and not MFC like
phylisophy, then it should reach the same speeds.
I deeply resent this move toward "managed" code, and I'm disappointed
that

the new Avalon user
interface system in Longhorn will use only .NET facilities. Is this an

indication that subsequent
versions of Windows will allow ONLY interpreted applications?

The biggest advantage if .NET is that it will improve security issuses
since
the security is integrated into the code.
An OS based on .NET code will be far less vunerable for the current types
of
worms and virusses. And I think the rest of the world would prefer an
little
bit more secure windows that crashes less than a incredible fast computer.

Also note that, .NET programs will run faster compared to conventional
executable in the future since the Windows core is beeing replaced by pure
.NET technology.
It is the transition between managed and unmanaged that takes lots of
time.
So it explains why .NET programs now are still a little bit slower since
the
Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will
be faster than conventional executables now.
Does anyone else share my feelings about this situation? Can anyone put

forth some reason that I should feel better about
embracing .NET, when it is so alien to me?

I understand the you completely that itis very confusing learning to
program
in a .NET way, but you have to trust all the people here that it is the
way
to go for future operating systems and programming languages. But it has a
steep learning curve as the technology matures.

Jul 21 '05 #15

> > Windows core is still unmanaged and .NET prigrams must go through that

transition every time. When Longhorn is out, it wil be reversed. .NET will be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so. Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api, why would it be any faster then a comparable method in native win32? Maybe the same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.
That means that .NET programs have less and less transitions from managed to
unmanaged to do.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.

..NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because of
the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

Conventional executables are static in nature. all methods and functions are
laid out in a certain memory order at the moment you compiled and linked.
..NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to start
cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code to
pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of security
build in. If I remember correctly a web page counter extension for Frontpage
97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

Jul 21 '05 #16

> > Windows core is still unmanaged and .NET prigrams must go through that

transition every time. When Longhorn is out, it wil be reversed. .NET will be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so. Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api, why would it be any faster then a comparable method in native win32? Maybe the same, I don't see how faster. That would be nice however if wrong.

Jul 21 '05 #17

> No, the windows core in LH is unmanaged Win32/64, and is here to stay for
a

long time.

Too bad.
But then again, converting million lines of code is not that simple to do in
a few years. :-)

Jul 21 '05 #18

> No, the windows core in LH is unmanaged Win32/64, and is here to stay for
a

long time.

Too bad.
But then again, converting million lines of code is not that simple to do in
a few years. :-)

Jul 21 '05 #19

Mike,

In short, no. If you like your C++ programming, there is no Microsoft army
that is going to confiscate your workstation should you not come to the
other side. If *you* think .NET can improve the way you or your organization
works, then use .NET. With that I can offer what we have seen so far, if it
helps.

It all depends on the project. C++ is totally inappropriate for some of the
things you could do in .NET, and .NET is totally inappropriate for some
applications that you may have written in C++.

We asked the exact same questions, and are trying to work out those
solutions within our own organization; i.e., the users complain that a .NET
app is slow to start (they get confused because they don't see a window
immediately and keep clicking on the desktop icon, etc, etc.), so we build a
splash screen in C++ that gets a window up there quickly and then launches
the .NET app. However, once a .NET application is running, although it does
perform a bit slower than native Win32 apps (as it should!), we have seen
firsthand how the advancements in code security and ease of domain
administration are a step in the right direction that the entire industry
needs right now. And as always, in the parallel industry of construction, if
I could build a house with only one tool, I would; but unfortunately
sometimes I need a wrench and sometimes I need a screwdriver to accomplish
the task.

The only other reason we use .NET is summed up in one of Microsoft's banner
ads from some time ago: "Why would you start from scratch, when you can
start from almost done?" -- We find something new every day that MS has
included in the framework that we had previously written our own libraries
for in C++, and the fact that we don't have to spend testing time on those
components allows us to develop in 4 days what previously took us 4 weeks.
It really takes care of the rudimentary processes / "management" while at
the same time gives us the ability to dive right into the Win32 API should
we need it.

With that said, .NET does make you feel like less of a programmer since it
manages so much for you, hence how it resembles a scripting language.
However, my personal outlook on that is if I am in a room with a C++
programmer and we are both working on, say, a $5,000 development project,
after a week of coding, the C++ programmer will still be coding the basic
framework and window management for the application while I'm depositing a
check at the bank... so that's what it comes down to. :)

FWIW on our organization's side of the fence,

Brandon

"Mike P." <an*******@discussions.microsoft.com> wrote in message
news:BC**********************************@microsof t.com...

Hello,

I come from the world of C++ programming, and I'm used to writing programs that are actually executed by the CPU, and that run with some
semblance of performance. I have taken the time to explore this .NET thing,
and found that not only do .NET applications run extremely s-l-o-w-l-y, but
the various .NET languages amount to nothing more than interpreted script
languages. It is the common language run-time that actually executes your
implementation.
I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user interface system in Longhorn will use only .NET
facilities. Is this an indication that subsequent versions of Windows will
allow ONLY interpreted applications?
Does anyone else share my feelings about this situation? Can anyone put forth some reason that I should feel better about embracing .NET, when
it is so alien to me?
Sincerely,
Mike

Jul 21 '05 #20

Hello,

I come from the world of C++ programming, and I'm used to writing programs that are actually executed by the CPU, and that run with some
semblance of performance. I have taken the time to explore this .NET thing,
and found that not only do .NET applications run extremely s-l-o-w-l-y, but
the various .NET languages amount to nothing more than interpreted script
languages. It is the common language run-time that actually executes your
implementation.
I deeply resent this move toward "managed" code, and I'm disappointed that the new Avalon user interface system in Longhorn will use only .NET
facilities. Is this an indication that subsequent versions of Windows will
allow ONLY interpreted applications?
Does anyone else share my feelings about this situation? Can anyone put forth some reason that I should feel better about embracing .NET, when
it is so alien to me?
Sincerely,
Mike

Jul 21 '05 #21

Agree mostly. Your not going to get faster then native c++ to native win32
however. That model will not go away soon. Managed c++ to managed .Net
should be ~same as Managed c# or vb to Managed .net. Unmanaged c++ to
managed will have some overhead probably on par with managed to unmanaged
pinvoke has today. Many of the .Net classes still wrap win32 calls. I
would guess that will continue with WinFX, but at a leaser percentage as
more primitives may be fully managed and exposed. However, most of the low
level primitives (i.e. mutex, IPCs, semaphore, etc) would still be wrappers
around win32. Don't get me wrong here, I have seen the light and love the
managed side. If I never see another pinvoke, I will be very happy.
Cheers!

--
William Stacey, MVP

<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...

Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api,

why
would it be any faster then a comparable method in native win32? Maybe

the
same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.
That means that .NET programs have less and less transitions from managed

to unmanaged to do.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.

.NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because of the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

Conventional executables are static in nature. all methods and functions are laid out in a certain memory order at the moment you compiled and linked.
.NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to start cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code to pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of security build in. If I remember correctly a web page counter extension for Frontpage 97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

Jul 21 '05 #22

Windows core is still unmanaged and .NET prigrams must go through that
transition every time. When Longhorn is out, it wil be reversed. .NET will be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api,

why
would it be any faster then a comparable method in native win32? Maybe

the
same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.
That means that .NET programs have less and less transitions from managed

to unmanaged to do.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.

.NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because of the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

Conventional executables are static in nature. all methods and functions are laid out in a certain memory order at the moment you compiled and linked.
.NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to start cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code to pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of security build in. If I remember correctly a web page counter extension for Frontpage 97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

Jul 21 '05 #23

See inline ****

Willy.

<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...

> Windows core is still unmanaged and .NET prigrams must go through that
> transition every time. When Longhorn is out, it wil be reversed. .NET will > be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api,

why
would it be any faster then a comparable method in native win32? Maybe

the
same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.

**** Hmmm... which Win32 API's have been replaced sofar?
More and more win32 API's are introduced by now (see W2K3 and LH).
That means that .NET programs have less and less transitions from managed
to
unmanaged to do.
*** No that's not true, .NET is built upon Win32, somehow, it will allways
need to transition between managed and Win32 for system services.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.
*** And break alot of existing applications, do you realy think the Server
and Office folks at MS are willing:
- to pay this perf. hit?
- to compromise the reliability of their server?

.NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because
of
the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

*** Don't overestimate the power of the JITter, he's heavily constrained by
the "time to optimize", and don't overestimate the power of the newer
processor family.
Don't forget that the latest native code compilers also generate better &
faster code, and that parts of the system cannot afford the overhead of the
GC both in time and space (think about drivers and core windows component
like the memory manager, scheduller, interupt handler....). And here I'm not
gonna talk about robustness, but why do you think Yukon and .NET 2.0 are
getting delayed?
Conventional executables are static in nature. all methods and functions
are
laid out in a certain memory order at the moment you compiled and linked.
.NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
*** "might", yes but officially anounced, no. For the moment MS has other
performance issues to solve which have much more impact than some profile
guided JITter.

different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to
start
cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code
to
pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of
security
build in. If I remember correctly a web page counter extension for
Frontpage
97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

Jul 21 '05 #24

See inline ****

Willy.

<Ol**********@skyscan.be> wrote in message
news:40***********************@news.skynet.be...

> Windows core is still unmanaged and .NET prigrams must go through that
> transition every time. When Longhorn is out, it wil be reversed. .NET will > be faster than conventional executables now.
That would be cool if that was the case. However I don't think that is

so.
Win32 is not going away with LH. WinFx classes will still need to call
Win32 apis in many cases. Even if a class does not pinvoke a win32 api,

why
would it be any faster then a comparable method in native win32? Maybe

the
same, I don't see how faster. That would be nice however if wrong.

Simple, more an more Win32 API is beeing replaced by .NET variants.

**** Hmmm... which Win32 API's have been replaced sofar?
More and more win32 API's are introduced by now (see W2K3 and LH).
That means that .NET programs have less and less transitions from managed
to
unmanaged to do.
*** No that's not true, .NET is built upon Win32, somehow, it will allways
need to transition between managed and Win32 for system services.

But for existing Win32 executables, the will need Win32 API's that wraps
functionality to the .NET core.
That means that Win32 executables must go from unmanaged to managed code
transitions. So they will slow down.
*** And break alot of existing applications, do you realy think the Server
and Office folks at MS are willing:
- to pay this perf. hit?
- to compromise the reliability of their server?

.NET programs will be faster because the CLR gets better and better.
At this moment, conventional exe works at its best perfocramence because
of
the compiler that optimizes it for the current known processors.
If you do not recompile the .NET applcation and conventional program, you
would see that the .NET version gets faster and faster compared to the
conventional program butcause JIT v2.0 will optimize for the most recent
processor while the conventional application is still stuck to the Pentium
IV optimizations.

*** Don't overestimate the power of the JITter, he's heavily constrained by
the "time to optimize", and don't overestimate the power of the newer
processor family.
Don't forget that the latest native code compilers also generate better &
faster code, and that parts of the system cannot afford the overhead of the
GC both in time and space (think about drivers and core windows component
like the memory manager, scheduller, interupt handler....). And here I'm not
gonna talk about robustness, but why do you think Yukon and .NET 2.0 are
getting delayed?
Conventional executables are static in nature. all methods and functions
are
laid out in a certain memory order at the moment you compiled and linked.
.NET programs are dynamic in nature. Future JIT compiler might perform
statistics what function is use how often, and might relocate it in a
*** "might", yes but officially anounced, no. For the moment MS has other
performance issues to solve which have much more impact than some profile
guided JITter.

different memory block so the the most used functions are grouped together
in a small memory address space, ready to be cached more often. Also .NET
programs written in pure OOP way is now far more performant compare to the
OOP version of a C++ unmanaged. because it does not need to delete small
memory memory bloks every time stalling then program. .NET starts deleting
the memory when it either needs memory, or if it can find some time to
start
cleaning up.

Just be aware! .NET is NOT an interpreter, It compiles the complete code
to
pure win32 code but optimized for your processor. When JIT matures, it ill
become even better optimizer.

Another thing that must be taken into mind, is the fact that .NET programs
also implements security at the low level standard.
You should compare Win32 functions with also this type of level of
security
build in. If I remember correctly a web page counter extension for
Frontpage
97 could be misused to take over the server. A stupid prgram that only
intended to show a bitmap on screen was misused. This is why all programs
now created should have this security integrated default.Even if it is a
simple screen saver, it could be misused by a worm. (examples enough: e.g.
windows help file could be used to take over your computer) Maybe next
Solitair....

But this is my opinion? I really believe that this .NET is the way to go,
and I admit that I also fight against it to have my code work. ;-)

Jul 21 '05 #25

> With that said, .NET does make you feel like less of a programmer since it

manages so much for you, hence how it resembles a scripting language.

I don't get the scripting language reference. c# and vb.net don't resemble
any scripting language anymore then any other language. I think your
talking more about the framework anyway then the actual language. Move to
msh, ksh, perl for scripting languages. That said, perl has a .Net language
so I guess the line can blur a bit. That makes me wonder, anyone do a ksh
package for VS yet?

--
William Stacey, MVP

Jul 21 '05 #26

> With that said, .NET does make you feel like less of a programmer since it

manages so much for you, hence how it resembles a scripting language.

Jul 21 '05 #27

Hi Mike,

Are you sure of this what you are writting about C++, are you really putting
every pixel by pixel on the screen every time again after that you have
chosen the right color from that pixel.

And are you really adding every byte to the register, accumulate the
registers, and than put them back in a memory place or to another register.

If not than what when the Net does some more than only the things you say
you are doing now with C++.

Just my thougth

Cor

Jul 21 '05 #28

Jul 21 '05 #29

When I made that reference (and I think the reference that Mike is referring
to, although I cannot speak for him), I am referring to the general
"feeling" that you get from programming in .NET (especially VB.NET) -- Since
you start a project and it's able to run and display an interactive user
interface from the first second you use it (thank you, code generator), it's
like all you have to do is put in the functionality, which is more like a
scripting language.

I have heard this reference once before by a team of programmers that wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET. I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy. I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer. Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Any philosophical thoughts on "real" vs. "fake" programmer psychology? ;)

Brandon

"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:ul**************@TK2MSFTNGP10.phx.gbl...

With that said, .NET does make you feel like less of a programmer since it manages so much for you, hence how it resembles a scripting language.
I don't get the scripting language reference. c# and vb.net don't

resemble any scripting language anymore then any other language. I think your
talking more about the framework anyway then the actual language. Move to
msh, ksh, perl for scripting languages. That said, perl has a .Net language so I guess the line can blur a bit. That makes me wonder, anyone do a ksh
package for VS yet?

--
William Stacey, MVP

Jul 21 '05 #30

With that said, .NET does make you feel like less of a programmer since it manages so much for you, hence how it resembles a scripting language.
I don't get the scripting language reference. c# and vb.net don't

resemble any scripting language anymore then any other language. I think your
talking more about the framework anyway then the actual language. Move to
msh, ksh, perl for scripting languages. That said, perl has a .Net language so I guess the line can blur a bit. That makes me wonder, anyone do a ksh
package for VS yet?

--
William Stacey, MVP

Jul 21 '05 #31

Brandon Potter <microsoft@brandonpotter_nospam.com> wrote:

When I made that reference (and I think the reference that Mike is referring
to, although I cannot speak for him), I am referring to the general
"feeling" that you get from programming in .NET (especially VB.NET) -- Since
you start a project and it's able to run and display an interactive user
interface from the first second you use it (thank you, code generator), it's
like all you have to do is put in the functionality, which is more like a
scripting language.
That has nothing to do with scripting - it's just being RAD-oriented.

Personally I avoid the forms designer when I can, but there we go. (I
tend to get more readable and maintainable code that way.)
I have heard this reference once before by a team of programmers that wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET.
That sounds like a silly comment to me from people who care more about
being "macho" than being productive. Why spend time thinking about
problems which have already been solved when you can be tackling new
problems inherent in whatever application you're trying to write?
I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy.
Exactly - and as long as you enjoy your job, of course.
I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer.
I don't think so - but then maybe I don't have the pejorative idea of a
script programmer that your colleagues do. There are plenty of times
when scripting is the best solution to a problem, but that doesn't make
it any less "real" programming, IMO. To me, a *good* programmer knows
to use the best tool for the job. There are still good reasons to use
native code rather than managed code in some cases, but "looking cool
as a programmer" is never one of them.
Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Any philosophical thoughts on "real" vs. "fake" programmer psychology? ;)

Try getting them to explain how they tackle all interntationalisation
problems (including surrogates etc), their multithreading strategies
etc. There's still plenty to think about in .NET.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #32

Brandon Potter <microsoft@brandonpotter_nospam.com> wrote:

When I made that reference (and I think the reference that Mike is referring
to, although I cannot speak for him), I am referring to the general
"feeling" that you get from programming in .NET (especially VB.NET) -- Since
you start a project and it's able to run and display an interactive user
interface from the first second you use it (thank you, code generator), it's
like all you have to do is put in the functionality, which is more like a
scripting language.
That has nothing to do with scripting - it's just being RAD-oriented.

Personally I avoid the forms designer when I can, but there we go. (I
tend to get more readable and maintainable code that way.)
I have heard this reference once before by a team of programmers that wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET.
That sounds like a silly comment to me from people who care more about
being "macho" than being productive. Why spend time thinking about
problems which have already been solved when you can be tackling new
problems inherent in whatever application you're trying to write?
I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that
keep customers happy.
Exactly - and as long as you enjoy your job, of course.
I guess if you are working in a RAD environment where
you can produce results quickly and don't have to mess with the more "geeky"
side of things (establishing the Win32 While() message loop and spend hours
and hours writing the code to paint the display), then it makes you look
more like a script programmer.
I don't think so - but then maybe I don't have the pejorative idea of a
script programmer that your colleagues do. There are plenty of times
when scripting is the best solution to a problem, but that doesn't make
it any less "real" programming, IMO. To me, a *good* programmer knows
to use the best tool for the job. There are still good reasons to use
native code rather than managed code in some cases, but "looking cool
as a programmer" is never one of them.
Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Any philosophical thoughts on "real" vs. "fake" programmer psychology? ;)

Jul 21 '05 #33

> I have heard this reference once before by a team of programmers that
wished

to remain in C++ to retain their status of "real" programmers and would not touch .NET.
As Don Box once said; "..time will take care of these people because they
don't reproduce." <g>
I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that keep customers happy. I guess if you are working in a RAD environment where you can produce results quickly and don't have to mess with the more "geeky" side of things (establishing the Win32 While() message loop and spend hours and hours writing the code to paint the display), then it makes you look
more like a script programmer. Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

I guess you can argue either way. However, the same people said the same
things when moving from assembler and c to c++. I guess this will always
be. We love what we know and resist change at times. That said, I think
they hit a sweet spot with c# on form and function. You can almost go as
close to metal as you want to get.

--
William Stacey, MVP

Jul 21 '05 #34

> I have heard this reference once before by a team of programmers that
wished

to remain in C++ to retain their status of "real" programmers and would not touch .NET.
As Don Box once said; "..time will take care of these people because they
don't reproduce." <g>
I was thinking to myself how I would never hire them with that
attitude, but it might just be because I don't think you should care how
"real" or "fake" you are as a programmer if you produce robust results that keep customers happy. I guess if you are working in a RAD environment where you can produce results quickly and don't have to mess with the more "geeky" side of things (establishing the Win32 While() message loop and spend hours and hours writing the code to paint the display), then it makes you look
more like a script programmer. Kind of in the same way that some people
swear on C# and play down VB.NET because it's a more complicated syntax,
when the functionality is almost identical.

Jul 21 '05 #35

Hi William,

I don't get the scripting language reference.

C++ is too a kind of scripting language. It has not that true connection to
the computer as assembler, with which you can direct translate every
instruction in a equivalent machine code.

It is just the point of view that you use.

:-))))

Cor

Jul 21 '05 #36

Hi William,

I don't get the scripting language reference.

Jul 21 '05 #37

> In short, no. If you like your C++ programming, there is no Microsoft army

that is going to confiscate your workstation should you not come to the
other side. If *you* think .NET can improve the way you or your organization works, then use .NET. With that I can offer what we have seen so far, if it helps.
Agree.
I have started some smaller .NET projects because I can create these same
programs 7 times faster with far better user functionality including dragn
and drop, colors, tooltips,... compared to the older C++ technology using
MFC. Starting up is slower, but I do not see any noticable performance
problems. But that is because I also use unmanaged C++ functionality mixed
for none user interface stuff.

The biggest resistance I get is from people that are totally new to .NET and
have to install the .NET framework and somehow trust my strong name when
they want to use the program from the network.
With that said, .NET does make you feel like less of a programmer since it
manages so much for you, hence how it resembles a scripting language.
However, my personal outlook on that is if I am in a room with a C++
programmer and we are both working on, say, a $5,000 development project,
after a week of coding, the C++ programmer will still be coding the basic
framework and window management for the application while I'm depositing a
check at the bank... so that's what it comes down to. :)

I don't feel less programmer. :-)
Now I can concentrate on important stuff and create new technology instead
of fiddeling with reading a value from a combo box. :-)

Jul 21 '05 #38

> Any philosophical thoughts on "real" vs. "fake" programmer psychology? ;)

From my point of view, real programmers create new programming technology,
try to find new techniques to make using the program much simpler to use.
Real programmers evolve and like to learn and explore new technology. And
try to make the program more user friendly.

Other programmers in my opinion are the people that get stuck to old (but
proven) technology. Once in their life they did an effort to learn C++ and
MFC and now they only use the existing code they know of, unless their
compiler cannot be bought anymore. This is not wrong, but they create
programs that are ancient by the time they release it. Sure it will be the
fastest meanest smallest code, but it will look like a TRABANT while
everybody now have a Mercedes. Not very user friendly.

Fake programmers just create a program that looks nice but don't care if it
works or not, as long as they can sell it with a lot of promisses.

But there is one very important reason why to use .NET! That is the security
that you get for free even though you are not developing for Internet, it
will help improving the stability of the Operating system against worms and
virusses. There is still a misconception that only programs used by the
Internet are vunerable, but in reality, *any* program can be misused by a
worm and virus. For example: the Windows help file. Maybe now, a lot of
companies use standalone PC's but what in 5 years when that program is still
beening used, but put on a computer with network access?

Jul 21 '05 #39

> I have heard this reference once before by a team of programmers that

wished
to remain in C++ to retain their status of "real" programmers and would not
touch .NET.

As Don Box once said; "..time will take care of these people because they
don't reproduce." <g>

Endangered species.:-)
They don't evolve. :-)
But I don't think that they program in C++, I honestly believe that they
still use the C part only while using some parts of the C++ class libraries.
I guess you can argue either way. However, the same people said the same
things when moving from assembler and c to c++. I guess this will always
be. We love what we know and resist change at times. That said, I think
they hit a sweet spot with c# on form and function. You can almost go as
close to metal as you want to get.

Assembler is still beeing programmed!
I do, but not als a whole program but parts of the C++ code that needs
optimized for speed (MMX, SSE, SSE2).

I am still suprised that so many C++ programmers still program in normal C.
They create one huge class, and clame it is C++! ;-)

Jul 21 '05 #40