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!"
.Not .Net, .Not on time, .Not secure, .Not free, .Not stable. Yep, it's .Not alright
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.
that typing 'dir' won't invoke a webservice.
What you get when you come across a LongHorn ... do people still actually use Windows?
comment directly in my journal
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?
Have you ever been to a turkish prison?
...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
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.
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.
.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.
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
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
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
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 even more dificult to change or update the runtime environment.
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
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 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.
Hey! Stop copying my sig!!! Stop copying my sig!!! Stop copying my sig!!! Stop copying my sig!!!
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.
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.
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.
Ever since Microsoft announced .NET they've maintained the same standpoint they have now: use .NET where it's appropriate, don't be stupid and rewrite existing code but interoperate with it and that certainly holds true for their own products as well.
.NET, that there was never any plan to do this and that it doesn't make any sense to do it.
.NET and only be exposed through the standard Win32/Win64 API where and if it makes sense.
.NET, it doesn't make any kind of sense since with those the prime concern is not ease of development, it's responsiveness, minimal memory footprint and most importantly speed and .NET just gets in the way of that.
.NET and never bothered to read up on it beyond gossip and speculation.
You can find plenty of videos, articles, blog entries and chat transcripts on MSDN that show Microsoft developers clearly stating that Longhorn will not be built on top of
What has been said and still holds true is that any new programming API will most likely only be exposed through
While writing drivers, services, servers, etc is certainly possible with
The only thing this article reveals is that the author has no clue about
So let me get this straight: it's foolish for Bill Gates to build important pieces on
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.
Ruby on Rails Screencast
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.
-
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.
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.
.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?)
.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.
However, it looks like they are going to ship a full
All of that is pretty reasonable. Why break working code? Why alienate thousands of developers? The inclusion of
let me get this straight. I don't know if this joke is now archaic, but... "micro" "soft".. is releasing a "long" "horn". HAH!
twitter.com/gravitronic
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
"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.
http://www.theregister.co.uk/2001/07/27/microsoft_ reshuffles_windows_roadmap_full/
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.