i wish to load my C# application after windows user login and before windows desktop appears. currently i added my application startup path to registry run key. it loads my application correctly but windows windows desktop appears[2 sec] then my application runs
Note:
My application creates seperate desktop using winapi, while my application running it hides the desktop temporarily.
This really isn't possible to do. Windows works pretty hard to get the desktop up and explorer responsive as soon after the user logs in. This is what is most important to the user.
Your goals may be noble, but they are at odds with what users want. So in general, they are at odds with how Windows works (especially Win-7).
If you have software that needs to run early that doesn't need to interact with the user, then a service is they way to go. It is important to note that in Vista and later Windows systems, there is no way for a service to interact with the user - e.g. they cannot have their own graphical user interface. Services with UI are inherently not secure.
One way to partition your software is to put some things in a service, and have a think UI layer on top of it. COM and Local RPC are good choices for communication between your service and your UI layer.
Note that you will need to do work here to prevent your components from slowing down boot. Poorly behaving applications are one of the biggest problems in the boot path. You can study this using the Windows Performance Toolkit
It is kinda possible I think, but you are really in for a lot of extra work. What you could do is replace the Windows Shell with your own code, but at that point you become solely responsible for the UI that the user interacts with.
If your code isn't 'just right', you may end up with an unusable Windows install, and I'm not sure your users are going to appreciate that much.
Also note that there may be features that you normally intuitively expect to be available on a Windows machine that are part of the shell which you will not have access to anymore. For details, try http://en.wikipedia.org/wiki/Windows_shell_replacement as a starting point.
Addendum:
I have only the vaguest knowledge myself about what is actually involved technically to make this happen, but http://dustyant.com/articles/deeshell/ seems to be a decent explanation of the basics. Again tho... here be dragons make sure you do this in a VM or something so that you don't end up stuffing your main Windows install.
Just briefly what 'Shell Replacement' means: after you log in, windows starts an application called 'explorer' (not sure if this still holds for Vista / Win 7... I have a vague recollection it got a little more involved recently), which basically draws the desktop, the taskbar, etc. ... it is possible to tell Windows to start a different application instead of the default graphical shell. At that point you are in control of the main UI of Windows... which means that you are responsible for everything that Windows normally does in the shell ... gives you a lot of control and flexibility, and possibly lots of headaches.
Related
I'd like to make my own custom program run on windows 10 in replacement of the start screen and logon screen.
Is there any way I can do this? I've currently replaced the accessibility program (accessible from the logon screen) with a command prompt, if I accidentally lock myself out (it has happened once!).
I recall seeing a particular Winlogon.exe. Is this my starting point? Am I able to replace the program that windows runs with my own?
Also, wrapping up, If I manage to replace this program, can I logon to windows in my program? I'm writing it in c#.
Old post, but still relevant...
I don't know if you can, or should replace it, but you could write an overlaying app to cover it and do it's own thing, if you can use a little windows command-line magic combined with node.js. More of a work-around, but then you won't chance destroying any os-specific functionality, and it seems to be universal from Vista on up (to my knowledge at least). Here is how you can get your starting point to run a GUI app on the logon screen.
Node-Windows - Run GUI app on Logon screen
You can use this technique to run any app in any language that you can open it's window from a command-line.
There will be a brief period where the normal logon screen will be visible before your app starts, but this will let you do it.
Whatever language you use for your logon GUI, you will need to send simulated key input to the real logon screen, possibly mouse-clicks-- but you can likely use simulated tabs to get to the right logon. Likely MS has API's for C# as well as a variety of related dialects to programmatically logon to the desktop in a more elegant fashion than this last part, however.
Your app will be running as the SYSTEM user (unless you specify otherwise), therefore it will be running with the highest authority-- so you can basically do anything that is possible from there. Permissions won't stop you. Be careful with this.
I have to run my C# application that I wrote it recently on several computers with window 7 operating system. Here is a big challenge with it, Application must run on startup and user must not be able to work with anything else such as windows hotkeys, other applications, some directories and etc.
Considering I don’t want to kill any process or service as less as possible, Please give me the best solution.
Thanks and waiting
Maybe A little more information will help
did you see Devices like ATMs or Medical devices that window is running on? Those devices don't allow user to manipulate with desktop or anywhere else, I want their solution. . . my Application Will run as a device handler(A Medical Device in Operating room).
You probably shouldn't write such an application in the first place (nagware?).
Anyway. I think what you are looking for is actually "kiosk" software. Here is blog entry that describes how to lock down the computer to effectively run in "kiosk mode".
Note however, that not every application can (or should) be used in that mode. Either because it has loopholes that still allow you to do thing (for example the file open/save dialog still allows you to create directories or navigate the file system), or because they were simply not designed with that goal in mind.
This sounds actually like a (very) bad idea to me...
You could probably hook every Keyboard event so you disable OS shortcut (Windows + D, Windows + E...). See here.
Also hide the Windows taskbar.
Make sure your application starts with Windows.
This sounds a bit hacky to me...
A program with the properties you mention is called a (very restrictive flavour of) shell. So you need to register your program as a shell (instead of explorer.exe) for the poor, poor user you want to restrict.
You might look into using a local group policy to enforce this restriction. Check this out.
Is it possible to run applications on the Windows Desktop? I mean... that it can only be seen in the system tray, and it should be able to run alongside the desktop.
I have no idea how to code it, please help me. I'm kind of new to these things, I am supposed to create something like a "Stardock Fence".
I have seen some examples, but they seem buggy, any strong alternative I could use?
Process.Start() can be used to start a windows application/console app from another win application. There are parameters that allow you to optionally hide the UI as well.
You want your application's windows to be always-on-bottom. In other words, your UI will always appear to be beneath any other open window and just above the Desktop's icons.
To accomplish that, see these related questions.
Once you have a window always on the bottom of the z-order, you'll probably want to remove the non-client window chrome (titlebar/min/max/close buttons) so that your UI can look like a more integrated part of the Desktop. There's plenty of examples around; Googling is left as an exercise for the reader.
Not entirely sure what you mean by background. I expect you mean a Windows Service which is a project type in visual studio, or you might (less likely) mean running a background thread.
Actually, if you want it in the system-tray, you don't want it entirely in the background.
If it was to be fully "in the background", then your best bet is to have it as a service.
System tray icons need a window, but you can just make it non-visible and non-taskbar and that's fine.
A common combo is a service that does the actual heavy-lifting, and a hidden-window application with a systray icon that reports on the service's status (possibly making that same window visible when further interaction is needed).
You want to run your application in the background? Is it on a windows machine? If so then you want to look into running your application as a windows service. Here's an msdn link:
Introduction to Windows Services
There's examples in the article I think - if not it's a good starting point. You can configure services to start automatically on startup of the machine etc. Your application will then run in the background.
Basically you craete your application as normal and then host it in a windows service rather than say a console app or a winforms app.
Background:
Started a fair amount of work before realizing that a Windows Service cannot start an app with a GUI that displays without potential problems. The proper solution of separating the GUI of the app to be started is non-trivial, so I'm trying to think of alternative solutions.
There is a GUI to manage the service that is a separate executable, but the process to be launched (actually multiple instances of it) has its own GUI that needs to be shown. It doesn't need to be made visible by the service itself, but it needs to be at least able to be made visible by another process with a visible GUI. The Windows User that is running the service and that needs to see the GUI of the launched process is the same and known at install time.
Is there some way to accomplish this or is it back to the drawing board?
Also both the service and the app to launch are both our code and modifiable.
My first thought was to suggest that you look at the WTS* functions and CreateProcessAsUser and then I followed the link you provided and saw that you have already considered this and dismissed it.
As an alternative, if I understood you correctly you have a Windows Service and GUI which is used to manage the service. So why not use the communication channel you have between the Service and the management GUI to send a message from the service to the management GUI and have the management GUI launch the other GUI apps on behalf of the service? Of course this would assume that the management GUI is always running.
You might even do this with a hidden application that is not visible and launches when the user logs-in, that way you reduce the risk of the user inadvertantly closing the application, this would be a separate app from the actual management application.
I have a GUI C# Windows form program that I would like to start as a service when the computer starts and perhaps have an icon in the system tray that when clicked maximizes the program. Is this possible without major rework?
Thanks
Windows Services cannot have a GUI, at least not directly. You will have to separate your application to a presentation layer/process and a service layer/process:
The presentation layer will remain a WinForms application
The service layer will run as a Windows Service
The two of them will have to communcate with each other with some means of inter-process communcation, like named pipes or sockets.
You can use a third party app, such as FireDaemon (http://www.firedaemon.com/), to start any program as a service. There are many options available in FireDaemon, such as form visibility, restart on failure, etc. However, it will not automatically create a tray icon for your app. So your app will have to be changed to have its own tray icon functionality and FireDaemon will just start the program and manage the process.
FireDaemon costs about $40 (USD). I imagine there are many other similar applications available.
I would first look into creating an actual service project as mentioned by other answerers, but keep this approach in mind. It has worded well for me in a handful of situations.
It depends on how the code is currently written. I have several WinForm apps that double as services, but the bulk of the work I have separated into another assembly. My solutions for those apps generally have 3 projects: WinApp, Service, and Library (I'm oversimplifying here).
If you feel that your WinForm app could make a good service then you probably have your code in such a state that you could probably separate it out easily enough. Adding a service project is pretty simple, adding the installer for it is a little more challenging but still well documented. The trickiest part is making a deployment package for it that installs the service properly, but again... its well documented as long as you know you need to look for it.
Edit: Just to clarify, in general I wouldn't consider this a major project.
You can write the code to have it run as a service, but I think the more important question is, what does it provide? There are ways of minimizing an application to the tray, and you can start said applications at launch to the system tray.
This is the link that I always refer back to about doing windows services. It is WCF based, but I think with a little modification you could make it work for you:
http://support.microsoft.com/kb/317421
As to minimizing to a tray, there's an excellent answer in this question:
What's the proper way to minimize to tray a C# WinForms app?
You could use Task Manager within windows and setup a task that would execute your application's .exe per windows boot.