True. I say 'principle API of Longhorn' because Longhorn's features, such as the Avalon window rendering & graphics, or the Indigo messaging system, will be available through WinFX and not Win32.
But you're right, there will still be code written on Win32 until the WinFX API becomes ubiquitous like Win32 has. Even then, Win32 will be around for many years (decades?) until there is no need for it any longer, which I don't see happening for a very, very long time to say the least.:-)
Yes, there has been some preliminary work in the "managed OS" direction (for example, Microsoft's experimental managed OS, Singularity) but all that is research; it would be foolish and hasty to try to implement Longhorn completely in managed code.
Look, there will always be the need for unmanaged applications, like I said in my original posting. I think we agree there. That's why you can choose to use Win32 for many, many years to come.
WinFX brings some good things to the table: a windowing & graphics system that is resolution independent, scalable, and can offloaded to video memory (as opposed to GDI+, which is almost all CPU-based). Let's not forget that 3d GUI objects can be mixed alongside 2d GUI objects, which has proven pretty beneficial to operating systems like Mac OS X.
WinFX also brings a unified messaging system. Here on Windows we have DCOM, web services with SOAP, MSMQ, Remoting, J2EE messaging, to name a few. WinFX's messaging system can not only interoperate with the existing messaging systems, but it can do it in a transactional & reliable way. All unified under a common API. I think that is a pretty nice benefit IMO, especially for me as a developer who's had to communicate with disparate messaging systems by writing custom communication code every dang time.
Also, memory management as a "slight tedium" is the biggest understatement of the day, my friend.:-) If memory deallocation was such an ease, we wouldn't have Java GC,.NET GC, COM ref counting, boost C++ smart pointers, to name a few.:-)
No, the article implies Longhorn will not use.NET, or will use it very sparingly in only "small parts" of the OS.
It's kind of funny, the article says Longhorn will use.NET in only small parts of the OS: the Windows API and Avalon. What the article fails to mention (or more likely, the author failed to realize) is that the Windows API is the central part of Longhorn; all applications that use the primary Longhorn API must be managed in order to use it. Not to even mention Avalon or Indigo, both of which are huge platforms (not "small parts") of Longhorn.
I say "managed" because the code is managed by a runtime environment that manages security, memory allocation/deallocation, and so on. I certainly don't mean it as a marketing term, but as a technical term speaking to developers.
By 'principle' API, I mean the application programming interface that will be the most often used, the primary library used for developing applications on Longhorn.
The Win32 API will still be there, fully supported and maintained, but if you're writing a new application, WinFX will be the prime choice.
Hey, just wanted to say I love those comic videos you and Scott did recently. Also, the pure programming inspiration that is NeoFox, heh, that was a gem.
Win32 makes direct system calls just as it does today; it won't have to go through the managed WinFX layer, as that would induce marshalling overhead for unmanaged applications.
How many times does this need to be said? Longhorn's kernel is not managed code, nor should it be.
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:
Longhorn is an unmanaged OS, of which.NET is a central part.
Longhorn's kernel is not managed, nor should it be.
Longhorn's primary developer API is managed, as it should be. The unmanaged Win32 API will still be there, of course, but will no longer be the principle API.
No, Longhorn's primary developer API is not just a wrapper over the Win32 API.
Passing laws blocking undesirable behavior is not the answer, and has failed over and over again throughout the American political system.
Currently there are a lot of debates in America over laws prohibiting marriages between same-sex couples. Even though I personally, as a believer in Christ, am against homosexuality, I don't believe passing laws blocking the behavior is the answer. It would be better to change the people from the ground up rather than passing a generic law trying to block the behavior at a higher level.
Well, calling Sun a "half-dead ex-competitor" is a little strong, considering Microsoft's.NET doesn't have near the market share as Sun's Java. Sun's Open Office is the #1 competitor to Microsoft Office.
Basically, Sun competes against MS on application development, web development, and office suites. All those are critical to Microsoft; that is nothing to be minimalized.
Oh I don't know, maybe the fact that about 95% of the people here bash anything non-Linux or non-GPL.
Try posting anything in the least bit positive about Microsoft (e.g. ".NET is a pretty good tool", etc), or anything that goes against the GPL (e.g. "the Java license works for most except the RMS supporters") or anything negative about Linux, you'll be modded down, silenced out of the discussion, followed by several APs claiming they've had sex with your mother.
Slashdot is the web's most vicious peanut gallery.
I can imagine lots of applications for this new battery including my own laptop.
For a limited time only! Now you too can have zero sperm and have a radioactive schlong. Just set this laptop on your lap for a few moments, and you'll be long, green, & sterile in no time!
No, that's the point you made in response to the parent who stated it's "damned if you do, damned if you don't" for Microsoft on Slashdot.
We could debate whether Microsoft's code base is secure until we're red in the face, but that's an entirely different topic that is seperate from the parent's point.
You totally missed the point. Regardless of how secure XP is, if Microsoft were to bundle AV software with the OS, the same Linuxoles bashing them for not having an AV package would bash them for bundling one, stiffling competition.
If you look at last week's security advisory, it was published by Secunia, the same company that's published various IE security holes in the past.
Which one should we go for?
on
Safari vs. KHTML
·
· Score: 0, Flamebait
Hello Slashdot editors and fellow Slashdotters,
I am fine, how are you? Hope you are doing well.
Pardon my curiousity, but I would like to know what is the official/. position on this particular topic? I would like to think everything related to OSS is in the right, and corporations are always wrong, but I have a predicament. We always let Apple slide on things like vendor lock-in and other topics other ideas we hammer other corporations for.
I'm just not sure who I should be rooting for! Please help! Respond to this soon, as my head is hurting from trying to decide on my own, I need you to make up my mind for me.
Yep, no problem. I'm actually a FF fan too (using 1.0.4 to post this), but it's good to realize the FF is not as invulnerable and ironclad as some Slashdotters would have us believe.
Dave, while that's usually the case, there have been several bugs that the Mozilla foundation has marked as private and have kept from the public for more than 2 years. I believe such cases have been mentioned by several slashdot posters in the past.
Slashdot Mirror
True. I say 'principle API of Longhorn' because Longhorn's features, such as the Avalon window rendering & graphics, or the Indigo messaging system, will be available through WinFX and not Win32.
:-)
But you're right, there will still be code written on Win32 until the WinFX API becomes ubiquitous like Win32 has. Even then, Win32 will be around for many years (decades?) until there is no need for it any longer, which I don't see happening for a very, very long time to say the least.
Yes, there has been some preliminary work in the "managed OS" direction (for example, Microsoft's experimental managed OS, Singularity) but all that is research; it would be foolish and hasty to try to implement Longhorn completely in managed code.
Look, there will always be the need for unmanaged applications, like I said in my original posting. I think we agree there. That's why you can choose to use Win32 for many, many years to come.
:-) If memory deallocation was such an ease, we wouldn't have Java GC, .NET GC, COM ref counting, boost C++ smart pointers, to name a few. :-)
WinFX brings some good things to the table: a windowing & graphics system that is resolution independent, scalable, and can offloaded to video memory (as opposed to GDI+, which is almost all CPU-based). Let's not forget that 3d GUI objects can be mixed alongside 2d GUI objects, which has proven pretty beneficial to operating systems like Mac OS X.
WinFX also brings a unified messaging system. Here on Windows we have DCOM, web services with SOAP, MSMQ, Remoting, J2EE messaging, to name a few. WinFX's messaging system can not only interoperate with the existing messaging systems, but it can do it in a transactional & reliable way. All unified under a common API. I think that is a pretty nice benefit IMO, especially for me as a developer who's had to communicate with disparate messaging systems by writing custom communication code every dang time.
Also, memory management as a "slight tedium" is the biggest understatement of the day, my friend.
No, the article implies Longhorn will not use .NET, or will use it very sparingly in only "small parts" of the OS.
.NET in only small parts of the OS: the Windows API and Avalon. What the article fails to mention (or more likely, the author failed to realize) is that the Windows API is the central part of Longhorn; all applications that use the primary Longhorn API must be managed in order to use it. Not to even mention Avalon or Indigo, both of which are huge platforms (not "small parts") of Longhorn.
It's kind of funny, the article says Longhorn will use
I say "managed" because the code is managed by a runtime environment that manages security, memory allocation/deallocation, and so on. I certainly don't mean it as a marketing term, but as a technical term speaking to developers.
By 'principle' API, I mean the application programming interface that will be the most often used, the primary library used for developing applications on Longhorn.
The Win32 API will still be there, fully supported and maintained, but if you're writing a new application, WinFX will be the prime choice.
Thanks Rory.
Hey, just wanted to say I love those comic videos you and Scott did recently. Also, the pure programming inspiration that is NeoFox, heh, that was a gem.
Win32 makes direct system calls just as it does today; it won't have to go through the managed WinFX layer, as that would induce marshalling overhead for unmanaged applications.
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:
Gigabyte has stated they will throw in a free Nuclear Power Plant to help pay for power consumption when you buy one of their 4-card chipsets.
Passing laws blocking undesirable behavior is not the answer, and has failed over and over again throughout the American political system.
Currently there are a lot of debates in America over laws prohibiting marriages between same-sex couples. Even though I personally, as a believer in Christ, am against homosexuality, I don't believe passing laws blocking the behavior is the answer. It would be better to change the people from the ground up rather than passing a generic law trying to block the behavior at a higher level.
Well, calling Sun a "half-dead ex-competitor" is a little strong, considering Microsoft's .NET doesn't have near the market share as Sun's Java. Sun's Open Office is the #1 competitor to Microsoft Office.
Basically, Sun competes against MS on application development, web development, and office suites. All those are critical to Microsoft; that is nothing to be minimalized.
I would very much find that fruitful. Most /.ers I've talked to over the last 2 years are very much prejudiced.
The same reason we all post, to put out our opinionated, prejudiced opinions. :-)
The misconception that the posters are somehow all independent thinkers, ha, well I will leave you to that if that's what floats your boat.
Oh I don't know, maybe the fact that about 95% of the people here bash anything non-Linux or non-GPL.
Try posting anything in the least bit positive about Microsoft (e.g. ".NET is a pretty good tool", etc), or anything that goes against the GPL (e.g. "the Java license works for most except the RMS supporters") or anything negative about Linux, you'll be modded down, silenced out of the discussion, followed by several APs claiming they've had sex with your mother.
Slashdot is the web's most vicious peanut gallery.
Oh, there are a few independant thinkers. But mostly everybody here is of the follow-the-leader mentality.
Linuxole == thee teens/twentysomethings that live with their parents and go to Slashdot to bash "M$ windoze". I'm kind of liking it, actually.
I can imagine lots of applications for this new battery including my own laptop.
For a limited time only! Now you too can have zero sperm and have a radioactive schlong. Just set this laptop on your lap for a few moments, and you'll be long, green, & sterile in no time!
No, that's the point you made in response to the parent who stated it's "damned if you do, damned if you don't" for Microsoft on Slashdot.
We could debate whether Microsoft's code base is secure until we're red in the face, but that's an entirely different topic that is seperate from the parent's point.
You totally missed the point. Regardless of how secure XP is, if Microsoft were to bundle AV software with the OS, the same Linuxoles bashing them for not having an AV package would bash them for bundling one, stiffling competition.
If you look at last week's security advisory, it was published by Secunia, the same company that's published various IE security holes in the past.
Hello Slashdot editors and fellow Slashdotters,
/. position on this particular topic? I would like to think everything related to OSS is in the right, and corporations are always wrong, but I have a predicament. We always let Apple slide on things like vendor lock-in and other topics other ideas we hammer other corporations for.
I am fine, how are you? Hope you are doing well.
Pardon my curiousity, but I would like to know what is the official
I'm just not sure who I should be rooting for! Please help! Respond to this soon, as my head is hurting from trying to decide on my own, I need you to make up my mind for me.
Thank you Slashdotters and Slashdot editors,
Sincerely,
Gabriel
Yep, no problem. I'm actually a FF fan too (using 1.0.4 to post this), but it's good to realize the FF is not as invulnerable and ironclad as some Slashdotters would have us believe.
Dave, while that's usually the case, there have been several bugs that the Mozilla foundation has marked as private and have kept from the public for more than 2 years. I believe such cases have been mentioned by several slashdot posters in the past.
From the parent,
Heck, even on Slashdot the editors don't just make stuff up so that it fits their story.
From the Slashdot headline,
"Wired Online Retracts Stories"
From the flippin' article,
Wired News is not retracting any of these stories.
Quick, Dial 911!!!!
OK, just as soon as my phone is done rebooting.
How horribly ironic it would be if the man in need of an ambulance died while you were rebooting after a blue screen of death.