IPC, WM_COPYDATA (IPC between desktops)

[Vozzie]

Hi,

Amazed by the fact that SendMessage only works after EnumDesktopWindows and not before... :icon_eek: I've tried the with commandline arguments yesterday but that didn't work. Now I made a test and it's strange to see it doesn't work before but does work after EnumDesktopWindows...

Code Select Expand

;....
.Data

ghWndApp1 DD 0

.Code

EnumDeskWinProc Proc Private hWnd:HWND, lParam:LPARAM
Mov Eax, hWnd
.If Eax == lParam
Mov ghWndApp1, Eax
Xor Eax, Eax
.Else
Mov Eax, TRUE
.EndIf
Ret
EnumDeskWinProc EndP

; ....

Invoke SendMessage, hWndApp1, WM_APP + 1, 0, 0
Invoke EnumDesktopWindows, hDesk, EnumDeskWinProc, hWndApp1
.If ghWndApp1
   Invoke SendMessage, ghWndApp1, WM_APP + 2, 0, 0
; ....


masm qeditor code attached...

[jj2007]

I get "insufficient memory" for CreateDesktop on WinXP SP3 Home...

Now I tried again and wow, it works!

[Vozzie]

Hi,

Yep, I had a error the first time too. Strange, i don't have this with the other desktop tests i tried(in EasyCode).

And do you also only get WM_APP+2 ? Or both WM_APP+1 and WM_APP+2? I only get WM_APP+2 (on vista).

[jj2007]

I get both WM_APP+1 and WM_APP+2.

[Vozzie]

 

Maybe something vista vs xp,... I'll go and try on 7...

Update : Win7 i only get WM_APP+2.

The 0xC0000142 'bug' when starting the second process i had all the time on Win7. This was due to Closing the process handle immediately after creating the process,... No more problem when using Sleep. (exactly what i'm going to do now,..)

Code Select Expand

       .If rvx(hProcess=DoCreateProcess, Addr szTemp1)
                        Invoke Sleep, 1000
                        Invoke CloseHandle, hProcess             

[qWord]

According to the documentation, you generally can't send any message between desktops - It is even surprisingly that it works when using EnumDesktopWindows().
I think that you must create a separate thread, which then calls SetThreadDesktop(). From that thread it may be possible to send messages to the corresponding desktop.
Sadly the documentation is a bit weak about this (IMO).

[Vozzie]

According to the documentation, you generally can't send any message between desktops - It is even surprisingly that it works when using EnumDesktopWindows().
......

Yep, i quoted that part from the msdn in my #6th post. So now we know that after after using EnumDesktopWindows, and not even in the callback, it does work, ...

On XP you can pass the hWnd by commandline(probably file etc) to an app running on another desktop and that app can use it to send messages.
On Vista and above it looks like it's only possible to send messages after EnumDesktopWindows.

Windows, sometimes, works in mysterious ways,... But it's fun to find limits , or break them,...

If it's a 'feature' unsupported according to the documentation the software can break one day when using it...

......
I think that you must create a separate thread, which then calls SetThreadDesktop(). From that thread it may be possible to send messages to the corresponding desktop.
Sadly the documentation is a bit weak about this (IMO).

I tried that a long time in the past, but not from a thread,... The msdn states that there can't be any hooks or windows in that thread,... But it's for the intention i had a bit overhead to create a thread for every message... (because the "program is dynamic" future messages are unknown)

Anyway i'm just doing this for fun, (and learning)...

[jj2007]

you must create a separate thread, which then calls SetThreadDesktop(). From that thread it may be possible to send messages to the corresponding desktop.

It is definitely possible to send WM_COPYDATA from a console app, so the "no windows" obstacle can be overcome if both processes have a send-only submarine in the "other" desktop.

[qWord]

Whatever he will do it, the fun will begin when he recognize that it is dam hard (at least for Win7/Vista) to close/remove a desktop without rebooting or closing the curent session:  Windows,  AVs and other software may create processes for that desktop. Because they keep handles to the desktop, it required to find and kill them...

[Vozzie]

Hi,

My aim was to make a program that runs software on a second desktop and disables the current user from switching back(without password). And i thought maybe one day i'll want to put extra features in that program so wanted to load dll's and make them communicate. (It's one instance running 2 times)...

I did my homework :) and some reading before starting. Went thru some codeproject articles and passed the bottlenecks you mention... I don't know if that desktop needs to be closed down, i don't think the software will ever be used , lol,...

The program keeps track of all handles for the processes it created , so it could call terminateprocess on them. And with enumdesktopwindows, getwindowprocessthreadid and terminateprocess it must be possible to kill most what's running on the second desktop,...

The current desktop is a field in a process it's PEB.RTL_USER_PROCESS_PARAMETERS. But that structure can vary between versions of windows(or updates). On ntinternals it's 'documented' as the 26'th field, but on vista it is the 31st field.

Code Select Expand

Assume Fs:Nothing
Mov Eax, Fs:[30H]
Mov Eax, [Eax + 10H]
Mov Eax, [Eax + 31 * 4]
Invoke MessageBoxW, NULL, Eax, Eax, MB_TOPMOST

Anyway, i have to draw the line somewhere of what i'll implement,...

[qWord]

I've found only one Method: run the program as administrator in the desktop to close, search for all handles using NtQuerySystemInformation() and finally kill the corresponding processes.
That PEB stuff sound interesting - you may give us feedback if you successfully implement that method.

BTW: Have you ever consider IPC using WinSock? – that would be a robust solution.

[johnparker29]

I believed to create it possible to fill DLL's in both procedures to create this system more powerful. And create a way for those dll's to connect. But i can keep this function of interaction behind and then the only need to connect is to quit the other procedure effectively.

[Vozzie]

I've found only one Method: run the program as administrator in the desktop to close, search for all handles using NtQuerySystemInformation() and finally kill the corresponding processes.
That PEB stuff sound interesting - you may give us feedback if you successfully implement that method.

Hy, i've attached a the source for a program "GetProcessDesktopName" that displays each process it's desktop value from the PEB. It uses NtQueryInformationProcess/ReadProcessMemory to find the names of the desktop...

Anyway, it was not the intention to implement, your question to give feedback felth like a challenge to me...

BTW: Have you ever consider IPC using WinSock? – that would be a robust solution.

Yes i did. But this would require some sort of protocol and for sending structures(binary data) it would need some kind of binary protocol(what is harder then text). So no, sockets , if needed can be implemented in the DLL, but sockets will not be implemented in the Host application...

I'll have a look at "NtQuerySystemInformation" now,...

[qWord]

The program looks confident :t
Unfortunately it didn't find the desktop for all processes (even with Admin rights).

In the attachment a simple console program, that enumerates all processes, which owns a handle of specified desktop.
Syntax:

enum_desktop_procs DesktopName

or

enum_desktop_procs DesktopName /a /c

Also there are option for killing the processes.

BTW: There are several macros which support Unicode:
- rvx/rvcx and fnx/fncx  with L"my txt" or L'my txt'
- UCSTR/uc$(),...
... see hlhelp.chm

[Vozzie]

Hi,

:icon_eek: You are mad, in a good way...  Your code is very learnfull to me

I'll come back later on this, first have to dig my way thru that project...

BTW, i guess the RBT lib is a kind of linked list api. Do you have some documentation on it,...? :)