A few words on desktop Communication Service

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:

#include "skyos/libskyos.h"
#include "libdcs/libdcs.h"
#include "skygi/skygi.h"

s_gi_msg m;

HRESULT Callback(HANDLE hInterface, sDCSMessage *pMessage,
char *pSource,
float fLevel)
printf("Battery level for '%s' is %f %%\n", pSource, fLevel);
return S_OK;

int main(void)

RemoteInterface_Create("Notify.Power.Battery.Change.MyApp", Callback, &hNode);
RemoteInterface_AddParameter(hNode, "Source", REMOTE_INTERFACE_PARAMETER_STRING,


while (1)
GI_MessageWait(&m, NULL);

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
  • etc.

Additionally you can perform actions by just sending such messages, for instance:

  • Power done, logout
  • Remote control applications (like mediaplayer, ...)
  • Soft-detach devices
  • etc.

To conclude, the Desktop Communication Service allows easy, fast, consistent and powerful communication between the kernel, drivers, services and applications.






jrLIoHB kFyiGSz


That's a really nifty feature. :-) I could imagine a load of possibilities of how to use this, not only to catch all kind of events.

Just a question:

this "Notify.Power.Battery.Change.MyApp" is like a path into an internal tree or do I see this the wrong?

stay safe :-)

Yeah, there are many things

Yeah, there are many things this can/will be used for, it allows complete communication between every parts of the OS.
The interface name itself is just logically devided with the dots, there is no tree or something similar behind it.


it allows complete communication between every parts of the OS.
The interface name itself is just logically devided with the dots, there is no tree or something similar behind it.
science assignment | statistics assignment

Hehe :-)

That's cool. I'm going to implement something similar in my own os some time later - I'll do it with a tree structure. It'd minimize all the string searching in some way, wouldn't it?

Stay safe :-)