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
Related
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.
Is there a way I can ensure that my program starts even in the "Windows Safe Mode" ?
There are several ways to do so. One of the easiest way to do this is adding your app in Windows registry.
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Here you will find a String value with default value data
Shell = explorer.exe
Now you can add your app here by editing its value data, so that after edit it will look like
Shell = explorer.exe,app1,app2
This will make these apps to run in safe mode.
Warning: Do not remove explorer.exe . Doing this will prevent auto start of Windows Explorer.
Safe mode is a mode of windows in which only the very bare minimum core windows features are started.
By design it does not load or automatically start up any 3rd party applications, services or drivers.
The purpose is to have a minimal running version of windows incase one of those 3rd party apps, services or drivers are malfunctioning and preventing windows from working correctly.
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).
this question has been asked before but there is no conclusive answer.
I've written a Windows service in Delphi, which needs to generate a beep under certain condition. This works fine on XP, however fails in Windows 7 or 2008.
Note:
Beep can work if i create a console program instead of a service - using PC speakers.
Beep cannot work in a service even if i enable "allow service to interact with desktop" or even assign administrator rights to the service.
My question: Is there a way I can call beep API such that it works in a service? Thanks.
You can't do this in Vista and up. Services run in a different session and so don't have access to the speaker.
Update: Someone found a way here. it involves IOCTL, and is available to drivers and services.
Original answer:
The only way I know of to interact with the user would be to have your Service communicate with a small user-agent process which would be added to HKEY_LOCAL_MACHINE\CurrentUser\Run to autorun.
This is the usual pattern in vista and win7 where no user interaction is possible directly from the service:
MyLittleService.exe has no access to the user. But it can communicate via a named pipe with a tray icon utility.
MyLittleTrayIcon.exe communicates to the service, and can also be told to signal the user with message boxes, beep via whatever method (windows sound effects probably would be better than trying to access the PC speaker which is not guaranteed to exist on every PC anymore), etc, and maybe even can be used to control the service (restart it, reload the configuration etc).
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.