by Michael S. Kaplan, published on 2012/07/30 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/07/30/10334641.aspx
The question I got this weekend has been preying on me for a bit, it is from a fan of MSKLC who loved the Windows 8 Surface demo:
I have been following posts in the MSDN forums, such as:
* Not able to build driver when target platform is ARM
* Setupapi.lib is missing for ARM
and several others with responses from a Microsoft employee that suggest that the rules for ARM applications and drivers are that they can't be created by everyone.
I know that MSKLC kind of creates drivers. Does MSKLC have the same problems with ARM?
If it does, could you talk that Microsoft employee about making an exception?
Well, I consider Doron to be a colleague and even a friend, but neither of us are in a position of power here. Even senior management is clear about the rules on this one....
If course I have actually talked in the past about how I'd like to see an MSKLC update in blogs like this one and this one.
That first one even suggested what a theoretical 1.5 version might contain, the three bug fixes..
There was one other work item i wanted to do, one originally suggested in someone else's spec.
You see, the optimized keyboard layouts for Windows 8 aren't going to be exposed for third parties. But one of those specs pointed out that custom keyboard layouts via MSKLC would be supported.
So I started asking people whether a new MSKLC could be built to support Windows On Arm (WoA) and the ARM platform -- WinRT.
I even created a rough version of KBDUTOOL.EXE that removed IA64 support and added ARM support -- it was trivial to do, really. It seemed like a sign that this was meant to be!
It turned out to be a STOP sign, though.
Because keyboards still have two basic requirements on Windows, one that MSKLC creates a setup for:
and unfortunately, those two things cannot be done on WoA apps, unless one is one of the small number of IHVs building device drivers for ARM devices that are being created for drivers specific devices might require, and/or one of the even smaller number of OEMs creating such devices.
None of this fits in well with the MSKLC-based model of "anyone can build a keyboard" if only that small number of people could use the tool....
And since that version of can't be released, even those specific OEMs and IHVs would never be able to create a new keyboard via MSKLC -- they'd have to use the WDK.
Even in the highly unlikely event that one of them actually had a business case that required a new keyboard layout.
Essentially, only the non-ARM-based tablets could use MSKLC-generated layouts -- unless you worked in Windows development or one of those specific IHV/OEM companies.
I'll have to get back to you on whether the update can still happen, for the original reasons. For now I only know it can't be ARMed.
And I'll have to ask about the testing one of those x86 Surface tablets! :-)
Joshua on 30 Jul 2012 8:48 AM:
You mean WoA apps cannot run with admin rights? If so, that's far more lame than not having custom keyboards.
Michael S. Kaplan on 30 Jul 2012 10:41 AM:
I don't know the full answer to that (I only know about the keyboard issue), but if so then it's only the model that iPads and iPhones use and they don't seem to be going out of style....
Mike Dimmick on 30 Jul 2012 11:00 AM:
@Joshua: No, it's worse than that. Win32 is banned. You can only use WinRT APIs on Windows RT devices (WoA). The only major applications that will be allowed to use Win32 APIs, i.e. run on the desktop, are the Office apps, and they will ship with the device.
Unsurprisingly the Mozilla Foundation and Google have already kicked off about this to the EU competition authorities.
I'm not sure if Office is running in the desktop because the WinRT APIs are insufficient for creating Office, or just because there's a dependency there - Microsoft have learned their lesson from the aborted Longhorn project, where the dependencies got so out of control that everything had to be reset and three years of work basically thrown away. Certainly the Office team wants to keep as much of the legacy code around as possible; the Mac team only recently migrated from Mac OS X's Carbon environment (a mildly-modified upgrade of the classic Mac OS APIs) to the newer Cocoa.
In fairness I can kind of see Microsoft's point. They don't want all kinds of badly-behaved applications ported from x86, and want to make everything downloadable from the store a trustworthy application (enforced by the policy-based permissions sets in AppX, with readily-understandable permissions).
Joshua on 30 Jul 2012 12:13 PM:
@Mike Dimmick: And people wonder why I haven't bought a smartphone yet. Maybe for once MS can change the model and get a real chance at being a leader at a new market, but I'll bet they haven't got the guts.
cheong00 on 30 Jul 2012 8:24 PM:
Emmm... Apple is known for their closed development environment and noone is surprised by that.
For Windows and Linux (Android) it's quite another...
Simon Buchan on 31 Jul 2012 12:01 AM:
@cheong: Apple was not known for their closed environments *before* iOS, though - there were plenty of Classic Mac bedroom programmers out there, selling direct to customers.
But I'm guessing MS isn't really going for a walled garden, when they have the functional super-set x86 Surfaces available.... I'm guessing the only reason ARM Office is on Win32 is because it's easier to port the Win32 subset of WinAPI that Office touches to ARM: mostly ripping out unused dependencies, then a recompile; than to try to port Office to WinRT (which probably has stuff from <windows.h> touched in 60~90% of it's functions).
I *expect* OfficeRT will eventually be a thing, maybe in Win9 timeframe, then (since they own all the apps using it) MS can completely drop Win32 and Desktop completely from their ARM devices, or whatever.
Back on topic, though: is there a chance, in Win8 SP1 or Win9 or whatever, to add data-driven or user-mode keyboard support? It does seem slightly weird to need to have custom code in the kernel to map one or more scancodes to one or more codepoints....
Jeroen Frijters on 4 Aug 2012 2:51 AM:
My guess is that Microsoft wants to keep the option open to remove the legacy Win32 stuff from Windows RT (to create a smaller footprint version of the OS for tablets). The Windows 8 based version probably will contain most of the Win32 stuff (and I'm looking forward to getting a Surface RT and I bet it won't take long before it'll run Win32 apps).
referenced by