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."
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.
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.
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.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
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.
So, here's the deal.
.NET
.NET development... it's pretty nice for some things, but others are just impossible.
.NET as much as possible, but sometimes have used C++ out of necessity.
My understanding is that people at MS have had difficulty doing a number of operating system "things" in
This is no shocker to anybody whose done any extensive
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
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.
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.
.NET, THEY JUST RENAMED IT AND WORKED OVER THE GUI.
THEY DID NOT RE-WRITE VISUAL STUDIO IN
The copper bosses killed you, Joe. 'I never died', said he.
In other news, screwdrivers make bad hammers.
Why should all software be written in one or another language/platform?
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 ?
PJRC: Electronic Projects, 8051 Microcontroller Tools