By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,263 Members | 1,694 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,263 IT Pros & Developers. It's quick & easy.

Does the .NET framework always call the API?

P: n/a
I want to double check my understanding about how the .NET framework works. From
what I understand every call to the .NET framework is ultimately translated into
one of more API calls, is this correct?
Jan 22 '06 #1
Share this Question
Share on Google+
28 Replies


P: n/a
"Peter Olcott" <ol****@att.net> a écrit dans le message de news:
DlEAf.68924$QW2.46682@dukeread08...

|I want to double check my understanding about how the .NET framework works.
From
| what I understand every call to the .NET framework is ultimately
translated into
| one of more API calls, is this correct?

The .NET framework is a massive library mainly written in managed code.
where the framework needs to , it calls existing APIs but there is a lot of
brand new code that doesn't need the old APIs.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jan 22 '06 #2

P: n/a
Try to download Reflector http://www.aisto.com/roeder/dotnet/ or have a
look at Rotor source code to see what the ".NET framework calls" exactly
do - most of them are definitely not API calls.

"Peter Olcott" <ol****@att.net> wrote in message
news:DlEAf.68924$QW2.46682@dukeread08...
I want to double check my understanding about how the .NET framework works.
From what I understand every call to the .NET framework is ultimately
translated into one of more API calls, is this correct?

Jan 22 '06 #3

P: n/a
I would expect it to only call any API's when its handling calls within the
Microsoft namespace, as this touches more on microsoft operating system
functionality - whereby the remaining namespaces are cross platform and
would be very unlikely to drop into API's.

--
Regards

John Timney
Microsoft MVP

"Peter Olcott" <ol****@att.net> wrote in message
news:DlEAf.68924$QW2.46682@dukeread08...
I want to double check my understanding about how the .NET framework works.
From what I understand every call to the .NET framework is ultimately
translated into one of more API calls, is this correct?

Jan 22 '06 #4

P: n/a
Whooo. Interesting. OK, folks, the OP just sent me on a mission to find
out. The very first thing that comes to mind is to spy on the system and
look at who is invoking whom. I cannot seem to find it on my system, but
there used to be a cool utility called APIMON.EXE that would list (log?) api
calls as they are called. It had a cartoon-like Frankenstein icon. Anyone
remember it?

It is the first step to the OP question, but now that I can't find the
thing, I would be grateful for any hints on how to *legitmately* acquire it.

--
Peace & happy computing,

Mike Labosh, MCSD MCT
"Escriba coda ergo sum." -- vbSensei
"Peter Olcott" <ol****@att.net> wrote in message
news:DlEAf.68924$QW2.46682@dukeread08...
I want to double check my understanding about how the .NET framework works. From what I understand every call to the .NET framework is ultimately translated into one of more API calls, is this correct?

Jan 22 '06 #5

P: n/a
You can download the API monitor version 1.5 from:
http://www.rohitab.com/apimonitor/

-----
Enjoy
Sharon
Jan 22 '06 #6

P: n/a
I am referring to those cases that result in API functionality, for example GDI
output to the display screen. Did MS write a whole new way to output things to
the screen, or merely wrap these calls in the .NET framework?

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
"Peter Olcott" <ol****@att.net> a écrit dans le message de news:
DlEAf.68924$QW2.46682@dukeread08...

|I want to double check my understanding about how the .NET framework works.
From
| what I understand every call to the .NET framework is ultimately
translated into
| one of more API calls, is this correct?

The .NET framework is a massive library mainly written in managed code.
where the framework needs to , it calls existing APIs but there is a lot of
brand new code that doesn't need the old APIs.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Jan 22 '06 #7

P: n/a

"John Timney ( MVP )" <ti*****@despammed.com> wrote in message
news:eh**************@TK2MSFTNGP10.phx.gbl...
I would expect it to only call any API's when its handling calls within the
Microsoft namespace, as this touches more on microsoft operating system
functionality - whereby the remaining namespaces are cross platform and
would be very unlikely to drop into API's.
That isn't totally complete by any means. While the remaining namespaces
are designed tobe platform independent, many still rely on platform
dependent mechanisms. Take the System.IO namespace for example. On Windows
it is likely using CreateFile and its ilk and on Linux perhaps the posix IO
system and on a third system whatever it uses. Same goes for
System.Windows.Forms(although that doesn't port very well), some of
System.Security(WindowsIdentity definatly uses windows APIs, Identity
classes for other systems would use that API as well, System.Threading(which
may or may not use system threads depending on implementation and how it is
hosted), and many other namespaces.

That is why Mono had to rewrite the class library instead of just copy it.
Large portions do rely on the underlying system, otherwise the framework
would have to replace everything from device drivers up. That doesn't mean
that every call, the string editing functions, large pieces of ASP.NET, much
of if not all of System.Xml for example, result in API calls, but many
things do..

--
Regards

John Timney
Microsoft MVP

"Peter Olcott" <ol****@att.net> wrote in message
news:DlEAf.68924$QW2.46682@dukeread08...
I want to double check my understanding about how the .NET framework
works. From what I understand every call to the .NET framework is
ultimately translated into one of more API calls, is this correct?


Jan 22 '06 #8

P: n/a
The framework classes and the run-time (the CLR) both wrap the Win32 API's
to call into OS and related services (like GDI+).

The framework (mostly written in C#) uses PInvoke to perform these API
calls, while the CLR (unmanaged C++) can directly call any API it
likes/needs. The framework and the CLR also call into system services
through COM interop, the CLR debugging, profiling and unmanaged hosting
interfaces are all COM interfaces. Some classes in the framework are thin
wrappers around COM services like ADSI, WMI, COM+., others use a mixture of
PInvoke and COM interop and a majority don't need to call into external
native code at all, but they might call into the CLR through the
internalcall interface. Some classes in v2 are written in managed C++ and
use C++ interop to call into unmanaged code.

Willy.
"Peter Olcott" <ol****@att.net> wrote in message
news:xsNAf.68937$QW2.29587@dukeread08...
|I am referring to those cases that result in API functionality, for example
GDI
| output to the display screen. Did MS write a whole new way to output
things to
| the screen, or merely wrap these calls in the .NET framework?
|
| "Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
| news:%2****************@TK2MSFTNGP09.phx.gbl...
| > "Peter Olcott" <ol****@att.net> a écrit dans le message de news:
| > DlEAf.68924$QW2.46682@dukeread08...
| >
| > |I want to double check my understanding about how the .NET framework
works.
| > From
| > | what I understand every call to the .NET framework is ultimately
| > translated into
| > | one of more API calls, is this correct?
| >
| > The .NET framework is a massive library mainly written in managed code.
| > where the framework needs to , it calls existing APIs but there is a lot
of
| > brand new code that doesn't need the old APIs.
| >
| > Joanna
| >
| > --
| > Joanna Carter [TeamB]
| > Consultant Software Engineer
| >
| >
|
|
Jan 22 '06 #9

P: n/a
"Peter Olcott" <ol****@att.net> wrote in message
news:DlEAf.68924$QW2.46682@dukeread08...
I want to double check my understanding about how the .NET framework works.
From what I understand every call to the .NET framework is ultimately
translated into one of more API calls, is this correct?

hmmm... your question doesn't makes much sense.
I don't really know what you mean so here are some various element of
response:
API: "Application Program Interface", basically that the set of all classes
/ method / library available as a single unit from a third party, in your
case you refer the .NET API as being all the classes by default in the
framework.

an API call: when you call 1 method of the framework. When you do 1 call you
do 1 call (and not 0 or 2).

Could an API call itself?
as much as you refer your own method in your own code.
Maybe you mean: The .NET API ultimately calls into the Win32 API ?

well not always, depending on the situation.
For exemple string.Format() simple manipulate and hardly need to call any
win32 code
On the other hand Form.Show() certainly call ShowWindow() and other win32
functions.
Jan 23 '06 #10

P: n/a
Peter,

In my opinion is it not important what Net uses.

Net provides a system that let you call the underlying OS parts. If this is
Win32, WinFX or Linux should not be important.

If that are called API's so what, for you that should not be important.

Just my thought,

Cor
Jan 23 '06 #11

P: n/a
John Timney ( MVP ) wrote:
I would expect it to only call any API's when its handling calls
within the Microsoft namespace, as this touches more on microsoft
operating system functionality - whereby the remaining namespaces are
cross platform and would be very unlikely to drop into API's.


I don't think you've thought this through John.

For example, the classes in System.EnterpriseServices are almost all
direct wrappers around the COM+ APIs. Then there are classes in
System.Net.Sockets where many classes are wrappers around Winsock 2.0,
and then there's classes in System.Threading that are wrappers around
Win32 threads and synchronization objects, do I need to go on?

Yes there are classes that are pure IL and don't make any calls to Win32
or Windows COM objects, but many classes do. I have done an analysis of
various versions of .NET by checking metadata to see which methods are
COM, pinvoke, or embedded native code, and which are internalcall. I
have also 'walked' through all IL in every IL method to see the method
calls it makes and then analyse the type of method called. The results
are shown here:

http://www.grimes.demon.co.uk/dotnet/dotnetWrappers.htm

For .NET v2.0 I find that there are

Methods in the framework:

IL Methods 92.8%
COM methods 4.2%
pinvokeimpl methods 2.5%
internalcall methods 0.40%
native methods 0.04%

Thus the implementation of almost 7% of methods is not in IL.

Method calls within the assembly:

IL Methods 56.3%
COM methods 0.18%
pinvokeimpl methods 0.98%
internalcall methods 0.80%
native methods 0.02%

Method calls outside the assembly:

IL Methods 38.3%
COM methods 0.03%
pinvokeimpl methods 0.01%
internalcall methods 2.3%
native methods 0%

This is better, just over 1% of calls is to non-IL methods.

Of course, my analysis does not take in to account how often methods are
called. AFAIK the method calls implemented through pinvoke may be the
most called methods <g>

Richard
--
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Jan 23 '06 #12

P: n/a
> John Timney ( MVP ) wrote:
I would expect it to only call any API's when its handling calls
within the Microsoft namespace, as this touches more on microsoft
operating system functionality - whereby the remaining namespaces are
cross platform and would be very unlikely to drop into API's.


I don't think you've thought this through John.

I assume that what you give is for Linux. Most of us know what it is for
current Windows Win32 systems. In my opinion is John however talking about
other systems. Of course is Net mainly a layer upon the OS. It would be very
crazy when it would gives other results way called by Net than direct by
other use of that.

Dit you think about that as John obiously did.

Cor
Jan 23 '06 #13

P: n/a
Cor Ligthert [MVP] wrote:
John Timney ( MVP ) wrote:
I would expect it to only call any API's when its handling calls
within the Microsoft namespace, as this touches more on microsoft
operating system functionality - whereby the remaining namespaces are
cross platform and would be very unlikely to drop into API's.


I don't think you've thought this through John.

I assume that what you give is for Linux.


Why would you assume that? It seems unlikely given that the title of
the page Richard is ".NET as a Win32 Wrapper".
Most of us know what it is for current Windows Win32 systems.
In my opinion is John however talking about other systems.


Again, I'm not sure where you get that impression from.

Jon

Jan 24 '06 #14

P: n/a
Jon,
> I don't think you've thought this through John.
>

I assume that what you give is for Linux.


Why would you assume that? It seems unlikely given that the title of
the page Richard is ".NET as a Win32 Wrapper".
Most of us know what it is for current Windows Win32 systems.
In my opinion is John however talking about other systems.


Again, I'm not sure where you get that impression from.


I am not blind and I can read.

It was the way it was written to John to give an answer in the same way as
it was in my idea given to John, while in my idea Johns answer was very
correct.

Cor
Jan 24 '06 #15

P: n/a
Cor Ligthert [MVP] wrote:
> I don't think you've thought this through John.
>
I assume that what you give is for Linux.
Why would you assume that? It seems unlikely given that the title of
the page Richard is ".NET as a Win32 Wrapper".
Most of us know what it is for current Windows Win32 systems.
In my opinion is John however talking about other systems.


Again, I'm not sure where you get that impression from.


I am not blind and I can read.


In that case I'm *very* confused by why you would assume Richard's
response was about Linux. Note that the .NET framework itself doesn't
exist on Linux in the first place. .NET is a Windows-specific
implementation of the CLI etc.
It was the way it was written to John to give an answer in the same way as
it was in my idea given to John
Not at all sure what you mean by that. Could you rephrase it?
while in my idea Johns answer was very correct.


No, John's answer was *not* correct. Classes like System.IO.FileStream
are bound to call into native APIs somewhere - either that, or they'd
have to call into CLR-implementation-specific classes which in turn
would call into APIs; either way it's not cross-platform.

Are you suggesting that Richard's research was inaccurate? I suggest
you look at FileStream using Reflector - look at methods such as
WriteFile, which import kernel32.dll - very Windows specific.

Jon

Jan 24 '06 #16

P: n/a
Jon,

Maybe is it that John and I are looking in an abstract way to this question.

"Does the .Net framework *always* call the API", what is as well in time.

And you and Richard look to it concrete related to current Win32.

Cor
Jan 24 '06 #17

P: n/a
My suggestion: download Reflector and take a look under the hood. You
will see almost all windows forms workings are ultimately winapi calls.
And getting the .NET SDK you can view the source of the CLR (which is
C++) which reveals a great deal. For example string.Equals (==) boils
down to a basic binary comparison with the first part checking the two
strings are equal length and returning false if they're not.

And the .NET "virtual machine" is a COM server too as far as I
understand it.

Jan 24 '06 #18

P: n/a
Cor Ligthert [MVP] wrote:
Maybe is it that John and I are looking in an abstract way to this question.

"Does the .Net framework *always* call the API", what is as well in time.

And you and Richard look to it concrete related to current Win32.


I agree that the .NET framework doesn't always call into an API. No-one
has stated that it does.

However, John expected that it would *never* call into an API from
classes outside the Microsoft.* namespace hierarchy. That's
demonstrably untrue for existing versions of .NET.

(I'm still baffled as to why you assumed Richard's post was about
Linux.)

Jon

Jan 24 '06 #19

P: n/a

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:eL**************@TK2MSFTNGP15.phx.gbl...
| Jon,
|
| Maybe is it that John and I are looking in an abstract way to this
question.
|
| "Does the .Net framework *always* call the API", what is as well in time.
|
| And you and Richard look to it concrete related to current Win32.
|
| Cor
|
|

Even if you look at it in an abstract way, you have to admit that the
framework is nothing else than a runtime (CLR/CLI) and a set of libraries
presenting an OO API to the users of the containing classes.
The CLR uses the platform (Win32) services to perform it's specific tasks
(memory allocator, thread allocator, timer and synchronization services
etc...) and offers some of these services to the framework classes in top of
it.
A large part of framework classes themselves, are also wrapping the platform
specific API's (think file I/O, Security service API's )or some specialized
API's (think ADO.NET, SQL Server etc..), or are calling into COM based
services to present an OO view of the services to the user of the framework.
The classes that wrap the OS or specialized services are not restricted to a
specific namespace or assembly, and that's what John implied, but he is
wrong.
Only a few of the framework classes are not calling into the 'unmanaged'
API, simply because they are self contained, they don't need any auxiliary
services.
Willy.

Jan 24 '06 #20

P: n/a
Jon,

(I'm still baffled as to why you assumed Richard's post was about
Linux.)


Read my replies before you write messages like this.

Cor
Jan 24 '06 #21

P: n/a
Willy,

Even if you look at it in an abstract way, you have to admit that the
framework is nothing else than a runtime (CLR/CLI) and a set of libraries
presenting an OO API to the users of the containing classes.
The CLR uses the platform (Win32) services to perform it's specific tasks
(memory allocator, thread allocator, timer and synchronization services
etc...) and offers some of these services to the framework classes in top
of
it.
No I don't admit, for me is it an extention on the current operating system.
Including things as culture, security or whatever, which are not really
needed in a runtime. CLR/CLI is a part of the Framework, it is for me not
the framework.
A large part of framework classes themselves, are also wrapping the
platform
specific API's (think file I/O, Security service API's )or some
specialized
API's (think ADO.NET, SQL Server etc..), or are calling into COM based
services to present an OO view of the services to the user of the
framework.
The classes that wrap the OS or specialized services are not restricted to
a
specific namespace or assembly, and that's what John implied, but he is
wrong.
I am not discussing what it does in Win32. Will you tell me that it will
work in the same way as this in WinXQ. (Some not existing version maybe
after WinFX). Where the Net still can be as an independable layer between
hardware, OS and whatever other parts, however in a more to the user and is
situation tailored way.
Only a few of the framework classes are not calling into the 'unmanaged'
API, simply because they are self contained, they don't need any auxiliary
services.

I wrote some messages ago already that I am not writing about what is now.
That a car was the most efficient driving on coal in 1890 (and in war time
in the Benelux) does not mean that coal would forever be the best fuel for a
car.

Cor
Jan 24 '06 #22

P: n/a

"Chris S."
My suggestion: download Reflector and take a look under the hood.


Do you have reflector for me for the system that comes after WinFX, its
Framework, the VS and that OS?

I am not talking about Win32, however this I repeat for the I don't know how
many time

So please read my messages before you start answering them.

Cor

Jan 24 '06 #23

P: n/a
Cor Ligthert [MVP] wrote:
(I'm still baffled as to why you assumed Richard's post was about
Linux.)


Read my replies before you write messages like this.


I've read your replies and I'm still baffled by it.

Please state clearly why you assumed Richard's reply, which included a
link to statistics *clearly* gathered entirely on Windows systems, was
referring to Linux.

Jon

Jan 24 '06 #24

P: n/a
Cor Ligthert [MVP] wrote:

<snip>
I am not discussing what it does in Win32.


And that's the problem. Everyone else is talking about what it's doing
now - hence the "Does" in the framework rather than "Will".

John's answer (which you apparently agree with) states an expectation
about the current behaviour. That expectation is incorrect.

Do you accept that in all current implementations of .NET, there are
classes in the System.* hierarchy which make API calls? If not, please
explain calls such as FileStream.WriteFile. If you do, please explain
how you can accept the statement above but still agree with John.

Jon

Jan 24 '06 #25

P: n/a

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:u9**************@TK2MSFTNGP15.phx.gbl...
| Willy,
|
| >
| > Even if you look at it in an abstract way, you have to admit that the
| > framework is nothing else than a runtime (CLR/CLI) and a set of
libraries
| > presenting an OO API to the users of the containing classes.
| > The CLR uses the platform (Win32) services to perform it's specific
tasks
| > (memory allocator, thread allocator, timer and synchronization services
| > etc...) and offers some of these services to the framework classes in
top
| > of
| > it.
|
| No I don't admit, for me is it an extention on the current operating
system.

The point is that it calls the OS through the native platform API's whenever
it needs a service from the OS. As such it doesn't extend the OS, that is,
it doesn't offer any extended OS services it just wraps the existing
services where needed. All it does is offering "Application" services that's
whay it an API. To know what this means, you'll have to run the v2.0 of the
Framework on Vista, there you can take advantage of some new services, not
because they are offered by the framework, no, because they are part of the
OS and it's Win32 extensions!

| Including things as culture, security or whatever, which are not really
| needed in a runtime.

Hmm.. not sure what you mean by this? But if you think that culture,
security etc.. are not part of the OS, then you are wrong again.

CLR/CLI is a part of the Framework, it is for me not
| the framework.
|
Yep, that's exactly what I said in above message, the Framework = CLR +
Framework Libraries.
| > A large part of framework classes themselves, are also wrapping the
| > platform
| > specific API's (think file I/O, Security service API's )or some
| > specialized
| > API's (think ADO.NET, SQL Server etc..), or are calling into COM based
| > services to present an OO view of the services to the user of the
| > framework.
| > The classes that wrap the OS or specialized services are not restricted
to
| > a
| > specific namespace or assembly, and that's what John implied, but he is
| > wrong.
|
| I am not discussing what it does in Win32. Will you tell me that it will
| work in the same way as this in WinXQ. (Some not existing version maybe
| after WinFX). Where the Net still can be as an independable layer between
| hardware, OS and whatever other parts, however in a more to the user and
is
| situation tailored way.

It works the same way in Vista at least, and it will work the same way as
long as the OS is Win32 based. That's my point exactly, the Framework is
actually a wrapper around Win32, which is the Windows API currently in use
(and in use in the upcoming Vista release). On other OS platforms it's a
wrapper around some other API, but it's still an API that wraps something to
call into the OS services, or otherwise stated it virtualizes the underlying
OS and other services.
|
| > Only a few of the framework classes are not calling into the 'unmanaged'
| > API, simply because they are self contained, they don't need any
auxiliary
| > services.
| >
| I wrote some messages ago already that I am not writing about what is now.
| That a car was the most efficient driving on coal in 1890 (and in war time
| in the Benelux) does not mean that coal would forever be the best fuel for
a
| car.

Sorry ... but you seem to largely overestimate the importance of .NET on
Windows, to stay in the anology, to me .NET is nothing more than an early
sixties semi-automatic transmission, which makes it possible for some people
who would otherwise be scared off by a "manual transmission" to drive a car
(at least that's what they think).

Willy.
Jan 24 '06 #26

P: n/a
Jon,

I've read your replies and I'm still baffled by it.

Please state clearly why you assumed Richard's reply, which included a
link to statistics *clearly* gathered entirely on Windows systems, was
referring to Linux.

I have given you that already as an answer as only answer on your first
reply.

And please again as so often asked to you. Don't tell in newsgroups what I
have written, without a *correct and complete* quote or link of the text
that I wrote.

With this you create long messages threads, from which even others think
that I wrote it, but it was you who was telling it.

Cor
Jan 24 '06 #27

P: n/a
Cor Ligthert [MVP] wrote:
I've read your replies and I'm still baffled by it.

Please state clearly why you assumed Richard's reply, which included a
link to statistics *clearly* gathered entirely on Windows systems, was
referring to Linux.
I have given you that already as an answer as only answer on your first
reply.


Where? You appear to have completely ignored it. Rather than keeping on
claiming you've already answered my question, why not either give that
answer again or quote *exactly* where you answered it first time? You
stated that you weren't blind and that you could read, but that doesn't
answer my question.
And please again as so often asked to you. Don't tell in newsgroups what I
have written, without a *correct and complete* quote or link of the text
that I wrote.
You've often asked that without actually showing any sign of me
misleading anyone.

Anyway, here's the correct and complete quote. You wrote the text
without any leading angle brackets. John wrote the text with two
leading angle brackets. Richard wrote the text with one leading angle
bracket.

<quote> John Timney ( MVP ) wrote:
I would expect it to only call any API's when its handling calls
within the Microsoft namespace, as this touches more on microsoft
operating system functionality - whereby the remaining namespaces are
cross platform and would be very unlikely to drop into API's.
I don't think you've thought this through John.
I assume that what you give is for Linux. Most of us know what it is
for
current Windows Win32 systems. In my opinion is John however talking
about
other systems. Of course is Net mainly a layer upon the OS. It would be
very
crazy when it would gives other results way called by Net than direct
by
other use of that.

Dit you think about that as John obiously did.
</quote>

So, I'm asking about the "I assume that what you give is for Linux"
part. As that was underneath text written by Richard, it's only fair to
assume that you were responding to Richard's text. Now, what do you
believe it was that Richard was giving "for Linux"? His entire reply
was pretty clearly about Windows in my view.

If you were actually responding to John's text (and making assumptions
about what John was referring to), you should have followed-up on
John's post instead of Richard's.
With this you create long messages threads, from which even others think
that I wrote it, but it was you who was telling it.


And where *exactly* have I done that in this thread (or in any other)?

Jon

Jan 24 '06 #28

P: n/a
Willy,

I overreaded that *and a set of libraries* I was to much focussed on that
runtime, sorry.

Our idea are in my idea not much in different. However I have the idea that
a platform interface not always will be called an API. (Application Program
Interface) for every platform that there will be. And I am sure that if that
is so, than they are completely different for every platform (where every
win32 is for me one) (With the exception maybe for OS/2 which is build with
the same basic tools).
As such it doesn't extend the OS, that is, it doesn't offer any extended
OS services it just wraps the >existing services where needed.
You have written something with almost the same context as well. I answer
it in one time.

If that is true, than there is no seperated Framework needed for different
languages. We both know that for the Dutch the 2.0 not yet available (I find
it takes terrible long, so there should be a lot that is not yet in the OS).
Sorry ... but you seem to largely overestimate the importance of .NET on
Windows, to stay in the anology, to me .NET is nothing more than an early
sixties semi-automatic transmission, which makes it possible for some
people
who would otherwise be scared off by a "manual transmission" to drive a
car
(at least that's what they think).


Probably is that a different idea between us. I think that .Net makes it in
future possible to say goodby to the old Win32 parts. That is in my idea
more important than a type of transmission in a car.

Maybe we become both old enough to see who is right,

On the things I did not requote, I have no comments with means that I have
no reasons to disagree..

:-)

Cor
Jan 24 '06 #29

This discussion thread is closed

Replies have been disabled for this discussion.