Slashdot Mirror
Windows 8 Roundup
There has been no shortage of Windows 8 news today. MrSeb writes: "Earlier this morning, at the Build Windows conference in Anaheim, California, Microsoft made it patently clear that 'To the cloud!' is not merely a throwaway phrase: it is the entire future of the company. Every single one of Microsoft's services, platforms, and form factors will now begin its hasty, leave-no-prisoners-behind transition to the always-on, internet-connected cloud." netbuzz pointed out that even the famous Blue Screen of Death will get a new look. Lastly mikejuk writes: "While everyone else is looking at the surface detail of Windows 8 there are some deep changes going on. Perhaps the biggest is that Metro now provides an alternative environment that doesn't use the age old Win32 API. This means no more overlapping windows — yes Metro really does take the windows out of Windows."
Indeed. Tried Win8 out yesterday. Extremely disappointed with the forced nature of the Metro UI and how it takes over .. everything. Must admit I'm a fan of the ribbon changes to Explorer, et al. It's just a shame it's all hidden behind this horrible Metro UI that I never want to see. It's a shame that it's so difficult to switch apps if you want to "search" or actually use Explorer.
"What's that? You want to look up something on Wikipedia in Internet Explorer, then go back to Word? No less than 4 mouse clicks and three full screen changes to get back there from here". - Metro UI
It's a damned shame too, because I felt like they just about got everything right with Windows 7. Give me Windows 7 + ribbon interface and I'm happy as Larry. But force me to use a crap interface that I don't want to interact with and I'm gone as a user. Maybe Ubuntu next.. Maybe even.. *shudder*.. a Mac.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
Not always the hardware itself, sometimes the driver, but I'd say 90% or more of the BSODs I see at work are related to hardware. Very rare that it is purely a software issue.
The article linked from TFA has got quite a few things regarding WinRT wrong. Point by point:
Windows Run Time, WinRT- a C++ object-oriented API.
It's not a C++ API. It's a COM-based API/ABI that can be accessed from any language that knows what a raw function pointer is. It's relatively easier to do that from C++, because COM vtables map nicely to C++ vtables. But WinRT ABI itself is intentionally designed to be projected to different languages, adapting along the way. C++ has its own projection, but so do .NET and JS.
Applications can choose to use either the old Win32 API or the new WinRT but not both.
Wrong. You can use Win32 APIs in Metro apps - some of them are not available (largely because they are pointless in the sandbox, or deal with the old UI concepts), but some are. If you open windows header files - "windows.h" and friends - they now have blocks of code that look like this:
Desktop partition is what's available to non-Metro apps running on the classic desktop. App partition is what's available to Metro apps.
Furthermore, classic apps can actually use WinRT (while retaining full access to Win32 APIs). Not all of WinRT will work - specifically, most of UI stuff won't - but huge chunks of WinRT are not UI-related and are accessible. Examples include I/O and networking libraries, XML parser, XSLT engine, new device and multimedia APIs etc.
Of course WinRT is delivered to the programmer via XAML (or HTML)
WinRT is not "delivered via XAML", and most definitely not "via HTML". WinRT includes a UI library (Windows.UI.* namespaces), which allow you to use XAML as a declarative markup language for your UI (but you don't have to, strictly speaking). This is what is normally used by Metro C++ and .NET apps. JS apps don't use WinRT for UI at all - they use HTML5/CSS3, rendered by chromeless IE. They do get access to non-UI parts of WinRT, but they don't have to use it, and in any case it's completely orthogonal to their (HTML5) UI.
There is also no more need for P/invoke. As Win32 isn't being used there is nothing to invoke. There is no API lurking beneath the covers. So anything that you used to do via P/Invoke you will now have to find a way to do via WinRT.
You absolutely can P/Invoke from a .NET Metro app. For one thing, you can P/Invoke to call any of Win32 API functions that are available to Metro apps, as described earlier. Furthermore, you can write a C++ DLL (e.g. for perf), bundle it with your app, and call it from C# as usual via P/Invoke.
Now, in practice, you probably won't, for the simple reason that pretty much everything that a Metro app can do is covered by WinRT APIs. So why would you mess around with P/Invoke declarations when you already have an object-oriented API that can be used directly? Mixed C#/C++ scenarios are also better supported that way - you can make a private WinRT component DLL in C++, and reference it from C#. Your WinRT C++ classes automagically become visible as .NET classes, no P/Invoke declarations needed.
In fact, you could even go the other way around - write a WinRT component DLL in C#, and reference it from C++. And then both of those can be used in JS, so you can really mix all three if you want.
When you create a Page object with WinRT and run it then it expands to fill the entire screen real estate
By default, yes, but you can have two Metro apps run side by side.
If you want overlapping windows and dialog