[Solved] Application triggers message about unsupported 16-bit application

[JanRoza]

I have a 32-bit windows application that on startup checks via internet on my server a ini-file to see what is the latest version.
If an update is available the application asks the user if he wants to update and if so downloads the new program file 'application.xyz'.
It then closes itself and activates a second program that first renames the current application to 'application.old' and after that renames the downloaded 'application.xyz' to 'application.exe'.
After that the second program ends and starts the new application program again.
This has worked for years without any problems but since a couple of weeks the original program is still renamed correctly to 'application.old' but then an error message pops up complaining an unsupported 16-bit application, but my application is 32-bits.
(see attached screenshot)
I also see that the new exe-file is only half the size of the file on the server so I suspect Windows somehow interrups the download.
Does anyone know what has changed in Windows 11 and a solution for this problem?

[jamie]

Yes, you must of upgraded your OS from 32 to 64 bit?

That program must be written in an old version of windows, or you are using an un-supported API that originated in the 16 bit days and is now no longer back supported.

Jamie

[Bart]

This will not solve the problem, but maybe have a checksum available for the new download and check that before trying to rename the old an run the new one?
To me it looks like the download gets corrupted maybe blocked by some firewall rule or something like that.
At my work I cannot download an executable, no errormessage, it just gets silently downloaded to oblivion. If that is the case you may be able to trick the system by splitting up the executable.
I could trick the system by cutting of the "MZ" 2-byte header and then the rest op the DOS stub (so ending up with 3 parts). The firewall (or some other system that checks this) doesn't recognize it as an executable anymore.
Wrote a utility for that of course.
Then just re-assemble after download (used "copy/b part1 + part2 + part3 new.exe" for that).

Bart

[JanRoza]

Windows is 64-bit and the application is 32-bit, there is no 16-bit application involved.
It indeed has to do with Windows cutting short the download, so the result is a corrupted executable. Would it help if I put the new executable in an encrypted zip file an download that?
I fear that the problem will then arise at unzipping.
Is there another way to get a program update from a server?

[Bart]

At least you can try?
Just zipping (not encrypted) won't do probably (tried that myself).
If it's in you rcompany/work, you can talk to ICT to get your app and download on a whitelist?
(Tried that here: "only signed executables are allowed", so no...)

Bart

[dseligo]

Would it help if I put the new executable in an encrypted zip file an download that?

I do it like that and it works fine (and rest is same as you described: 32bit application, 64bit and 32bit Windows, ...). I also check checksum (as Bart suggested you do) before I unpack (or after? I am not sure now). I use 7zip.

[creaothceann]

Would it help if I put the new executable in an encrypted zip file an download that? I fear that the problem will then arise at unzipping.

Even if it works, it'd technically circumvent company policy. Some companies disallow updates because newer software may have unwanted / less features, or may be hijacked.

Is there another way to get a program update from a server?

Many programs just open a link to the software's download page.

[JanRoza]

If the software was for a company then I too would use a download page on a website but this is an application only use by some (eight) glider technicians to lookup or enter maintenance work they performed on a certain glider and to print reports.
I prefer a solution where the application automatically updates itself when an update is available after the user says it's OK to update, no extra work to be done by the technicians and this has worked this way for more than 15 years without a glitch and now our friends at Microsoft seem to block every way I try to get the update to the user. Encrypted zip does not work either, the moment the application wants to unzip the new version it's the end of the line. 
Anyone with an alternative way? Otherwise I have to revert to good old WeTransfer to send the update to my fellow technicians.   

[wp]

Does anyone know what has changed in Windows 11 and a solution for this problem?

I only know that Microsoft has put more and more effort into security (sometimes with dubious effects), in particular in Windows 11. Personally I would consider an application which downloads an exe with "innocent" extension from the internet, deletes an exe from the hard disk and renames the download to the deleted file to be extremely suspicious... Did you run a test when your Antivirus has been turned off?

[creaothceann]

Well, you could put the actual program logic into a script (doesn't even have to be downloaded as a stand-alone file) and let a local interpreter executable run it.

That interpreter would have to be updated very rarely.

[JanRoza]

A script is not a solution as when changes in regulations are published by goverment departments I still have to send updates for the script. 
As wp suggests I do one more test with virus protection turned of and if that test is negative I give up and use the oldfashioned WeTransfer until a better solution comes up.
Funny that Windows does not complain when I unzip the file manually with Peazip. 

[Bart]

he line. 
Anyone with an alternative way? Otherwise I have to revert to good old WeTransfer to send the update to my fellow technicians.   

Did you try my hack?
exesplit?

You split the exe on your side, zip the three parts and upload.
The program downloads the zip, extracts it's contents and either just calls cmd.exe/c copy/b ... or does the assembling itself.
Note: I did not try this at work with Win11 because it clearly circumvents company policy, and I'm already having enough troubles with ICT here as it is 

Bart

[jamie]

Well, I still think not all of the story is coming out here?

 You can have a 16-bit app run on a 32-bit OS, that works and many people still use 32-bit Windows, including me, and many of the industrial machines at work along with the LABS.

 However, if someone just decided to update their OS to Windows 11, of course it's going to be 64 bit and that 16-bit app is not going to run.

 But there is also the other possibility that some files got highjacked from the source or maybe a restore was done and older version files were put in their place.

 I think the best that can come out of this is to re-build that utility.

 I did notice that you are using CodeTyphon.

Jamie

[JanRoza]

@Jamie There is no 16-bit application, that is an error message from Windows that is definitely wrong as the whole application is 32-bit.
I still think that Windows half-way through the download kills the download so when after that kill my program tries to rename it (via RenameFile) then the incorrect Windows message appears.
If I have time this weekend I will try and give Bart's solution a try (now busy restoring a 1946 wing).

[PascalDragon]

@Jamie There is no 16-bit application, that is an error message from Windows that is definitely wrong as the whole application is 32-bit.

The thing is, every Windows executable, no matter if 32-bit or 64-bit, starts with a 16-bit stub. And if your downloaded/moved binary is corrupted/truncated in the right way Windows might think the executable to be 16-bit and thus show this popup since Windows 64-bit does not support 16-bit applications.