Slashdot Mirror
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."
from microsoft's official page 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."
...NET framework knowledge"
...NET framework".
the key here is the word knowledge: "longhorn builds on
which could possibly be construed differently than "longhorn builds on
who knows? maybe i'm reading too much into it..
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?
.NET another Microsoft vaporware?
.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.
Is
Instead, the
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.
"Rocky Rococo, at your cervix!"
that typing 'dir' won't invoke a webservice.
...there's precious little to improve on. It would be like giving the Mona Lisa a face lift.
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:
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.
What did they expect? That the Longhorn will kernel would be written in C#?
.NET Framework.
.NET - not only would that delay the shipping process, what added value would it mean to the customer?
.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.
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
It would be plain stupid to rewrite the whole OS using
Being a
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.
To put it in simple terms, hopefully to clear up some of the misunderstanding:
Tech, life, family, faith: Give me a visit
At what point were Microsoft going to rewrite all of Longhorn in .Net?
.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++?
There are major parts of the new functionality that are
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!
My Journal
There may well be problems with .NET, but lack of dogfooding isn't one of them.
.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.
Plenty of new development is done in
This is one of the primary functions of good technical management: preventing the engineers from rewriting every couple years in the latest and greatest.
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.
--
make install -not war
Java is not in the core of Solaris, Linux or AIX.
Does that mean that you shouldn't use Java?
The Internet is full. Go Away!!!
This article is complete rubbish. Microsoft NEVER said that Longhorn would be "based on" .NET. Never. Not once.
.NET-based API that completely (or almost completely) exposes the Win32 API as native .NET libraries.
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
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.
C++ will continue to be the 'crown jewels' of microsoft.
You misspelled C.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
-
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.