@SGaist I have not, as I thought the project is unmaintaned and unsupported. I'll check out that implementation too since you're bringing it up though. Thanks

sender() returns the pointer to the object which emitted the signal (http://doc.qt.io/qt-5.6/qobject.html#sender). In this case it is a pointer to QLocalSocket, so you need to cast it from QObject* to QLocalSocket* using qobject_cast

@Wieland QLocalSocket uses named pipes on Windows. Sure, I acknowledged that in my first post. Speaking of Linux, all these IPCs are more or less obsolete with the advent of kdbus. Maybe, however there are some issues with that. Kdbus is in the newest kernels only and not all distributions provide them (especially such as the stable flavor of Debian and other OS-es focused on longer release cycle/long-term support). The d-bus daemon is usually present, but not always, and as I recently found out (@SGaist pointed me to it) it's coming to Windows as a service. However without a full blown support from the core OS it may or may not prove a reasonable alternative. On the other hand, pipes are as old as computers themselves and run fine on pretty much any platform, have small overhead and are flexible solution to many such small-ish problems as mine. Do note, also, that from time to time a new technology claims that a more mature one will simply die out, however, it doesn't much seem to be the case. Java was supposed to "kill" C++, well it didn't happen. QML was supposed to replace the widgets - I personally find QML distasteful and still stick to the old-school C++ way and many others it seems. Anyway, don't take this as a rant, I'm just sharing a few observations. ;) Cheers!

@LuGRU Why not to use: QSharedMemory and You don't need to worry about message formatting. Because I run process with different account. First process run from System account and second from local account When I read SharedMemory in another process I have error "QSharedMemory handle doesn't exist"