Windows inter-app messaging and 32 bit apps under win7-64

[peter-h]

That window freeze hack did not do anything.

A clue may be that it finds the systreeview32 as before, doesn't find the Edit item, and the next item it says it found has an address which is not seen anywhere in winspy. So it looks like garbage is being picked up.

Perhaps it is an issue with the way win32 versus win64 packs structures.

[Postal2]

That window freeze hack did not do anything. ...

I don't know what it does, maybe some structures are being completed and become available, but without it the program works as in the screenshot.

[peter-h]

It wasn't clear to which object that hack should be applied.

[Postal2]

If you click in the edit field 2 times in succession, the program does not crash. If you try to move the window (clicking on the window strip is enough), the program crashes. This means that access to the message pipe was created by the system incorrectly, and this access is corrected by entering a positioning command from the control flow (window in another flow).

[mariush]

Kinda stupid obvious question, but have you tried  playing with the Compatibility options when you right click on executables and select Properties?

You have there Windows 7 compatibility , though it may not do anything about 32bit vs 64bit handles.

I'd probably redesign the app by making that in-between app act like a basic http 1 server that supports only the GET and POST commands ... POST to push a message to the server, GET to poll the server and get the data if something new is available.

[peter-h]

I did try winXP compatibility modes, on both apps, but they appear to make no difference.

There are no sources available for the "target" app.

[Postal2]

It turns out that you created a blink program on a microcontroller and deceptively felt your omnipotence, which is a mistake that everyone goes through.

You can correct the dll import table in the unchangeable exe and substitute your interceptor (your dll) with a filter as an option. Thus, calling the print dialog, the program will call your dialog, inside which you can filter everything you need.

[peter-h]

That is indeed an interesting approach. Unfortunately this program does not get to print anything until you select one of a number of items to print, and then you right-click on that item, then from a list that appears you click on Print.

So just calling a Print DLL will not do it. Somehow you have to pass the required parameters to it.

Another way I wondered about is a GUI based hack: get the screen x,y address of an item which can be located, add an offset to it, and issue a mouse click at that x,y. I think it should work if one ensures that that part of the GUI is always visible. Windows apps (this one, certainly) are fixed in pixel dimensions.

[Postal2]

... So just calling a Print DLL will not do it. ...

What does the printing dll have to do with it? You can even intercept the kernel if you have enough patience to rewrite the prototypes of all functions. I gave an example of intercepting a dll for understanding.

And note that no one is interested in programming itself (the example posted), but it is very interesting to talk about programming and chat about installing Windows 11. And about writing graphical interfaces for Linux in assembler.

[peter-h]

I should be asking chatgpt...

In case anyone is interested: winspy32 finds all the objects just fine, under win7-64, and since its source is available, a win32 app must also be able to find them, so the "win64 app is required" is obviously nonsense!

[Postal2]

I should be asking chatgpt... ....

You should go back to your Windows XP image and not force your brain.
But if you still try to intercept dll - you can start the graphical interface directly in your fake dll, while being in the namespace and resources of the calling dll program. That is, you can rewrite your application as such a dll - and you will not have a communication problem, and everything will work fine on any system (you can also control the memory leak through your dll).

... In case anyone is interested: .....

No need to confuse people with stupid assumptions. The program simply switches the mode automatically, this should be visible in the source code.

It is also necessary to take into account that winspy injects itself into the process being examined (to read passwords), therefore I suggested doing the same in the most correct way - through its dll. In my example, the program loads the dll by its usual name, and the original dll is renamed. This approach is used because the dll for win9x is being corrected, and the original is needed for winXP. In your case, you need to change the name in the import table of the immutable application (directly with a binary editor) and create a dll with a changed name, which will call the original dll through itself.

I also know that there is a way to run your immutable application as a dll in the address space of your program, but I have never tried it. It would be convenient in your case. But no one can give advice, because the TRIM command is much more interesting to discuss.


I also just figured out how to compile a program for x86 and then, when running it on a 64-bit system, use 64-bit dlls from a 32-bit program. I need to try it. First, the program is compiled with assembler inserts, filled with nop to the required size. Then the code for the inserts is compiled in 64-bit assembler and directly inserted into the compiled program using a binary editor.