EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: peter-h on October 02, 2024, 06:56:42 am
-
I have a "server" which does a peculiar job, whereby a custom win32 GUI app (written in MS VC++) is sending messages to another win32 GUI app (no idea what that one is written in; it is a 15 year old thing from somewhere and no sources are available).
The whole setup runs fine under winXP (32 bit) and has done so 24/7/365 for about 10 years, on a dedicated machine. There is no UI (in normal operation). The setup collects some data (over Ethernet) and generates a logfile (PDF, produced by a nice app called PDF24 which gets invoked by the 2nd app) which it emails somewhere.
One can run XP for ever, but the hard disk will eventually fail and one cannot use an SSD with XP because XP always destroys an SSD after about a year of 24/7/365 operation. I don't know why but fairly obviously it keeps repeatedly writing to some block, usually where NTLDR is sitting, while defeating any wear levelling in the SSD - one can dig around this by searching on say the win7+ TRIM command which would obviously not be needed if wear levelling was totally autonomous inside the SSD. So I am now trying to move this thing to win7 which works fine with SSDs, and I built a new industrial PC with win7-64 which I use everywhere else (you can still get updates for it, via the Simplix route!).
I found some reliability problems with the inter app messaging, and according to the colleague who wrote the C++ app (which he can still rebuild) it may be due to this
https://devblogs.microsoft.com/oldnewthing/20110629-00/?p=10303
It is possible that the 64 bit difference is that some message params will be 64 bit integers on 64 bit Windows. So if we send a 32 bit param, it may be a matter of luck what the uninitialised upper 32 bits contain. If they happen to be 0 then it will work, but if not, who knows!
Unfortunately I don't want to rebuild the whole thing with win7-32! I've already spent days setting stuff up on there under win7-64... The OS is legit, BTW.
Can anyone think of a way forward?
I've tried the obvious hacks like running both apps in winXP compatibility mode, and they are already running as Administrator.
-
It's not undefined behavior, it says right there:
The WPARAM is zero-extended, while LPARAM and LRESULT are sign-extended.
But, can't you run it in a 32-bit VM?
-
Isn't it the case that two win32 apps sending 32 bit messages between each other use legacy 32 bit win API? Shouldn't 64 bit Windows handle this fairly obvious case right? If it doesn't, how rebuilding only one app in 64 bits is supposed to help?
The post you linked says that when messages cross 32/64 bit boundary (but do they, in this case?), they are truncated or zero/sign-extended, so it's 100% deterministic.
I suspect a bug in the applications, or maybe in Windows 7.
Just replace the HDD and continue running on XP?
-
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.
they are truncated or zero/sign-extended, so it's 100% deterministic.
I would have hoped so!
Just replace the HDD and continue running on XP?
I could do that but would prefer in that case to find an SSD route which XP doesn't trash. I could then do a Trueimage backup, and restore it onto the new SSD. But I never found an SSD which works long term with XP.
-
... custom win32 GUI app (written in MS VC++) is sending messages to another win32 GUI app ...
If you mean the window message, you won't find a solution anywhere except here:
https://www.eevblog.com/forum/programming/postal23-flash-and-mcu-programmer/msg5562347/#msg5562347 (https://www.eevblog.com/forum/programming/postal23-flash-and-mcu-programmer/msg5562347/#msg5562347)
-
Obviously I don't know how the code is written, but I suppose both apps are 32-bit executables?
In which case, the article you link to, while having substance, should not matter as the receiving end, even if it runs on a 64-bit Windows, if it's a 32-bit app, then the upper 32-bit of passed integers would be ignored anyway.
But are both apps 32-bit executables? The second, I suppose so. The first? If the above should matter, then I suspect you colleague's app may be a 64-bit executable. If so, and he wrote it, you can just ask him to rebuild it as a 32-bit app. If it was written "properly", it should not be too painful at all.
Without source code for the second app, it's pretty hard to debug anything though, short of that.
-
What is the simplest way to tell if an app is win32 or win64?
The C++ app runs on winXP so it must be 32 bit, no?
-
... Without source code for the second app, it's pretty hard to debug anything though, short of that.
Your outstanding inventions should be entered into the record book immediately. If a window is assigned a 64-bit handle, the receiving program will accept it in any case. This only affects the sending program.
-
Postal2, are you real, or chatgpt?
I suppose both apps are 32-bit executables?
I am sure they are.
Apparently using the win7 "Aero" UI complicates this whole thing but I am not using that; I am using the classic UI.
There was always a Windows program called Winspy+ that was used to view the windows and send messages to them - that’s what was used to explore and find the names of the controls to send message to.
-
Postal2, are you real, or chatgpt?
peter-h, I have already read your messages, I understand that I have to explain everything to you like a schoolboy. The handle is assigned by the operating system, it doesn't care what bit depth the program has.
-
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.
Is the app very io hungry? A VM on a cpu with virtualization enabled should be fine.
Windows 7 should run 32 bit apps native just fine. You don't need to recompile iirc.
However, there are some major changes between xp and 7 filesystem wise, eg access to the program files is different for 32/64 and there is this thing called filesystem virtualization that annoys many old apps.
https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc138019(v=msdn.10)?redirectedfrom=MSDN
-
Indeed win7-64 (and win7-32 which I have on one laptop) run all these apps fine. Win7-64 does not run win16 apps (DOS box stuff also), which win7-32 does run, but everybody knows that (a funny decision by MS to do that).
I have absolutely no issue just running these apps on a desktop win7-64 machine (a proper one, 24GB RAM, 3.5GHz, quad i7, etc) and that also perfectly runs VMWARE VMs for old XP-only apps. The issue here seems to be 100% related to the windows inter-app messaging. I am aware of the filesystem issues; indeed the config paths differ from XP.
I seem to have the following options:
1) Find an SSD which works with XP (never heard of one) and image backup/restore the present XP machine onto that SSD
2) Get a beefier industrial computer which is still fanless (another key requirement since fans always fail) and can take enough RAM (current one has 4GB, Atom 1.8GHz) to run a winXP VM and run the existing XP setup inside that VM
3) Rebuild the win7-64 machine to win7-32 and hope that magically fixes this messaging issue
It is not IO hungry. Maybe I need to investigate going up to 8GB RAM. Of course anything is possible by spending another £500+ :) But this is quite a cool (literally) industrial computer.
I suspect the reason XP kills SSDs (read a lot about this) is that the absence of the TRIM command means the SSD cannot tell which blocks are free, and over time this reduces the wear levelling pool. This seems a primitive explanation though because wear levelling ought to also swap high usage blocks for low usage (but not free) blocks, but it seems SSDs do not do that and only swap used blocks for never-used blocks. This suggests that a huge SSD (say 1TB, with only 5% used) should last a lot longer.
The handle is assigned by the operating system, it doesn't care what bit depth the program has.
So what do you think the problem is? For example the "target" app pops up a print dialog, which the "control" app is waiting to see so it can right-click on a Print item, but it doesn't see it (mostly - sometimes it does).
-
... So what do you think the problem is? ...
The problem is that the program that wants to transmit requests the handle of another window, it gets a 64-bit handle, but it cuts it to 32, and the remaining bits with a probability of 90% will not be zeros. When it requests a handle within its process, the operating system will correct it. You need to run both programs within one 32-bit process, some script or bat file that itself has 32-bit properties and simply run the programs in turn.
-
Stupid question and I haven't programmed in win-api for 20 years, but...
I can see how posting a message to the app may trick it into thinking that you clicked "print item", but if your problem is detecting when the target app displays its print dialog, are messages involved at all and aren't you doing it by some other means? (Actually, I don't know how to do that.)
-
You need to run both programs within one 32-bit process, some script or bat file that itself has 32-bit properties and simply run the programs in turn
How is that doable, short of win7-32 native, or a win7-32 or winXP VM running in the win7-64 system?
but if your problem is detecting when the target app displays its print dialog, are messages involved at all and aren't you doing it by some other means? (Actually, I don't know how to do that.)
I don't know the detail but it seems to be an established process which a lot of systems use when they are driving another application to do something. Here is some description
https://stackoverflow.com/questions/11285928/detecting-a-modal-dialog-box-of-another-process
What about rebuilding the "control" app to be a 64 bit one? Would that help with the messaging?
-
... How is that doable, short of win7-32 native, or a win7-32 or winXP VM running in the win7-64 system? ...
This is possible in the same way as Windows x64 handles x32 dlls within one process - all handles will be valid.
... What about rebuilding the "control" app to be a 64 bit one? Would that help with the messaging?
Yes, this will solve the problem, but first you need to try simpler options.
And tell me the model of your SSD, I have many Windows XP installations on SSD, everything works fine, and most likely when working 24/7/365 the problem is in the reliability of the SSD, and not in the system. For this mode I recommend HDD.
-
Yes, this will solve the problem
OK I will ask my colleague to rebuild it as win64. It will still be driving a win32 app. As I already have it all set up (with a lot of work) on a win7-64 system, it is better to continue for now. I am upgrading the RAM to 8GB in case I need to move to the XP VM alternative.
And tell me the model of your SSD
Various SSDs, over years. They always fail after about 1 year of 24/7/365 use, and always report NTLDR is not found. SSDs work fine on XP apart from that. They also work fine in laptops (never had a failure) but those are not running 24/7/365. New laptops are win7, of course... but at work we have had various XP laptops on test rigs.
-
I suspect the reason XP kills SSDs (read a lot about this) is that the absence of the TRIM command means the SSD cannot tell which blocks are free, and over time this reduces the wear levelling pool. This seems a primitive explanation though because wear levelling ought to also swap high usage blocks for low usage (but not free) blocks, but it seems SSDs do not do that and only swap used blocks for never-used blocks. This suggests that a huge SSD (say 1TB, with only 5% used) should last a lot longer.
It should not impact wear leveling, but it does impact write latency big time.
Consumer ssd's with very low sustained write will be worst, look in the benchmarks and see which ones still maintain some speed after more than one full sequential disk write.
-
OK I will ask my colleague to rebuild it as win64. It will still be driving a win32 app. ...
It's strange that your colleague didn't suggest this to you himself.
... Various SSDs, over years. They always fail after about 1 year of 24/7/365 use, and always report NTLDR is not found. ...
Then it turns out that an SSD formatted in fat32 will work for at least 3 years.
-
How did you calculate the 3 years?
There is probably a 1Hz write somewhere.
Yes they were probably all FAT32. Nowadays I use NTFS.
-
... Yes they were probably all FAT32. ...
I thought it was NTFS. It makes more records when working with files. Then it turns out that for 24/7/365 operation under Windows XP, you need strictly HDD.
-
Why?
With wear levelling, the total data volume written is proportional to the SSD size. It is fairly large, IIRC for say a 256GB SSD the total volume was something like 100TB. But not infinite. When that total volume has been written, every block on the SSD reaches the 10k or whatever FLASH write limit.
So you can choose a larger SSD and get a longer life, in a given system. That was clearly stated by e.g. Intel in the early days of SSDs. They published the calculations.
But somehow this falls apart for XP, and nobody knows why, other than it being to do with the absence of TRIM.
-
... So you can choose a larger SSD and get a longer life, in a given system. ...
That's true. But you can't control how well it works until the disc breaks.
...But somehow this falls apart for XP, and nobody knows why, other than it being to do with the absence of TRIM.
I've heard all this talk about TRIM. It doesn't affect reliability, only speed. The complaints about Windows XP were about NTFS, which writes a lot of unnecessary stuff.
-
Without TRIM the firmware in the ssd controller runs out of it spare empty blocks and performance plummets.
You have to wait for the erases, and with MLC you also have to put back in the other content you didn't touch. Like shingled hdd.
This puts a high penalty on writes of used blocks.
Some disks can be put in SLC mode with different firmware, for XP I would definitely recommend SLC disks.
If you exceed the lifetime writes rating nothing can help you, availability of trim does not matter in this.
-
Without TRIM the firmware in the ssd controller runs out of it spare empty blocks and performance plummets.
OK; I get that. But that is dumb "wear levelling". Smart wear levelling should swap in unused blocks first, and later on move to swapping in blocks on the basis of how far below max #writes they are, and run a background process for erasing unused blocks. Since free blocks (whether full of 0xFF or not) are visible by reference to the directory structure, you can have a background process erasing them.
Maybe TRIM does the last one? I've just been around this on a product I developed (FAT12 FLASH FS) and while I don't actually have an RTOS task erasing the free space, I could have. The difference in write time is 3ms versus 15ms.
With XP, no TRIM etc, performance will drop once the SSD has no virgin blocks, which for a 500GB SSD will obviously happen at 500GB of writes. I can see the SSD itself cannot do the erasing because it doesn't understand the directory structure. Only the OS has that info, for whatever dir system you have selected.
But the drop, of say 5x, is probably never going to be noticed.
Interesting topic... but why does XP trash SSDs after a year? (Typical SSD size say 50GB back then). They should merely slow down, not corrupt outright.
-
I don't think it's specific to windows xp, but any budget ssd will be shred by a host that does not allow it to free blocks.
They are heavily optimized for speed, not for endurance. This is simply an scenario they're not developed for.
You can buy enterprise SLC SSDs that are intended for this, they will last a lot longer, but cost a lot more.
Even with windows 10 the only failures we see in embedded pc's is the little msata disks failing. They're just worn out.
-
.... but why does XP trash SSDs after a year? ....
Buy a refurbished hdd cheap and don't bother.
https://aliexpress.com/item/1005002617399974.html
-
One can run XP for ever, but the hard disk will eventually fail and one cannot use an SSD with XP because XP always destroys an SSD after about a year of 24/7/365 operation. I don't know why but fairly obviously it keeps repeatedly writing to some block, usually where NTLDR is sitting, while defeating any wear levelling in the SSD - one can dig around this by searching on say the win7+ TRIM command which would obviously not be needed if wear levelling was totally autonomous inside the SSD.
1. This doesn't match my experience at all. I checked my notes, and e.g. on one PC I ran Windows XP on an undistinguished Kingston SH103S3 120GB SSD from June 2013 to October 2017, about 12 hours per day. I never saw an SSD error, and that SSD still works fine.
2. NTLDR is never written after install.
3. TRIM has nothing to do with wear leveling or drive endurance. It's a performance optimization that lets the SSD pre-erase blocks.
4. On the systems that failed, did you use an SSD-aware utility to create SSD-aligned partitions? Non-aligned partitions cause write amplification, and the Win XP installer didn't know about alignment.
5. On the systems that failed, did you run the defragmenter? That would be bad.
-
1. Interesting
2. I am sure that's true but the failure was "NTLDR not found" so the start of the SSD was somehow corrupted. Could be the FAT32 directory, which does get written on any update
3. I get that now - thanks
4. No
5. Not sure; have now found the registry changes for stopping that
-
Why were you using FAT32 instead of NTFS?
-
Probably was.
-
Actually, did you check SMART to verify it was a hardware issue and not plain old data corruption?
-
No idea what that is :)
-
It's the first thing you do when you suspect hardware problems with a disk.
Get some HDTune, CrystalDiskInfo or whatever people use on Windows, run it on a machine with the suspect SSD connected, find the option to get "health data", "diagnostic data" or whatever the software calls it, look at the results. If all "normalized" values are at or near 100 and raw values of counters involving uncorrectable errors are zero, the disk hasn't had bad sectors. SSDs should also report "Media Wearout", so take a look at that.
-
I have such a utility (Samsung Magician) for my PC
(https://peter-ftp.co.uk/screenshots/202410025519215917.jpg)
But you can't run it if the machine does not boot :)
-
But you can't run it if the machine does not boot :)
Then you connect the drive to a different computer.
Or boot one of the many recovery CDs that include e.g. GSmartControl: https://gparted.org/livecd.php
-
Interesting and useful digression.
I am waiting for a SLC SSD and 8GB RAM to arrive, and hopefully the 64 bit control app. If the new app does not solve it, I will just restore an XP image backup (of a working machine with a HD) to the SSD machine. Maybe I should create the partition first, on a 4k boundary... what is the easiest way to do that, short of using a win7 boot DVD?
-
I usually use the free version of AOMEI Partition Assistant: https://www.aomeitech.com/pa/standard.html (https://www.aomeitech.com/pa/standard.html)
The GParted CD I just linked will also do it, but is less user friendly.
-
...I am waiting for a SLC SSD ...
Isn't the initial area of the SSD, where your ntldr is, SLC? And what difference will it make? I haven't analyzed SSDs, but for EMMC used as a disk, the initial area is done SLC, and SSD utilities suggest doing the same by default.
... I usually use the free version of AOMEI Partition Assistant: ...
What does this stupid utility have to do with partitioning SSDs into SLC/MLC/TLC zones?
-
The SLC thing is a red herring. There is no evidence that the Win XP issue was SSD endurance.
-
The SLC thing is a red herring. ...
I agree. And peter-h got caught on this hook. The thing is that if the chips are rejected and can't handle MLC - they are sold to various idiots. At the same time, if the chips that can handle MLC are switched to SLC - the reliability will really increase.
-
HDtune (free version) and Crystaldisk info do nothing on winXP. CrystalDiskInfo won't install (not a valid win32 app, it says - but I am running XP 32).
Never mind.
-
There are several approaches to inter-process communication (IPC) in Windows:
1) Shared memory is the fastest method for IPC on Windows, providing high performance by allowing direct access to shared memory regions.
2) Named pipes offer a more versatile approach, generally faster than sockets, but are limited to communication between processes on the same machine.
3) Sockets are the most platform-independent option, enabling communication across different platforms, including Linux.
4) Window messages allow lightweight communication between GUI applications within the Windows environment.
-
XP works fine with SSDs
https://www.reddit.com/r/windowsxp/comments/x16gjk/yes_you_can_use_an_ssd_drive_with_windows_xp_hear/ (https://www.reddit.com/r/windowsxp/comments/x16gjk/yes_you_can_use_an_ssd_drive_with_windows_xp_hear/)
-
You can get a license for HDSentinel and have it email reports about the disks. You can then track the state of any disk over time.
It also keeps a log, but if the disk it's installed to fails you can't read it. :P
-
.... (current one has 4GB, Atom 1.8GHz) ....
I am waiting for a SLC SSD and 8GB RAM to arrive, ...
Very strange. My Atom boards support 2 GB of RAM, I know that you can break your brain and expand it to 4. But where to stick 8 GB?
-
It takes two modules, and you can get 4GB ones, £15 each. PC3-10600. Whether the MB will support them, I will find out. I cannot see its P/N without bending some stiff flat cable...
Window messages allow lightweight communication between GUI applications within the Windows environment.
That is the only one available if you cannot recompile one of the apps.
XP works fine with SSDs
It does... but see discussion above.
-
... I will find out. ...
I will simplify your impossible task.
-
...But somehow this falls apart for XP, and nobody knows why, other than it being to do with the absence of TRIM.
I've heard all this talk about TRIM. It doesn't affect reliability, only speed. The complaints about Windows XP were about NTFS, which writes a lot of unnecessary stuff.
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. With XP I'd disable the virtual memory as well to avoid unnecessary hard drive access.
-
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. With XP I'd disable the virtual memory as well to avoid unnecessary hard drive access.
All of this was explained in the link above.
- Align partitions
- Disable swap file - optional
- Disable defrag - optional
- Disable last access timestamp - optional
https://www.youtube.com/watch?v=SdNG7YImRQQ (https://www.youtube.com/watch?v=SdNG7YImRQQ)
-
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
... 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.
-
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.
-
... 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.
-
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.
-
... 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.
-
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.
-
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.
-
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.
-
... 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).
-
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...
-
I recommend you to rewrite this app on Linux
-
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):
(https://peter-ftp.co.uk/screenshots/202410145519235209.jpg)
It is related to stuff like this
https://www.autoitscript.com/forum/topic/177397-accessing-individual-elements-within-a-systreeview32-control/ (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 :)
-
.... 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.
-
immediately do a dummy positioning of that window
Why, and how?
-
Why, ...
Something inside Windows starts working correctly.
... and how?
SetWindowPos(yourWindowHwnd, HWND_TOP, 0,0,0,0, SWP_NOMOVE | SWP_NOSIZE);
-
Should one do the above on the 904C8 window?
The 50574 window is apparently invisible to the control app.
-
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.
-
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.
-
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.
-
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.
-
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.
-
It wasn't clear to which object that hack should be applied.
-
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).
-
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.
-
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.
-
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.
-
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.
-
... 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.
-
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!
-
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.