<html>
<head>
<base href="http://bugzilla.wpkg.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Intermittent problem Uninstall not found in System Context"
href="http://bugzilla.wpkg.org/show_bug.cgi?id=287#c10">Comment # 10</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Intermittent problem Uninstall not found in System Context"
href="http://bugzilla.wpkg.org/show_bug.cgi?id=287">bug 287</a>
from <span class="vcard"><a class="email" href="mailto:r.meier@wpkg.org" title="Rainer Meier <r.meier@wpkg.org>"> <span class="fn">Rainer Meier</span></a>
</span></b>
<pre><span class="quote">> So in order to stop this chain I can use %windir%\SysWOW64\cscript.exe /b
> /nologo \\DOMAIN\wpkg\wrapper.js which will then choose the proper mode in
> which to launch wpkg.js and will override the architecture it was launched
> in and just pick the correct version.
>
> Is this correct?</span >
NO. This is NOT correct.
Launching %windir%\SysWOW64\cscript.exe will forcybly launch the 32-bit
version. Remember: SysWoW64 always contains 32-bit binaries!
So you need to launch %windir%\system32\cscript.exe. But Remember this will
ONLY work if your launching process is a 64-bit process as if the launcher is
32-bit it will get redirected from system32 to syswow64 which will trigger the
32-bit version again.
You can try this by launching syswow64\cmd.exe. Then "cd" into
c:\windows\system32 and you will be redirected to c:\windows\syswow64. There is
no way for 32-bit applications to access the real system32 folder with 64-bit
binaries in it as the folder is invisible and redirected to syswow64 for 32-bit
programs.
The only way to launch a 64-bit binary from the real system32 folder is to open
it via sysnative folder. So if you're inside a 32-bit program and want to
launch something from the real system32 folder you need to launch
%windir%\sysnative\cscript.exe.
<span class="quote">> That being said I'm a little curious as to why this actually doesn't work
> when running 32bit cscript? When I dug into the wpkg.js a little bit to try
> troubleshooting it looks as if the uninstall check uses the
> scanUninstallKeys function which is suppose to determine which registry hive
> it's searching through. This check relies on a function called is64bit()
> which is then reliant on getArchitecture which should be looking at the
> processor_architecture. </span >
Remember that wpkg.js runs inside some interpreter "virtual machine". If this
interpreter is 32-bit there is no way for the script (wpkg.js) to access any
64-bit resources. Even if the detection is able to detect that the CPU
architecture and even OS architecture is 64-bit the 32-bit cscript.exe runtime
will suffer from the same forced redirection as any 32-bit process. So
accessing the 64-bit registry keys or system32 folder you will be redirected to
the corresponding 32-bit folders!
So when you access HKLM uninstall keys (64-bit) you will be redirected to
32-bit keys and you won't see anything in there except 32-bit applications.
The same applies for %ProgramFiles% and %ProgramFiles(x86)% with some slight
differences in access redirection.
So again, you NEED TO MAKE SURE TO RUN wpkg.js WITHIN 64-bit cscript.exe!
Else it won't be able to access any 64-bit resources. This is intentional and
by design (Microsoft). Blame microsoft for the complex redirection issues which
already caused a lot of confusion. Just remember that any 32-bit appliction
will not see the real contents here and there but being redirected to 32-bit
equivalents. This actually hides 64-bit structures from 32-bit applications
entirely. So There is nothing WPKG can do to access those resources.
If you'reunsure then change the script to launch wrapper.js rather than wpkg.js
directly. wrapper.js will ensure to launch wpkg.js in 64-bit cscript.exe even
if wrapper.js itself is launched from 32-bit cscript.exe.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>