MS getting rid of dot net?

[Richard Grimes [MVP]]

WinFX is the current popular opinion. Last I heard Longhorn will
spell the end of hte individual framework and the beginning of a
plain managed API.

I doubt it. The recent removal of WinFS from LH and the annoucement that
Avalon and Indigo will be available to other versions of Windows seems to me
to mean that the .NET framework will remain a separate entity.

As to a plain managed API, that sounds to me to be a bit optimistic, indeed
from the evidence I have just mentioned, it sounds to me that Longhorn will
be an unmanaged operating system with .NET bundled, rather than the PDC tech
preview which basically would not work without .NET.

But who knows, marketing departments like to change things far to
often.

Indeed, first it was COM+ 2, then NGWS and finally .NET. Anyone remember
cool?

Richard

 

[Daniel O'Connell [C# MVP]]

I doubt it. The recent removal of WinFS from LH and the annoucement that
Avalon and Indigo will be available to other versions of Windows seems to
me to mean that the .NET framework will remain a separate entity.

As to a plain managed API, that sounds to me to be a bit optimistic,
indeed from the evidence I have just mentioned, it sounds to me that
Longhorn will be an unmanaged operating system with .NET bundled, rather
than the PDC tech preview which basically would not work without .NET.

It seems that way,...but, if Longhorn comes out in the way you are
suggesting, it'll be little more than XP SP3, .

Actually, the loss of WinFS is troubling, the externsion of Avalon to other
platforms is distressing(I'm sure they are going to cut it down for that
purpose), although it seems to me Indigo was always supposed to come out for
atleast XP and 2k3 server.

The really sad thing is that most of this is due to whiney people who insist
on XP supporting everything.

The question is what WinFX will be and what other bits they havn't announced
will be written in. My primary hope is that WinFX becomes a real api
layer(meaning virtually no pinvoke needed for anything that is achievable in
managed code) that is expected and as stable as the windows API has been.
This new framework version every year is really getting old quickly.
Functionality additions should be done with additional assemblies just like
everyone else has to do.

Really, I expect managed code in longhorn to be something like COM was in
2k: offered a fair amount of old functionality and some new stuff(a very
small porition of which isn't available via the Win32 api), I do not expect
the framework to be simply an add on as I do expect explorer and other
applicatinos(maybe even IE7) to be using avalon and likely will be a C++/CLI
mux of managed and unmanaged instead of forcing COM interop.

And I can still hold out hope that COM will finally start to die, can't I?
. As it is I'm unwilling to write windows extensions because of the
inherent nastiness of COM, even .NET wrappers suck pretty badly and are
usually more work to implement than they are worth.

 

[Guest]

I agree that .NET is too common name. A tip for searching: dotNet is often
used to identify .NET

 

[Richard Grimes [MVP]]

It seems that way,...but, if Longhorn comes out in the way you are
suggesting, it'll be little more than XP SP3, .

Actually, the loss of WinFS is troubling, the externsion of Avalon to
other platforms is distressing(I'm sure they are going to cut it down
for that purpose), although it seems to me Indigo was always supposed
to come out for atleast XP and 2k3 server.

Yes, that's true about Indigo, it wouldn't be as useful if other versions of
Windows didn't have access to it (it is all about communications between
machines, after all).

My primary hope is that WinFX becomes a
real api layer(meaning virtually no pinvoke needed for anything that
is achievable in managed code) that is expected and as stable as the
windows API has been. This new framework version every year is really

Indeed. The problem is baggage from previous versions. I have always felt
that .NET was released too early. There are some parts which are mere
wrappers over Win32 with little thought for producing a new paradigm. The
problem with releasing such classes is that people will use them and so the
framework will always have to support them. I would have preferred that a
cutdown core framework was released and that the extra stuff got released
later as and when Microsoft got the design right.

Really, I expect managed code in longhorn to be something like COM
was in 2k: offered a fair amount of old functionality and some new
stuff(a very small porition of which isn't available via the Win32
api), I do not expect the framework to be simply an add on as I do
expect explorer and other applicatinos(maybe even IE7) to be using
avalon and likely will be a C++/CLI mux of managed and unmanaged
instead of forcing COM interop.

We will just have to wait and see.

And I can still hold out hope that COM will finally start to die,
can't I? . As it is I'm unwilling to write windows extensions
because of the inherent nastiness of COM, even .NET wrappers suck
pretty badly and are usually more work to implement than they are
worth.

The litmus test will be whether the shell in Longhorn will be managed and
hence get rid of the COM-like shell extensions. (Win32 shell extensions
don't actually use COM, even though they are implemented with COM
interfaces).

Richard

 

[Richard Grimes [MVP]]

i heard a rumor that microsoft is throwing dot net out the window. is
this true?

BTW do you have a link to somewhere that mentions the rumour?

Richard

 

[Daniel O'Connell [C# MVP]]

My primary hope is that WinFX becomes a

Indeed. The problem is baggage from previous versions. I have always felt
that .NET was released too early. There are some parts which are mere
wrappers over Win32 with little thought for producing a new paradigm. The
problem with releasing such classes is that people will use them and so
the framework will always have to support them. I would have preferred
that a cutdown core framework was released and that the extra stuff got
released later as and when Microsoft got the design right.

Yes, I quite agree. The framework and CLS should not have been released
pre-generics, at the least, and preferably choosing either
delegates(preferably) or interfaces for passeble code chunks, the curent
half and half mechanism is frustrating.

The litmus test will be whether the shell in Longhorn will be managed and
hence get rid of the COM-like shell extensions. (Win32 shell extensions
don't actually use COM, even though they are implemented with COM
interfaces).

Yes, that certainly will. I worry quite extensivly that they will choose to
use wrappers instead of re-writing the extension mechanism(it could use some
cleanup, the interfaces are getting pretty messy at this point).

 

[Jon Skeet [C# MVP]]

Yes, I quite agree. The framework and CLS should not have been released
pre-generics, at the least, and preferably choosing either
delegates(preferably) or interfaces for passeble code chunks, the curent
half and half mechanism is frustrating.

While I agree that generics should have been in there to start with, I
think having both delegates and interfaces is fine. Delegates are handy
when you want to pass a *single* method pointer (effectively) but what
about when there are more members than that which should be
implemented? What, for example, would you do for IList?

 

[Daniel O'Connell [C# MVP]]

While I agree that generics should have been in there to start with, I
think having both delegates and interfaces is fine. Delegates are handy
when you want to pass a *single* method pointer (effectively) but what
about when there are more members than that which should be
implemented? What, for example, would you do for IList?

Sorry, didn't mean interfaces and delegates as a whole, but as the container
for simple code chunks passed to a method. For example, the way that
IComparer<T> and Comparison<T> work with List<T>.Sort()(I know that
IComparer<T> does more, but their usage in Sort is identical). They both
basically do the same thing in the end and both are supported, however it
increases the complexity of List.Sort() and classes further down(or up,
whichever way you prefer) the composition chain may need to continue support
for both methods lest their classes choice between delegates and interfaces
conflicts with another classes choice which would use the same comparison
code, forcing end users to support both. It is not a serious addition of
complexity, but its one that would have been nice to avoid.

Alot of existing code I've seen tends to use interfaces, but with the coming
of anonymous methods, I see quite a bit of movement towards delegates, this
will eventually result in mixed code bases where IComparer<T> is used in
some places but other classes require Comparison<T>(luckily that one maps
directly to IComparer<T>.Compare, but other instances will spring up)

Really rather a minor thing, but one that is already a clear point of legacy
in some designs IMHO.

 

[Guest]

Hi there,

..Net is okay but I think who ever created this name is a radical and
eccentric - no offence! Don't take my word for it because I'm no computer wiz
but I recommend something simple, like Microsoft Network etc ... Hey, what
about namely it after a fruit, say "Orange" or even "Peaches" - hahaha!
That'll have Bill Gates standing on his head ... haha. Just Joking, don't
take this seriously.

Domino

 

[User]

Be careful, they might come back with Microsoft Bob.