[wpkg-users] [Bug 93] 64-bit OS support announcement

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=93





--- Comment #4 from Rainer Meier <skybeam at users.sourceforge.net>  2007-12-15 16:54:28 ---
Hi Tomasz,

You're right but this is exactly what I introduced here.
The main problem is that HKLM\Software is re-directed to a "virtual store" for
32-bit apps (which is accessible for 64-bit applications at
HKLM\Software\Wow6432Node). So I added a functionality that lookups to
HKLM\Software\* will be first queried at HKLM\Software\* directly and if not
found it will look up the key at HKLM\Software\Wow6432Node. This makes 32-bit
keys transparently available for 64-bit applications at well.

However as I wrote this requires invoking 64-bit cscript since 32-bit cscript
hides access to 64-bit keys. So it's absolutely crucial for WPKG to be run by
64-bit cscript.

The problem is that WPKG client (32-bit) invokes the script and runs
%SystemRoot%\system32\cscript.exe. For 32-bit applications this folder is
redirected to %SysremRoot%\SysWOW64 which actually contains the 32-bit
cscript.exe.

Note that WPKG client cannot invoke the 64-bit binary from the "real"
%SystemRoot%\system32 since for 32-bit applications it is simply not
accessible. A work-around is to copy the 64-bit cscript.exe to another folder
which is accessible by WPKG client. However I did not like this approach since
cscript is subject to change (updates). I decided to copy cmd.exe (64-bit)
instead. Since cmd.exe is a 64-bit application then it can access the real
64-bit content at %SystemRoot%\system32. So I just use:
path\to\64-bit\cmd.exe /c cscript path\to\wpkg.js
This will run WPKG in 64-bit mode where I can access all the keys.

Again, run by WPKG client in 32-bit mode WPKG has no chance to read the 64-bit
keys and therefore all registry checks (especially uninstall string checks) are
not working for native 64-bit applications. For example You cannot check if
TortoiseSVN-64 or Java Runtime AMD64 is installed since their keys are stored
within the 64-bit-only part of the registry.


To clarify it again.When WPKG is run by 64-bit cscript it is possible to access
both (32-bit and 64-bit keys and files).
If WPKG is run by 32-bit cscript then we can perfectly access 32-bit
application information (registry and files) but there is no chance to read any
64-bit information since it's completely hidden by Windows.

Therefore it's crucial that WPKG is run by 64-bit cscript. My wrapper requires
doing a copy of cmd.exe. Somebody could also write a wrapper in
C/C++/C#/whatever. It just needs to be a 64-bit application which has access
tothe 64-bit cscript.exe to launch it. WPKG client cannot do this currently
since the "real" %SystemRoot%\system32 folder is not accessible for WPKG
client.

I hope that clarifies it.

Small "side-node" my new version still perfectly works when directly invoked
(without wrapper.js) but of course it will run as 32-bit application and cannot
access 64-bit uninstall keys as well as 64-bit files.
Moreover the wrapper was written in a way that it can be used on 64-bit and
32-bit Windows versions. So it's absolutely safe to use it for all clients. It
will simply invoke the copied 64-bit cmd.exe on 64-bit systems or run the local
cmd.exe on 32-bit systems.



I know all this redirecting, mounting, hiding and obfuscating by Microsoft is
REALLY pain in the ass but we have to deal with it. So I just did an
enhancement which CAN do it while still keeping exactly the same functionality
on 32-bit systems.

My request is simply to get rid of my "hack" (wrapper.js) and allow WPKG client
to directly invoke 64-bit cscript. To do so we will need a 64-bit version of
WPKG client (or at least the part which is invoking wpkg.js).

If anything is still not clear please do not hesitate to ask here.


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.