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

[peter-h]

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.

[Jeroen3]

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?

[magic]

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?

[peter-h]

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.

[Postal2]

... 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

[SiliconWizard]

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.

[peter-h]

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?

[Postal2]

... 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.

[peter-h]

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]

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.

[Jeroen3]

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

[peter-h]

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).

[Postal2]

... 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.

[magic]

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.)

[peter-h]

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?

[Postal2]

... 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.

[peter-h]

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.

[Jeroen3]

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.

[Postal2]

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.

[peter-h]

How did you calculate the 3 years?

There is probably a 1Hz write somewhere.

Yes they were probably all FAT32. Nowadays I use NTFS.

[Postal2]

... 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.

[peter-h]

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.

[Postal2]

... 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.

[Jeroen3]

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.

[peter-h]

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.