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

[peter-h]

AFAIK there is more to TRIM. It releases unused blocks on the SSD so these can be used for more even wear levelling. Otherwise the SSD is limited to using the few extra blocks it has for wear levelling which will wear very fast.

That suggests a really dumb wear levelling algorithm - as I wrote further back. Intel explained this for their SSDs. Their levelling worked across the whole SSD, and the drive became scrap only when every FLASH block reached the 10k writes.

The other thing is: does the SSD know which blocks wear fast? It doesn't know the OS installed, the partition layout, etc.

[peter-h]

Building a win64 version of the "control" app has not fixed the issue(s). So now working on this with Winspy+ to see what else a 64 bit OS changes...

[Postal2]

I told you it was a difficult path. It needs to be rewritten, a simple build for 64 is not enough. I recommend going back to a 32-bit system.

[radiolistener]

proper code should compile and run on both x86 and x64 platform with no change and no issue. If it don't works or leads to a crash, then there is mistake in the code. My apps works ok on both platforms with no need for code change, all what is need is just to select platform for compilation.

The difference is that some types are 64 bit instead of 32 bit.

[Postal2]

proper code should compile and run on both x86 and x64 platform with no change and no issue. ....

I'm glad you have the knowledge to figure this out. My current knowledge is not enough to understand how Windows 64 exposes a 32-bit process to a 64-bit space.

[peter-h]

My apps works ok on both platforms with no need for code change, all what is need is just to select platform for compilation.

Obviously so, if it is a win32/64 command line app, or a GUI app. But this app interacts with another app via the target app's UI messages.

At this point it looks like sending messages to the win32 target app works fine, but the stuff coming back is an issue. OTOH, messages don't get sent to the win32 app until the controlling app detects the right-looking menu, so it must be partly working.

I wonder if running the target app in winXP compatibility mode does anything? It never seems to do anything useful.

[Postal2]

... but the stuff coming back is an issue.

You didn't say to pass it back. In any case, try the method where both processes (both 32 bit) are launched within a single 32-bit process.

[peter-h]

How would one achieve that?

When I said "stuff coming back" I meant that the controlling app doesn't issue the mouse clicks until it detects the appropriate menu is up.

There are "scripting apps" out there which just issue mouse clicks blindly. I had one such, written in VisBas, which worked in win2000 only They are called "automation apps" and you can train them by clicking on stuff and they store the mouse clicks etc.

[Postal2]

... until it detects the appropriate menu is up. ...

This means that 32-bit methods are used for searching and identification. The program needs to be rewritten for 64 bits normally.

I wonder if running the target app in winXP compatibility mode does anything?....

I already wrote to you, make a bat-file, assign Windows XP to it, and run both applications inside it. Or write a 32-bit program that does the same.

[peter-h]

OK, there is another little problem

The target app leaks memory - a few tens of k after each operation. Eventually one runs out of RAM. So the control app periodically terminates it and restarts it.

I don't know how you could do this if both apps are to be invoked from a single .bat file.

[Postal2]

... The target app leaks memory....

Because it does CloseHandle(32 bit).

... I don't know how you could do this if both apps are to be invoked from a single .bat file.

Windows 64 somehow knows how to handle this for one process, otherwise any 32-bit program would leak memory.

[peter-h]

No; that app always leaks memory No way to stop it. Somewhere they do a malloc() and not free() probably. It was never fixed because it is not normally run in an automated situation.

[Postal2]

No; that app always leaks memory ...

And on Windows XP it did the same thing?

Then write a program like I wrote above. Since it will be a parent process, it will be able to easily restart anything you want.

[peter-h]

Yes same under XP.

Re writing a 32 bit program, I don't get how different that is to running a win32 "controller" under win7-64.

[Postal2]

... I don't get how different that is ...

If a separate 32-bit process works fine, then combining the programs into one process should solve the problem.

I certainly welcome your approach, but it still seems to me that it is better to install a 32-bit system together with an HDD. At least an HDD from a laptop (just not WD).

[peter-h]

Yes if all this fails then I will build this machine using winXP natively.

This particular industrial computer cannot have enough RAM to run win7-64, and then winXP in a VMWARE VM. I would have to chuck a lot more money at it...

[radiolistener]

I recommend you to rewrite this app on Linux

[peter-h]

The "target" app is a win32 3rd party one, about 10 years old, and cannot be changed.

We are getting some funny stuff on winspy. All the target app UI objects can be seen (as should be the case; everything visible on screen should be visible in winspy - unless the text within it is implemented as a graphic, presumably) but their handles are not easy to pick up for the "control" app (which is now win64). I know this is vague and I will post more detail once I have it. It appears to be a win7 v. winXP difference.

There are many people out there struggling with what is generically called "automation". A google on e.g. Systreeview32 digs up lots of stuff. For example the last item (5th line below) is not apparently visible (between the quotes is a specific text string):



It is related to stuff like this
https://www.autoitscript.com/forum/topic/177397-accessing-individual-elements-within-a-systreeview32-control/

A lot of "automation" is flakey code. As a funny example, years ago someone (who actually worked for M$ so knew all the details) wrote an automation app not totally dissimilar to this one. It was written in VisBas, and ran only under win2000

[Postal2]

.... but their handles are not easy to pick up for the "control" app (which is now win64). ....

Now that you understand this, it makes sense to go back to my very first post in this thread. You'll be looking for six months and no one will be able to tell you anything.

I'm going to assume you haven't gotten any smarter in such a short time, so... after getting the window handle, immediately do a dummy positioning of that window, and then do everything else.

[peter-h]

immediately do a dummy positioning of that window

Why, and how?

[Postal2]

Why, ...

Something inside Windows starts working correctly.

... and how?

SetWindowPos(yourWindowHwnd, HWND_TOP, 0,0,0,0, SWP_NOMOVE | SWP_NOSIZE);

[peter-h]

Should one do the above on the 904C8 window?

The 50574 window is apparently invisible to the control app.

[digger]

But, can't you run it in a 32-bit VM?

Yes I could indeed, and I use winXP VMs to run various old software, but that makes everything run a lot slower. This industrial computer is not some speed demon.

this seems like an obvious solution to me. are you sure it's too slow to run a winxp vm? and if it really is, why not run it on more capable hardware?

3) Rebuild the win7-64 machine to win7-32 and hope that magically fixes this messaging issue

or yeah, maybe even better. why not try that? not exactly a difficult or time consuming experiment.

[peter-h]

Actually it is which is why I will wait a bit longer for a win7-64 solution. It takes a good couple of days of messing around to sort out the drivers for ETH, USB, startup files (there are various windows scheduler tasks) etc.

If win7-64 is impossible then I will restore a Trueimage backup of a disk from the currently running winXP machine, onto this one. That way of doing it (restoring an image backup onto a different motherboard and CPU) usually works because Windows rebuilds the registry hardware tree at each bootup. The SATA controller has to be configured for IDE (not one of the trendy new modes; they gain barely 10% more speed IME) which avoids the need to slipstream HD drivers, and IDE is what enables an old Trueimage 10 to work, otherwise you need to buy the very latest version and keep fingers firmly crossed. You just have to fix up some drivers but video usually works (if it didn't you would be screwed).

Another approach is to create a VM from this winXP machine. For me this would be the last resort.

For sure one could spend a bundle on a more powerful fanless computer but then you get more heat. I have right here a nice fanless i5 machine, used as a server, and it has a huge heatsink on it. The 1.8GHz Atom one I am currently running this on is much cooler.

If I go the XP route I will investigate 3rd party utils to do the TRIM command.

[Postal2]

Should one do the above on the 904C8 window?

The 50574 window is apparently invisible to the control app.

I don't know. I found this solution by trying different options. If you have another similar problem in addition - you won't cope. All the advice you will get is to rewrite your program for Linux in assembler.