Nothing of .Net in Longhorn?

turnitover writes "We've been waiting for Longhorn before we really get on the .Net train, but should we bother at all? According to Mary Jo Foley at Microsoft Watch, Longhorn won't be based on .Net at all. Foley, who's usually right on target, calls this MS's 'dirty little secret'." From the article: "We're guessing that Microsoft will maintain that nothing has changed-that no one ever promised that the .Net Framework 2.0 would be the foundation for Longhorn. But developer types we've been chatting with seem to find this update a newsworthy revelation."

asdf

[professorhojo]

from microsoft's official page [microsoft.com] on preparing for longhorn, i quote: "Preparing for Longhorn - Longhorn builds on existing security and Microsoft .NET Framework knowledge. Use the resources on this page to understand why it is important to adopt these concepts today, and discover how they will apply to Longhorn tomorrow."

the key here is the word knowledge: "longhorn builds on ...NET framework knowledge"

which could possibly be construed differently than "longhorn builds on ...NET framework".

who knows? maybe i'm reading too much into it..

Re:asdf

[jav1231]

This is why you should be able to club marketing reps to death.
Of course, Windows in general is an example of why you should be able to club marketing reps to death.

Re:asdf

[c0d3h4x0r]

This is why you should be able to club marketing reps to death.
Of course, Windows in general is an example of why you should be able to club marketing reps to death.

Honestly, do we even need an example to justify why you should be able to club marketing reps to death?

Re:asdf

[clem]

I thought it was so you wouldn't damage their valuable Armani pelts...I mean suits.

Re:asdf

[aoteoroa]

This is why you should be able to club marketing reps to death.

After working as a programmer for 6 years I have heard a lot of marketing hype through brochures, white papers, and information seminars and I have come up with this principal: "Never promise that a task can be done based on what documentation or white papers say."

When a new API, IDE, framework or whatever is realeased I try building a small prototype, or test application, and only after first hand experience do I promise a project manager that it can be done. Otherwise I tell him that this new technology represents an unknown that could (is likely to) throw our timeline out of whack

Re:asdf

[Monkey-Man2000]

Yeah, this probably means they knew that the .NET framework wouldn't work for some reason as a basis for an OS.

Re:asdf

[MynockGuano]

From TFA:

But given how late [.Net Framework 2.0] is, and how new it would be, [Microsoft chairman] Bill Gates realized it would be foolish to build important pieces of Longhorn on top of .Net."

Not that building critical elements upon instabilities has ever stopped them before, of course.

Re:asdf

[connorbd]

I'd say the real issue is that Microsoft has a problem with eating its own dogfood. If they had to build on .NET 2.0, you'd better believe they'd have it done by now, especially if that was their development platform.

Don't forget, Solaris utterly sucked until Sun forced its developers off of SunOS -- it didn't get better until the developers actually had to work with it.

Am I dreaming?

[acidrain]

Funny, I am shocked that anyone seriously thought they would write an OS on top of a virtual machine. Writing core OS functions on top of a virtual machine is pure lunacy. Crazy talk. La la la...

Remember when people made fun of M$ for using C++ in WinNT? Ok so times have changed but that doesn't mean that you write perfomance sensitive code that will be used by billions of people on top of an interpreter. Consider the cost/benifit ratio of the extra development effort. After all, they are writing th

Re:asdf

[mmusson]

.NET is more or less equivalent to the Java environment in that you have languages that compile to byte code (CLR or JVM). This is popular for writing applications but is a horrible idea for an OS kernel.

Kernels need to be small and efficient. Could you imagine someone criticizing the Linux kernel for not being written in Java?

Re:asdf

[eggoeater]

I'm not sure where everyone is getting this... there's plenty of stuff in Longhorn that will require .NET CLR 2.0. The best example is WinFX. You don't /have/ to use WinFX but you better believe Win32 will be depricated in a subsequent version.

Re:asdf

[Fulcrum of Evil]

You don't /have/ to use WinFX but you better believe Win32 will be depricated in a subsequent version.

Oh sure, they just deprecated win16 for 64 bit windows. Why're they going to run off and deprecate the bulk of their installed base? If you have to rewrite your crappy old custom windows apps, maybe you'll start looking at mac.

Re:asdf

[NitsujTPU]

So, here's the deal.

My understanding is that people at MS have had difficulty doing a number of operating system "things" in .NET

This is no shocker to anybody whose done any extensive .NET development... it's pretty nice for some things, but others are just impossible.

Have you for instance:
1) Written a device driver
2) Written memory management
3) Manually changed context

Now, you may say "oh, but that's all automagic," which is where you are wrong. If you are writing an OS, you need to do these things. Developers on MS have been trying to use .NET as much as possible, but sometimes have used C++ out of necessity.

Not only should it not be surprising, but MS shouldn't be picking up any flack over it. Really, it is quite discrediting to the free software community to brow-beat MS over every move that they make. If you are going to have a pricipal, you really need to apply it with an even hand.

This comment wasn't directed entirely at the parent. Honestly, I see mostly MS users here discussing this... which is also an interesting commentary on Free Software.

Re:asdf

[ednopantz]

In other news, screwdrivers make bad hammers.
Why should all software be written in one or another language/platform?

Re:asdf

[pjrc]

but MS shouldn't be picking up any flack over it.

Not long ago, Microsoft launched a big PR effort, touting the superiority of proprietary software development, and specifically windows over linux. Why? Because with Microsoft, you get a 3 year road map. A single entity is in control of where the technology is headed and where it'll be in a few years. They implied that open source development has no control, no known future. FUD, emphasis on the "U" for Uncertainty.

Turns out, Longhorn is very late and lacking in many of the interesting new features that were promised. The 3 year road map turned out, in reality, to be more wishful thinking and vapor than some dependable scheduled release of upcoming technologies. The supposed advantage of depending on proprietary, rather than risking business plans on the uncertain future of linux and free software, turned out to be just empty promises.

THAT is why plenty of people should be "picking" on Microsoft. They made promises. They spread FUD, specificly claiming their future was reliable because they made dependable promises while the competition generally did not.

If there's a public backlash and negative PR, well, they deserve it. If they gave everyone unrealistic expectations, that was their own doing. Absent their history of bashing linux for lacking their 3 year planning, I might buy into your assertion that they deserve a break and a little understanding for falling short of overly ambitious plans. But their prior conduct, spreading FUD... not just by word of mouth, but with massive advertising dollars, acusing their competition of not having solid plans for the future, casts their failure to meet their own plans in an entirely different light.

The truth is they consistently fail to meet their own goals. Yet some people STILL buy into the "nobody is managing open source future development, so it's unpredictable and has uncertain future". When will these gullible people finally realize Microsoft regularly over promises and under delivers, that their supposedly superior planning is just a big sham?

Maybe, if instead of giving them a break, we all instead continue to reinforce Microsoft's the well-deserved reputation for vaporous plans and late delivery, it'll put the damper on their hypocritical FUD ?

Re:asdf

[IntlHarvester]

Microsoft does spread FUD. Microsoft does pre-announce products and over-promise on release dates.

However, Microsoft also has an extrodinary history of actually delivering what they promised to (eventually). People thought that Windows 95 was technically impossible, but they shipped it. People thought NT5 (2000) would never see the light of day. Even Cairo 's announced features mostly shipped, in bits and pieces. Historically, you could take a MS product plan to the bank, which kept customers loyal to MS's direction.

That Longhorn seems to be proceeding so aimlessly and as such a soft target indicates a management breakdown. They used to be quite good with delivering large projects up there -- did the talent cash out?

Re:asdf

[Deviate_X]

Microsoft have written one OS in .NET/c# [msdn.com]

However no one _ever_ said the the longhorn kernel would be re-written in .net

So Why .NET?

[geomon]

If Microsoft seems unwilling to bind .NET to its next flagship OS, then why all the rush to produce .NET-capable products? Is .NET going to be a wash? Why bother worrying about Mono's fate as well? If Microsoft doesn't seem to work hard to integrate it into their primary platform, then should the Mono developers continue to look over their shoulders?

Is .NET another Microsoft vaporware?

Instead, the .Net Framework will be the core for a small subset of Longhorn, specifically the Windows API Platform (WAP), which consists primarily of the "Avalon" Windows presentation system and the "Indigo" Windows communications system, our tipsters say.

Okay, but will Avalon be a core system in Longhorn? The new file system is out, and some of the early discussion from Microsoft indicated that Avalon might be 'out' until after the first version of Longhorn ships.

I use Microsoft products and am really getting confused about their software roadmap.

Re:So Why .NET?

[ZephyrXero]

I imagine they're ditching .Net after the realization that mono is letting even more Windows apps come to Linux (they're only real threat).

Re:So Why .NET?

[daviddennis]

I could have sworn I read something about Avalon not making it into Longhorn.

Now we know .net isn't going to be a primary component of Longhorn, despite products being named after .net for eons. Does this mean that we never have had .net, or that the meaning of it has changed?

If Avalon might or might not be in Longhorn, and Longhorn isn't .net added to Windows, and Longhorn isn't WINFS, well ... exactly what IS Longhorn, anyway?

D

Re:So Why .NET?

[GoatEnigma]

Uh... what the hell are you talking about? "Does this mean that we never have had .net"? Think before you post for craps sake.

.Net is three things - a strategy, a platform, and a suite of development tools. The strategy has been in place for five years. The platform has been in place and stable for three years. The development tools have been good for almost two years.

Why would Longhorn "be" WinFS? Man, go do some reading before you post. WinFS is a file system that's been in development for almost 10 years. Longhorn was supposed to finally implement it. Avalon is the UI subsystem of Longhorn, and yes, it will be in Longhorn, you're just spreading uncertainty with your crap that you "swear you read it wasn't". Don't post that crap without a link.

Go read MSDN if you want to find out what longhorn is. It's about the most useful development reference on the internet, right up there with the php site.

Re:So Why .NET?

[toddbu]

The strategy has been in place for five years.

I want to ask a really serious question here - What exactly is the .Net strategy? I ask this question because people ask me what .Net is, and after all this time all I can only tell them is that it's given us a new programming language similar to Java. Forget the FUD, what is .Net really? I'm not looking for a link to MSDN. I'm looking for is a single concise statement about the technology. For example, I could say that managed code is "a replacement for traditional programming techniques that focuses on eliminating mistakes made by novice programmers thereby improving program stability and security". Is there such a one-liner for the .Net strategy?

Re:So Why .NET?

[FriedTurkey]

.NET is marketing. Microsoft has applied it to a wide array of technologies. It has come to the point that .NET doesn't really mean anything anymore.

Re:So Why .NET?

[pboulang]

.NET is maybe best defined as the CLR (Common Language Runtime). You have the abilitiy to write in VB, Eiffel, C# and others that compiles down to similar intermediary code, just like Java does. If you have the CLR running on multiple OS's (I believe I heard that they had it running for BSD, but haven't heard anything about it recently) then you can run the .NET compiled code on any of those OS's.

Now, just like Java, .NET programming removes a whole lot of things from the programmers hands, which certainly makes for fewer mistakes (strongly typed, memory management, etc) but does force developers to leave the .NET framework and use (for instance) C++ to write a device driver (coming full circle on why an OS using only .NET isn't currently possible)

Java uses a virtual machine, .NET uses a CLR (not quite as virtual, more an API on a machine), so I think if you wanted to come up with a one liner for .NET, you should come up with one for Java and then simply append the words "... in order to take over the world."

Re:So Why .NET?

[CaymanIslandCarpedie]

OK, here is the best I can do with the .NET strategy question while keeping it concise ;-)

.NET is the name MS gave its goal of making interoperable systems very simple so you can easily and seemlessly have multiple systems on any platform all working together. This isn't just a MS goal, but .NET is the name they gave it. Besides such an abstract statement, you can look at SOA and XML web-services. Again, these aren't technologies unique to MS but they are examples of the implementation of the .NET strategy.

Now why call this .NET? Thats a good question ;-) Many will say .NET is just marketing, and its very true that naming it .NET was marketing. However, .NET is not JUST marketing. The name is marketing, but the underlying strategy and goals are very real (and you can see plenty of implementations today).

The other issue was MS didn't really have any way to accomplish this ".NET strategy" when they came up with it. Luckily, I've never had to try SOA or web services with the VS6 family of tools, but I know those who have and said while it is possible, its one of the more painful things to try. So they needed new tools to enable this strategy. Hense, the .NET Framework. The .NET framework is more than JUST making SOA/web service stuff easier (they really needed to update thier stuff anyway so did that as part of .NET Framework). The .NET Framework does do a good job of making this type of interoperablity very easy. Next they needed tools to build applications for the .NET Framework. Thus, VS.NET was born. VS.NET is simply a very productive set of tools to allow you to build .NET applications.

As part of the .NET Framework was also the CLR/CLI, this allow you to program in basically any .NET langauge (cobol, vb, java, C#, etc, etc, etc). I assume when you talk about "language similar to Java", you mean C#. That is basically an answer MS needed since they REALLY needed a new modern langauge, but hopefully from the above description you can see that C# is just a tiny little spec on top of the whole .NET platform.

Re:So Why .NET?

[ChicagoDave]

Forget the original marketing push to have everyone buy into the application as a service model. That was a bit grandiose and given MS's stature in the overall development community (monopolies are not our friends), that was hardly going to fly.

What .NET is _today_ is a different way of doing application development. It took Microsoft a long time to externalize their own best practices, but they finally realized that they needed to push their Visual Basic audience up a notch into thinking about object-orientation, messaging, services, and overall best practices in architecture.

There was no way to do that with VB6 and there was no way to make C++ pretty enough to get people to mass-adopt it. Let's face it, you can put lipstick on a pig, but it's still a pig. (No offense to all you C++ geeks, it's just that for writing a screen and a report for the accounting department, C++ is a bit of overkill).

Anyway, the folks at MS were working on some third-generation messaging stuff and also saw the benefits of managed code in the Java world. So they're not stupid and they spend $5 or $6 billion per year on doing new suff. Out of this came the CLI, the CLR, C#, and in parallel, web services.

Now the lights started going off. They knew they had security problems and they also knew that the business world had moved past the point where adhoc VB6 systems were acceptable. The business world was adopting Java because it came with serious thinkers and sound architectures (stable, secure, and fast).

So as MS does, they adapted to the needs of the business world. They pushed their new toys to that end. But the thing that makes .NET successful and useful beyond any of the underlying architecture is the IDE. Visual Studio .NET is by far the most useful tool for developing web and windows applications. And in the next version, 2005, it gets even better. A lot better.

This is why Sun failed to steal the VB6 crowd away from MS. They never understood that if you create a great IDE, developers will come. Eclipse has proven this theory, although too late to damage .NET's growing market-base.

In summary, .NET is just a productive platform for developing web and windows applications, along with enterprise architectures, that were previously locked in the C++ world.

At the end of the day, I can say that my job is vastly easier now than it was 5 years ago.

That's what .NET is.

Re:So Why .NET?

[Nybler]

.NET is COM done right.

Here are some of the problems with COM:

• Late binding interfaces, IDispatch, are incompatible with early binding interfaces, IUnknown.
• Lack of common data types accross different environments. For example the C++ notion of a string is markedly different from VB's notion of a string. Don't even get me going about arrays!
• Inconsistent runtime documentation. C++ projects weren't required to produce a TLB file. Plus the TLB documentation file was separate from the DLL implementation fil

Re:So Why .NET?

[AJWM]

So in other words, you don't know either.

Re:So Why .NET?

[Proc6]

Is .NET another Microsoft vaporware?

Huh?

Well no. [microsoft.com] If it is I've made a pretty good living the last 2-3 years building functional web and GUI apps for clients using vaporware.

Re:So Why .NET?

[Sique]

The question was not, if .NET (version 1.0, version 1.1) are vaporware. They are present and usable.

The question was, if the .NET OS is vaporware, and if the rumours are somewhat related to the truth, it may be. The question was, if the rush to rebuild everything on .NET to be able to serve Microsoft's next generation OS, was founded on vaporware. It might be, if the rumours contain a grain of correctness.

Re:So Why .NET?

[toddbu]

The question was, if the .NET OS is vaporware

It's important to note that for any Microsoft idea to flourish it needs support from two arenas - the external public development community and the internal Microsoft development community. While there have always been a lot of folks at Microsoft (including Bill) who will tell you that managed code is the way to go, there is also a huge community of developers at Microsoft who still believe that lightweight code is the best and that managed code sucks at the k

Re:So Why .NET?

[CaymanIslandCarpedie]

I can promise you "news" of this story is correct. Longhorn will NOT be written entirely in .NET. However, this story is the first I'd heard that anyone for some reason assumed it would be.

In other breaking "news" MS Office is still written in C++ (the vast majority of it anyway). Longhorn is not a complete re-write of Windows, its just a new version. Sure a lot of the new tools/applications/etc are written in .NET, but it will be a VERY long time (if ever) until you see Windows entirely in .NET. Inte

Re:M$-serfs are so pathetic

[geomon]

At least if I'm doing the hiring.

If you are doing the hiring, I would hope that at that point you will have learned to write in complete sentences.

I don't understand your hostility. The guy is making a living. I assume that you 'like' IBM because it supports open source. Not long ago that 'support' for IBM would have been heresy to open computing advocates.

Now open source programmers worship at the feet of people who work for IBM. I would hire the guy even if (and a pretty *big* if at this point) Micros

So are dumbasses

[nurd68]

I work for a consulting company. We go where the money is. Clients want something on Windows, we write for Windows. Clients want something on Linux, we write for Linux. Client want something on Solaris, we write for Solaris. .NET/Mono is kind of nice because it allows anything to run anywhere (at least, in theory. Practice has some holes in it, but it will get better).

Re:So are dumbasses

[swillden]

Nope, I have, except that logic dictates that code that constantly executes under a VM will be slower than code that is JIT compiled and then runs as native code.

All major Java JVMs do JIT compilation, and then run the result as native code. Even better, most of them (especially Sun's) do run-time execution analysis prior to JIT compilation so that when they compile to native they can make better optimization decisions than a static compiler or "normal" JIT compiler can do.

.NET has no advantage over Java in this respect. I'd expect Java to have the advantage, actually, given the maturity of its JVMs.

Re:M$-serfs are so pathetic

[GeckoX]

Oh noooooo....!
What ever shall I do!

An Anonymous Coward won't hire me in the future!

My life is over!

I'm sorry, I'll go back to my binary editor and hand massage machine code from now on, cause I REALLY NEED YOUR JOB.

Jackass.

Re:M$-serfs are so pathetic

[jellomizer]

Once we become liberated you realize that it wasn't the way you planned it. So except for the damn Microsoft People who are all the causes to all the people in the world it is all those emacs and or vi people who are causing all the problems in the world. You also there are people who work for Microsoft are not always the MS Zealots but sometimes just people you need a job. Microsoft was hiring and they got the job that paid the right price with the right benefits. Oddly enough there are a lot of highly

So Why Java?

[ad0gg]

If Sun seems unwilling to bind .=Java to its next flagship OS, then why all the rush to produce Java-capable products? Is Java going to be a wash?

Re:So Why Java?

[geomon]

If Sun seems unwilling to bind .=Java to its next flagship OS, then why all the rush to produce Java-capable products? Is Java going to be a wash?

I had no idea that Sun dominated the desktop market.

Imagine my confusion on that point.

Re:So Why Java?

[jjohnson]

Did Sun promise to build the next version of Solaris around Java when I wasn't looking?

Re:So Why Java?

[AKAImBatman]

Sun did bind Java to its next flagship OS. "Java Desktop System" (JDS) is an attempt to slowly integrate Java subsystems into a traditional desktop environment. Future versions of the desktop are expected to fully migrate to the Looking Glass Desktop Environment [java.net], which is based on the Java3D API.

JDS is currently available as a complete Linux OS, or a Desktop option for Solaris Sparc/x86/AMD64.

Oh, and BTW: Sun has been integrating Java with Solaris for a very long time. Previous versions of Solaris had man

Is .NET another Microsoft vaporware?

[smittyoneeach]

Clearly not, it's installed and running in a lot of places.
I'll speculate that the rationale is going to break down into technical and business dimensions.
Technically, if it's such a fat sow that its wallowings make it uncompetitive, they may want to use faster core libraries.
If backwards compatibility is too painful to do in .Net, they may hold off.
Business-wise, if too much openness for C-octothorpe WRT Mono is seen as watering down the Windows brand, then that may also be a reason to slow down.
The C

Re:Is .NET another Microsoft vaporware?

[geomon]

The danger is that, having touted .Net as "all that and a scoop of ice cream", people finally wake up and realize that viable alternative exist.

Well, I got that impression from folks in our shop who code .NET. They were happy to jettison VB in favor of what one of my colleagues described as "true object oriented programming" in Windows.

If .NET is stalled for any of the reasons you have described it would be a shame. There are programmers who are quite excited about the prosepects of building applications

Re:Is .NET another Microsoft vaporware?

[smittyoneeach]

The secret to surviving a crisis is not losing your head.
If there is no .Net bread, let them eat Mono cake.

Re:So Why .NET?

[MikeMacK]

I use Microsoft products and am really getting confused about their software roadmap.

Don't worry, so is Microsoft.

Re:So Why .NET?

[hey!]

If Microsoft seems unwilling to bind .NET to its next flagship OS,

Maybe because doing so is not good design, and there is no competitive reason to overrule the engineers.

Is .NET another Microsoft vaporware?

Well, what do you mean? The framework? The CLI and CLR? They all exist and are being used by real people. The branding initiative? Well, what did you expect?

.Not ?

[Anonymous Coward]

.Not .Net, .Not on time, .Not secure, .Not free, .Not stable. Yep, it's .Not alright

Re:.Not ?

[brasten]

Good one, McNealy. :)

Re:.Not ?

[GeckoX]

Cute, mildly amusing, totally completely .Not true. .Not .Net: Um, it exists so rather it .Is. .Not on time: Eh? It's here now. .Not secure: Care to elaborate with specifics? .Not free: How's that? You don't have a text editor? .Not stable: Blatant lie.

Somewhat Typical

[under_score]

I don't understand why this would be a suprise. MSFT does this all the time. Windows 95 wasn't really 32-bit... etc. etc. I think there are a lot of people here who could come up with big and small promises that MSFT has broken.

Re:Somewhat Typical

[NickFortune]

This is why I tell people that windows is a Hostile Platform. Your home grown apps may be broken by the next service pack, and you can count yourelf doubly lucky if they survive the next release of the windows.

MS seem to change things on a whim, and without a thought for people trying to maintain apps on their platforms. Anyone'd think they were the only game in town...

I wonder what the opposite is of a self fulfilling prophecy?

I am so relieved

[thammoud]

that typing 'dir' won't invoke a webservice.

Re:I am so relieved

[bigtallmofo]

It will. The web service will just be written in Java.

Load of Bull

[emptybody]

What you get when you come across a LongHorn ... do people still actually use Windows?

When you have an model as beautiful as COM...

[Anonymous Coward]

...there's precious little to improve on. It would be like giving the Mona Lisa a face lift.

this IS significant!

[yagu]

First off, let me preface this post with the lol: I find it amazingly ironic that the advertisement on the Slashdot "read more" page has the Microsoft .NET ad, apparently Macro Flash.... with the hook: "If it takes eighteen months to write and integrate a new application...", [fade to next frame...], "It's not really new anymore, is it?".... the ad is for .NET!

I find Microsoft's "not eating their own dog food" rumors to be significant. Why does the rest of the world have to eat it (literally and figuratively) and not Microsoft?

More hubris from Microsoft. Apparently .NET is something Microsoft discussed and presented and strategized around at one of Bill Gates' yearly "meeting of the minds" at his Hood Canal retreat a number of years ago... Former Microsoft CFO John Connors bragged on this during a one-day glad handing session with the company I worked for at the time. He got up for a impromptu presentation as we all worked on our .NET "labs", and described how worked up into a slather the Microsofties were at the retreat.... describing the .NET architecture, and philosophy. He said, and I quote, "We realized that not only had we won the battle [with .NET], but we've won the war [against(?) the industry]".

The collective sound generated of all of the techies eyes rolling in the conference room was deafening, but the upper level management (and really, this entire session was about them getting to meet with Microsoft royalty, and cinching a sale/contract) postively glowed and nodded knowingly and smugly that they were part of this technology nirvana about to sweep the world.

I would say we're at least four or five years into this and so far what I've seen with .NET is:

• it doesn't always work
• .NET 2 is not retro compatible with .NET 1.1 (they say it is, it isn't).
• .NET is monstrously large
• .NET does not solve the dll hell problem (they said it would.)

So, again, the fact that by the time (and I guess we're all speculating here) Longhorn gets here if Longhorn is not largely based on and implemented with .NET says a lot for either: how difficult it really is to move applicatioins to the .NET architecture, or, how much even Microsoft itself believes in the technology. Neither possibility is good. Other slashdotters feel free to offer other theories.

MS does eat their own dogfood

[jbellis]

There may well be problems with .NET, but lack of dogfooding isn't one of them.

Plenty of new development is done in .NET. But their managers would deserve to be fired if they started wholesale rewriting of millions of loc of C++ just because there's a bunch of new toys to play with.

This is one of the primary functions of good technical management: preventing the engineers from rewriting every couple years in the latest and greatest.

Re:MS does eat their own dogfood

[musikit]

if MS eats their own dogfood then how come MS Office 2006 isnt based on .net? why because .net is a sham to get other people to write code that MS can easily read by de-compiling the CLR binaries.

no MS product will ever be based on .NET and you can quote me on that.

Re:MS does eat their own dogfood

[michael.creasy]

"no MS product will ever be based on .NET and you can quote me on that. " Hmm. Microsoft Speech Server [microsoft.com] Media Center" [microsoft.com] Both of those are based on .NET and I'm sure there are others as well.

Re:MS does eat their own dogfood

[Richard W.M. Jones]

The next version of MS SQL Server has embedded .Net support. Want to write your stored procedures is C#? Go right ahead.

So? PostgreSQL can run Perl stored procedures. Does this mean PostgreSQL is written in Perl? Does the fact that MS SQL Server finally happens to run a CLR interpreter mean that MS SQL Server is written in C#?

Rich.

Re:this IS significant!

[GeckoX]

Do you actively develop for .NET?

I do and have been for 2 years now.
Been playing with 2.0 since beta2 was released, and am now 1 month into active development using 2.0.

I'm sorry, but you are _completely_ full of shit. So much so that it'd just be feeding a troll to try to counter all of your points.

Re:this IS significant!

[yagu]

I always hestitate to take the bait of ad hominem posts.... but, you got me thinking, so I've gone back, and I've re-read my entire post.

As for the factual parts (the visit with John Connors), I stand by the accuracy of my recall of those events.

As for the interpretation of those events (which obviously are my interpretation and subject to my bias -- however much this stems from discussions with both management and technical staff that day), I stand by my interpretation as being one reasonable view (of

Re:this IS significant!

[KaiserSoze]

The other reply I saw referenced Microsoft dogfooding .Net, but not in specifics. A fundamental Microsoft offering: Visual Studio, was completely rewritten in .Net. If Microsoft ported their development suite, it means they are serious. Why? Because if the dev tools suck, it limits the uptake (or reup, for existing Windows-targetting software companies) to the Windows platform. Lean close and I'll tell you a secret: "Everything Microsft does is with the ultimate purpose to drive sales of the Windows OS." Now, some may say "they don't care, because they already own the market." That's a puerile statement. Does anyone think Microsoft is honestly stupid enough to sit back and say "That's it, we own the market, time to stop producing products and let the moeny roll in."? Realistically, Microsoft has to find new ways every year to make the Windows platform attractive to developers, because what's the alternative? Governments adopting Linux, home user adopting Apple, lunatics everywhere adopting Minix (heh)?

It's tiring to hear the same old slams on Microsoft every day on Slashdot. I used to hate Windows and love Linux back in college, but now, 4 years out, I've taken a more moderate approach. That is to say, I'm looking out for whichever platform allows me to get my goals accomplished (has the tools, the docs, the online community). For dumb personal reasons I always hated Java, but now I love working in .Net. I'm excited that my company is looking towards some new .Net-based projects. Why? Because of all the great tools and frameworks out there to work with. I know Java had all these things as well, but for whatever reason I wasn't a fan.

By the way, and this is not a sarcastic question because I'd like to know, how does .Net not solve the DLL Hell problem? How are versioned assemblies with metadata not able to identify themselves to applications questioning their version and origin? If there's a real-world problem with this, I'd be interested in hearing more, because its the first I've heard. If you are talking about a world in which managed assemblies and unmanaged DLLs co-mingle, then I understand, but if you are talking about a .Net application I'd love to hear more.

Re:this IS significant!

[rhinoX]

Visual Studio .NET is HARDLY re-written in .NET. In fact, they merely host the CLR so you can set properties and such with the GUI when you are editing forms.

THEY DID NOT RE-WRITE VISUAL STUDIO IN .NET, THEY JUST RENAMED IT AND WORKED OVER THE GUI.

Re:this IS significant!

[neile]

Well, actually, neither comment is quite correct. I actually work in Visual Studio, and believe I have a tiny bit of insight into this :)

Obviously all of Visual Studio hasn't been re-written in .NET, as another poster mentioned. That would be a massive undertaking and a silly use of developer resources when there is already a stable codebase that is well-understood.

However, where appropriate, new features being added to VS are written entirely using managed code, where it makes sense. My feature area, for

What did they expect?

[Anonymous Coward]

What did they expect? That the Longhorn will kernel would be written in C#?

Look at the way Visual Studio is evolving. Of course they have a huge codebase written in C/C++, and slowly new components are being added that run on top of the .NET Framework.

It would be plain stupid to rewrite the whole OS using .NET - not only would that delay the shipping process, what added value would it mean to the customer?

Being a .NET developer, the thing I really look forward to is having the .NET framework built in in a version of Windows. Given that, there is no need to ship the .NET framework with my application. That would be huge.

Re:What did they expect?

[mikvo]

It would be plain stupid to rewrite the whole OS using .NET - not only would that delay the shipping process, what added value would it mean to the customer?

I thought delaying the shipping process was the added value to the customer...

Beating a dead horse

[Swamii]

How many times does this need to be said? Longhorn's kernel is not managed code, nor should it be.

The primary developer API, codenamed WinFX, will be a managed (.NET-based) API, meaning most Longhorn applications will be managed apps. The Avalon (graphics) windowing system and the Indigo (messaging) system are both managed, and exposed primarily to managed apps.

That said, the kernel is not managed; there is and always will be needs for applications that are not managed, and need direct access to the underlying hardware and OS.

I've touched on this before many times, most recently here [thecodeproject.com].

To put it in simple terms, hopefully to clear up some of the misunderstanding:

• Longhorn is an unmanaged OS, of which .NET is a central part.
• Longhorn's kernel is not managed, nor should it be.
• Longhorn's primary developer API is managed, as it should be. The unmanaged Win32 API will still be there, of course, but will no longer be the principle API.
• No, Longhorn's primary developer API is not just a wrapper over the Win32 API.

Que?

[samael]

At what point were Microsoft going to rewrite all of Longhorn in .Net?

There are major parts of the new functionality that are .Net only. You can access pretty much all the old functionality via .Net as well. But why on earth would they waste developer time _rewriting_ code that works perfectly well so that it's in managed code rather than in C++?

This sounds to me to be nothing more than people who didn't understand what was going on in the first place feeling disgruntled.

"Everything in Longhorn was supposed to be written in C# and to be managed code. But managed code was going to require machines that weren't going to be available for five years or more. So now Microsoft is rewriting everything in Longhorn, the developer says.

Sounds likethis person _did_ expect the entire OS to be rewritten - and seems to think that managed code is orders of magnitude slower than C++ - yes it's slower - but it's nowhere near that much slower.

Microsoft promised to deliver Avalon and Indigo - the new windows APIs - in managed code - and they're on track to do that. They've dropped WinFS, true, but they haven't fundamentally changed direction for Longhorn at all!

Re:Que?

[ad0gg]

You mean device drives and kernel code aren't going to be running under .net runtime!?!?! Longhorn must be a failure!! </Sarcasm

Reason why there's no .NET in Longhorn

[Anonymous Coward]

Longhorn was first developed with .NET components being used, but the performance was horrible. Microsoft scrapped the entire development tree and went back to the original code base with much higher quality cut-off points for each of the teams if they wanted to re-add their features to the build, and with the rule that NO .NET components could be a part of the default install.

One place where this is really annoying is the new Avalon vector graphics system for applications. This will no longer be included in the default install, which means that developers who want to use it in future applications will burden their users with having to stick their Windows CDs in and install the optional Avalon component before the app will work, which of course will discourage developers from using it.

The lack of .NET in the default install, plus the incredibly high quality cut-off points for feature adds, means that Longhorn is truly a very unimpressive service pack to XP rather than a revolution or evolution of the operating system line.

OLE! Viva .NET!

[Doc Ruby]

I remember when Microsoft was getting us ready for Win95, back in 1993, telling us we were going all-OLE. Programming would mean sending OLE messages among a universe of interoperable COM objects, reusable in any combination we pleased. Then we got Win95, and a COM that didn't do that, and a *lot* of other stuff we needed to do, then COM+, then DCOM, and on and on. And it was never as easy as they'd promised.

These MS technologies are promoted for the sake of promoting Microsoft. Every generation produces something that would be great, but the marketers and engineers are never on the same page. Microsoft succeeds by putting the marketers in charge, but they wind up baiting developers with great tech, then switching us after we're hooked. Maybe the engineers are too busy making all the legacy almost-happened technologies work at all, rather than switching to the new framework that finally sets us free.

Probably based on

[dtfinch]

Lots and lots of embedded .HTA's. Even in XP, a lot of Windows .dll's are loaded with bits of html and javascript, but they give it a nice Windows look and feel.

What's The Big Deal?

[snookerdoodle]

Honest question, from a guy who doesn't own (or run ;)) a copy of MS anything:

Why does an O/S have to be based on an application framework?

Maybe it's *good* thing: updates to .net could possibly be installed without rebooting the computer. Nah. That would be too much to hope for.

Mark

it makes sence...

[dns_server]

you don't use a high level language for writeing interpreters. is the JRE written in java? is the .net runtime written in c#? no, because they are runtime environments that provide an abstraction for the code to be interpreted. it does not make sence directly includeing an interpreter into a kernel instead you have a runtime environment that sits above the kernel. it would be a bad design decision to directly intergrate these because it would be bad for security, stability and it would also mean it would be

"Based on Longhorn"

[jeff_schiller]

I think Foley is just fishing for controversy here:

"Longhorn won't be based on the .Net Framework."

"...the .Net Framework will be the core for a small subset of Longhorn, specifically the WAP (Windows API Platform), which consists primarily of the "Avalon" Windows presentation system and the "Indigo" Windows communications system."

But Avalon and Indigo are subsets of Longhorn. So .Net IS INDEED at the core of a subset of Longhorn.

I guess the question is: Did someone believe that EVERY SINGLE PIECE of

WinFX

[ejamie]

If I recall correctly, Longhorn promised to be built on top of a new .NET API level called "WinFX".

WinFX itself is a system-level .NET library that provides application programmers with all the functionality you previously had to rely on Win32 API to get (windows messages, message pumpts, etc).

However, the thing to remember about WinFX is that WinFX does not completely replace Win32 API--it only provides a .NET callable-layer that encapsulates the Win32 API.

I would guess that at some later date (x y

Re:WinFX

[glesga_kiss]

I would guess that at some later date (x years from now; x==5, x==10, x==100) once the WinFX API is established and becomes the primary API used by windows system-level programming, then the Win32 API underneath may be rewritten in .NET. I don't think this will happen any time in the near term though.

Hmm, that sounds like a really unworkable idea. Others have said how it's daft for MS to re-write code for .Net if it works fine as is. Guess what? Most of the third-party Win32 API dependant apps work fine r

Exactly which idiots were you chatting to?

[kahei]

Was someone expecting an OS that was implemented in .NET, with .NET kernel and .NET device drivers and a fully .NET API?

I think most people were expecting an OS written the way previous versions of the product, and most other OSes, are written. It would be reasonable to expect it to come bundled with a .NET runtime, and to offer interfaces that that .NET runtime can use, so that you can write .NET applications and run them on it.

Amazingly enough, that is exactly what it does come with, and exactly what i

Of course it isn't!

[Neuracnu Coyote]

Anyone who has spent any amount of time working with .Net will tell you that the framework is not meant to be run at the OS level. It's a sandbox, full of app-builting tools and helpers, that developers use to assemble custom applications. At a very very high level, it's simply an attempt to take some of the busy work out of programming. The framework was built to sit ON TOP of an operating system, not be the basis for one.

Java

[3770]

Java is not in the core of Solaris, Linux or AIX.

Does that mean that you shouldn't use Java?

When technology ignorant people make news...

[Anonymous Coward]

This article is complete rubbish. Microsoft NEVER said that Longhorn would be "based on" .NET. Never. Not once.

In fact, when asked, they've repeatedly said that would NOT be the case.

What Microsoft is doing, and what they've said they would be doing since they first announced Longhorn, is to create a .NET-based API that completely (or almost completely) exposes the Win32 API as native .NET libraries.

In addition, some parts of Longhorn would be written using this managed API. The new Explorer.exe, for instance, is a mostly managed application.

This woman's ignorance is the real story here, not her foolish conclusions and strawman arguments.

A good decision

[Zebra_X]

Longhorn, should *not* be based on the Framework. One word - performance. What I think confuses most people is that while the OS and libraries may be written in C or C++ these libraries still can easily be used via the framework. .NET is a application developers framework, it gives us access to almost all of the features of the C++ SDK but with a higher level of cleanliness and organization. "Managed code" offers a host of benefits for application developers such as protection from buffer overflows, more tr

What to learn...

[__aaclcg7560]

I just finished taking an introductory C++ course at the local college. If I were to continue to learning C++ and developing software for Windows, should I learn Microsoft Foundation Classes (MFC) or .NET?

Seems like Microsoft has too many MFC programmers and not enough .NET programmers to make the transition for Longhorn.

Re:What to learn...

[jsoderba]

While you should probably focus on Managed C++, since there are significant time savings in developing with the less byzantine .NET API (actually I suggest using C# if you can, since the advantages of C++ are largely nullified in managed code), there's an enormous amount of Win32 code out there. Unless you start working at a start up building a brand new codebase you'll probably be asked to maintain or integrate with Win32 code, so you need to learn enough to get around eventually.

Another spooky Star Wars parallel

[SuperKendall]

On the one side you have the Republic of Java. On the other, the .Net seperatists - well Longhorn has been sent to "take care" of you .Net guys. Good luck with the career!

actual article

[veg_all]

The posting link is to an abstract of the story. Here [tinyurl.com] is the actual article.

Java

[digidave]

Truth is, the lead developer couldn't tell the difference and accidentally based Longhorn on J2EE.

(I know they're not identical. I was just making fun of how MS copied Java so much.)

Favorite Quote

[kahei]

We're still expecting that the .Net Framework will ship with Longhorn - on the CD and/or "in the box" in some way. But the .Net Framework won't be at Longhorn's core, we hear.

Hmm... looks like a slow news day...

Another developer source, who asked not to be named, says he has been hearing some related hall talk.

Now that is what I call a slow news day!

In REAL news, readers of a popular web news/discussion site were reported to be disappointed that 'news for nerds, stuff that matters' would not, after

Could this be another 'trying to please everyone'?

[pg110404]

I keep hearing stories about how language abc or environment xyz is going to revolutionize the programming world and it will be so simple, easy to use and all encompassing that the boss's pet monkey can do most of the work.

The fact of the matter is, all languages, no matter how clever, complete or complicated they are, must ultimately get translated to binary code. There are so many proven and well established languages/environments out there, I roll my eyes when I hear of promises that another will beco

For those who don't read the articles

[Ridgelift]

FTA: "The original plan for Longhorn was to build lots of components on top of the next version of the .Net Framework," according to one of our developer sources, who requested anonymity. "But given how late (.Net Framework 2.0) is, and how new it would be (Microsoft Chairman) Bill Gates realized it would be foolish to build important pieces of Longhorn on top of .Net."

So let me get this straight: it's foolish for Bill Gates to build important pieces on .Net, but it's smart for eveyone else?

Let's face it, Microsoft Windows is beginning to buckle under the weight of their own code. I don't think Longhorn will be shipped any earlier than late 2007 or early 2008. If they release Longhorn now, they will orphan the OS: Too big to be run on today's hardware, too incompatible with many critical applications, and too few business reasons to make the switch.

This is significant!!

[sethadam1]

Microsoft has for about 5 years now been advertising the hell out of .net with their TV spots about "real time" networks and such. Longhorn was supposed to be lots of things - new frameworks, new APIs, new codebase, etc. It's turning out to be NONE of those things. In fact, it's starting to sound like Windows 2003 SP1 + a few extra desktop features. I fail to see anything revolutionary in it anymore.

Microsoft will only really blaze new ground if they decide to screw backwards compatibility and understand that it will take a few years for people to catch on and really start using it. Unfortunately, that leaves the door open for Linux and Macs to fill the gap.

You can say whatever you want, but if you believe this isn't backtracking then you've fallen victim to the slow but steady retreat from the original campaign.

Layering will not fix a bloated OS

[Animats]

The software industry has settled on a strategy for dealing with the fact that its operating systems are bloated and insecure. This strategy is roughly as follows:

• Put virtual machines on top, like Java and .NET. Claim that they're more secure than the OS.
• Put virtual machines underneath, like VMware. Claim that they're more secure than the OS.
• Add software to catch known attacks, like firewalls, virus scanners, and spyware removers.
• Patch, patch, patch.

It's not working.

It's not just a Microsoft problem, either; Linux is acquiring exactly the same set of problems as the kernel grows and grows.

It doesn't have to be this bad.

Dave Cutler, the architect of Windows NT, tried to fix it. NT 3.51 was the last version he controlled, and the last one that looks even vaguely like a "microkernel". He once told Bill Gates "I won't pollute it [NT] with crap!" So he was taken off NT, and for NT 4, the kode kiddies from the Windows 95 team were allowed to put huge volumes of crap Win95 code in the kernel, for "compatibility". The end result is XP, which in practice is only slightly less vulnerable than Windows 95.

It's striking to run QNX [qnx.com], which is a true microkernel (about 60K of code), with drivers, file systems, and networking outside the kernel. It can run X windows, Firefox, multimedia players, and now has OpenGL. That's a demonstration that you don't need a bloated kernel. Nor do you need one that changes much. The QNX kernel changes very slowly; new capabilities are added outside the kernel, in user space. Unfortunately, QNX on the desktop is going nowhere, because there are few applications and the current marketing push is for automotive applications. Nor is QNX intended as a secure operating system, just a reliable real-time one. Despite this, it's a clear demonstration that the basic OS does not have to be big or constantly changing.

If the Hurd guys had a clue, and could write something as good as QNX, there might be some hope from that direction. But after ten years of screwing up, there's not much hope there.

Re:nonsense

[ArbitraryConstant]

"It's not the virtual machines that make Java and C# applications more secure, it's the fact that the languages are better designed than C and C++."

The fact that the VM can run applications in a sandbox helps.

"Until kernel designers kick the C/C++ habit, we are not going to get a decent kernel.

It's unfortunate that Java and C# (pretty decent language designs) happen to be implemented with such bloated runtimes by their main proponents. But that's not necessary: Java and C#-like languages can be implement

Re:nonsense

[cahiha]

They cannot match OSes like Solaris, Linux, and FreeBSD in terms of performance any more than microkernels can.

How do you know? Have you ever run any of them?

In any case, I would gladly use a kernel that ran with more overhead than, say, Linux and in return wasn't as buggy, had more functionality (what about a working and secure network file system, for example?), and was easier to hack.

[C memory management is] just a library.

And you can do the same in other HLLs.

Kernel memory management routines

Re:Layering will not fix a bloated OS

[Animats]

In practice, you lose about 20% performance with a good microkernel OS. You get much more than that back from the reduced downtime and maintenance.

The big win with a microkernel is that you don't have to patch it all the time. They're small enough you can get the bugs out. Microkernels like VM and QNX settled down into stability years ago.

I'm posting this from Mozilla on a QNX machine. QNX isn't going anywhere on the desktop, but that's a business problem, not a technical one. Desktop QNX actually w

no news there

[cahiha]

Well, I think this has been clear for a long time. The Windows XP kernel and many of its key user mode libraries will continue to be written in C/C++. I suspect that Explorer, Internet Explorer, and the control panel will likely continue to remain C/C++ based.

However, it looks like they are going to ship a full .NET runtime with Longhorn, as well as lots of .NET libraries. I suspect that if you removed the .NET runtime, some applications and system utilities would break, although the system overall would probably still boot. (Didn't SP2 come with a .NET runtime anyway?)

All of that is pretty reasonable. Why break working code? Why alienate thousands of developers? The inclusion of .NET isn't a revolution, it's an evolution. Think of it as a Visual Basic replacement--a better designed runtime with a choice of better designed libraries. And, unlike Visual Basic, .NET may actually be good enough for Microsoft to start writing small applications and system utilities in.

Every time I post this, it becomes funnier

[Lars T.]

http://www.theregister.co.uk/2001/07/27/microsoft_ reshuffles_windows_roadmap_full/ [theregister.co.uk]

Re:c++

[Dasein]

C++ will continue to be the 'crown jewels' of microsoft.
You misspelled C.

Re:What About Java?

[bigtallmofo]

I'd like a platform with longevity after being burned by using VisualBasic.

Apologies if I misunderstood your comment, but... I've been a Visual Basic developer for 10 years (and an MCSD on the VB6 track for 4 years). What sort of longevity were you looking for in your development environment?