Submitted by Robert Szeleney on Tue, 2006-10-31 13:32.
Desktop Communication Service
The desktop communication service is a powerful interprocess communication system, used to communicate between applications, services, drivers and the kernel.
Internally, communication is based on messages which are based on DataCollections. Such a DataCollection Object is able to store an unlimited number of various datatypes like strings, values, etc.
Communication itself is done between interfaces, regardless where the interface exists. (kernel or user mode, application or driver, ...). This way it is very easy to, for instance,
send a message from a device driver to user applications.
Lets consider the USB stack and device attachement.
When the USB stack initialized a new just attached device it will send following message:
MessageType STRING "Attachement"
DeviceType STRING "Printer"
DevicePath STRING "/dev/usblp0"
Product STRING "Desktjet 5550C"
Manufacturer STRING "HP"
Status STRING "Ready"
to the interface Notify.Device.Attachement.*
The * in the interface name means: Send this message to all applications waiting for messages on interfaces starting with Notify.Device.Attachement.
For instance, on a fresh SkyOS installation, there are two applications waiting for messages on this interface. The notification panel - which informs you with a little message window at the bottom left side of the screen - waits for messages on Notify.Device.Attachement.Application.NotificationPanel. Additionally, the HardwareChangeService waits on Notify.Device.Attachement.Service.HardwareChange, immediately displaying the printer configuration dialog when you attached the printer.
Communication between applications is also done using the Desktop communication interface. For instance, sending this message:
MessageType STRING "Next Song"
to Notify.Media.Player.Control will cause all running mediaplayer applications to switch to the next song.
But sending the same message to
will only tell MediaLibary to switch to the next song. Other media applications will continue playing the current song.
So, lets say you want to write an application displaying the current battery level. Thats quite easy:
HRESULT Callback(HANDLE hInterface, sDCSMessage *pMessage,
printf("Battery level for '%s' is %f %%\n", pSource, fLevel);
RemoteInterface_Create("Notify.Power.Battery.Change.MyApp", Callback, &hNode);
RemoteInterface_AddParameter(hNode, "Source", REMOTE_INTERFACE_PARAMETER_STRING,
Thats all. When running this application, everytime the battery level changes you will see something like this:
Battery level for 'Primary battery' is 98%
Battery level for 'Primary battery' is 97%
Battery level for 'Primary battery' is 96%
Many similar things can be done with just this few lines of code, like :
- reacting when the user made network interface changes or new proxy settings
- new weather data arrived
- new devices attached
- devices removed
- disks mounted/unmounted (e.g. Open viewer window or add desktop icon)
- a song finished playing
- new software has been installed
- a gesture was drawn onto the screen
- a failed login
- an operation was not allowed because of security policy
Additionally you can perform actions by just sending such messages, for instance:
- Power done, logout
- Remote control applications (like mediaplayer, ...)
- Soft-detach devices
To conclude, the Desktop Communication Service allows easy, fast, consistent and powerful communication between the kernel, drivers, services and applications.