So basically what my trivial research on debuggers lead me to was a debugger works by creating a wrapper around the original process and the process runs within the wrapper.(Not in the scenario where debugger is attached to an already running process). So how does it work for metro apps? Metro apps can only run inside the app container which is allocated to them when they are installed ( actually metro apps are not installed in the true sense) and the mapping between app container and metro app is recorded in a registry key. (All from my research,dont know how correct please correct me if I am wrong). So does the debugger also run within the same app container?
EDIT: A short note on the driving force why I wanted to learn this. I am stuck with this. So I was thinking if I can achieve this IPC by making the desktop app as a debugger (Or automating the debugger, drats this is getting even more creepier) and simulating the communication between metro apps and desktop apps using DebugBreak(From inside the metro app) and Continue statements(From the pseudo debugger app)
The mental image of a "wrapper" is wrong. A debugger is just a separate process that uses the built-in Windows support for debugging. It has the SE_DEBUG privilege and is initiated by an app that has the normal desktop app privileges. Like Visual Studio. So it doesn't run inside the AppContainer itself.
Han's answer is correct. For Metro style apps, we introduced a new feature that allows you to start the app suspended and we will launch the registered debugger with command line options to indicate what process to attach to. See the IPackageDebugSettings API for information on this feature, or check out the http://winrt.codeplex.com project for an example usage. I'm not certain, but there may be developer license restrictions around this API.
As to your original intention of supporting IPC between a Metro style app and a desktop app - as the linked thread states, this is unsupported.
Related
Using the Desktop Bridge (formerly known as Project Centennial) through the DAC, one can create a full-trust UWP App. I thought this meant you can now create a Full-Trust UWP App and if so, how do you do that?
What I am trying to figure out is what configuration can I manually set on my UWP Project to grant it full-trust.
If you need some background, I need to create an Enterprise tool that has to be UWP. The application is going to be run on my company and one of the features that would make the UX better is to be able to access some parts of the file system outside of those allowed by UWP and preferably without the summoning of a dialog. Being able to run other DLL would also be a big plus; perhaps DLL Hell is desired this time around.
#Anzurio - just stumbled across your question and thought I'd share our experiences building the new Windows Terminal.
We originally set out to create the Terminal as a UWP app, with a nice modern XAML UI, but quickly found that the UWP app platform couldn't support a couple of our key requirements:
1. Terminal must be able to be launched elevated
2. Terminal must be able to launch & connect to arbitrary executables (e.g. cmd, powershell, wsl, etc.)
Because of these limitations, we had to create the Terminal as a standard Win32 process which contains a XAML Island which hosts the Terminal's Tab Bar and Terminal XAML Control instances in the main window frame.
We have taken care to keep as much app lifetime/logic code OUT of the Win32 host as we can, so that we'll have less work to do if/when the app platform does support our requirements and we get to ship a real UWP Terminal apps.
We are working with the app plat team to figure out how we might be able to build/full-trust modern apps more cleanly in the future.
In the meantime, I hope this response helps, and hope the Terminal source gives you some inspiration as to how to craft your own apps.
I don't know such of options. Yes, DAC can contain the Full-Trusted Win32 apps, but it is only applicable for Win32. UWP - WinRT - apps are restricted with App Container.
The alternative option is - using the "Special capabilities".
Special and restricted capabilities
There are many of declarations that overcome the restrictions of sandbox. Some of these are not applicable for store submission - only for in-house deployment apps. Others need registration for Microsoft to deploy with store. If your requirement is matched, you can use it.
(Added - June 2017) From Win10 AU, we can use the "FullTrustLauncher" API to launch the Win32 component from UWP App. But, yes, it does not mean we can run the "UWP" - WinRT process with full-trust rights. It's applicable only for Win32 process. And, the Win32 app executable should be contained in the application's AppX package and the manifest should declare the executable as "windows.fullTrustProcess".
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="fulltrustprocess.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="SyncGroup" Parameters="/Sync"/>
<desktop:ParameterGroup GroupId="OtherGroup" Parameters="/Other"/>
</desktop:FullTrustProcess>
</desktop:Extension>
</Extensions>
FullTrustProcessLauncher Class
The requirement is to be able to run a kiosk application on Windows 10 which has unrestricted capability on the host computer to make arbitrary system calls and launch any kind of app including Appx and Win32. The kiosk app can be fully trusted - it may be thought of as a side-loaded in-house app for machines equipped with conventional keyboard and mouse to be used in a public setting. The user should not be able to circumvent or escape the kiosk app.
Assigned access fits the general idea, except that assigned access only works for Appx which are not full trust (no access to the needed APIs to launch Win32 apps, etc.). These restrictions appear to be by design, so it would be unlikely this approach could successfully meet the stated requirements. Although it is possible to author a WPF app as a "full trust" Appx, it won't work in kiosk mode.
Replacing the Windows shell with a custom one (the kiosk app) would work except that some of the tasks the kiosk app needs to be able to perform require the presence of the explorer shell (e.g. launch an Appx - requires services provided by the explorer shell).
Running a Win32 app above the lock screen might be a solution, if it were possible (I believe this is what assigned access does with its Appx).
Running an app in any normal fashion would require that many hotkey combinations are disabled or intercepted, including [CTRL][Alt][Del], which seems to be a major issue/challenge. It seems there is no way to prevent the user from invoking task manager or otherwise circumventing an app to gain unsecured/unmediated access to the system.
Is there any way to meet the requirement as I've outlined? If so, what is the technique and (if relevant), what APIs are central to the approach?
Update:
Although the full-trust converted WPF AppX could be installed and selected for assigned access, it "did not work" because of some issues found to have been recorded in the event log, specifically: Applications and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI/Operational. Observed behavior was that upon user login, a blue screen would be displayed with the familiar Windows spinner, which would flicker every second or so as if something was being retried over and over. The associated event log messages (all source "Apps") are:
ActivateApplicationForContractByAppIdAsUserWithHost of the app LockDownSample_y1sem70fxfdf6!LockDownSample for the Windows.Launch contract failed with This app does not support the contract specified or is not installed.. (Event ID: 5985)
The app LockDownSample_y1sem70fxfdf6!LockDownSample is not registered for the Windows.Launch contract or is not installed. (Event ID: 5951)
The app Microsoft.WindowsMaps_8wekyb3d8bbwe!App is not registered for the Windows.PreInstalledConfigTask contract or is not installed. (also Event ID: 5951)
Activation via contract helper of the app Microsoft.WindowsMaps_8wekyb3d8bbwe!App for the Windows.PreInstalledConfigTask contract failed with Class not registered. (Event ID: 5990)
Is this due to an intentionally imposed limitation, or is this something which can be resolved?
Update 2:
Found this recent question:
Windows 10 assigned access app fails to start due to not registered for Windows.Launch contract
This fairly accurately describes my experience with Assigned Access for a full-trust kiosk app, concluding with the answer "not yet supported".
I'm doing a metro app for Windows 8. And as part of its functionality, I need to initiate shutdown of Winodws 8 from the Metro App. Here are the questions:
1) Firstly, I researched a lot on this topic and I found out that System.Diagnostics.Process is not available for Metro App. So, is there a another way around?
2) Even if I can't directly shutdown, is there a way to trigger it from the Metro App?
I would prefer a solution in C#.
Thanks.
Doing this just isn't possible in a Windows Store (aka Metro) app. Such apps are strictly limited in what they can do, nothing that affects the way the operating system works or affects other processes running on the same machine is possible.
These restrictions are enforced by omission if you program in a managed language. The .NET framework class you hope to use is just missing. If you program in a native language like C++ then you can try to work around it by using the winapi. But that doesn't work either, a Windows Store app runs in a sandbox that simply fails the api call. Very similar to the Protected Mode feature of Internet Explorer, the security model is named "App Container". And enforced by the store screening procedure, even if you did find a hole in the sandbox then you can't get it past the validator and can't get it published in the app store.
Key point here is that it just doesn't make sense to write a store app to reboot the machine. Because there is nothing such an app could do that requires a reboot.
To shut down or reboot Windows 8, just shell to the following:
Shutdown:
%windir%\System32\shutdown.exe /s /t 0
Reboot:
%windir%\System32\shutdown.exe /r /t 0
I need to write an application that can detect if the "Bing - Get me there" application is installed on the current phone and if so, launch it.
Is this possible? The app would need to do this for other external applications as well, so a generic method or interface for this would be helpful.
Applications run in a sandbox on Windows Phone and there is no way to tell if other applications are installed unless you are writing both of them and you use a method to announce to other applications that you are installed and they know how to read that announcement.
2 approaches to such announcements would be:
Have both (all) apps synchronise with a web server and report which devices they have been installed on. The apps can the query which other apps have been installed on that device.
Have all apps write a file to a location where all apps can access. The only place to do this is the PicturesLibrary so you have to embed the identifier in the name of the image or in its contents and be able to query all images to identify the other installed apps. The user could manually delete any images you create in this way though.
Beware, neither method can tell if the other app has subsequently been uninstalled though so this is far from foolproof.
As far as I know, there's no way to do that.
Applications on Windows Phone run in complete isolation, and can not act with other applications, other than some highly specialized apps (i.e. for playing media).
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.