MMF demo with 32 and 64 bit cross communicating.

[hutch--]

The ZIP file contains 2 stripped down editors, one in 32 bit, the other in 64 bit, the demo is a rough proof of concept of using private messaging and a memory mapped file as the memory used by both. The two examples both have 3 toolbar buttons, WRITE, READ and BYE.

WRITE will copy the data in the edit control to the MMF and send a HWND_BROADCAST message to any app listening to the correct private message and load the contents of the MMF into the listeners edit control. It then clears its own local edit control.

READ is for an app that is started after the first one writes to the MMF and it will load the data in the MMF into its own edit control.

BYE shuts down the instance where it is clicked.

You can run 2 or more instances of either editor and any data you enter into one local edit control will be read by any other instance of either that is running.

This is a bare minimal example and the general technique is not limited to zero terminated text data, by passing the byte length as well as the data you can routinely pass binary data, images, even apps if you have some reason to do so.

The reason for the basic design is to be able to extend the available memory of 32 bit apps and you can routinely use a gigabyte of MMF if you set it up that way. The test pieces I have played with so far pass multiple large blocks of memory from a 32 bit app to a 64 bit host and the only real limitation for 32 bit is you can only work on one at a time, its almost an emulation of the ancient bank switching memory of the early DOS days.

[mineiro]

Very fine. Congrats.
Using empty command line in 64 bits version I'm receiving a MessageBox:
Whoops: Command line file 'e' cannot be found.

I have tried to type 3 words "sim\n" and exchange between empty editors. At some point the last letter "m" of last word was lost. And continuing these exchanges other letters are lost.

I'm using linux and wine to run these editors. The problem here can be UTF8, LF and 32/64 functions being called, not sure.

[hutch--]

Thanks for testing, I don't know enough about Wine to know what is happening. See if you can open a file from the menu on both and see if either or both will write to the other.

[mineiro]

Using a filename in commandline or opening a file by menu happens the same thing.
I opened ed64.asm file and pressed write button in one editor, text was clean and reach other editor. So, on other editor pressed write button, text was clean and reach other editor. And by doing this consecutivelly the last line of text was lost.
After load text I have pressed only write button in both editors.

[hutch--]

I have tried but I cannot emulate the problem here. I even added 1 byte to each editor's write length but it made no difference. It may be an internal difference with Wine in comparison to the Win10 64 I am using, with the edit control OR the technique for loading it with the combination of GetWindowTextLength() then GetWindowText().