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."
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).
"A truly wise man realizes he knows nothing."
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.
Helping with organizational effectiveness is our job.
I could have sworn I read something about Avalon not making it into Longhorn.
.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?
.net added to Windows, and Longhorn isn't WINFS, well ... exactly what IS Longhorn, anyway?
Now we know
If Avalon might or might not be in Longhorn, and Longhorn isn't
D
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
Clearly not, it's installed and running in a lot of places. .Net, they may hold off. .Net as "all that and a scoop of ice cream", people finally wake up and realize that viable alternative exist.
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
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 CLR has to build a compelling case that Windows is ethical and not monopolistic, while subtly rewarding those who continue to genuflect to Redmond.
And that's not evil, it's just smart business, so relax.
The danger is that, having touted
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Honest question, from a guy who doesn't own (or run ;)) a copy of MS anything:
.net could possibly be installed without rebooting the computer. Nah. That would be too much to hope for.
Why does an O/S have to be based on an application framework?
Maybe it's *good* thing: updates to
Mark
I think Foley is just fishing for controversy here:
.Net Framework."
.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."
.Net IS INDEED at the core of a subset of Longhorn.
.NET? i.e. a complete redesign of every single facet of the OS from the ground up? That would be an incredibly risky gamble on Microsoft's part wouldn't it? Does everyone remember what happened to Netscape when it decided to scrap its codebase and start from scratch?
"Longhorn won't be based on the
"...the
But Avalon and Indigo are subsets of Longhorn. So
I guess the question is: Did someone believe that EVERY SINGLE PIECE of the next Windows OS would be based on
Something Witty Goes Here
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 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.
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.
$7.95/mo, 200 GB disk, 2TBxfer, MySQL, PHP, RoR.
Jesus Christ. All they said was they're not basing the system off the framework, who the hell cares? They said that they are including the framwork in the OS, thats all you need.
"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..."
Linux kernel and Binary drivers.
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 skilled workers whose passion is to program, and their passion is not determining very controversial morals on what they are doing.
Think about this. Ohh you wrote a program that allows people to do a task. But because it is not Open Source you must be Evil. There is nothing evil about making a tool that helps people. It may not be the best tool for every job the true evil person is the one you tells others that it is the right tool for every job.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
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.
Maybe MS doesn't want to build on the .Net framework b/c it is buggy and has been known to have vulnerabilities......Oh wait.....
There are 10 kinds of people in the world - those who understand binary and those who don't
So are most programmers that have been dealing with Active X over the years. You learn to be carefull when dealing with them. Else you get eating by the Tiger.
Talk about going at 120 mph then turning at 90 degrees or going instanly into reverse!
They still have about 1.5 years to get someting beyond a service pack/pretty GUI ready.
NOTE: Tiger here is not refering to a company in Florida or somthing dealling with a just released OS. But a very large striped kitty with teeth, fur and want you as THE snack!
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 right now as well. If they want to keep any form of backwards compatability, they'll need to keep the Win32 API around for a very very long time. The code-base is spagetti-like already it would seem!
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.
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.
.NET, but it will be a VERY long time (if ever) until you see Windows entirely in .NET. Interpreted byte-code just doesn't tend to lend itself great kernal performance.
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
"reality has a well-known liberal bias" - Steven Colbert
.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.
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.
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.
.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?
SYS 49152
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 the next windows OS, not some random application.
-- http://thegirlorthecar.com funny dating game for guys
In other news, screwdrivers make bad hammers.
Why should all software be written in one or another language/platform?
"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 implemented natively with pretty much the same efficiency as C and C++."
Well it depends what you're doing. They kernel has to do heavily architechture dependant things. It has to manage page tables and do I/O directly. You just can't do that in a managed language. The whole point of a managed language is that you don't do pointer manipulation directly. That makes C/C++ less safe, but it's also a necessary part of the kernel. In fact, kernels are one of the few places where it will never and can never go away.
You're also stuck with garbage collection even if you compile to native code. The kernel has to be as deterministic as possible, for stability as much as for speed. Garbage collection by definition is not deterministic. Ever wonder why the Java EULA requires that you agree not to use it in a nuclear reactor? That's why. They can't guarantee that it won't lock up when you're trying to click the "AVERT MELTDOWN" button.
Java and C# might be able to compete with C++ in terms of speed, but they can't touch hand-tuned C mixed with assembly, not for the sorts of thing that goes on in the kernel. Even C++ is of questionable merit in a kernel.
I rarely criticize things I don't care about.
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 works reasonably well. I'm not fanatical about QNX, but technically, it's fundamentally sounder than the Microsoft and Linux messes.
If you want to try QNX, you can downoad it here. Get the "30 day evaluation version". It will still run after 30 days, but the Eclipse development environment turns off when the timer runs out.
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
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 meet the needs of the kernel.
Thy only "meet the needs of the kernel" because people are satisfied with a kernel that works like shit. Kernels benefit greatly from a good garbage collector, in their ability to respond in real time, in the amount of memory used, in correctness, and in ease of development.
Conversely, good programming practices can keep security problems in the kernel to a minimum (eg OpenBSD), while some problems are universal to both. A dedication to security will meet with success with any language.
It evidently does not. The huge number of problems that keep cropping up in all C-based software systems that would have been avoided automatically by most other languages is evidence for that.
And even if C programmers did actually produce bug-free software, still wouldn't mean everything is OK. Even the sad state of C-based kernels and system software as is is only achieved through wasting enormous amounts of memory and CPU, wasting enormous amounts of time on testing that could be avoided in other languages, and a paranoid phobia of adding any kind of new functionality. C programmers try to put a positive spin on these behaviors by using phrases like "expert C programmers" and "against bloat", but it's really pathetic.
C programmers have proven over the last three decades that they are incapable of producing reasonably dependable, functional, and safe software. The experiment has failed--we should move on.