MS getting rid of dot net?

[Guest]

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

 

[Chris, Master of All Things Insignificant]

Yes, but it isn't happening until they stop creating operating systems.

Chris

 

[Daniel O'Connell [C# MVP]]

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

The name? Yes.

The framework itself, no, I don't think so. Although its name is expected to
change in the next couple of years.

 

[cody]

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

The name? Yes.

The framework itself, no, I don't think so. Although its name is expected to
change in the next couple of years.

Which name? .NET? How will they name it then?

M$JAVA? WINAPI2? COM++?

 

[Daniel O'Connell [C# MVP]]

Which name? .NET? How will they name it then?

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.

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

M$JAVA? WINAPI2? COM++?

Cute. Stupid, but cute.

 

[Sylvain Lafontaine]

How about: Active-Net ?

S. L.

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.

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


Cute. Stupid, but cute.

 

[Guest]

How about a name that is easy to find in search engines. ".net" brings up
nearly every page on the internet, and most search engines ignore the dot.

WinFX would probably do fine. It's short and fairly unique.

 

[cody]

How about a name that is easy to find in search engines. ".net" brings up

nearly every page on the internet, and most search engines ignore the dot.

Indeed, I often have a hard time to find .NET things due to this. But why
didn't they think on this in the first time?
..NET is a stupid word anyway. People might think on a top level domain or
the interNET.

WinFX would probably do fine. It's short and fairly unique.

But I don't think they will name it WinFX - it doesn't sound platform
independend and they pretend it to be platform independend - this would be
bad marketing strategy.

 

[C# Learner]

Indeed, I often have a hard time to find .NET things due to this.

Yeah. Currently, it's not possible to search for ".NET" in Google. I
e-mailed them about this and was told that they'll /look into/ allowing it
as a search term.

I agree with you on it being a bad name.

 

[Daniel O'Connell [C# MVP]]

But I don't think they will name it WinFX - it doesn't sound platform
independend and they pretend it to be platform independend - this would be
bad marketing strategy.

Its as platform independent as MS wants it to be. The .NET framework is not
terribly platform independent either, have you seen a Microsoft .NET
implementation for linux yet? There have been proofs of concept, but they
aren't called .NET, rotor is a *CLR* implementation, mono is a *CLR*
implementation. There is

WinFX is platform independent in that it will handle 32 and 64 bit windows
as well as PDA cores that run windows variants, which is about all I expect
that MS itself ever intends to write for.

 

[Kapil M]

Currently the .NET lies above the Win32 API's (like a wrapper) . The idea is
that in the next few years they are going to do away with Win32 API's ,
giving .NET direct access to the underlying hardware. Win32 is from the
DOS-era and hence, is really not the best approach to go forward.

-kapil

 

[Richard Corfield]

I've noticed that Dot-Net really follows the Windows model, where Java
is more UNIXy in architecture. Although there's some convergence
(Windows moving to be more like UNIX in many ways), there are still
some fundamental differences and assumptions. Also, in the Dot-Net
books I'm reading, programmers are quite positively invited to talk to
Win32 functions and implement Win32's WndProc, models which don't map
well onto other systems perhaps. WinForms seems quite a thin wrapper
around Windows.

Mono is an interesting project though. It takes the best of the C#
language and the CLR. It may even take some good things from the
framework, but it has other related libraries such as Gtk# for
windowing. I've not tried these, but wonder if they'll be more UNIXy in
their model. I like Java for its well thought out object orientated
design, with strong patterns like Model View Controller, and I like the
component architecture in Dot-Net, so a best of both worlds would be
interesting if someone does it.

The main advantage I see of the CLR for Microsoft is that it is
processor architecture independent. Without it, and with the arrival of
64 bit systems, developers including Microsoft would have to maintain
and ship different copies of their software. The CLR approach, like the
Java Bytecode approach, allows last minute compilation for the platform
that the software happens to be installed on, with only the need for
one install image, making software development and distribution cheaper.

 

[Daniel O'Connell [C# MVP]]

I've noticed that Dot-Net really follows the Windows model, where Java
is more UNIXy in architecture. Although there's some convergence
(Windows moving to be more like UNIX in many ways), there are still
some fundamental differences and assumptions. Also, in the Dot-Net
books I'm reading, programmers are quite positively invited to talk to
Win32 functions and implement Win32's WndProc, models which don't map
well onto other systems perhaps. WinForms seems quite a thin wrapper
around Windows.

Yes, System.Windows.Forms is quite Win32ish, but it is also not specified in
the BCL specification either, I don't believe. The majority of the CLR is
pretty platform independent, but MS's implementation and common usage
patterns certainly aren't.

Mono is an interesting project though. It takes the best of the C#
language and the CLR. It may even take some good things from the
framework, but it has other related libraries such as Gtk# for
windowing. I've not tried these, but wonder if they'll be more UNIXy in
their model. I like Java for its well thought out object orientated
design, with strong patterns like Model View Controller, and I like the
component architecture in Dot-Net, so a best of both worlds would be
interesting if someone does it.

Mono implements the entire CLR spec, as I understand it, including the C#
language and the entire BCL. Other things, like WinForms, ASP.NET and
ADO.NET are, to some extent atleast, supported, but none of them are in the
standard.

Java has some interesting OO patterns and some of its libraries are quite
well thought out, but then others are horrible. I found Swing to be
ridiculously hard to use and oddly patterned and I consider the web tech
support to be very diseparte and somewhat confusing, so I think the two are
rather on equal ground as far as design goes(with .NET maybe having an
advantage in that the designers were able to see where java screwed up and
fix some of them).

MVC is not terrible, but I don't think the langauge or runtime really needs
to support it directly. .NET is certainly capable of doing MVC, the BCL just
does not provide anything to support it.

The main advantage I see of the CLR for Microsoft is that it is
processor architecture independent. Without it, and with the arrival of
64 bit systems, developers including Microsoft would have to maintain
and ship different copies of their software. The CLR approach, like the
Java Bytecode approach, allows last minute compilation for the platform
that the software happens to be installed on, with only the need for
one install image, making software development and distribution cheaper.

Yes, this certainly is a nice upside. Hopefully the JIT will mature as well
and provide more dramatic performance enhancements as the app scales up
processors. A JIT\native cache utility that could recognize and handle
situations where SIMD instructions or the like would make sense would be
fitting, IMHO.

It would also be interesting to see how CPU designers could work in a world
where very little code was directly tied to the chips architecture and
performance characteristics, but Java and .NET are not going to cause that
to come around

 

[Daniel O'Connell [C# MVP]]

Currently the .NET lies above the Win32 API's (like a wrapper) . The idea
is
that in the next few years they are going to do away with Win32 API's ,
giving .NET direct access to the underlying hardware. Win32 is from the
DOS-era and hence, is really not the best approach to go forward.

Actually, Win32 is not going to die any time soon. WinFX, as of the last
public information I'm aware of, will basically be a combination of Win32
wrappers and replacements(wrapping what must be, re-writing that which can
benefit), with many\most new extensions being written primarily in managed
code and provided via COM or other unmanaged means if they need to be.
Something similar to the movement of some small portions of functionality to
COM in the 2k and XP era, just on a grander scale.

Also, .NET directly to hardware will likely not happen, atleast not to the
extent I think you mean. I doubt the kernel or device drivers are going to
go to managed code within the next decade, if they ever do. Even Avalon
doesn't appear to reach all the way into the kernel using managed code, but
hides the unmanaged stuff from most people.

Also, Win32 was designed for NT, not any dos based OS. Win95 and 3.x with
the 32bit runtiem supported Win32, but it was certainly not from the
"dos-era", it is an era in its own right, IMHO.

But, you are right, it doesn't look like the way forward anymore than POSIX
does.

 

[cody]

WinFX would probably do fine. It's short and fairly unique.

Its as platform independent as MS wants it to be. The .NET framework is not
terribly platform independent either, have you seen a Microsoft .NET
implementation for linux yet? There have been proofs of concept, but they
aren't called .NET, rotor is a *CLR* implementation, mono is a *CLR*
implementation. There is

WinFX is platform independent in that it will handle 32 and 64 bit windows
as well as PDA cores that run windows variants, which is about all I expect
that MS itself ever intends to write for.

I also won't expect something from MS - they hope that others will do the
work for them and theses others do.
But that was not my point, MS claims that .NET is platform independent,
therefore it would be a bad idea for them renaming .NET in WinFX because
this name suggests windows only and they don't want the customers to think
that.

 

[Richard Blewett [DevelopMentor]]

There are a couple of naming issues here:

There is a specification called the Common Language Infrastructure (CLI) which is an ECMA spec (submitted by Microsoft on the early days of .NET). The CLR, ROTOR and Mono are implementations of that spec - the first two from Microsoft the third from Ximean/Novell.

The CLI is a platform independent spec. No-one has claimed that the CLR is platform independant, its the Windows implementation of the CLI. As such, WinFX is the taking of the Windows platgform and fully exposing it using CLR based code. This API being the replacement to Win32 as the core API for Windows programming

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Its as platform independent as MS wants it to be. The .NET framework is not
terribly platform independent either, have you seen a Microsoft .NET
implementation for linux yet? There have been proofs of concept, but they
aren't called .NET, rotor is a *CLR* implementation, mono is a *CLR*
implementation. There is

WinFX is platform independent in that it will handle 32 and 64 bit windows
as well as PDA cores that run windows variants, which is about all I expect
that MS itself ever intends to write for.

I also won't expect something from MS - they hope that others will do the
work for them and theses others do.
But that was not my point, MS claims that .NET is platform independent,
therefore it would be a bad idea for them renaming .NET in WinFX because
this name suggests windows only and they don't want the customers to think
that.

 

[Richard Corfield]

Java has some interesting OO patterns and some of its libraries are quite
well thought out, but then others are horrible. I found Swing to be
ridiculously hard to use and oddly patterned and I consider the web tech
support to be very diseparte and somewhat confusing, so I think the two are
rather on equal ground as far as design goes(with .NET maybe having an
advantage in that the designers were able to see where java screwed up and
fix some of them).

Do you think Java's web technologies support has got better since
Java-Server-Faces came about? Also there are technologies such as
Struts which make a godo framework.

Yes, this certainly is a nice upside. Hopefully the JIT will mature as well
and provide more dramatic performance enhancements as the app scales up
processors. A JIT\native cache utility that could recognize and handle
situations where SIMD instructions or the like would make sense would be
fitting, IMHO.

The first such technology I'm aware of was the AS400, which apparently
had software shipped and installed as bytecode, and the native code
cached by the system. The administrator worked in terms of the
bytecode, and the system managed the native.

A similar system for Java on UNIX would be great! The UNIX (and Linux)
library system is already designed to manage multi user code sharing
and even side by side versioning for native code. It's well matured and
has been doing that for years. It even has features like swapping the
code from (no need to swap to) the image stored on disk so further
increasing efficiency.

For example, 10 users could be running xterm, 3 of those and 2 more
could be running xclock (boring users, oh well). Despite 15
applications running, there'll be only 1 copy of xterm, one copy of
xclock and one copy of the X libraries in memory shared by all of them.


I've heard that Java 1.5 addresses some of the limitations of
effectively having a seperate instance of the program, bytecode or
native, for each application, but a complete solution where Java (or
Dot-Net as this is a Dot-Net newsgroup) classes can be effectively
shared between applications and users on a multi user system will bring
a lot of advantages back. Imagine all Swing applications sharing one
instance of Swing, and once the first one has been loaded, startup for
the rest is so much faster as Swing and so much more bits of
fundamental Java are already in memory - like when you start your
second xterm on Linux.

It looks like Dot-Net may be closer to this than Java, though I am
unsure whether Dot-Net delivers it (Windows not being renouned for
multi-user prowess), or how far away Java is from delivering it. Its a
runtime thing, so the language in either case need not change, apart
from versioning perhaps (does that need to be explicit or can it be
done implicitely?)

- Richard

 

[Boyd Ferris]

I have written a few console applications in .NET that run on Linux.
(The program processes a text file and manages data in a SQL Server
database.) I had no problem using Mono; it took my Windows compiled
..NET programs without any problem.

- Boyd

 

[Daniel O'Connell [C# MVP]]

I have written a few console applications in .NET that run on Linux.
(The program processes a text file and manages data in a SQL Server
database.) I had no problem using Mono; it took my Windows compiled
.NET programs without any problem.

Yes, and I would bet it ran on bits that were either emulated in mono(like
ADO.NET), and on standardized items. Mono has gone a long way towards
emulating waht was not designed to be platform independent, but isn't
capable of getting everything 100%.

And, anyway, the bigger point was the *.NET framework* itself would never be
ported to linux, not that a linux box couldn't conceivably run some apps
compiled by the .NET framework. Therefore the .NET name does not need to be
platform independent.

 

[Guest]

I doubt Microsoft are going to be writing much of the OS in managed code for
quite some time. They may release pre-compiled binaries derived from managed
code (I heard this was on the cards for VS.2005/6), but MSIL is too
high-level to protect their IP.

Although I hope they keep the future .NET Framework remain in MSIL; I'd be
lost without Lutz Roeder's .NET Reflector which has saved me many times when
I've got stuck with weird behaviour in the .NET base classes.

[And yes I have a Tablet PC and I have gone through the inking classes and
most of the really interesting stuff is to internal calls to a unmanaged DLL].