Windows makes an important distinction between system services and interactive user desktops.
Understanding that distinction explains why remFREE remote control uses more than one process on Windows.
The Windows service
The remFREE Windows agent runs as a service.
That is useful for management because a service can operate independently of a specific user keeping an application open.
The service is appropriate for work such as:
- persistent agent communication
- heartbeat processing
- job coordination
- inventory collection
- service-level operations
- update management
But services do not simply live inside the same desktop as the logged-in user.
Session 0
Modern Windows isolates services in a session commonly known as Session 0.
Interactive users normally work in different sessions.
Conceptually:
Session 0
-------------------------
remFREE service
Windows services
system processes
Interactive user session
-------------------------
Desktop
Explorer
applications
mouse
keyboard
visible windows
This separation is an intentional Windows security boundary.
Why the service cannot simply capture everything
A service running in Session 0 should not be treated as if it owns the user's visible desktop.
Trying to force graphical desktop capture and input entirely through the service creates reliability and security problems.
The correct architecture is to separate service responsibilities from interactive-session responsibilities.
The remFREE user-session helper
For Windows remote control, remFREE uses a helper that operates within the relevant interactive user session.
The service remains responsible for service-level coordination.
The helper handles work that belongs inside the graphical session.
Examples include:
- desktop capture
- keyboard input
- mouse movement
- mouse clicks
- interactive remote-session media
Conceptually:
remFREE Service
|
| coordinates
v
User-Session Helper
|
+---- capture desktop
+---- inject keyboard
+---- inject mouse
+---- provide remote video
Why this is safer architecture
This follows an important design principle:
Perform work in the context where that work actually belongs.
Service operations belong in the service context.
Interactive desktop operations belong in the interactive user context.
Trying to collapse both into one privileged process makes behavior harder to reason about.
Multiple Windows sessions
Windows can have more than one session.
Examples include:
- the physical console
- a local signed-in user
- Remote Desktop sessions
- a locked session
- disconnected user sessions
This means the phrase the desktop is not always specific enough.
remFREE must identify which user session is appropriate for the remote-support operation.
Remote Desktop behavior
Depending on the active Windows session, remFREE may interact with an active Remote Desktop user session rather than only the physical monitor's visible console.
That behavior can be useful in administrative environments where the active user's work is occurring inside an RDP session.
Long term, remFREE can make this behavior increasingly visible by exposing session information and capabilities to the technician.
Session changes
Windows sessions can appear, disappear, lock, unlock, reconnect, or change ownership.
A production-quality remote-control system therefore needs to handle session lifecycle events rather than assuming the first session discovered will exist forever.
The helper architecture gives remFREE a foundation for that behavior.
Cross-platform lesson
The Windows design illustrates a broader remFREE principle.
The server should describe the capability it wants:
capture screen
move mouse
press key
The endpoint should decide how that capability is implemented on the current operating system.
That keeps server-side jobs and remote-support workflows platform-neutral while allowing Windows, Linux, and future platforms to follow their own security models.