Web updates with Win 10 64-bit

[NewsArchive]

Friedrich,

My clients have upgraded to Win 10. I published an update that
wupdate.exe should detect and then run. Works fine here (32-bit). But
one of my clients reports that he had to go into Program Files (64-bit
version) and launch it there to get it to work. That is the default
install location (%PROGRAMFILESDIR%\[PRODUCTNAME]).

The installer has not changed, the program is launched AsInvoker at the
end of the install, shortcut from the desktop after that.

The program always silently checks for a new update when launched or
when a menu item run (same code actually).

Is there anything about 64-bit ProgramFiles location where this could fail?
--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Hi Russ,

It only goes into the "Program Files" folder on x64 [instead of "Program
Files (x86)"] if the installer is running in 64-bit mode. But a 32-bit
application should *always* go into the 32-bit Program Files folder. So the
question is, why is his 32-bit application under the 64-bit folder? Not
allowed. Did he manually move it to that location? The uninstall .log can
give us the answer ;-)

Friedrich

[NewsArchive]

No, it goes into the 32 bit version (x86).

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> No, it goes into the 32 bit version (x86).

Hmmm, but you said "...he had to go into Program Files (64-bit version) and
launch it there to get it to work...". Why is it in Program Files (64-bit
version)?

Friedrich

[NewsArchive]

Sorry, I misspoke. I meant it was installed on Win 10 64-bit.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

> Sorry, I misspoke. I meant it was installed on Win 10 64-bit.

Aha, okay. If "wupdate.exe" and/or "wucheck.exe" go into the correct 32-bit
Program Files folder on his 64-bit Windows 10 machine and it does not work
then his protection software blocks the client. There is no difference to
previous Windows versions.

BTW, make sure that your installer type is set to "Windows 32-bit" and not
"32/64-bit (Hybrid)" !!!

Friedrich

[NewsArchive]

I've never turned this on. Only change I made to this install was where
the files for the installation reside (since this solution is Clarion
10). I'll check his protection software.

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Hi Russ,

> I've never turned this on. Only change I made to this install was where
> the files for the installation reside (since this solution is Clarion 10).
> I'll check his protection software.

Okay, if it worked fine on previous 64-bit Windows 8.x, Windows 7.x and
Vista versions and you did not change the deployment strategy (and target
locations) then it's definitely caused by his protection software.

Friedrich

[NewsArchive]

BTW, and make sure that you call wupdate.exe correctly. I am not sure if
your application uses different "Run" methods for 32-bit and 64-bit Windows.
For example, the CreateProcess API will always fail if a non-elevated
application (your app) attempts to launch another application whose manifest
requires elevation (wupdate.exe). GetLastError will return 740
(ERROR_ELEVATION_REQUIRED) in this case. If your application runs
non-elevated and you use CreateProcess to start wupdate.exe then this will
fail. Of course, wucheck.exe (asInvoker manifested) will work fine.

Check the return value for the wupdate.exe calling process and this should
give us more information.

Friedrich

[NewsArchive]

Hi Friedrich,

> (ERROR_ELEVATION_REQUIRED) in this case. If your application runs
> non-elevated and you use CreateProcess to start wupdate.exe then this will
> fail. Of course, wucheck.exe (asInvoker manifested) will work fine.

Which is why I use ShellExecuteEx to run just about anything;) Doesn't
give as much control as CreateProcess, but has no problems with running
elevated programs:)

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

RUN('wucheck.exe /S /C', 1)
IF RUNCODE() = 1
MESSAGE('Update available!||NOTE: APP WILL BE CLOSED.||Click OK to
download and install...', 'Auto Updater', ICON:Exclamation)
RUN('wupdate.exe')
CleanCloseDown()
END

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Russ,

In previous Clarion versions RUN() was a wrapper around the CreateProcess
API. IIRC, this changed in Clarion 9. Don't know if there was any change
in Clarion 10. But I would suggest to use a fully qualified pathname (who
knows what the current folder is <g>). '"<PATH>\wucheck.exe"' instead of
'wucheck.exe'.

What does RUN return? Perhaps your app ("asInvoker" manifested and running
non-elevated) never starts wupdate.exe!? Does he see an elevation prompt?
If not, then your app does not start wupdate.exe at all.

Friedrich

[NewsArchive]

Food for thought, thanks. I'll see what becomes of his protection
software first. But I've added a little bit of code to get the current
path; then we've got the bases covered.

--

Russ Eggen
RADFusion International, LLC