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 kind a newbie on windows service programing, my idea is that i want to create a windows service that will take a screen shoot of the desktop client,i mean i want to attach this to a aspx page, the screen shoot code is working 100% but problem is when i trigger windows service after install it, nothing happened.
I debugged it and there was not prp, after that i made a small screenCapture.exe file to do the job and try calling it from the service, all i got was a black screen, tried everything with it and no luck.
Then i read about desktops and stuff like that, but honestly i don't understand any of that, i goggled a lot but no luck so far, problem is that i saw a website that implement this function so it can be done. BUT HOW ??? please help me out cause i am stuck here, and if u do explain good, cause as i told u i am kinda new to this
A service does not have access to the desktop. You might want to create a program that runs when the user is logged in interactively.
Not sure which Windows you are using...but starting with Vista, the ability to interact with desktop from a service has been disabled.
A service will not have access to the desktop. This is done intentionally by Microsoft for better security. The other option you can try is, goto the service properties and give it option to interact with the desktop. This can be done using local user permissions.
I am working on some Automation Project where one needs to perform some action related to display resolution.Change the Display resolution , Lock the Desktop and then Unlock Desktop again to check that resolution remained same.
I am able to perform LockWorkstation but unable to have any thing for Unlock Workstation.
Can any body help me regarding unlocking Display with help of C# and in Win 7 ?
I heard of GINA dll which can help ,but I dont know anything about it.Can this be used for Win7 and .NET 3.5?
Thanks
_Prat.
I don't think that doing this is technically feasible. GINAs were deprecated after XP and the new way to provide custom authentication in Vista/Win7 is to use the ICredentialProvider
interface. Even if you get this working you'll still have to somehow send the the secure attention sequence, i.e. ctrl-alt-delete, to initiate the logon. Sending ctrl-alt-delete programmatically is itself something that is difficult to do and not really supported.
This sounds like a lot of work for some automation and probably won't have much ROI. Can you test this by logging the user off completely and then logging back in? If so, then you could set your test machine to auto-logon the user. When you log-off it will shut down the session and then promptly log the user back in and you could check if the resolution is what you expect.
I have installed cc.net 1.4.3 version on Windows Vista. But It keeps giving me Interactive services dialog detection when I execute tests. I even have disabled the interactive services from services panel. but still getting this.
Any idea how to get rid of this problem
regards
Sam
No easy fix that you can do. The service is trying to pop up UI on the user desktop. In XP this worked because services and the first user log on both run in session 0. In Vista, services run in session 0 and the first user runs in session 1, so there is no way for a service to directly show UI to the user. This was due to security issues - search for Win32 Shatter Attack to get more details, but basically an untrusted user could send malformed window messages to the services, and in some cases could even cause arbitrary code execution.
You can disable it altogether by disabling the "Interactive Services Detection" service on the system. But you won't see notifications at all, and this will disable it for all interactive services. Best approach is to complain to the vendor to update their software for Vista.
EDIT: And the software is broken on XP when multiple users are logged on and the active user isn't in session 0.
Update: Since development machine has moved to Vista, i now automatically test as a standard user. And with XP being phased out, this question isn't so relavent anymore.
Since the Windows 2000 logo requirements, Microsoft has been requiring that applications run as standard user. Like everyone else i always ran my desktop as an administrative user. And like every developer: i log in, develop, run, and test as an administrative user.
Now with a new push to finally support standard users, i've been testing my applications by running them as a normal user - either through RunAs, or having my application relaunch itself with normal rights using [SaferCreateLevel][1]/[SaferComputeTokenFromLevel][2] if it detects it is running as an administrator. i quickly see how specacularly some of my apps fail under Windows XP as a standard user (due to my own stupidity). i also see how the same applications work fine under Vista (thanks to it's numerous shims to fix my bugs for me).
Aside: It's ironic that applications are more likely to run on Vista as a standard user than on XP.
The question is do you test your applications for standard user compatiblity? Do you develop as a standard user on XP? Do you ignore standard user access and hope for the best?
i tried, as a bonus, to have my app relaunch itself as a limited user (rather than normal user). It doesn't even come up - Windows says it failed to initialize. So there an area of future research on my part: making the app even support limited user.
i specifically referred to standard users on XP rather than Vista to enforce the truth that Vista is no different from XP as far as compatibility is concerned. And anyone who says their app fails on Vista must realize it also fails on XP.
I'm going to point you to Crispin Cowan's "Best Practices for Developing for Windows Standard User" talk. It's well worth watching.
If you want to sell your application to businesses then yes, you must test your application running as a standard user. If your application can't run without administrative privelleges, that's going to doom any sale in to a business.
Even in the home market, plenty of people can and do use limited users to go about their daily activities; I know I do.
Even administrative applications that do legimately need administrative privelleges should behave sensibly when running as a limited user. They should popup up a dialog informing the user that administrative rights are required to complete whatever task it was that they were attempting.
The best way to build software that respects these limitations is to develop your software under a user that has limited privileges. That way, every time you develop a feature you're implicitly testing whether it will work in a limited environment.
None of this is hard, it just take a degree of discipline - just like all quality assurance procedures do. People have been developing as non-root users on *nix for decades. Windows development is behind the curve in this respect.
Crispin, in his PDC talk, made a very good point, one that i had never considered before.
Google Chrome installs as a standard user: it installs in the per-user folder, without needing a UAC or OTS prompt, and everything is user friendly because the install is so easy. Unfortunatly, it is installed in a per-user folder, where the user can modify it.
Put it another way: malware can modify the Chrome exe.
Chrome would now become the biggest target for any mal-ware. And if some malware does modify it, Chrome is now sending your usernames, passwords, and credit card info back to home base, because that's what the new Chrome exe does.
That is why you sometimes want applications installed to protected locations.
Edit: The entire Microsoft "Click Once" deployment inititave suffers the danger.
I run on XP as a limited user almost all of the time and as the default. (On Vista, I use an adminstrative account and rely on UAC.)
I develop as a limited user. There's very little in Java and Visual Studio development that requires any more privilege than that.
If I need to run something under the limited account but with administrative privileges, I use a MakeMeAdmin (renamed and tuned as ConsoleMeAdmin) .bat script that creates an administrative console session.
If I really need to be an administrator in order to do installs and do first-time-runs so my security software can condition itself to allow network access to the new code (or not), etc., I will elevate my Limited User Account to Administrator long enough to get all of that done, then restart the account as Limited User again. Other than for Windows Updates, I do all of my downloads as a limited user and then install off-line after elevation to Administrator.
Because I only have a small workgroup LAN with no Active Directory, the only useful account types are Administrator and Limited User on XP. (I tried power user when I first began using XP but found that I could do without it and I prefer what that teaches me about not depending on special privileges in code I build.)
[PS: I also have Data Execution Protection (supported in hardware) active by default on my XP system, and you'd be surprised what that turns up.]
In the business environment most users are standard windows domain users.
To ignore standard user compliance tests is a really bad move.
And you will get each domain administrator that has to install your application very angry and they will go to your competition.
IMHO developing in an administrator account is not only unnecessary, but also highly dangerous! Suppose you check something on the internet while developing (stackoverflow comes to mind) and you catch some malware - history shows that this is far easier than you might have thought, e.g. through banners. As an administrator this malware will infect your computer and you might never get rid of it. It can even be a danger to all your development work (think of industrial espionage)!
If you have to run/test anything as an administrator, use either runas or even better virtual machines - that way you can use separate systems with defined behaviour (lots of problems with Windows software come from libraries that are of course available on the developer's PC, but hardly anywhere else!). In times of Microsoft Virtual PC and VMWare Server (both free) there isn't even an excuse due to high prices for virtualization software.
I've developed some Windows apps some years ago and besides their installers NOTHING ever required administrative rights. The run-time settings always belong to the user, not to the machine.
And yes, I run Windows XP as normal user at home too, as do my family members (parents etc.). Sometimes a crappy piece of software needs write access to their installation folder, but 95% of all installed apps run fine out-of-the-box by today.
Yes, we test that.
Probably the simplest, but most abused, rule is that you shouldn't do anything that requires write access to your program's install folder. Instead, there's a special folder called Application Data for that kind of thing.
Yes, and I took the general advice that its much easier to get your application to run on Vista if it runs ok on XP as limited user. To achieve that, and know if there were any problems running as limited user, I used LUABuglight.
I generally don't develop as limited user but only log on as limited user for testing.
The number of programs that require Admin rights and write to their own Program Files folder is amazing. To be honest, I've found very few programs that run correctly as limited user, from any software company, big or small.
Anyone else find it funny that Windows developers think its normal to run as Admin (apparently), but Linux developers pretty much never run as root?
As an old-time BOFH I will rain fire and ugly words over anyone asking for elevated rights for their client-side applications to run properly. It's just out of the question, always was ever since around 2001-2002 when we switched from Win9x to XP (sic).
As a newly born developer in a place where everyone on XP is a local admin by a forced group policy and changing it seems to take time and noone is especially inclined to start either - I've installed the RunAsAdmin shim that lowers me down to a normal user for most tasks including developing - much like in Vista. Recommended if you're stuck as a local admin on XP ^^