(888) 881-CORE
We’ve been deploying AlwaysUp with our products for years. We use it to run as services, many small programs we have developed as simple “stay in the tray area” windows applications.But lately, my co-workers have been criticizing that approach. They say that what AlwaysUp does is “dirty” because “Windows Services should not have any user interface”. They are afraid that one day Microsoft will want to enforce this by making it impossible to run any application that tries to open a user interface as a service. And then AlwaysUp wouldn’t work for our programs.
Do you think this true or are my colleagues mistaken?
By the way, I’m kinda reluctant to convert all our small programs — developed in Delphi — to proper services because debugging a Windows Service in Delphi is a huge pain and very rarely works (no matter what Embarcadero says). Thanks for creating a pragmatic alternative!
— Carlo
Hi Carlo, thanks for reaching out.
Your colleagues are mostly right when they say “Windows Services should not have any user interface”. Indeed, that’s very common advice given to developers constructing services today.
But in reality, that statement is overly restrictive and misses the mark. A careful reading of Microsoft’s technical articles and documents reveals that interfaces alone aren’t bad. And Microsoft’s actual advice to those developing services is “don’t design a Windows Service that must interact directly with a logged-in user”.
And, in light of that more accurate statement, you’ll be happy to know that there’s no indication that Microsoft will ever prohibit a Windows service from creating an interface. It simply won’t happen.
Let’s dive into the details to understand why.
What are the problems with a Service having a UI?
Back in the ancient days of Windows XP, Microsoft was happy for any Windows Service to present a user interface. It was even encouraged and many, many applications took advantage of that convenient design.
You see, Windows Services run in Session 0 — the session created when your PC boots. And because of that, all windows created by a service show up in Session 0. That’s always been the case — and remains so today.
In XP and before, the user logging in to the console would also be assigned to Session 0. All their desktop applications would run in that shared session too. As a consequence, that user would see any windows created by a service alongside his own, running on his desktop. This picture from Microsoft’s blog illustrates the arrangement:
Unfortunately, that lax architecture created a couple of problems.
Problem #1: Support for multiple simultaneous logins complicated interactive services
The visibility of interactive services was clear when only a single user could log in to Windows. The user who logs in could see any UI elements the services created.
But with the advent of Fast User Switching — where multiple people can log into a PC simultaneously — the situation became murky. Important considerations like these arose:
Why does a service’s UI only show up for only one person at a time?
Why can’t everyone logged in see the windows from an interactive service?
How can we make sure that the “right” user sees the service’s windows?
Unfortunately, there were no good answers for those questions. And as a result, we had strike one against interactive services on modern computers.
Problem #2: Mixing services and regular programs invites misbehavior
Second, and more importantly, the issue of security came to the forefront.
As mentioned before, Windows Services and all the programs launched by the first logged-in user would run in the same session (Session 0). But as it turns out, there are serious shortcomings of that architecture!
In “Exploiting design flaws in the Win32 API for privilege escalation”, Kristin Paget showed how a normal user could gain powerful admin rights by exploiting a Windows Service running interactively on his desktop. The attack was straightforward and Paget easily demonstrated how a virus lurking in an untrusted application could gain full access over your PC and create chaos. Ouch!
After initially downplaying the situation, Microsoft admitted that its flagship operating system was vulnerable. They moved quickly to patch it. And sure enough, the next version of Windows (Vista) eliminated the problem.
Microsoft solved both problems by isolating Session 0
The folks in Redmond negated both the interface and security problems in one fell swoop — by locking down access to Session 0. In no subtle terms, they pledged to reserve Session 0 for Windows Services and prohibit users from logging into that protected area.
In a nutshell, there would be no mixing of secure services and regular, potentially insecure applications in the same session. Services would run in Session 0 and user initiated programs would run in Session 1 and higher.
And with isolation in place, all talk of a service showing a UI has been rendered moot because no user would be able to see that UI.
Kudos to Microsoft for addressing both problems in a simple and effective way!
But Microsoft chose not to outlaw interactive services
Despite all the adjustments, it’s important to note that Microsoft didn’t plug the security hole by preventing a Windows Service from creating a UI.
Even though enforcing such a restriction would have disarmed Paget’s shatter attack, it wouldn’t have addressed the root problem — the dangerous mixing of highly privileged services and untrusted programs in the same security context.
It’s clear that if that risky co-mingling was allowed to persist, it would only be a matter of time before unscrupulous characters found another way to break in to powerful services running in the same session. So Microsoft focused on that problem.
Indeed, the engineers realized the truth — that interactive services pose no danger once they’re protected from untrusted code.
Today, Microsoft has no compelling reason to prevent a Windows Service from having a UI
With the security holes plugged and application developers no longer having to wrestle with the complexities that stem from visually interactive services, Microsoft has zero incentive to prevent services from creating UI elements. There is simply no upside for them.
On the other hand there is tremendous downside from shackling services in that way. Without a doubt, many of today’s services would break, thereby causing unnecessary nightmares for Microsoft and the thousands of independent programmers who’ve written services for the platform.
Furthermore:
All the documentation for Win32 GUI functions would need to be updated to signal that they don’t work in services or Session 0;
Programmers would face increasing complexity, forever burdened with having to understand where API functions work and where they don’t;
New API-level error codes would need to be introduced to signal when the new UI restrictions were violated.
In summary, it would be a significant undertaking to prevent services from creating a UI. And to what end?
Yes, Microsoft is far from perfect. The 2024 CrowdStrike outage reminded us of that. But they’re certainly smart enough to avoid intentionally shooting themselves in the foot for no good reason, which crippling Windows Services would surely do.
