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."

Comments

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?

[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 kernel level. Many of these people still haven't moved into the world of C++, so how is it now that people believe that they will adopt .Net? The notion that any truly important pieces of Longhorn would be built on top of .Net was more marketing FUD than anything else. But then again Microsoft has a long history of stringing the market along to keep their interest, going all the way back to Cairo.

It's interesting to note that in recent years that Microsoft has developed a "one size fits all" mentality. In the early days of Microsoft there were lots of options to pick from (like we currently see in the Linux community), but economy of scale has dictated a streamlining of technology. For example, Microsoft used to support lots of different database technologies (Access, FoxPro, SQL Server) and then there came a big push to center everything around SQL Server. The problem is that SQL Server is great for some applications, but not for others. So the drive to center everything around .Net doesn't suprise me because Microsoft no longer values diversity of technology in its products.

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?

[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 file and the TLB file required special tools to view its contents.
• Interface definition via IDL was awkward and made COM interfaces different from their environment.
• Apartments. I knew what they were and how to use them, alas most other developers did not - not that Microsoft did a good job of documenting them anyway. Remoting (which arose via apartments in the COM world) is handled much better in .NET when needed.
• Thread models. Exactly, don't need to worry about them in .NET do you?

Unless you lived in the world of COM, .NET won't make any sense to you and I can see where one would get the notion that .NET is Microsoft's copy of Java - which it isn't.

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?

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.

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: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.

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, 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: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

[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?