[DUG] Sending data between process on same computer on windows

Myles Penlington myles at ams.co.nz
Tue May 8 11:30:19 NZST 2007


The reason behind the second one is security - which is even tighter on
Vista. You can no longer do a SendMessage to a process running at a
higher security level, and for that matter from a interactive program to
a service - all due to security restrictions that have been added in
recent years by M$ to stop viruses etc. E.g In Vista you can no longer
allow a service to interact with the desktop.

 

Things need to be running on the same window station (which is the root
of all security in windows). If you have processes running on different
window stations (which applies to services etc), then you will have
security issues.

 

Myles.

 

From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
On Behalf Of Leigh Wanstead
Sent: Tuesday, 8 May 2007 11:18
To: NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Sending data between process on same computer on
windows

 

Hi Conor,

 

Thanks

 

Regards

Leigh

	-----Original Message-----
	From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz]On Behalf Of Conor Boyd
	Sent: Tuesday, 8 May 2007 11:04 a.m.
	To: NZ Borland Developers Group - Delphi List
	Subject: RE: [DUG] Sending data between process on same computer
on windows

	I've already given you one scenario (although I admit it's not
one that's going to bother most people), and couldn't find any doco
anywhere to describe why Send/PostMessage failed in that instance.

	 

	Another scenario was described on the page I linked to: "The
easiest way to do such IPC (inter process communication) is to use the
message APIs like FindWindow + PostMessage. Unfortunately messages may
not work inside of non interactive service/system processes in the NT
family."

	 

	C.

	 

	
________________________________


	From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz] On Behalf Of Leigh Wanstead
	 

	May I ask why sendmessage is not reliable? In what situation
will cause sendmessage fail to break the communication?

		-----Original Message-----
		From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz]On Behalf Of Myles Penlington

		 

		The devil is in the detail in this kind of stuff, and
your actual implementation can have a great effect.

		As implied, the best method will be to develop 2 or 3
different methods, test and compare the results.

		 

		 

		From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz] On Behalf Of Conor Boyd

		 

		Sorry Leigh, I haven't done enough testing with big
volume messages to be able to answer that for you.

		 

		I was more interested in something that worked and was
reliable.

		 

		Cheers,

		 

		Conor

		 

		
________________________________


		From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz] On Behalf Of Leigh Wanstead
		 

		May I ask which is faster, ipc or sendmessage?

			-----Original Message-----
			From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz]On Behalf Of Conor Boyd
			 

			I found the IPC functionality from madshi.net
(http://help.madshi.net/IPC.htm <http://help.madshi.net/IPC.htm> ) to
work very nicely.

			 

			I needed a way to send messages from a
screensaver I was writing to another process on the same box, and
SendMessage didn't seem to work when a screensaver was active (which I
found strange, but anyway...), and the IPC stuff from madshi works
flawlessly.

			 

			
________________________________


			From: delphi-bounces at delphi.org.nz
[mailto:delphi-bounces at delphi.org.nz] On Behalf Of Leigh Wanstead
			 

			May I ask what is the fastest way to send data
between process on same computer on windows? I assume sendmessage api
faster than semaphore waiting, of course faster than TCP/IP which will
go through huge amounts of tcp/ip stack. I just want lowest overhead on
per call. Anyone have any experiences on that?



Attention:
This communication is confidential and may be legally privileged.  If you are not the intended recipient, please do not use, disclose, copy or distribute it, other than to return it to us with your confirmation that it has been deleted from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.adventureeducation.co.nz/pipermail/delphi/attachments/20070508/204cb960/attachment.html


More information about the Delphi mailing list