Just to add my 2cents, I know WPF/Silverlight isn't going anywhere AND i'm not suggesting that in any of my posts. BUT what I am trying to point out is if you compare what the WinMD interop layer exposes to the equivalent interfaces/functionality found in WPF/SL/WP7 you can see some pretty big differences across all the UI frameworks, as well as similarities. And agree that this new UI Framework will be at a much reduced featureset to WPF/SL/WP7 BUT at the same time it will probably be much more lean & optimized. The new UI framework, whatever it is called, definetely has a long way to go to match WPF/SL functionality BUT if it finally gets there it may be the better framework. Thus we need to keep hounding MS to keep WPF/SL ticking over with improvements and fixes..
Turns out that this dll is actually loaded, inside Windows Installer (msiexec.exe) service. So probably there's something else that's needed for app container exes to run.
Yeah, turns out that app containers actually work. Installer "appx" executables simply run as low integrity process, similar to IE's protected mode. The process - can't read/write files and registry keys all other the place, it doesn't even have access to user's files - it gets its own application data and temp directories - it gets its own NT object directory (under \Sessions\1\LowBoxNamedObjects\<app-sid> So... pretty much sandboxed...
Question on WinMD Hey Bored_Neo or NaiveUser could you possible answer a nagging question I have regarding WinMD?! I understand that the metadata (WinMD) is a way to access the WindowsRunTime from managed code by simply referencing the WinMD in our managed projects and calling the relevant library classes/methods/properties. Question I have is, is the WinMD files just a very small subset of the entire WindowsRunTime? I'm just wondering if Microsoft will generate the WinMD for the entire library of Windows native dlls or just a particular subset that is relevant to the vision of Windows 8. The reason I ask is because I'm looking at the actual native dll's referenced by the WinMDs' eg. System32\DirectUI.dll depends on UIAUTOMATIONCORE.dll BUT there are no exposed Windows meta data for the UIAUTOMATIONCORE.dll. It may be too early to know the full breath of native windows runtime (WinRT) that the WinMD will expose ?! And more importantly how they created the WinMD and if we developers can create them ourselves !? Does my question make sense ?! Sorry if it's cryptic !
I think WinMD files contain the full WinRT api, they're likely generated automatically from .idl files. Somewhere in the BuildBinaries folder there's a midlrt.exe, the IDL compiler for WinRT probably. However the WinRT api is a new api. It wraps some of the existing Win32 api functionality but it's by no means complete. Only time will tell if WinRT will end up wrapping all the Win32 api, probably not.
I dont understand, what purpose could that serve ? write some library code then make it inaccessible to anyone ? this doesnt make sense.
some small interesting stuff in System.dll Code: // System.EnvironmentHelpers public static bool IsAppContainerProcess { get { if (!EnvironmentHelpers.s_IsAppContainerProcessInitalized) { if (Environment.OSVersion.Platform != PlatformID.Win32NT) { EnvironmentHelpers.s_IsAppContainerProcess = false; } else { if (Environment.OSVersion.Version.Major < 6 || (Environment.OSVersion.Version.Major == 6 && Environment.OSVersion.Version.Minor <= 1)) { EnvironmentHelpers.s_IsAppContainerProcess = false; } else { EnvironmentHelpers.s_IsAppContainerProcess = EnvironmentHelpers.HasAppContainerToken(); } } EnvironmentHelpers.s_IsAppContainerProcessInitalized = true; } return EnvironmentHelpers.s_IsAppContainerProcess; } } Code: // System.EnvironmentHelpers [SecuritySafeCritical] [SecurityPermission(SecurityAction.Assert, Flags = (SecurityPermissionFlag.UnmanagedCode | SecurityPermissionFlag.ControlPrincipal))] private unsafe static bool HasAppContainerToken() { int* ptr = stackalloc int[(UIntPtr)1]; uint num = 0u; using (WindowsIdentity current = WindowsIdentity.GetCurrent(TokenAccessLevels.Query)) { if (!UnsafeNativeMethods.GetTokenInformation(current.Token, 29u, new IntPtr((void*)ptr), 4u, out num)) { throw new Win32Exception(); } } return *ptr != 0; } Code: // System.Diagnostics.PerformanceCounter private static void VerifyWriteableCounterAllowed() { if (EnvironmentHelpers.IsAppContainerProcess) { throw new NotSupportedException(SR.GetString("PCNotSupportedUnderAppContainer")); } } and mscorlib Code: // System.Environment internal static bool IsWindows8OrAbove { get { if (!Environment.s_CheckedOSWin8OrAbove) { OperatingSystem oSVersion = Environment.OSVersion; bool arg_48_0 = Environment.s_IsWindows8OrAbove = (oSVersion.Platform == PlatformID.Win32NT && ((oSVersion.Version.Major == 6 && oSVersion.Version.Minor >= 2) || oSVersion.Version.Major > 6)); Environment.s_CheckedOSWin8OrAbove = true; } return Environment.s_IsWindows8OrAbove; } } Code: // System.Globalization.IdnMapping public string GetAscii(string unicode, int index, int count) { ...... ...... if (Environment.IsWindows8OrAbove) { return this.GetAsciiUsingOS(unicode); } ...... ...... } Code: // System.Globalization.IdnMapping public string GetUnicode(string ascii, int index, int count) { ...... ...... if (Environment.IsWindows8OrAbove) { return this.GetUnicodeUsingOS(ascii); } ...... ...... } Code: // System.Environment internal static bool IsWinRTSupported { [SecuritySafeCritical] get { if (!Environment.s_CheckedWinRT) { Environment.s_WinRTSupported = Environment.WinRTSupported(); Environment.s_CheckedWinRT = true; } return Environment.s_WinRTSupported; } } Code: // System.Environment [SuppressUnmanagedCodeSecurity, SecurityCritical] [DllImport("QCall", CharSet = CharSet.Unicode)] [return: MarshalAs(UnmanagedType.Bool)] private static extern bool WinRTSupported();
And for the sake of completness you can find token information class 29 in System.Security.Principal.TokenInformationClass: TokenIsAppContainer
Is that how you run wwa? It doesn't work for me. Tried for example wwahost /appid Tweetarama.App /manifest "C:\Program Files\Applications\microsoft.tweetrama_1.0.0.8_neutral_neutral_8wekyb3d8bbwe\AppxManifest.xml". Only gives the message "The system cannot execute the specified program.". Double clicking wwahost.exe gives the message "This application can only run in the context of an AppContainer."
Well, things are constantly changing between builds for AppContainer exe, I believe there was a StartAppcontainer.exe in the build tools directory in some previous leaked builds like 7959 x64 or 7927 x86, you may try that. And, the command line paramters syntax could also change, IIRC it has already changed in 7989, I guess it takes a 'moniker' or something now. Maybe I will also try this later.