[discostu]

Yeah, that's how the messaging loop works. Not sure I'd go so far as to say you can send any ammount of data in the other apps memory space, you can send a pointer and that will be in the other program memory space. With OLE (oops, ActiveX, whatever they're calling it today) you get a lot more data sending ability. I learned all this in early 95 when I took a Windows Programming class that used Petzold's then current book (Programming for Windows 3.1 3rd Ed, copyright 1992, published by Microsoft Press). This was all known, including the dangers (we of course looked at them as bad things you can do on accident, any hacker would see it a little differently). You send the message with the appropriate arguements and the other program handles it, and yes everything after Windows giving the message and parameters to the other program happens in that program's address space, not the most secure design architecture in the world (arguably the least secure) but not a secret. Like I said, the only shock to me is that people didn't already know this, I learned it when I was a wet behind the ears college student, from a book published by MS. To me this news is about as shocking as the revelation that rain is wet.

[supercat]

Yeah, that's how the messaging loop works. Not sure I'd go so far as to say you can send any ammount of data in the other apps memory space, you can send a pointer and that will be in the other program memory space.

Under the default message handlers for a textedit control, you can. That's one of the real problems here. A program may provide full validation for all the messages it process in its windows (and check for things like buffer overflow and such), and it may be designed so that an outside application could send any of the message it processes itself without security implications, but the default system handlers leave a great big gaping hole in security when they allow arbitrary read/write/execute to another application's process space.