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!"
Why don't they say : Nothing to see here, move on !!
.Not .Net, .Not on time, .Not secure, .Not free, .Not stable. Yep, it's .Not alright
As long as they keep GDI+ I'll be happy...
Finally some good news on /.
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
Microsoft is not using the .NET 2.0 framework to build large parts of Longhorn because the .NET 2.0 framework isn't done yet. That's what the article is trying to say, and yet fails to get the point across. Now, that said, when Longhorn finally ships, it will include the 2.0 framework to build upon, as well as the extended WinFX. WinFX is basically an extension to the standard framework that allows for greater programming access to Longhorn. I'm not sure it is right to call it .NET 3.0, but WinFX is the future for development ON Longhorn, not develop OF Longhorn. Clear?
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
C++ will continue to be the 'crown jewels' of microsoft. The more Microsft can get people working in interpreted languanges the more control they will have over Windows software. Don't forget that MS wants to own the applications domain as well.
Please sign petition to restore sanity to our banking system!!!
http://financialpetition.org/
Will we be able to use Java on Longhorn? I'm trying to figure out what a good platform for my project would be. I'd like a platform with longevity after being burned by using VisualBasic.
People, including developers, are constantly mistaken about either what .NET is, or what it is design to do.
.NET is pointless, which it is, it's not worth the investment. But going forward new technologies should be based on .NET. And guess what, the new technologies in Longhorn, such as Avalon and Indigo, are based on .NET. So what is everyone complaining about? That Microsoft has not rewritten every last one of their products in .NET? .NET is already the preferred API for developing applications in Longhorn, what more do you want?
Microsoft has made it clear that rewriting old code for the sake of running it under
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 can understand Microsoft not using .Net at the lower-level components of the OS....the whole, impossible thing. But why drop it altogether? I'm a .Net fan myself, and sad to see the dream die. I guess I'll be sticking with XP until Cedega or Wine mature, then switch to Gentoo.
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
like Slashdot already has?
IIRC most of .NET just wrappers around the same old API's?
Performance is already bad enough to want to put another layer on it. It may be worth it when you want to rapidly develop some app but an OS, I dunno.
--
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
Lots and lots of embedded .HTA's. Even in XP, a lot of Windows .dll's are loaded with bits of html and javascript, but they give it a nice Windows look and feel.
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!!!
Was someone expecting an OS that was implemented in
I think most people were expecting an OS written the way previous versions of the product, and most other OSes, are written. It would be reasonable to expect it to come bundled with a
Amazingly enough, that is exactly what it does come with, and exactly what it does offer.
Now, were there _really_ any people who expected Longhorn to be 'in'
Or is this the most groundless, gratuitous Slashdot FUD... EVER?
If the former, then those people are odd, odd people and should probably be put in a special safe place. If the latter, then it has a certain geeky glory to it but it's also a bit sad.
Whence? Hence. Whither? Thither.
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!!!
At least if I'm doing the hiring.
If you are doing the hiring, I would hope that at that point you will have learned to write in complete sentences.
I don't understand your hostility. The guy is making a living. I assume that you 'like' IBM because it supports open source. Not long ago that 'support' for IBM would have been heresy to open computing advocates.
Now open source programmers worship at the feet of people who work for IBM. I would hire the guy even if (and a pretty *big* if at this point) Microsoft becomes a niche player.
"Rocky Rococo, at your cervix!"
...and I'll rant about it again. When it comes to security vs. making money, Microsoft will choose making money every time. They have always done so in the past and every future prediction says they will continue to make the same choice. The Register wrote ahout this yesterday. And why not? It makes perfect business sense because there is still no penalty for releasing an insecure product.
The NSA: The only part of the US government that actually listens.
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.
Make the money! Certainly easier than a certain other methodology.
Shut up.
Longhorn, should *not* be based on the Framework. One word - performance. What I think confuses most people is that while the OS and libraries may be written in C or C++ these libraries still can easily be used via the framework. .NET is a application developers framework, it gives us access to almost all of the features of the C++ SDK but with a higher level of cleanliness and organization. "Managed code" offers a host of benefits for application developers such as protection from buffer overflows, more transparent management of system resources and better identity management.
.NET base constructs to interact with the classes, methods or functions in external libraries - it's all good. A perfect example of this: a few weeks ago I had to write a framework adapter class to a legacy C library. It took about 30 minutes to expose the functions of the library that were needed. Just include a reference in the .net project and you're good to go.
.NET is a good thing. Let's be realistic, why on earth would you build your OS on a garbage collecting framework? I mean, should Solaris move to using the JVM as it's core execution environment? Probably not.
To the framework developer it doesn't matter what the undelying library code is written in, so long as there are
All of this fuss about Longhorn not being developed in
So the short and sweet is, the core os will be built on traditional technologies (they are faster), but supporting applications will use the framework as their developemnt platform. In addition, all of the system level api calls will be available in the framework, making it easy for appliaction developers to build and deploy applications quickly.
Yes, I can't wait to see what /. posts to top this...I guess Mary Jo is really to blame though. I found this talkback comment amusing: http://www.eweek.com/talkback_details/0,2278,s=259 84&a=152824,00.asp?m=8123
Something Witty Goes Here
I just finished taking an introductory C++ course at the local college. If I were to continue to learning C++ and developing software for Windows, should I learn Microsoft Foundation Classes (MFC) or .NET?
.NET programmers to make the transition for Longhorn.
Seems like Microsoft has too many MFC programmers and not enough
I work for a consulting company. We go where the money is. Clients want something on Windows, we write for Windows. Clients want something on Linux, we write for Linux. Client want something on Solaris, we write for Solaris. .NET/Mono is kind of nice because it allows anything to run anywhere (at least, in theory. Practice has some holes in it, but it will get better).
ha ha ha
Oh noooooo....!
What ever shall I do!
An Anonymous Coward won't hire me in the future!
My life is over!
I'm sorry, I'll go back to my binary editor and hand massage machine code from now on, cause I REALLY NEED YOUR JOB.
Jackass.
No Comment.
On the one side you have the Republic of Java. On the other, the .Net seperatists - well Longhorn has been sent to "take care" of you .Net guys. Good luck with the career!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The posting link is to an abstract of the story. Here is the actual article.
grammar-lesson free since 1999. (rescinded - 2005)
They created a controversy where none existed. MS never promised a .Net kernel. They promised .net wrappers to provide more managed APIs. .Net is a nicely architected product. It helps develop nicely architected apps.
.Net architecture. That would make .Net the single exception to MS consistent delivery of clunky APIs. The other controversy is that 2003 server is a GREAT platform for .Net development and deployment and it runs the old shit great. So why upgrade? What's in it for the user?
If there is a legitimate controversy it may involve the fact that some claim that Avalon is a rather clunky architecture built on a nice
If MS watch wants credibility, write an article about that, not some manufactured controversy.
For those who don't see adds at Slashdot. Just after the news summary there is a big nice M$ add which says: "See how Windows Server System with .NET helps get applications up and running faster." X-D
Except Longhorn, I guess.
Mod parent up. kthxbye
Truth is, the lead developer couldn't tell the difference and accidentally based Longhorn on J2EE.
(I know they're not identical. I was just making fun of how MS copied Java so much.)
The global economy is a great thing until you feel it locally.
We're still expecting that the .Net Framework will ship with Longhorn - on the CD and/or "in the box" in some way. But the .Net Framework won't be at Longhorn's core, we hear.
Hmm... looks like a slow news day...
Another developer source, who asked not to be named, says he has been hearing some related hall talk.
Now that is what I call a slow news day!
In REAL news, readers of a popular web news/discussion site were reported to be disappointed that 'news for nerds, stuff that matters' would not, after all, be at the core of their experience.
"Actual news will occur in some areas and subcomponents," said a guy who heard someone say something about it on the bus, "but the site will be founded on a meaningless, seemingly random series of poorly-chosen blog pages and zine articles. It's probably for the best."
Whence? Hence. Whither? Thither.
"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.
Dear Misinformed Idiots:
.NET. That was never the plan at all. Longhorn will expose more existing functionality through managed [.NET] interfaces plus NEW functionality like Indigo http://pluralsight.com/blogs/dbox/archive/2005/02/ 06/5596.aspx and parts of Avalon will be written in .NET. Much of Longhorn is NT/Windows 2000/XP/2003 c/C++ codebase. There will lots of new functionality written in .NET. But the vast majority of the Longhorn codebase will remain in C/C++. And that was always the case.
Longhorn was never supposed to be re-written or even based on
.net is dying? (Was BSD Thread...)
If it were done when 'tis done, then t'were well it were done quickly... MacBeth
I keep hearing stories about how language abc or environment xyz is going to revolutionize the programming world and it will be so simple, easy to use and all encompassing that the boss's pet monkey can do most of the work.
.net. Also, given the chicken and the egg phenomenon, its (eventual) adoption is slowed by the lack of developers and the developers are waiting for its adoption.
The fact of the matter is, all languages, no matter how clever, complete or complicated they are, must ultimately get translated to binary code. There are so many proven and well established languages/environments out there, I roll my eyes when I hear of promises that another will become the definitive one that will displace all others (yeah, here we go again).
Given this one is from microsoft means it's (very likely) targetted to windows exclusively (or mainly, most complete, the only supported platform) and in the grander scheme of things, becomes irrelevant for other platforms like mac os, or linux/bsd/etc. Microsoft has shown again and again that they want to please everyone (as long as everyone is everyone who uses their products), just a little bit, so they end up making their products so utterly complicated and complex pleasing everyone just a tiny little bit, security and performance are the first casualties.
They've recently abandonned all hope for their passport id system, and while it may have been clever on paper, in reality, didn't seem so clever. I wonder if the result of the passport debacle has made them think twice about
While I'm not convinced it will flop so utterly horribly, I do believe looking back 30 or even 15 years from now, it will have been marginalized to some extent like so many other things that promised so much yet delivered so little.
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
But does the Win32 layer sit on top of the kernel or WinFX ?
Best Question Ever. Microsoft always has to integrate absolutely everything. I'm not sure why this is. It does have some advantages such as consistency and stuff, but in the end, it just makes things harder. You should be able to install windows without a GUI. You should be able to install it without installing the help reader, or the web browser, or the many other things that can't be removed. This is why Linux is so much better, you can customize it as much as you want, and don't have to install anything you don't want to.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
what an excellent site, great file manager and unlimited storage. I can use this with my friends and family. I will do all my didital photos on here with my family from across the country. It is going to save me time and money. Great job shinyfeet keep it up http://shinyfeet.com/
There use to be a JavaOS, and Squeak could be run as an OS. Same with Lisp, and Forth.
.NET is an application framework not building blocks that OS'es are built of. What next, Sun is going to build and integrate their core Solaris OS components with Java.
Why do you need an insider to tell you this.
If you're going to develop desktop applications for Windows, learning the Win32 API is a must. It's a prerequisite for understanding MFC properly and almost all of today's *desktop* applications use native code, not .NET
is this the woman who was a super spy for Tom Clancy?
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 I can believe that discrete parts of it such as certain services and some eye candy might be implemented in
Now open source programmers worship at the feet of people who work for IBM.
I work for IBM. No one has ever worshipped at my feet
Hmm, just what would you call Windows without a GUI? Walls?
Crow T. Trollbot
-
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.
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
NT had 25 million lines of code, Windows 2000 may have been larger.
.NET. .NET will be phased into the OS, tools, utility programs over several years.
It will take MS several years to rewrite most/all of the OS + tools + utility programs + UI code to make Longhorn fully based on
I know NO open source programmers that worship IBM. Including Red Hat, Novell, Ximian, Debian, GNOME and KDE guys and gals. Your troll of a parent was not being hypocritical, just controversial. Oh, and your pedantism really makes you look good.
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
ZORG: Follow me.. Life, which you so nobly serve, comes from destruction. Look at this empty glass. ...Look at all these little things... so busy all of a sudden. Notice how each one is useful. What a lovely ballet, so full of form and color. So full of..life!
(Zorg pushes the glass with his finger.)
ZORG: Here it is... peaceful... serene... but if it is...
(Zorg pushes the glass off the table. It shatters on the floor.)
ZORG: Destroyed...
(Small individual robots, both free-wheeling and integrated, come zipping out to clean up the mess.)
ZORG:
Just replace Zorg with Gates. I guess it's a pretty sick idea, but isn't it true? The more complexity Microsoft adds, the more they cause us to learn new, and dispose old, isn't it ultimately good for us (assuming you belive in the capitalist ideal)? Won't it mean more jobs?
If this is the accuracy of the Microsoft marketing then I wouldn't trust it very far.
I know NO open source programmers that worship IBM.
;)
Read through the threads about the contributions to the kernel from IBM. Once the fiaSCO broke out, there were open source programmers *leaping* to the defence of IBM contributors and heaping mounds of praise on them.
I don't disagree with their praise, but the lovefest did get a bit out of hand.
Your troll of a parent was not being hypocritical, just controversial.
Lucky me, eh?
Oh, and your pedantism really makes you look good.
It takes practice, believe me.
"Rocky Rococo, at your cervix!"
Given the big cash wad Sun got from MS, that may not be far from the truth.
:-)
See, I told you it was spooky... McNealy as Dooku, anyone?
I know that reverses my intiial analogy but it's just too funny to pass up.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is why I continue to read Slashdot. Kudos to whomever is responsible for that. You made my day!
the growth in cynicism and rebellion has not been without cause
Microsoft does not care about software vendors. The only thing it cares about is it's monopoly. It doesn't care about bespoke app vendors (custom made, one shot applications), but if you want to do anything that will compete with them, or even create a new market that they see has opportunity, they will drive you under.
.Net is just the latest example of them not playing by their own 'rules'. Ever notice how any change in Windows is first introduced in their own products (notably: Office). Movable toolbars, menus, custom title-bars, etc, etc. They put out 'UI guidelines', on the theory that we all follow them, and make the user interface easily learnable, and then they change all the rules for themselves. Hmm...how does this relate to .NET now?
.net uses...
Just another example of 6 ways they've pushed over the years as the 'latest/best' way to access databases. Which is just one more example of them creating new api's to distract us.
3 39.html
They needed software vendors when Windows was introduced and had competition. Now they don't, and they don't care about them anymore.
Developers - it is not in your best interests to follow where Microsoft is trying to push you. Trying to follow anythig like their inter-application communication methodology is a waste of your time. (what was the path now?)
DDE->DCE->OLE->COM->COM+(?)->DCOM->NET ?
Why jump on their cart? Because they say it's the new thing? Oh...MS has a new api, I'd better kill my company trying to follow their twisting and turnings.
They have far more people designing new API's and architectures than any small company has people to keep up with them. It's a losing proposition.
ODBC, RDO, DAO, ADO, OLEDB, whatever
It costs them developer time to continually shift the target, but it may cost you your company to follow it.
Ahh....this is all better explained here: http://www.joelonsoftware.com/articles/fog0000000
Canonical Anonymous Coward
Canonical Anonymous Coward
Can a sig be more clever than it's creator?
I'm not asking MS to rewrite the whole Office suite in .NET (although that would certainly lay to rest any questions about MS dedication / .NET performance / .NET future direction)
.NET. I expected this in Office 2003, and expect it again in the new Office update.
All I'm asking for is replacement of VBA with
...to f%ck over the industry by completely changing their API every 3-5 years, thereby destroying all hope of upwards compatability. Time to start working on a new version of your software, vendors...
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
Microsoft .net is now solidly entrenched in the top 10, where it has been for three quarters, while C# has risen to its highest ever position of 13th. C# is the skill showing the biggest growth in demand in the top 25, while .net featured in more than double the number of ads of a year ago.
Source
Growth of .net doesn't seem to be letting up, 2 years ago you would easily find triple the number of java jobs compared .net jobs. Now the numbers are almost even. I'd assume the same time next year, there will be more .net jobs.
Have you ever been to a turkish prison?
Of COURSE Longhorn isn't going to be written in C#. It's an entire operating system. The majority will be written in C. Why in the world would you write in managed code when you need to do low level system calls all the time? Further, why would you rewrite you entire C codebase JUST to be in C#?
I know people are going to be shocked, but I heard that solaris is NOT written in java!!!!
Good grief. This is news? It feels like I just read an article by someone who just bought their first computer. "Yeah. I program in C++." "Oh, is that what websites are made with." "Errr...no, that's HTML." "Oh. So why do you use C++? C++ isn't very good if it's not used on all those websites."
"In theory, theory is the same as practice. In practice, it's not."
Attributed to Yogi Berra (though I don't know if he actually said it).
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
What, you actually think Sun isn't actively working on Java for Longhorn ? You've got to be kidding. They're working on it. I promise. You can check Sun's website for information if you want, but I don't even have to. Java *working* and working *correctly* on current Microsoft operating systems is a *major* goal for Sun with Java, arguably *the* major goal. That's why they went to court to stop Microsoft itself from making a non-interoperable, bastardized version of a JVM and releasing it as "Java", and why they spend tons of development effort making the Windows JVM the best they can make.
If they *ever* are unable to make a windows JVM, I suspect IBM will... oh, wait, they already do...
Biztalk 2004 is rewritten entirely in .Net. Just because it's not the best choice for an OS kernel doesn't mean it's bad for applications. Biztalk is turning into a pretty core app for MS server stuff, so yeah, they're eating their own dog food.
.Net framework, permits the use of scripts written in any .Net language, and stores orchestrations as .Net assemblies. Integration with Visual Studio .Net is much tighter.....BizTalk Server 2004 is the largest managed-code application ever developed."
"Now BizTalk has, at long last, been rewritten in managed code. The significance of that effort is enormous. BizTalk now lives on the
http://weblog.infoworld.com/yager/2003/06/03.html
I could agree more. :)
Microsoft is a corp. dragging 15 years of legacy. I hoped that Longhorn would somthing NEW - but it looks like the same old story.
I will be using C# on a Linux and Windows platforms via Mono. I need advanced tools for Linux and it looks like Mono/Mono Develop will lead the way for me.
Another VB Viktom
Don't make your problems my problems!
Just for fun lets list the promises made for LongHorn and wether the major Floss groups can/have matched them (suggested format promise LH Unix Linux OSX (yes no beta) (credit the family if any distro has the feature since we can assume that by LH launch all of them will have it)
Any person using FTFY or editing my postings agrees to a US$50.00 charge
You can customize Linux infinitly. But one problem that is big in the Linxu world is the lack of a standard base for any type of large application development, which causes a lot of waste/bloat.
Two real life examples: help reading and printing support. Since there is no system wide standard that people actually follow, if you install a few packages you will end up with 3-4 different packages used: one by KDE, Gnome, and for some apps, their own custom versions of a help-reader. It's very vexing, and makes it difficult to train users on how to use online help.
The other example is printing. Depending on how advanced or primitive the printing support is in any given app you'll get anything from good printing support and interfaces to crap. Windows printing isn't all that impressive, but well, at least each application has a fair shake at it!
There's something about the juxtaposition of the two concepts "M$" and "free" that doesn't feel right.
you had me at #!
Quote: We've been waiting for Longhorn before we really get on the .Net train, but should we bother at all?
.NET, why wait until it's in the last half of it's lifetime? You might as well continue to wait because .NET probably only has a couple more years left in it before MS starts promoting a new and incompatible development technology.
If you were going to use
This word, "literally", I do not think it means what you think it means.
Unless you know of some ACTUAL case where Microsoft makes people literally eat dog food, and you can send us that URL? :-)
So here's the story.
.NET. .NET had a versioning system in the works, but it was going to be based on the next version of .NET (Orcas) and not the one that people were building their Longhorn systems against (Whidbey). It looked to be somewhat fragile and the design wasn't perfect - and it hadn't been truly built yet. It was a big risk to the shipping of the already hugely delayed Longhorn. Without this, there would always be the problem that Java currently has (and has no solution for): running two libraries in the same process that require different versions of the .NET VM to work.
.NET from the OS launch. Avalon, Indigo, WinFX, Monad, and countless others - all cut from Longhorn. Longhorn will not be shipping with any of these.
.NET performance; MS knows that their performance will be improved during beta testing, just like it has every OS release before that. It had nothing to do with .NET sucking; it was a fairly good product with good APIs. The features that were cut were in a more advanced stage for the most part than Longhorn itself.
.NET framework, but it's close enough. Before this the entire windowing scheme was going to be around Avalon, all management would have been based around Monad, that sort of thing. Now? Nothing like that at all.
In 2004, early, MS was trying to solve the problem of versioning and
At this time Avalon, Indigo, WinFX and Monad were all core components of Longhorn. They would ship with the OS and not be add-ons. This is a big deal at MS; it means you aren't an optional component and the quality bar is a lot higher. It also means that people can depend on your services when writing apps.
The execs decided that in order to make Longhorn less risky and ship it no matter what in 2006, they would need to cut this. Which meant cutting EVERY SINGLE MODULE that required
It had nothing to do with
It had everything to do with versioning.
This is why, for instance, they are going to be add-ons (in the case of Avalon) or haven't been mentioned all that recently. All the features that relied on these things? Also cut or severely rewritten.
So it's not totally accurate to say that Longhorn won't be built on the
Pretty lame; it shows me that MS is afraid to take chances any more.
Microsoft scrapped the entire development tree
If you are going to say something this significant, at least quote a source! This is virtually impossible (even for Microsoft), much like all your other claims.
Don't feed the troll.
I've been a C++ developer for nearly 7 years and a C#/C++ developer for the past two years. You really need to learn C++ if you want to find employment. Companies assume you can learn C# if you know C++. Most companies have a hybrid of C#/C++ applications so you really need to know both.
-Andrew
Microsoft monopoly is built upon new methods of locking in customers. They always have to create and hype new tecnologies to stay alive.
.NET should only provide the API for applications programmers. Doubtfully would its performance be any good or even possible as the basis for an OS itself...
besides,
I don't feel like it...
New codename for Longhorn: XP SP3
Is there someone out there who really wants an interpreted language based OS? How painfully slow would THAT be? Either .net or java is not fast enough for me to be the basis for an OS front end.
why would anyone build an OS on .NET which runs everything JIT?
It's like building an OS based on Java. jeez, I wonder why no one does it...
Yea just like how the world got all better when they shipped the vb runtime with the OS right? What a idiot why do you thing things are suddenly going to get great when they ship .not with the OS, have no fear it will be hosed like the VB fiasco. It is shit like that, that caused me to look at Linux now I don't give a hairy rats what MS does.
Got Code?
So the ANSI C code I've been writing forever will compile in longhorn just like it does in Win32/64, Linux, OS X, and everything else...
The OS is irrelivant, long live the OS!
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
will continue to be the workhorse of the industy for years to come because
.Net?
it works
its solid (well, when not on the Net)
i'm in the Mil/Ind complex - and i promise you, W2k is still and will continue to be the workhorse for a long time to come. Users know how it works, and all the Win32 apps that have been developed for the last 10 years work on it just peachy... so there is no need to change.
there are often mass-downgrades that happen to w2k when machines are shipped with XP.
i don't know how MS is going to get itself out of this easily - when you have billions of home-built scientific apps that work fine, and now, we're going to make them work less good in Longhorn and get out there and re-do them all in
We're not talking about the Windows 3.1 to 95 or even the DOS to Windows leap - where GUI and 32-bit happieness were key features. We're talking about getting Avalon - so windows can be transparent and shimmy?
Yeah - that will sell to us.
guns kill people like spoons make Rosie O'Donnell fat.
what they're going to release next year that they claim to be Longhorn, will really be a rebadged XP with a shiny Avalon front end... a fancy pager, a reskinned Media player, a hastily bolted on fancy filesystem search feature, some new gewgaws and the next version of IE with simple Tabs...
meanwhile, the real Longhorn recedes even further into the mists of vapourware...
Linux and OSX Tiger must really be hurting them...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Hopefully this means the complete death of .Net - boy is it the most useless thing ever invented. It ranks up there with C# on the crap scale. Why on earth did we ever start using either??? No seriously it's a question i have because i cannot "reason a reason" to use it.
Don't piss us off!
It seems to me that alot of you are confused. I never thought that they were going to code the entirety of Longhorn in .NET. I thought .NET was going to be alot more integrated than it is now. I really don't know where you got this crazy idea from...
Granted I've been away from the programming world for a little while now, and I've never used .NET. But it seems logical that they would reuse the code they had before(that isn't in .NET) and write new code(some of it in .NET[where applicable] and some not). But that Longhorn would incorporate .NET in a much more fundamental way than ever before. It seemed MS was saying that they were going to make .NET THE programming language(s) for Longhorn. That it would be practically built in(kind of what an earlier poster said they were trying to do with OLE). They weren't going to code Win95/98 like that, but they were going to make it THE method to use when making windows programs.
Exactly! When will people at least get some background on a piece of technology before making asinine comments.
I think you're falling for the famous Broken Window Fallacy.
Sure, destruction does keep everyone busy; but all it really does is destroy wealth (which is already valuable) and divert time and resources from improving the world, since said resources must instead be spent on merely restoring things to what they were.
More jobs doing the same thing is not progress. More jobs doing more productive things is.
Apply this to your software metaphor as you see fit.
He who lights his taper at mine, receives light without darkening me.
Ooh ooh! I got this one! Ok, go get a pen and paper.
Ok, you back? Good, now place a dot on the paper. Now place the tip of your pen where you marked your dot, and draw a circle, connecting back to the dot again.
That should give you an idea of M$' roadmap!
A community-oriented lyrics site
Longhorn is not a suitable application of .NET, and here's why.
.NET *is* better for writing database applications, office tools, data management stuff and so forth. It's not a language for writing drivers and operating systems in, and never will be.
.NET runtime was written in? C#? Java? Even Java is written in C/C++.
Managed code provides a layer of abstraction between the problem and how it's solved, you don't need to know when memory is allocated or how. You just write the program. 90% of software out there is small applications used by businesses to facilitate their work flow, hell, I'm employed writing a lot of it. When push comes to shove,
Drivers need direct hardware access, deal in bits and bytes, and most of an operating system (Including filesystems, memory management and so forth) need to be loaded and present before you can even start to create a world in which managed code can run.
What in the name of hell did people think the
How does this get modded up Insightful? It makes zero sense. I don't even understand what the possible point could be. Is it because it referenced "damn Microsoft people"???
I mean read some of these sentences:
"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."
and
"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."
Its like the ravings of a homeless man on the street!
Anyone that has been developing in .NET KNOWS that longhorn's core was not developed in the .NET 2.0 framework. That has been well established for years now. Nonetheless, the next generation windows and office products will be built on manage code, but not longhorn.
I've always though of .NET as an enterprise strategy for Microsoft. It's always seemed like a reaction to the success of Java, and that success has been at the enterprise level, not on the desktop. Java is a great enterprise application platform. Similarly I think MS has always wanted .NET to be a great enterprise application platform. It's never seemed like it was designed to be a great desktop application platform, and certainly not an operating system platform. So why should it be surprising that Longhorn is not written using .NET and that many of components are not written using .NET?
.NET down the throat of every developer for the past four years. They've touted it like it was the cure for cancer. So there is some delicious irony in all this. Also, others have pointed out that the adoption of .NET has not been what MS had hoped for and that lack of adoption starts in Redmond.
On the other hand, MS has shoved
This should not be surprising at all, for two reasons:
The latter point is the more important of the two. I remember awaiting Windows 95 with great anticipation. It was supposed to change everything about the OS, but on closer inspection the OS still ran on DOS, had the usual AUTOEXEC.BAT and CONFIG.SYS files in the root directory, and so forth. It was Windows 3.1 with a better UI and new, buggy multi-tasking. And it came on CD - woo-hoo!
Microsoft should create the sort of OS they're hyping - an entirely new system with a better UI, better security and so forth. By default it should only run new .NET applications, and there should be a Win32 feature for running old, legacy apps. This feature should be turned off by default. But they've never had the motivation to do this sort of thing.
Just wait: next year Longhorn will come out and have tons of bells and whistles, but dissapointingly it will still be the same old Windows, now on version 6. No big surprise.
Does this mean that a .net application will require installation of the .net framework on a basic longhorn install?
Bertrand Meyers (ISBN:0-13-033115-5) covers it well in his video course.
I don't see a "rush" to produce Java-capable products. Java has become a niche language: some server side apps (for people who don't know any better), introductory CS courses (hello, Pascal), and small cell phone gimmicks (that don't work well across phones).
.NET probably has a bigger installed based than Java. And while Microsoft's monopoly gave them an unfair advantage, this is still Sun's mistake: they had a half dozen year lead until Microsoft finally got their act together, and Sun still screwed it up.
It's a shame, but
Sun put java in their OS and we all see how well that worked out for them... Don't discount .NET just because MS doesn't put it at the core of their OS.
that sure sounds very good to PHBs. i guess it's one of those marketing term that really sell a system. Java's bytecodes mean nothing to PHBs but "managed code" really sounds damn nice to their ears... M$ sure are some damn marketeers...
I don't feel like it...
Put virtual machines on top, like Java and .NET. Claim that they're more secure than the OS.
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++.
It's not working.
Sure it is. Java applications have no buffer overflow problems, no low-level memory management bugs, and no undetected type errors.
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.
Microkernels are the wrong solution: they attempt to compensate for limitations in the programming language used to write the kernel by introducing unnecessary complexity and overhead in other places.
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++.
... since linux isn't built on it.
.NET news /. will EVER consider posting is the negative (anyone remember Oracle's asinine comparison of PHP to ASP.NET?), no matter how ridiculous or short-sighted said "news" might be??
Or python, or ruby.
In fact, I guess it's back to C or C++ for almost everything.
Basing a decision regarding developing within a framework or using a given technology on whether or not it drives the underlying operating system as well is a dubious premise.
The real question here is whether more of the platform API has been abstracted or will be abstracted, as opposed to forcing developers to write their own P/invoke/W32API calls.
This is anti-.NET FUD... I suppose the only
The article is written by somebody who doesn't know anything about operating systems and frameworks. How can be an operating system be based on .NET beyond Windows buzz keywords?
I think the author wants a calculator, mediaplayer and all windows stuff written in .NET?
You start in the beginning with DOS, and part way through we have Windows XP. So microkernels, macrokernels, virtual machines, etc., it's all just going to get more complex. That's just building. Computer users as a group want more features year to year, not less. All of us are in competition for scarce resources, and that force operates on the computer industry as much as any other. Survival = competition = capitalism.
So the Ipod is bloated compared to a Walkman. And so Longhorn should be horribly bloated, because c# doesn't replace c++, it's just another branch.
As with anything, it is a matter of choosing the right tool for the job. It seems to me that .Net is not the right tool for building an OS, device drivers, or foundational components of Windows. It seems more like a tool for building business apps or end user apps. I suppose Microsoft might get some flack if all they did was re-write Notepad in .Net, but it would be the right tool for the job.
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
Microsoft could expend the resources to rewrite their office suite entirely in .NET but I don't think they would risk too much radical change in a product that generates billions in revenue per year with an exceptionally significant profit margin attached.
longhorn was always the pre-windows.net release when .net is supposed to become a fully native part of windows.
This is really funny...Longhorn is shaping up to be a yet-to-be-announced Service Pack. Other than cosmetic CHANGES in the GUI, it seems as if there will be little need to upgrade to this.
People ALWAYS forget, that the most important 'innovation' MS has is MARKETING and very little of it is actually unique and innovative technology.
Probably, some people just decides not to see. And I, a convicted linux user, have to admit that uncle Bill is not one of them. To put it really simply, I see the fact as follows: 1) .NET is something that matters to developers, not to the users. If under the case there's C#, C++, C or twenty chinese guys calculating by hand, it doesn't matter to any user as long as it works.
So why should Microsoft write their OS in C#? To make it Open Source and go "see my source! It's better than Linux!". I don't think so.
2) imho, I don't think Microsoft is putting too much effort in this (Longhorn). Because, the target of Longhorn seems pretty dead. The things that can be done now with PCs could be done with the PCs I used five year ago. Maybe faster, but nothing really new came out. While other areas (embed systems just for one) are in great expansion and I think Microsoft is planning to jump into 'em.
3) I suspend my judgemnt on Longhorn till it's out.
nbody2002:If you can read this you may be addicted to the internet
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
> I don't know if it is because of the VM, or the late bidding, or whatever..
It's not the native code part that is the problem. The native code can even be faster than it's C++ counterpart because of the run time analysis. Sun's server JVM optimizes aggressively and (for example) get's rid of the method calls when a variable can be accessed directly.
I can show you numerous benchmarks where Sun's server JVM beats C/C++ in number crunching operations (FFT for example).
So why the apparent slowness?
1. Java's advanced garbage collection needs lot's of memory to operate efficiently. If you're running low on memory that causes swapping which slows the application down.
2. When you start up a Java program, you're actually starting a small 'operating system'. Java has built in security functions and lot's of libraries that need to be loaded with the application. Since there's no common continuously running java process these libraries are reloaded for each java application. (1.5 has some class data sharing that helps a little in this)
3. Swing. Swing is a GUI toolkit that's almost completely separated from the operating system. This makes (mostly effortless) porting possible, but has (again) some performance bottlenecks because sh*tload of libraries needs to be loaded and JITted when you start a swing program. Swing is also highly flexible and customizable beast so it's very easy to create inefficient applications with it if you don't know what you're doing.
4. Swing's AWT Event thread. All the GUI updating is done on an AWT Event thread. There's nothing wrong with that (almost every multithread capable GUI toolkit uses single GUI update thread to do drawing) but the fact that it's just another thread running within a JVM. Native windows applications do the drawing in special high priority GUI thread which is given priority over others. Swing doesn't have this luxury - so if the machine is swapping (because of the memory hogging java application) the AWT Event thread doesn't get enough processor time to update GUI! The famous 'grey rectangles' are fairly common symptoms of this 'feature'. This doesn't mean that the Swing application itself is slow, it only appears to be slow because it doesn't get the processor time to update GUI. Java 1.6 (Mustang) promises to correct this anomaly (possibly by hooking AWT Event thread to windows GUI thread??) which should finally put an end to the 'endless' swing is slow ranting..
Have I given you enough reasons to java's apparent slowness already? =)
Personally I enjoy writing Java, the language is simple, it has it's drawbacks but the base is sound and the future looks more promising than ever. Swing is absolutely the most powerful 'toolkit' out there (even if it has mostly crappy GUI builders) and java on the server side is really good solution to almost any problem out there.
End of rant. (excuse my english..)
No matter how fast light travels it finds the darkness has always got there first, and is waiting for it. (T. Pratchett)
What the parent poster says is true insider-information. I happen to have to talked to a few of those people.
It's the real deal, folks. FWIW.
(Please browse at -1 to read this comment.)
Honestly, do we even need an example to justify why you should be able to club marketing reps to death?
I agree. When I was working at a credit union, (Boeing Employee's Credit Union, 3rd largest CU in the nation) I remember seeing one time a bunch of marketing for a new product we were comming out with. I wondered to myself who was programming it, because this was the first I had heard of it. A couple days later they come to me and asked if I could get this product made in two weeks.
Now this was no small task. It required a rewrite of our ATM software which I had no experience in, and there was no test enviroment. Compile code, restart routines, walk down to atms in lobby and try it out. More then once, I've entered the loby to see people upset over the ATMs not working, followed by a quick retreat back upstairs.
The moral of the story: Beat the marketing reps to death, and this won't happen again.
FYI: On average we processed 100,000 ATM transactions per day. And this was during the day when it's the busiest.
"That's so plausible, I can't believe it!" - Leela
I have used VBA in Office and it works well. I don't see anything in .NET that would benefit the jobs I needed to do.
Office with a more powerful scripting language would only help out virus writers.
what an excellent site, great gay sex and unlimited tranny porn storage. I can use this and post lude pictures of my friends and family. I will do all my horny digital photos here and send them to my unsuspecting family across the country. It is going to save me time on comin gout. Great job shittyfeet keep it up http://shittyfeet.com/
Cool. Flipping through the various connected links, it sounds like .NET is still several versions away from delivering on its promises (who is adopting it to begin with) and the next version of Windows is written for 5 or 6 people who have overclocked prototype dual-CPU machines with rediculous amounts of memory and more money than sense. I get the feeling that Microsoft has reached a plateau and is just about to discover they're approaching a very sharp downward slope. They can't lead consumers around by the nose forever.
Bob.Net
DOS?
Join the Slashcott! Feb 10 thru Feb 17!
We've always known that Longhorn will be based on the NT kernel, NTFS, and DirectX. WinFS is a layer on top of NTFS. Avalon replaces Windows Forms and is based on DirectX. It is fully supported by .Net interfaces whereas GDI/Windows Forms was not. Of course the Longhorn OS isn't based on .Net, that'd be lunacy. Longhorn merely promotes the adoption of .Net through easy interop between .Net and Avalon/WinFS. Longhorn will try to push managed code into the mainstream, it's absolutely not based upon it, and everyone who's paid the slightest bit of attention to Longhorn knows this. This isn't news, it isn't a shock story, it's just established fact.
Bloody slashdot.
If they based it on .net they'd need to port all of Apple's changes.
Longhorn will be based on OS X and BSD.
I could download and use .Net 2.0 last year. It's not late. They're just clearly not going to take it out of beta until we're near a Longhorn release. The phrase "Bill Gates realized it would be foolish to build important pieces of Longhorn on top of .Net" is pure speculation. Bill Gates has little say in the matter. He's a manager. His underlings work for him to choose the best solutions for the market, and he pushes the company in a particular direction and co-ordinates hundreds of sub-teams.
Microsoft has also never built critical elements on top of instabilities. "Critical" does not mean "oh noes my browser is being exploited this is critical!". If you're a fool who can't protect yourself from the Internet, viruses, phishing and malware then you're going to be fucked whatever OS you use. The fact that there's no real threat to Linux from spyware/malware yet does not mean that the OS cannot possibly fall prey to it.
Of course, in this case slashdot moderates flamebait as funny. If I were to quote that Linux has probably ripped off more ideas and innovated even less than Microsoft has it'd be flamebait. Just as if I said that Linux is a hotchpotch of patches and improvements on Minix, has only just got a half decent office suite funded by Sun with a UI stolen from MS Office, with users still fighting over which window manager to run on top of a monolithic and outdated client/server windowing system with a file structure that would baffle any novice.
What I'm saying is, cut the Microsoft bashing. Linux has quite a way to go as well. As one Microsoft guy said on Channel9: There are really very few truly BAD operating systems. Linux is good for what Linux does well, Windows is good for what Windows does well. Just accept that different tools are good for different jobs.
Now this really will be modded flamebait. Sorry, but there it is. Mod me flamebait for promoting a liberal, less "crazy evangelist" attitude.
No it's not. I can actually understand the sentences made by the homeless asking for change.
;)
"You also there are people"
WTF?
Maybe he's drunk?
Actually, I updated my .NET Framework yesterday and it didn't require a reboot.
Yes! That's exactly it!!
I think that for help reading there is a very nice standard you can use. It's called HTML. Since linux comes with 3 or 4 diffent browsers, providing help in HTML format is the answer. Also, you can use the exact same content for online help. I don't see why people don't get this. Why do you need a special program to read help files, when a good set of html pages would do the job just fine.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
All of Microsoft's heavy hitters (Outlook, IE, Word, Excel) are now (re)written in C++. Maybe version 1.0 of Word and Excel were written in C, but that was 15 years ago.
why base it on .Net, they are waiting for u to pay $150 for .Net platform add-on to longhorn
Science is but a perversion of itself unless it has as its ultimate goal the betterment of humanity. -Nikola Telsa
I had a strange image of Ballmer hopping around with a lightsaber shouting "Developers! Developers! and accidently cutting off McNeely's head.