Products > Programming

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

(1/18) > >>

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:

--- Quote ---The WPARAM is zero-extended, while LPARAM and LRESULT are sign-extended.
--- End quote ---

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:

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

--- End quote ---

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.


--- Quote ---they are truncated or zero/sign-extended, so it's 100% deterministic.
--- End quote ---

I would have hoped so!


--- Quote ---Just replace the HDD and continue running on XP?
--- End quote ---

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:

--- Quote from: peter-h on October 02, 2024, 06:56:42 am ---... custom win32 GUI app (written in MS VC++) is sending messages to another win32 GUI app ...

--- End quote ---
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

Navigation

[0] Message Index

[#] Next page