| > Win32 is not in any sense deprecated. It's restricted.
| Only on ARM - and MS is not encouraging it's use at all. My point is
| that win32 is deprecated in that it is not likely to get a lot of
| further enhancement and that it's not going to be the official primary
| developement api for 3rd parties.
It is partially restricted on x86 Metro.
But I understand
what you mean. Nevertheless, this is an important point
that MS tries to cloud up. If you search for WinRT you'll find
all sorts of articles talking about how "the aging win32 api"
is being replaced by WinRT. There was similar talk when
..Net came out. In both cases the new wrapper is marketed
as a new core API, replacing Win32. Microsoft has successfully
misled people, in both cases, into thinking they're getting
a newer, better engine when actually they're just getting
a wrapper. Even the experts are confused. Dino Esposito
says here, quite plainly, that .Net runs on top of the Win32
But then he goes on in blurry, vague language to say strange things
about WinRT like: "Microsoft is attempting to touch and restructure
some of the pillars of all Windows applications", implying that WinRT
is a fundamental new core API.
He then says, "WinRT is ultimately a new layer of code that is
expected to provide the same core services as Win32/COM."
A layer where? Again, he's implying but never actually claiming that
WinRT is a new core API. It sounds to me like he really just wasn't
sure when he wrote that article, so he avoided definitive statements.
Yet one of Microsoft's own people says the following here:
"Moreover, the WinRT APIs call into the Win32 DLLs - so they
are not a replacement but rather a wrapper, an API flavor, on
top of Win32."
So I'm not arguing with you on this. Just trying to clarify
what's going on and what the options are. Saying that Win32
is deprecated is misleading. What it really means is that MS
wants to discourage people from writing native software
and switch to web apps or phone apps. Deprecated generally
means "on its way out". The FONT tag was deprecated to let
people know that at some later point browsers wouldn't be
expected to support it. But MS is not phasing out Win32. And
Win32 is not "aging" or "crusty" or anything else of the sort.
Win32 is Windows. MS is just "discouraging its use" by anyone
other than themselves.
| > Read the news about Mozilla's complaints. They specifically
| > point out that IE (and other MS software) is using the
| > Windows API in Metro but that MS will not allow Firefox to
| > access it;
| The complaint is about the legacy desktop on arm - Windows RT. MS is
| not allowing any 3rd party software to run there. They are free to do
| so on x86. And their Metro version will be allowed to run just fine.
| I'm not sure where Firefox would benifit from direct api access since -
| well, they don't use the same rendering engine that ie uses.
How can you say that? MS software will have direct API
access on ARM while others will be limited to the WinRT
wrapper that prevents access to any direct hardware
and system APIs.
The author never explains exactly which functionality is
missing, but it seems like common sense to me. WinRT is a
sandboxing wrapper for software that's seems to be mainly
running in a browser window itself. (The GUI options are
CSS and XAML. I haven't seen a detailed explanation about
that, but that's why I was talking about HTAs. The entire
WinRT system seems to be a kind of browser-based web
services platform running on Windows.) How could a fullscale
browser be built on that? Even if WinRT were not so limited...
if it were equivalent to .Net or Java... that would still be a
step away from the efficiency of direct API.
| > It's true, of course,
| > that WinRT is connected with battery issues, etc., but Metro
| > is also being put into Win8 as a wrapper GUI -- as the primary
| > GUI, even when there is no "swipe 'n smudge" functionality
| > on a given PC. And no one gets the option to choose which
| > native software they want to run. (Mozilla would presumably
| > write a lean version of Firefox for Metro and some people might
| > want the choice to risk their battery life. But they won't get
| > the choice.) Surely that's writing on the wall?
| I think you are confusing Windows 8 and Windows RT (windows on arm).
| Windows 8 on x86 will allow them to have a native client - that you can
| download and install just like any other software. You won't get it
| through the windows marketplace - that will be the metro version, but
| they can happily provide one for x86. It's different on windows rt. MS
| is not allowing ANY 3rd party legacy desktop apps to run.
I understand all of that. But Metro on x86 is limited. (Link above.)
And it's the primary GUI. Native software can run on the Desktop.
I've already tested some and it's fine. But the Desktop, as you like
to say, is being "deprecated". The only reason to force Metro
on people with fullscale PCs is as a way to push toward further
restricting access in all versions of Windows down the road. On
a normal PC -- especially one without a touch-enabled screen --
there simply is no role at all for Metro. The M-Softies might say
that it's there because people mostly want to see realtime
updates onscreen, but that makes no sense. If you're on a bus,
looking at your phone, you might want to see who just posted
to your Facebook page without needing to log in. That's a clever
idea. But no one is going to sit around in their office, staring at
a 21" screen full of giant rectangles to watch Facebook news and
weather reports update themselves.
This is what I was saying before: So far everything still works
as of Windows 8. The API is accessible. VB6 software runs. But
the writing is on the wall that Microsoft is probably going to
try to rein it all in down the road.