using winRT to code desktop apps

not sure from these threads how much WinRT can be used to code desktop apps. Can a desktop app, that looks just like a WPF or Win32 app, be coded using WinRT?

http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/4e79b002-2361-4911-af49-0a8c47c1411b

http://social.msdn.microsoft.com/Forums/en-IN/winappswithnativecode/thread/ce649545-9ec6-45da-a4ee-71b9f2bed156

WinRT sounds terrific in terms of bringing XAML to native apps, deployment and siloing the app to avoid viruses.

If you can use WinRT to code a desktop app, would that app be able to run on Windows 7?  Where WinRT is installed on the Win7 PC just like .NET is installed on a PC to run a .NET app.

If you write .Net you can use portable class lib other then that, I dunno.

I'm not sure the portable class library actually applies in this case, but even so you still need an application to call that library.  All of the info I have seen leads me to believe that you can't create a desktop app with WinRT and that you never will.  There are a bunch of things in WinRT that only apply to a Metro environment.  At some point, we may see a desktop equivalent of WinRT that contains the relevant parts without the Metro stuff.  That would be nice.  It seems we are going to have to wait for Win9 to see what the plan is going to be for the future of the desktop.

One of these days Felix will probably uncover what is going on ...

the question is, can you make a winRT app on win8 desktop? And purchases and installed as metro app, just have it moveable like a regular window.

As for @SteveRichter: question, I don't think so. WinRT is win8, not a layer on top of win8. You maybe able port it to .Net and run on win7. But the security would be using .Net instead winRT model.

As for @SteveRichter: question, I don't think so. WinRT is win8, not a layer on top of win8. You maybe able port it to .Net and run on win7. But the security would be using .Net instead winRT model.

WinRT is lots of different things depending on who you talk to, but then "kernel" means different things depending on who you talk to as well, so it's all semantics one way or the other.

WinRT classes can usually be used on the desktop, but obviously since you're on the desktop and not on Metro, you can't use WinRT classes designed for interacting with Metro.

You can also use Win32 in metro btw - LoadLibrary and so on are all still there - after all, it's all syscalls and memory operations under the hood - and Metro can do both of those

35 minutes ago, evildictaitor wrote

WinRT classes can usually be used on the desktop, but obviously since you're on the desktop and not on Metro, you can't use WinRT classes designed for interacting with Metro.

I am looking for the deployment from the app store, the follow me everywhere app settings and especially the siloed features that provides the user with assurance that the app will not hijack their PC in a virus like way.

Another way to put this is, I want to be able to write an app that when it is run on a windows phone looks like a windows phone app, on a tablet it looks like a metro app, on the desktop it looks like a desktop app.

Nope, the Apps store is Metro only. However, they going to list Desktop apps as well but they just link out to for download and install like it is today. The apps will be not maintained by the App store. Not even Microsoft software like Office will be delivered via the App store.  

48 minutes ago, SteveRichter wrote

I am looking for the deployment from the app store

Win8 appstore is for Metro apps only

the follow me everywhere app settings

Don't know about that - but you should probably be able to fudge your own there. It might be exposed over COM (since the usermode WinRT classes are built on top of COM).

and especially the siloed features that provides the user with assurance that the app will not hijack their PC in a virus like way.

That's a kernel protection mechanism and will be available to all user-mode processes, although I'm not sure if they've announced how you're supposed to do it. This is used by IE10 for instance to "sandbox" the page rendering process.

19 hours ago, evildictaitor wrote

*snip*

You can also use Win32 in metro btw - LoadLibrary and so on are all still there - after all, it's all syscalls and memory operations under the hood - and Metro can do both of those

No, you can't. Metro apps have to come from the store and will fail the validation if they try to call arbitrary Win32 APIs.

LoadLibrary is NOT there in the metro-style api 'partition', you can use LoadPackagedLibrary instead, which is very limited.

9 hours ago, AndyC wrote

*snip*

No, you can't. Metro apps have to come from the store and will fail the validation if they try to call arbitrary Win32 APIs.

They fail the onboarding process because you imported the Win32 api. That's not to say you can't call it.

Firstly - onboarding process is only there for win8appstore - you can make your own metro apps or sideload them to avoid the onboarding process entirely if you want to. Metro doesn't stop you calling Win32, the win8appstore tries to stop you calling them.

Secondly - you can do a LoadLibrary and GetProcAddress to do anything you want - you can't import ntdll!NtOpenFile, but there's nothing to stop you doing GetProcAddress(LoadLibraryA("ntdll"), "NtOpenFile").

And thirdly literally all that usermode can do is memory operations and syscalls. Anything interesting from graphics, to virtual memory allocations to file manipulation to inter-process communication is done by syscalls. And C++ can just issue the syscalls directly. You might not be allowed to import NtOpenFile from Ntdll but they can't detect or stop you from just doing the mov eax, SYSCALL_NTOPENFILE; sysenter yourself.

That's why all of the metro app-protection is done in kernel-mode, not done by closing off Win32 functions.

6 hours ago, felix9 wrote

LoadLibrary is NOT there in the metro-style api 'partition', you can use LoadPackagedLibrary instead, which is very limited.

It is there, you're just not being creative enough. Kernel32 is loaded into your address space and LoadLibrary is there. All you need to do is find it and call it. You're not allowed to import LoadLibrary. That doesn't mean you can't call it.

Oh and before someone else mentions it - Microsoft banned the API for good reasons and will block your app retrospectively if they find out that you're doing it. My point is that you can call Win32, not that you're allowed to.

9 hours ago, evildictaitor wrote

*snip*

They fail the onboarding process because you imported the Win32 api. That's not to say you can't call it.

Firstly - onboarding process is only there for win8appstore - you can make your own metro apps or sideload them to avoid the onboarding process entirely if you want to. Metro doesn't stop you calling Win32, the win8appstore tries to stop you calling them.

Side-loaded Metro apps (aside from only being available to Enterprise developers) may still have to obey by the rules anyway as, from what I have heard, logic may yet be added to key internal functions like LoadLibrary to fail if loaded into a Metro process (even though it may not be there in current builds). Even if not done for Windows 8, it's perfectly possible for future versions to prohibit such behaviour, so attempting to rely on it is doomed to failure.

Secondly - you can do a LoadLibrary and GetProcAddress to do anything you want - you can't import ntdll!NtOpenFile, but there's nothing to stop you doing GetProcAddress(LoadLibraryA("ntdll"), "NtOpenFile").

Except that you can't call LoadLibraryA. And you can't load arbitrary files into memory, so bypassing that is out too.

Except that you can't call LoadLibraryA. And you can't load arbitrary files into memory, so bypassing that is out too.

O'rly? Here's the key part of LoadLibrary: it loads the file up into memory (yes an arbitrary executable or DLL file that your app can see) and marks it as executable. You have to do your own import resolution (recursively), relocations, and calling DLLmain if you want to use it properly though. Note that GetProcAddress is in-memory only, i.e. you don't have to ask the kernel for help to write that function.

    OBJECT_ATTRIBUTES objectAttributes;    UNICODE_STRING objName;    HANDLE hFile;    IO_STATUS_BLOCK ioBlock;    NTSTATUS status;    HANDLE hSection;    void* baseAddress = 0;    size_t viewSize = 0;    LoadFns();    objName.val = L"\\??\\" DLL_PATH;    objName.L = objName.M = wcslen(objName.val) * 2;    InitializeObjectAttributes(        &objectAttributes,        &objName,        OBJ_CASE_INSENSITIVE,        NULL, NULL);    status = pNtOpenFile(&hFile,        SYNCHRONIZE | FILE_EXECUTE | FILE_READ_DATA,        &objectAttributes,        &ioBlock,        FILE_SHARE_READ | FILE_SHARE_DELETE,        FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT);    status = pNtCreateSection(        &hSection,         SECTION_MAP_READ | SECTION_MAP_EXECUTE | SECTION_MAP_WRITE | SECTION_QUERY,        NULL,        NULL,        PAGE_EXECUTE,        SEC_IMAGE,        hFile);    status = pNtMapViewOfSection(        hSection,         hProcess,        &baseAddress,        NULL,        0,        NULL,        &viewSize,        SECTION_VIEW_SHARE,        0,        PAGE_READWRITE);

Usermode can only do memory operations and syscalls. C/C++ can do both of those without importing anything, and hence metro apps can do anything that is not specifically denied to them by kernel mode - e.g. app-protection stuff. The onboarding process is more of a code-quality thing than a barrier.

@evildictaitor: You're still making the assumption that you have unrestricted access to the file system, there is no such guarantee that forthcoming updates to the kernel-mode parts of Metro won't prohibit that. At which point no amount of trying to circumvent it helps.

There's probably also a fair bit that can be accomplished by simply applying appropriate filesystems ACLs, since UAC has to be on, there is no elevation option and Integrity Levels are enforced at kernel level. Working on the assumption today that you'll be able to make arbitrary Win32 calls is just plain foolish, even for sideloaded apps.

47 minutes ago, AndyC wrote

@evildictaitor: You're still making the assumption that you have unrestricted access to the file system, there is no such guarantee that forthcoming updates to the kernel-mode parts of Metro won't prohibit that. At which point no amount of trying to circumvent it helps.

I am making no such assumption. You can load stuff like ntdll and kernel32 because they're not really files, they're kernel namespace objects. Additionally, if you take sysinternal's vmmap to a metro app you'll see that ntdll and kernel32 and so on are already loaded in your address space. All your app needs to do is find it and jump to it and you'll have called a Win32 api!

Yes, there is stuff you can't do in Metro apps, but that's not because of the WinRT libraries, it's because of the LowBox tokens in kernel mode. My point was actually that the on-boarding process doesn't really mean very much when it comes to protecting your apps.

Working on the assumption today that you'll be able to make arbitrary Win32 calls is just plain foolish, even for sideloaded apps.

You can make arbitrary Win32 calls. They might return STATUS_ACCESS_DENIED if they interact with the kernel and the kernel says no, but that doesn't mean you can't call them.

There's a lot of terminology abuse going on around here (since WinRT seems to mean wildly different things to different people), so I'll define what I mean when I say stuff:

Win32: All of the old-fashioned APIs in user-mode libraries such as ntdll, kernel32. Specifically when I say Win32, I don't mean Win32k or anything in kernel-mode (when I want to say that I'll say Win32k or "the windows kernel"). Win32 APIs might call the kernel (e.g. VirtualAlloc calls NtAllocateVirtualMemory, but I consider "NtAllocateVirtualMemory" part of "the kernel" and "VirtualAlloc" to be a Win32-api).

Kernel-mode: processor Ring 0, or system-mode in ARM.

"The kernel": ntoskrnl.exe and win32k.sys, and any other Microsoft drivers that are designed to service requests from user-mode (like Afd.sys).

WinRT: The APIs and framework of user-mode libraries for Metro apps. WinRT is only in user-mode.

Metro: The start menu thing for apps, as opposed to "Desktop mode".

On-boarding process: The process by which you submit a binary to Microsoft and they decide if it goes into the app-store

app-protection: The kernel-mode protections to stop metro apps doing something bad at the syscall layer. app-protection is only in kernel-mode.

Hence, "WinRT" sits on top of "Win32" in user-mode, and is protected by the "the kernel" in "kernel-mode" by "app-protection". 

With those definitions, a Metro app can call any WinRT or any Win32 api. Indeed any user-mode app can call any WinRT or Win32 api. If that API tries to do a protected syscall it might fail (e.g. ZwLoadDriver), but that's not to say that the API can't be called.

I'm sure someone will figure out how to "jailbreak" Win8 Metro and remove any limitations on sideloading. It probably wouldn't be protected under the DMCA exceptions like it is for phones, so the legality will be questionable in some jurisdictions. But has the DMCA really ever stopped anyone?