Windows inter-app messaging and 32 bit apps under win7-64 - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 06:56:42 am
content: 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 XPalwaysdestroys 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 hecanstill rebuild) it may be due to thishttps://devblogs.microsoft.com/oldnewthing/20110629-00/?p=10303It 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 02, 2024, 07:16:25 am
content: It's not undefined behavior, it says right there:QuoteBut, can't you run it in a 32-bit VM?

author: magic
author_rank: Super Contributor
timestamp: October 02, 2024, 07:20:22 am
content: 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?

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 07:23:34 am
content: QuoteYes 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.QuoteI would have hoped so!QuoteI 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 07:26:14 am
content: Quote from: peter-h on October 02, 2024, 06:56:42 amIf 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 02, 2024, 07:26:26 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 07:35:22 am
content: 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?

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 07:45:09 am
content: Quote from: SiliconWizard on October 02, 2024, 07:26:26 amYour 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 08:07:49 am
content: Postal2, are you real, or chatgpt?QuoteI 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 08:14:25 am
content: Quote from: peter-h on October 02, 2024, 08:07:49 ampeter-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.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 02, 2024, 08:33:20 am
content: Quote from: peter-h on October 02, 2024, 07:23:34 amIs 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

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 09:02:01 am
content: 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 thewindows 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 SSD2) 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 VM3) Rebuild the win7-64 machine to win7-32 and hope that magically fixes this messaging issueIt 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.QuoteSo 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).

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 11:00:54 am
content: Quote from: peter-h on October 02, 2024, 09:02:01 amThe 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.

author: magic
author_rank: Super Contributor
timestamp: October 02, 2024, 11:03:41 am
content: 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.)

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 11:10:53 am
content: QuoteHow is that doable, short of win7-32 native, or a win7-32 or winXP VM running in the win7-64 system?QuoteI 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 descriptionhttps://stackoverflow.com/questions/11285928/detecting-a-modal-dialog-box-of-another-processWhat about rebuilding the "control" app to be a 64 bit one? Would that help with the messaging?

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 11:22:51 am
content: Quote from: peter-h on October 02, 2024, 11:10:53 amThis is possible in the same way as Windows x64 handles x32 dlls within one process - all handles will be valid.Quote from: peter-h on October 02, 2024, 11:10:53 amYes, 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 11:42:47 am
content: QuoteOK 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.QuoteVarious 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 02, 2024, 11:44:52 am
content: Quote from: peter-h on October 02, 2024, 09:02:01 amIt 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 11:57:26 am
content: Quote from: peter-h on October 02, 2024, 11:42:47 amIt's strange that your colleague didn't suggest this to you himself.Quote from: peter-h on October 02, 2024, 11:42:47 amThen it turns out that an SSD formatted in fat32 will work for at least 3 years.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 12:11:08 pm
content: How did you calculate the 3 years?There is probably a 1Hz write somewhere.Yes they were probably all FAT32. Nowadays I use NTFS.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 12:19:42 pm
content: Quote from: peter-h on October 02, 2024, 12:11:08 pmI 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 01:32:22 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 02:14:44 pm
content: Quote from: peter-h on October 02, 2024, 01:32:22 pmThat's true. But you can't control how well it works until the disc breaks.Quote from: peter-h on October 02, 2024, 01:32:22 pmI'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.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 02, 2024, 02:15:05 pm
content: Without TRIM the firmware in the ssd controller runs out of it spare empty blocks and performance plummets.You have towaitfor 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 02:39:57 pm
content: QuoteOK; 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 SSDitselfcannot 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.

author: Jeroen3
author_rank: Super Contributor
timestamp: October 02, 2024, 02:51:40 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 02:59:08 pm
content: Quote from: peter-h on October 02, 2024, 02:39:57 pmBuy a refurbished hdd cheap and don't bother.https://aliexpress.com/item/1005002617399974.html

author: edavid
author_rank: Super Contributor
timestamp: October 02, 2024, 03:28:57 pm
content: Quote from: peter-h on October 02, 2024, 06:56:42 am1. 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 03:36:23 pm
content: 1. Interesting2. 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 update3. I get that now - thanks4. No5. Not sure; have now found the registry changes for stopping that

author: edavid
author_rank: Super Contributor
timestamp: October 02, 2024, 03:40:12 pm
content: Why were you using FAT32 instead of NTFS?

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 03:41:36 pm
content: Probably was.

author: magic
author_rank: Super Contributor
timestamp: October 02, 2024, 04:09:26 pm
content: Actually, did you check SMART to verify it was a hardware issue and not plain old data corruption?

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 04:15:56 pm
content: No idea what that is

author: magic
author_rank: Super Contributor
timestamp: October 02, 2024, 04:38:39 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 05:00:30 pm
content: I have such a utility (Samsung Magician) for my PCBut you can't run it if the machine does not boot

author: edavid
author_rank: Super Contributor
timestamp: October 02, 2024, 05:06:45 pm
content: Quote from: peter-h on October 02, 2024, 05:00:30 pmThen 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

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 05:17:10 pm
content: 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?

author: edavid
author_rank: Super Contributor
timestamp: October 02, 2024, 05:29:45 pm
content: I usually use the free version of AOMEI Partition Assistant:https://www.aomeitech.com/pa/standard.htmlThe GParted CD I just linked will also do it, but is less user friendly.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 05:59:30 pm
content: Quote from: peter-h on October 02, 2024, 05:17:10 pmIsn'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.Quote from: edavid on October 02, 2024, 05:29:45 pmWhat does this stupid utility have to do with partitioning SSDs into SLC/MLC/TLC zones?

author: edavid
author_rank: Super Contributor
timestamp: October 02, 2024, 06:04:20 pm
content: The SLC thing is a red herring. There is no evidence that the Win XP issue was SSD endurance.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 02, 2024, 06:21:15 pm
content: Quote from: edavid on October 02, 2024, 06:04:20 pmI 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 02, 2024, 07:32:23 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: October 02, 2024, 10:21:36 pm
content: 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.

author: thm_w
author_rank: Super Contributor
timestamp: October 02, 2024, 11:45:07 pm
content: XP works fine with SSDshttps://www.reddit.com/r/windowsxp/comments/x16gjk/yes_you_can_use_an_ssd_drive_with_windows_xp_hear/

author: Jeroen3
author_rank: Super Contributor
timestamp: October 03, 2024, 05:50:38 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 03, 2024, 05:53:11 am
content: Quote from: peter-h on October 02, 2024, 09:02:01 amQuote from: peter-h on October 02, 2024, 05:17:10 pmVery 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?

author: peter-h
author_rank: Super Contributor
timestamp: October 03, 2024, 06:47:07 am
content: 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...QuoteThat is the only one available if you cannot recompile one of the apps.QuoteIt does... but see discussion above.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 03, 2024, 07:05:14 am
content: Quote from: peter-h on October 03, 2024, 06:47:07 amI will simplify your impossible task.

author: nctnico
author_rank: Super Contributor
timestamp: October 03, 2024, 09:59:08 pm
content: Quote from: Postal2 on October 02, 2024, 02:14:44 pmAFAIK 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.

author: thm_w
author_rank: Super Contributor
timestamp: October 03, 2024, 10:32:16 pm
content: Quote from: nctnico on October 03, 2024, 09:59:08 pmAll of this was explained in the link above.- Align partitions- Disable swap file - optional- Disable defrag - optional- Disable last access timestamp - optional

author: peter-h
author_rank: Super Contributor
timestamp: October 04, 2024, 06:10:17 am
content: QuoteThat 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 wheneveryFLASH 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 11:08:15 am
content: 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...

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 12:39:34 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: October 10, 2024, 01:14:38 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 01:23:11 pm
content: Quote from: radiolistener on October 10, 2024, 01:14:38 pmI'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.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 01:27:59 pm
content: QuoteObviously 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 messagestothe 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 01:36:54 pm
content: Quote from: peter-h on October 10, 2024, 01:27:59 pmYou 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 01:37:57 pm
content: 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 onlyThey are called "automation apps" and you can train them by clicking on stuff and they store the mouse clicks etc.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 01:45:20 pm
content: Quote from: peter-h on October 10, 2024, 01:37:57 pmThis means that 32-bit methods are used for searching and identification. The program needs to be rewritten for 64 bits normally.Quote from: peter-h on October 10, 2024, 01:27:59 pmI 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 01:52:03 pm
content: OK, there is another little problemThe 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 01:59:47 pm
content: Quote from: peter-h on October 10, 2024, 01:52:03 pmBecause it does CloseHandle(32 bit).Quote from: peter-h on October 10, 2024, 01:52:03 pmWindows 64 somehow knows how to handle this for one process, otherwise any 32-bit program would leak memory.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 02:06:01 pm
content: No; that app always leaks memoryNo 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 02:13:16 pm
content: Quote from: peter-h on October 10, 2024, 02:06:01 pmAnd 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 02:21:39 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 10, 2024, 02:34:47 pm
content: Quote from: peter-h on October 10, 2024, 02:21:39 pmIf 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).

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 03:14:31 pm
content: 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...

author: radiolistener
author_rank: Super Contributor
timestamp: October 12, 2024, 01:45:10 am
content: I recommend you to rewrite this app on Linux

author: peter-h
author_rank: Super Contributor
timestamp: October 14, 2024, 08:44:10 am
content: 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 objectscanbe 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 thishttps://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

author: Postal2
author_rank: Frequent Contributor
timestamp: October 14, 2024, 01:55:04 pm
content: Quote from: peter-h on October 14, 2024, 08:44:10 amNow 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 14, 2024, 02:59:51 pm
content: QuoteWhy, and how?

author: Postal2
author_rank: Frequent Contributor
timestamp: October 14, 2024, 03:21:32 pm
content: Quote from: peter-h on October 14, 2024, 02:59:51 pmSomething inside Windows starts working correctly.Quote from: peter-h on October 14, 2024, 02:59:51 pmSetWindowPos(yourWindowHwnd, HWND_TOP, 0,0,0,0, SWP_NOMOVE | SWP_NOSIZE);

author: peter-h
author_rank: Super Contributor
timestamp: October 15, 2024, 07:15:02 am
content: Should one do the above on the 904C8 window?The 50574 window is apparently invisible to the control app.

author: digger
author_rank: Regular Contributor
timestamp: October 15, 2024, 10:03:39 am
content: Quote from: peter-h on October 02, 2024, 07:23:34 amthis 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?Quote from: peter-h on October 02, 2024, 09:02:01 amor yeah, maybe even better. why not try that? not exactly a difficult or time consuming experiment.

author: peter-h
author_rank: Super Contributor
timestamp: October 15, 2024, 12:47:01 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 15, 2024, 02:33:24 pm
content: Quote from: peter-h on October 15, 2024, 07:15:02 amI 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 19, 2024, 07:57:39 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 19, 2024, 05:49:42 pm
content: Quote from: peter-h on October 19, 2024, 07:57:39 amI 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 19, 2024, 08:32:57 pm
content: It wasn't clear to which object that hack should be applied.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 19, 2024, 09:07:18 pm
content: 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).

author: mariush
author_rank: Super Contributor
timestamp: October 19, 2024, 09:44:22 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 20, 2024, 08:12:45 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 20, 2024, 09:38:16 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 21, 2024, 07:23:10 am
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: October 21, 2024, 08:36:03 am
content: Quote from: peter-h on October 21, 2024, 07:23:10 amWhat 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.

author: peter-h
author_rank: Super Contributor
timestamp: October 21, 2024, 04:28:51 pm
content: 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!

author: Postal2
author_rank: Frequent Contributor
timestamp: October 21, 2024, 07:13:08 pm
content: Quote from: peter-h on October 21, 2024, 04:28:51 pmYou 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).Quote from: peter-h on October 21, 2024, 04:28:51 pmNo 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.

author: peter-h
author_rank: Super Contributor
timestamp: January 10, 2025, 04:22:34 pm
content: A late update on this, in case anybody finds it in 100 years' timeDespite the deluge of ChatGPS-like posts above, this was not solved, due to lack of time. Obviously itcanbe solved because e.g. Winspycansee the messages, and it is available in source form.I have moved to setting up XP under VMWARE, as a guest VM, in the win7-64 host. Obviously this works. I have a pile of XP VMs, ready to run.What I have so far not been able to do is restore an Trueimage backup of the current working winXP machine, to XP under VMWARE. The reason is not obvious because I can install Trueimage in that XP VM and do a restore of the .tib file. The restored XP doesn't start up. Initially it starts Windows (the GUI screen) and then says Windows was not powered down properly and offers the usual Safe Mode options, but none of them work. I can obviously solve it by configuring a working XP VM, but there is a fair bit of detail and restoring that backup into the VM would save a lot of time.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 10, 2025, 08:40:40 pm
content: Quote from: peter-h on January 10, 2025, 04:22:34 pmAll the time is spent fighting angry toothbrushes, I saw your topic.Quote from: peter-h on January 10, 2025, 04:22:34 pmI'm not surprised. That's why I suggested going back to the original state with a normally working Windows XP. All your statements about it ruining the SSD are exactly "ChatGPS-like posts".

author: peter-h
author_rank: Super Contributor
timestamp: January 10, 2025, 08:43:38 pm
content: Restoring the backup image to the SSD directly doesn't boot either. Must be a device driver that crashes... but even safe mode bombs.

author: Postal2
author_rank: Frequent Contributor
timestamp: January 10, 2025, 08:56:17 pm
content: Quote from: peter-h on January 10, 2025, 08:43:38 pmIt is too late to offer you my cloning program, which I use myself, because you solved the problem with your own mind and naturally ruined everything. Then install Windows XP from scratch, since you have programs for it separately.Then install some cheap controller that allows you to create RAID, which duplicate disks, and you can replace cheap SSDs quickly.This way you will free up time and those shameless toothbrushes will finally be defeated.