send info between apps

[Sam Hobbs]

Memory mapped files?

Woka

I might be using incorrect terminology but it is correct to the extent that this is a common use of the term. I don't know how familiar you are with Memory mapped files, so I should try to define them assuming you know very little. If I don't do that well enough, then say so.

Memory mapped files is a common way for processes to share data; perhaps the most common. It does seem to be an indirect solution, and it probably is, at least somewhat. A Unix system, for example, has more direct functions for sharing memory; at least if my memory is accurate.

When a file is mapped to memory, a portion of memory in each process's address space is mapped to a common portion of virtual memory. The memory can be paged in and out, but that is not done unless physical memory is used to the extent that pages need to be swapped, whether they are part of a memory-mapped file or not. Data in a memory-mapped file can be accessed as efficiently as normal memory in an address space. In terms of efficiency, the memory is the same as the rest of memory for the process. ReadProcessMemory and/or WriteProcessMemory are very inefficient in comparison.

A memory-mapped file can be backed by the pagefile(s), for which the file becomes just a way to share memory. Believe me, that is a solution that is very, very common.

[Wokawidget]

Any exmaples of code?

Woka

[Sam Hobbs]

Any exmaples of code?

Woka

How did you search? Whatever you are using to search is no good, since there should be many to be found. As soon as I get through doing things such as checking ther weather, I will look for samples using VB, and hopefully we can help you in knowing how to search.

[Wokawidget]

Hahaha. You sarcastic sod Hahaha.

OK. I will search. I was just wondering if you had any small samples to hand. Not actively looking for this code as I have no need.

Woof

[Sam Hobbs]

I did not know of any samples, expecially not VB samples. There are many more samples that use the C/C++ languages but the following are two that use VB:

Visual Basic Samples by Karl E. Peterson (MapFile.zip)
Binaryworld - Sharing Data Between Processes Using Memory-Mapped Files ... [ VB -> Memory ]

Also, the MSDN previously contained an online copy of Hardcore Visual Basic, in which there is an article called "Shared Memory Through Memory-Mapped Files".

[Wokawidget]

Cheers for that.
Just got to work. Will check out those link.

Much appreciated

Woka

[Megatron]

One of the mistakes was "subclass the receiving app"

A grave mistake, that was.

Megatron also said that it is possible to "pass the string in the lParam parameter" of a "WM_USER + X message" which is not possible. If Megatron meant that the string could be put into a lParam parameter, then it is possible to send only a few characters, not enough to be considered a string

Do you see the irony in me finger-pointing this insignificant "mistake" you made?

Life's too short to buy green bananas.

No; the WM_COPYDATA does not need custom marshalling, but WM_USER and WM_APP messages do.

No. If the data structure you're passing with WM_COPYDATA contains pointers to other locations of memory, you'll need to improvise a different approach (i.e. remove the pointers).

Receiving messages in another application that cannot be by modified at the source code level is one thing, but how to process them in that other application is a more critical problem, and likely more difficult than simply receiving the messages. Therefore I think it is best to assume that this is not a requirement until it is stated explicitly that it is.

If you're sending strings between two applications, what good is it to only be notified when a string is received? The sole reason you are sending the message (string) is so the other application can make use of it (process it). You can process the messages in that external process by subclassing. Since you have already installed a hook (the callback is already mapped into the address space of that process) you're already half-way there.

To say it's more "difficult" is subjective. Yes, there's more typing involved, but I wouldn't consider that difficult.

avoid use of ReadProcessMemory, at least in programs being developed for use by other people. I am working on getting some authoritative references on the subject.

So long as the memory locations are not modifiable by the user, it does not present a security risk. If you are not confident with your own ability to harness these functions, then don't use them.

[Sam Hobbs]

Do you see the irony in me finger-pointing this insignificant "mistake" you made?

I don't know what you are referring to.

Life's too short to buy green bananas.

That is a subject for the chit-chat forum, but when the closest store that sells ripe bananas is far away, life is to short not to buy green bananas.

No. If the data structure you're passing with WM_COPYDATA contains pointers to other locations of memory, you'll need to improvise a different approach (i.e. remove the pointers).

Of course. If we had to specify all exceptions such as that (such as WM_COPYDATA works except to send pointers) then we would never get anything done. It's like wasting time driving around in search of ripe bananas.

If you're sending strings between two applications, what good is it to only be notified when a string is received? The sole reason you are sending the message (string) is so the other application can make use of it (process it). You can process the messages in that external process by subclassing. Since you have already installed a hook (the callback is already mapped into the address space of that process) you're already half-way there.

It depends on what is needed. Yes, if it is simply a matter of processing a message sent to/from a window, then that is as easy as you describe. However if there is something that needs to be done with the data differently than what the other application does, then it can be a lot of work.

For example, if the requirement is to draw text on an image in another application's window, then that might be quite easy. If the image can be resized (zoomed) by the other application, and if the text needs to be correspondingly resized, then that is more work. And it is likely to be more work than someone might think initially, since the text would potentially need to be redrawn after each paint message. If however the requirement is to draw the text in the bitmap that is shown in a window, then that might be significantly more difficult. When I say bitmap here, I mean it might be a bitmap drawn in memory (a memory device context?) that potentially could be written to disk, and the requirement is that the additional text be included in the image when it is written to disk.

Then there are millions of other possible requirements, such as a requirement to alter text that is being processed from/to a database.

So long as the memory locations are not modifiable by the user, it does not present a security risk. If you are not confident with your own ability to harness these functions, then don't use them.

I am talking more from the point of view of the user of the software. It is my understanding that security specialists would object to use of ReadProcessMemory and WriteProcessMemory. ReadProcessMemory can be a problem when used to get passwords and such. A security specialist has reason to be concerned about allowing use of ReadProcessMemory, since when it is allowed, it has access to all of a process's memory. Also, if a person does not understand Windows adequately, a user might allow use of ReadProcessMemory for an account (theirs or another account) in such a manner that allows all other applications that execute under that user's authority (including unintentional applications such as viruses) to have that access.

Programmers essentially need to have a userid that allows general use of ReadProcessMemory and WriteProcessMemory, right? So for programmers, it might be an insignificant problem. If an application is to be used in a relatively more secure environment, then ReadProcessMemory and WriteProcessMemory would be an important consideration. I am not familiar with Windows security enough to clear about details, but I am attempting to get help from security specialists.