Submitted by “Early milestone builds of Windows 8 have leaked onto the Internet, and considerable effort has been put into figuring out how they work. Though officially tight-lipped, snippets of information have escaped Redmond’s walls. So far, it appears that Windows 8 development doesn’t just look not bad – there are signs that it will actually resolve many long-standing annoyances with writing Windows software. If Microsoft can pull off everything it’s hoping to achieve with the platform, Windows 8 will be as important and radical a release as Windows Longhorn was going to be.” Fantastic article by Ars’ Peter Bright. His stance on H264 and WebM may boil my blood at times, but this is a good piece of writing. Highly recommended.
It reads as speculative fiction. This has been officially promised before in longhorn. It would make a lot of sense for Microsoft to do this. As he laments at the end of the article, their PR strategy of silence on the HTML5/dotNet/Silverlight win 8 controversy right now doesn’t make a lot of sense. Sometimes companies do stupid things that aren’t in their long term interests. Not doing what Peter Bright is speculating would be one of those times.
Well, at least the pieces are now all in place – with that I mean that Windows in and of itself is in a pretty decent place, and doesn’t need to go through the round of low-level stack rewrites that Vista brought to the table. It makes more sense now than in 2002, but in the end – it’ll all depend on if they can pull it off.
While that is true, its exactly what I thought in 2002. They just merged the consumer friendly 9x line with the stable NT line to create WinXp. We didn’t know at the time how bad the code was underlying it all, we had to ( and still have to) take Microsoft’s word for it.
Having been a Visual C++ MFC developer, IF this happens, this would be good news. In a way, C++ became the ugly step-child on Windows. It went from being the Cadillac language for important third-party Windows apps, to an afterthought after the arrival of .NET. While you can write managed C++ apps, it is very messy – an awful kludge at best.
I would be happy to see C++ step up again to be a peer of Visual Basic and C#. At times, there is still a need for native application. Not everything should be written for the Web. I really hope this happens.
And as being a C# developer I would want this as well. There are a ton of great features that C++ developers enjoys which we want as well.
Which are?
We’re not going to get deterministic destructors in C#, at least not unless something radically changes – it just doesn’t mix with a root-tracing GC. (There’s a pretty thorough analysis of why out there somewhere).
We’re not going to get native performance either, not that it really matters (as long as we can P/Invoke to native code).
So what do you feel C# misses that C++ has? I find myself missing C# features in C++ more than the other way around, though thankfully C++0x fixes some of the important issues.
I don’t think it is LANGUAGE features that either is missing. It is support of the full API of Windows. Some things were .NET only, and kludgy to use from C++. Some things were Win32 API only, and more cumbersome to use from C#. Creating a standard API that is avaiable in the native mode of each language is what is important.
Edited 2011-06-24 17:50 UTC
That’s the point. As both C++ and C# developer (now mainly C#) I neither need nor want C# language features in C++ or viceversa. However, I want to access some native apis from C# and some .NET apis from native C++.
Yes, thank you! Right now, there are some gaping holes in the .NET library that forces C#/.NET devs to pinvoke to the Win32 API. So instead of plugging those holes, MS is (according to the article) writing yet ANOTHER framework that runs alongside Win32, plus a new GUI framework so that C++ programmers can access the WPF stuff. And then HTML5 is gonna fit in there somewhere.
If all this is true, it means that Windows is turning into a real clusterfuck of frameworks and wrappers. If this WinRT API ends up being a clean version of the Win32 API and you can write native apps with it, would there be any reason to code .NET apps anymore?
No…They are writing an API wrapper than both native C++ and .net applications can use to access windows features and C++ is being given full access to the .Net framework.
And, would there be a reason not to use .net?
I would ask you as a .net developer… is there a reason to use C++ anymore?
Edited 2011-06-24 23:02 UTC
So you’re saying there’s gonna be two different frameworks (WinRT and .NET) that both C++ and .NET developers can use? Why not just have them both using the same framework instead of two different ones?
Maybe I should rephrase the question… instead of making it so you can either code native apps or .NET apps, why not make it so everybody is coding the same thing going forward, either native or .NET? I don’t give a shit which way they go… just go ONE direction and stick with it.
Basically what I’m saying is, why make a split between C++ and the other .NET languages? If they’re going to insist on having BOTH native and .NET, why not allow C# or VB developers to write native apps, when C++ devs will be able to do both? Why are C++ devs the only ones allowed to choose?
winRT is not a framework, it is an API into windows.
Do you understand the difference between a framework and an API?
.net is a comprehensive set of tools to use for many common activities that developers perform in a program….WinRT is an API into windows, allowing deep control over the operating system.
In this case… from the perspective of a C# developer, WinRT would look like a namespaced set of tools for working with the OS directly in ways that could not be easily done before in C#, in the Case of a C++ developer, .net would look like an add on framework of tools (like the standard library) and winRT would simply replace win32, COM, MFC, etc and hopefully make interacting with the OS less of a pain in the ass and perhaps even make use of some nice C++2011 Changes.
Edited 2011-06-25 15:37 UTC
Portability, code reuse, performance, avoidance of VM bloat.
If you write code in C#, you are a serf for Microsoft for the lifetime of that code. Not so for C++.
If you are writing Win32 C++ code, then portability is not a concern.
If I write C# code against most of the .net framework, I can still port that to Linux and MS offers a CLR for OS X.
Edited 2011-06-25 15:39 UTC
Huh? Only very a small part of a given C++ program would be accessing a low level api like the win32 one.
Depends on how you would write the code as to how portable it is…. however, I think my example showed that C# is pretty dang portable for the domain that it is used in.
Hey.. I very much like C++/CLI. It is pretty amazing tech.
This article mostly focuses on native (nonmanaged) C++.
I know; I was simply replying to parent.
There is a lot of weird things going on in the Windows 8 bits. First, they’ve severed the garbage collector from the CLR, and are making some kind of low level bridge between the CLR and this new native runtime.
They’re doing a lot of work around COM stuff (which is now apparently called WinRT).
They’ve reengineered a lot of top heavy WPF class libraries and made them really, really slim (WPF always was an infinitely complex swiss army knife).
My best guess is we’re going to see something completely radical, the biggest change in .NET ever, in fact .NET may cease to even exist as we know it. The result could be something which blurs the lines signifnicantly between managed and native code.
Think the performance of native code with the protections of managed code, or being able to go in and set varying degrees of protection on various components in your project.
There is a lot of question marks in my head, including the fate of the bytecode (along with it architecture independence) and other things.
What I can say is , for all this work, this thing better be wicked fast. Imagine, if they implement their C++ AMP stuff into their low level frameworks. That’d scream on modern GPUs.
The C++ experience would be great if MS swapped out Win32 API for Qt. They could also promote Javascript+HTML5 for other parts. I hate it when I have to debug+hack Win32 code. For some weird reason it is always convoluted.
You mean swap MFC for QT. I think MS can’t use QT, even if they buy it from Nokia and they forgot somehow that QT is dual licensed, they already have a better api for .NET: WPF. And QT isn’t suitable to well integrate with both native apps and .NET. I think DirectUI and WinRT will be a part of a new set of apis that will be more suitable for windows programming than QT.
QT is just a wrapper that relies on Winapi calls. MS needs some apis that are written around their operating systems and technologies and integrates well.
Edited 2011-06-26 10:38 UTC
Windows 8 is a mixture of Windows 98 ActiveDesktop (DHTML pages as desktop) and Microsoft Bob (dumbed down interface).
Active Desktop => Yes.
BOB => No.
Active Desktop could have been configured to be exactly like win 8’s interface … if Windows 98 was secure, HTML 5 existed back then, and it was stable. I’ve always thought that they had the right idea with that one.
BOB is not what windows 8 is. Bob was a tour guided /wizardly experience. Windows 8 is Fitt’s law applied.
Edited 2011-06-24 17:37 UTC
No. It was intended to be a replacement for the traditionally too complicated desktop (with a main view on novice users who didn’t understand the metaphors and pictograms and needed a more “common” approach to GUI interaction).
See this article at the GUI gallery:
http://toastytech.com/guis/bob.html
It was much more than a “tour”: It had specific applications that claimed to be used for productivity (although the term is highly debatable here).
Yeah, you didn’t understand my analogy. I understand it was a desktop replacement. They replaced it with a series of tour guides and rooms. Some apps had a different guide that would help you accomplish the features exposed in that room. Its where the whole clippy idea came from.
Why people would want something that’s bloated and connected at the same time, the fundamentally insecure combination of most modern web browsers, to be at the core of their desktop experience remains beyond me.
Oh, well, I do have an idea that’s linked to the fundamental nature of the internet, but I don’t think it’s about that.
I really hope they work to get this right and don’t rush it. Windows 7 is awesome and we can use it for a long long time. I hope MS takes their time with Windows 8 and doesn’t shove it out the door and shelve the really desirable features this time around.
Edited 2011-06-24 16:53 UTC
Ya know this, this right here, is what to me gives MSFT an advantage over the competitors, even the free ones. How many years of support have we gotten for XP? Something like 14 YEARS by the time it is EOL? And Windows 7 is due to be supported until 2020?
With Apple it is stay on the treadmill or get abandoned, with FOSS it is the 6 month driver breaking death march, but with MSFT one can simply wait and if you time it right completely avoid the occasional bad OS. One could have easily (and still can) go from WinXP straight to 7 while avoiding the bugfest that was Vista, just as one will be able to completely skip Win 8 it if turned out to be another Vista style SNAFU.
So frankly if MSFT bones Win 8 like they did Vista there really is no reason to panic, as both MSFT and third party software developers will continue to support both XP and Win 7 for quite a while. Hell personally I wouldn’t be surprised if third party software continues to support XP even after EOL, just as many programs just released still run just fine on win2K.
So there really is no reason to panic developers, companies are just now switching in mass to Win 7 and by the time 7 is EOL there will probably be Win 8-10 to choose from. Frankly I am quite happy with Win 7 HP and don’t see myself jumping ship anytime soon. For me Win 7 “just works” and the cheap family packs made it trivial to switch over all my relatives.
Which part of “Developers DO NOT WANT to use .NET” for applications do you not understand? Java was there before, java failed. Only a very small minority used it for that, and .NET followed the same route. In the end, it was used only in servers.
Want to program audio, music, graphics, simulation, emulation, video, games, etc? java and .net are not cool. I mean, remember why uTorrent became widespread as the most popular bittorrent client? because it was the opposite to that bloated java-based one, Azureus ( which everyone complained was slow and bloated).
One thing is James Gosling claiming that Java is faster than C++ at fibonacci, another really believing that it’s as nearly as efficient for large apps.
So, in the end.. I think it’s ridiculous to assume that an OS will become mainly .NET or Java based, it’s just like thin clients, been there before, failed at that.
.NET is not Java. I use .NET to write desktop apps. There are a lot of people who use .NET for desktop. Right now we have to do the heavy lifting using p/invokes but in the future we will be able to use native apis like DirectUI and WinRT.
Lots of developers love .NET, I’ve written several in house apps with it, and I love it, but Hey, Thanks for speaking for us all.
No, Santa isn’t coming but mr. Ballmer will let us write windows apps in native C++ and .NET.
[quote]Far from being a developer disaster, Windows 8 should be a huge leap forward: a release that threatens to make development a pleasure for native, managed, and Web developers alike.[/quote]
I guess I have to quit sending threat letters to Steve Ballmer, and stop thinking about kidnapping his cat.
If the things are half as good as in the Ars article, I see a shiny future for Windows devs. The only thing that I would request is being able to access DirectX from managed code.
I think that us devs, will still have to wait until the conference in September. Ars article is nice, but is compilation of inside news and rumors. Nothing is certain until MS will officially say it’s going to happen.
Reading the article, one thing saddens me: we, users and devs, are few years behind just because some teams inside Microsoft couldn’t cooperate well enough.
“The only thing that I would request is being able to access DirectX from managed code. ”
I thought you could already. Isnt that what XNA is all about?
Not quite. DirectX is an immediate mode API, XNA is a retained mode.
The difference is that XNA is many, many levels of abstractions above DirectX, and quite slower. Though easier to work with.
XNA is not retained mode. That’s WPF/WPF3D.
XNA is managed interface to a subset of DirectX (D3D9 as far as graphics). Its precursor was called Managed DirectX. IIRC, XNA (vs Managed DX) improved the API to fit better with common .NET patterns, added a content pipeline to make asset management easier, added support for the Xbox 360 as a build target, and also incorporated the Xbox’s input and audio APIs. ZuneHD was later added as a build target, and more recently, Windows Phone. A somewhat limited version of XNA (Reach Profile) is the API for Silverlight 3D in Silverlight 5 (currently in beta).
Access to DirectX 10+ functionality is currently available to managed code via the Windows API CodePack
http://archive.msdn.microsoft.com/WindowsAPICodePack
http://windowsteamblog.com/windows/b/developers/archive/2010/04/27/…
Edited 2011-06-26 02:39 UTC
You’re right. Don’t know what I was thinking. Still it’ orders of magnitudes slower due to all the interop especially dealing with what are largely incompatible native and managed heaps.
Which is why I think its interesting that the CLR’s heap has been moved into this new SLR dll. Maybe COM vNext is getting garbage collection to replace reference counting.
Would be a pretty big perf win, imo.
But yeah, my bad.
Excuse my silly question, but isn’t reference counting part of the garbage collection job ? If so, how can a superset of something be faster than the original thing ?
Becaus as it stands the managed and unmanaged heaps are two separate beasts and copying memory across managed boundaries and vice versa is a slow operation.
Then you need to be mindful of holding native references to managed objects which the GC may or may not move around during a collection. So that takes pinning portions of memory in place which is also slow.
So imo, replacing reference counting in COM with Garbage Collection (which iirc was actually intended way back when COM was Micrsoft’s favorite child) I don’t think would adversely affect performance in the bigger picture, when it comes to having tighter .NET integration.
Again though, this might simply be an ease of use thing vs a performance thing. Thinking about it some more; I don’t think that GC and memory allocation are common perf bottlenecks in many common programs.
Edited 2011-06-26 10:19 UTC
Thanks for the explanation