Glenn Linderman wrote: >> It seams that you have a pretty complete and consistent vision on how to >> do it. IMHO, it would be beneficial if you convert it to the code. It >> would have 2 advantages: >> 1. You yourself would be able to verify if your concept is consistent >> 2. Others would be able to bettern understand your idea. > > It would also have some significant disadvantages... it wouldn't be > available for several years, and, since I'm only a casual user of > GuiTest, it might break compatibility with some significant features of > GuiTest. > > I'd be glad to discuss the idea, and help people understand it, if > anyone wants to understand it. Beyond discussion, I'm afraid it would > be several months, at least, before I might be able to start > contributing code.
We would mark it as experimental. You know, coding is of course an actual implementation. But it is also a kind consistency check. When you design in your imagination or on paper you can still miss some important details. Coding forces us to specify everything so we can then verify if our concepts are OK. The fact that you will implement the method and post it to the group does not mean your code will make it to the code base. But everyone who is interested would be able to try it out. It would also be a good base for further discussion. > OK, so the Win32::GuiTest documentation states that both DLL injection > and allocation of memory in remote process are used by GuiTest. > > What I read in Richter, Advnaced Windows, 3rd edition, implies that DLL > injection is built using allocation of memory in remote process, > together with some other features. > Is "Advanced Window" the same as "Programming Applications for MS Windows"? I read 4th edition. I will reread it if I have time, to make sure if I am right, but this is how understand it: * There are several ways of DLL injections. * Not all of them require that you explicitly allocate memory in remote process address space * There is DLL injection method called "by remote threads" where you do need to allocate memory in other process address space. > I haven't read enough Win32::GuiTest documentation to figure out why > GuiTest uses each of the techniques. Is such documented, so that I > could read about it? Well, the reason for it isn't very scientific. Dennis Paulsen, one of contributors, implemented some ListView, TreeView related functions using DLL injections with Win32 hooks. In the same time I was strugling with some common controls and I thought it would be good to have a mechanism, which would allow experimenting without a need to modify the code in xs file. So I implemented remote process memory handling function. > > You mentioned that performance isn't a big deal, because GuiTest > programs generally have to wait for the tested program anyway, but the > more cycles consumed by GuiTest, the fewer are available for the tested > program... so performance shouldn't be totally ignored. While Windows > provides a number of APIs that can affect other processes, I have no > idea what the costs are to use those APIs. It would seem that any > interprocess activities would require a significant amount of > synchronization, and that would make such APIs costly, compared to local > actions. Hence, one of the purposes of my envisioned approach is to > reduce the number of cross-process APIs that are used. If benchmarking > shows that cross-process operations are nearly as fast as in-process > operations, then perhaps that concern is unwarranted. I agree but I would put it the other way around: If benchmarking shows that cross-process operations are performance bottle necks, we should then start thinking about optimisation. --Piotr
