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).
Related
I build a application to monitor 24/7 the input level of a soundcard. I use the WaveIn API to get the audio level. This applications works well on Windows 7. On Windows 10 it works well too, only thing is that when I connect with RDP to the Windows 10 machine, the audioinput level 'hangs' to one value.
The application is not hanging. When I start the monitoring again everything works. I tried MSTSC /ADMIN so I be sure that I use the same session.
I think something goes wrong with the WaveIn API I use. Does anybody know something about this issue?
Best Regards,
Nicos
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.
#UPDATE:
OK FOR ANYONE ELSE WHO IS SEEKING ADVICE ON THIS ISSUE...
So far, the best thing I have found is to download yourself a copy of pGina and for 2k/XP modify the GINA, and for vista/win7 you will need to create custom login credentials (pGina have the tools/samples to interface with the Vista/Win7 architecture).
to confirm -- it appears that this is what Novell are doing with Vista/Win7 rather than the traditional method of replacing the GINA (like in 2k/XP)
If anyone else comes up with a way to run an application on the logon screen in Win7 please post it.
Ok I'm writing some vb6 software that requires input before the user logs on to the system.
Basically I want to run an application on the Windows logon screen where the user can interact with the program. At present I have the application running as a service allowing to interact with the desktop, but it is still now showing.
I know that "Allow service to interact with desktop" will work in Windows 2000 / XP, I'm running Windows 7 - I am also aware that services cannot directly interact with a user as of Windows Vista - saying this, are there any other methods to get my application running on the logon screen. Novell does it
Does anyone have any other ideas to get this working?
You can only do this if you are authenticating the credentials yourself. Prior to Vista, this was done via GINA, but since Vista, you need to write your own Credential Provider.
The reasons behind this are buried deep in the security principles -- Ctrl-Alt-Del will only ever bring up the window station associated with login (etc), and no other application can get to that window station (so you can't create a fake password box over the top to scrape passwords, for instance).
Without knowing why you think your service needs to interact with that desktop, it's difficult to advise further, but it might mean that your design is broken somehow.
Service isolation will probably prevent you doing this from a service.
Pre-vista Novell and the like would probably have used GINA, which was replaced in vista; http://msdn.microsoft.com/en-gb/magazine/cc163489.aspx
The only way I know of would be to write your own msgina.dll.
It can get dicey during testing though. Any mistakes can mess up your OS so bad that a complete reinstall becomes necessary.
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.