Problem on 64bit OS

[midiboy]

Hi!

I today finally found the reason why my 64bit OS checks in a cmd never worked during an unattended installation while they work fine if I test them manually.

Here´s what I am doing:

I have this check somewhere in a cmd:

if /I %PROCESSOR_ARCHITECTURE% EQU AMD64 goto Vista64

This works fine if I manually start the cmd on a 32 bit or 64 bit OS.

Now, if WPI starts the cmd on a 32 bit Windows, it still works fine, but if WPI starts the cmd on a 64 bit Vista, then you can see the result in the screenshot below.

WPI starts the 32 bit cmd.exe in the sysWOW64 directory and this cmd.exe will echo x86 as a result to the above command, making the script fail because the wrong files are executed.

Now, I realize this may not be a bug but a feature since WPI is a 32 bit app, it may not be possible for it to see or start the 64 bit cmd.exe (Don´t know about that but it would be a logical explanation).

My question is:

Is there any other way to solve that problem, meaning, have a command check for the version of the OS regardless of the bit level of the cmd running the script ? Or can WPI be changed so that it uses the 64 bit cmd.exe on a 64 bit OS automatically ?

Any ideas would be most welcome !

Thanks for your help !

Alex

Edited May 3, 2008 by midiboy

[midiboy]

Hi again,

just found this:

How to detect process bitness

Seems like one has to use this command:

IF /i %PROCESSOR_ARCHITECTURE% == AMD64 goto Vista64 
IF DEFINED PROCESSOR_ARCHITEW6432 goto Vista64

edit:

Had to change the code around a number of times because it didn´t work in all situations. There are: 32bit OS, 64bit OS and 64bit OS with 32bit cmd.exe (WOW). Anyway works now !

Edited May 4, 2008 by midiboy

[mritter]

I have started a list of registry checks that will be added for 6.5 release. I will also be adding to the properties page to show more computer info: brand, bit, mhz, etc.

With these new checks I will make it so it uses the correct cmd version.

[cluberti]

WPI starts the 32 bit cmd.exe in the sysWOW64 directory and this cmd.exe will echo x86 as a result to the above command, making the script fail because the wrong files are executed.

Now, I realize this may not be a bug but a feature since WPI is a 32 bit app, it may not be possible for it to see or start the 64 bit cmd.exe (Don´t know about that but it would be a logical explanation).

Quite astute, as CreateProcess on an x64 OS from a 32bit app will create a 32bit process (in this case, a 32bit cmd prompt) that will have precisely this problem. However, and mritter may already be aware of this, but if the app was compiled to use the Wow64DisableWow64FsRedirection API, this would cause any CreateProcess calls made from the 32bit app after this API was called to start as 64bit processes.

You could, as a workaround, use a vbscript instead of a cmd to do your work and use WMI calls to Win32_Processor to determine the processor in the system as well (although it looks like you already have a viable solution).

[midiboy]

Hi guys,

thanks for the infos !

@cluberti: I am not very good with vbs so I will stay with cmd for the time being but thanks for the info!

@mritter: Thanks, looking forward to the new version !

Bye,

Alex

[midiboy]

Hi guys,

I have run into another problem with this 64/32bit thing from within WPI.

I need to add registry values to the HKLM\Software node in the registry using WPI. The command would be

REG ADD HKLM\SOFTWARE\MyAPP /V Test /D "start.cmd" /f

Now, on a 32 bit system this is no Problem obviously, but on a 64bit system this seems to be impossible using WPI because whatever I do, those values always get redirected to HKLM\Software\Wow6432Node\MyAPP.

Since this app is a 64bit app, it won´t see the values in there an cause problems.

I have tried to work around this by doing this in config.js

pn=1;
prog[pn]=['MyAPP'];
ordr[pn]=[11];
uid[pn]=['MYAPP'];
dflt[pn]=['yes'];
cat[pn]=['Utilities'];
forc[pn]=['no'];
cmd1[pn]=['"%windir%\\system32\\cmd.exe" /C %root%\\test.cmd'];
pn++;

where test.cmd has the reg add commands. The theory behind this is that calling the 64bit cmd.exe directly from WPI would maybe add the reg entries to the correct location in the registry. But this did not work either, they still get written to the Wow6432Node subnode.

Calling this test.cmd directly on a 64bit system works fine so it seems that even if a 32 bit app calls the 64bit cmd.exe, registry values will be written to the Wow6432Node node. Only if a 64bit app is started directly, will those entries be written to the HLKM\Software node.

Is there any workaround for this behaviour ? Any way I can add registry values to the HKLM\Software node with WPI today ?

I hope someone can help !

Thanks,

Alex

[midiboy]

Hi again,

actually, it seems like the problem is that even if you start

%windir%\system32\cmd.exe

from WPI, this will be redirected to the 32bit cmd.exe from within SysWOW64. So the problem is that there does not seem to be a way to start the 64bit cmd.exe from within WPI ?

Any way around this ?

Thanks,

Alex

[midiboy]

No ideas ?

:-(

Still hoping ....

Thanks !

Alex

[cluberti]

If you're in a 32bit process, and attempt to run an app, you will get the 32bit version of the app. There's no way around it without disabling redirection in code.

Wait for the 6.5 version, as one of the stated features is using the 64bit binaries on an x64 system.

[midiboy]

Hi cluberti,

thanks for the info. Any idea when this 6.5 will be released ?

There is no way to disable redirection with a cmd or vb script ? (a sample would be nice if it is possible for you!)

Thanks,

Alex

[Kelsenellenelvian]

We are planning it for this weekend!!

[mritter]

But 64bit checks will not be included. Sorry. Just haven't had the time yet. There are some bugs that we needed to get fixed, and a new Window feature, before anything else new got added.

I am planning, maybe, a Super Update to v7 next. I have a nice list started of new features that will satisfy everyone: updated installer, theme/style editor, registry tweaks (instead of nLite or doing it yourself), etc.

I will get ahold of you when I start the 64bit stuff. Seems like no diffinitive answer has been found yet. I have an AMD64, but not using WindowsXP64 so I can't really test it. That's where you will come in. You will have to be the tester.

[midiboy]

Hi guys,

thanks for the update on the development cicle. Of course I will gladly test this for you !

Since I would need those 64bit features badly I am once again asking if there is a workaround of some sorts. Maybe some vb code to turn of redirection and start a 64 bit cmd.exe and add reg entries using that cmd.exe ? If there isn´t I am out of luck but maybe there is.

My current workaround is to write reg values into a cmd on disc during installation in WPI and have those cmds executed later on after WPI finished from a 64 bit cmd.exe. However I am having a problem with variable expansion that I wasn´t able to solve yet. Maybe you have an idea here ? This is what I am doing:

1.

Write reg values to disc:

ECHO REG ADD HKLM\SOFTWARE\MyAPP /V Test /D "start.cmd" /f  > "C:\install_1.cmd"
ECHO exit >> "C:\install_1.cmd"

2. Have the following code pick those cmds up in setupcomplete.cmd during next startup:

SET KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx
REG ADD %KEY%\141 /VE /D "Install missing features" /f
REG ADD %KEY%\141 /V 1 /D "CMD /C for %%i in (C:\install_*.cmd) do start \"\" /wait %%i" /f

Now, this currently does NOT WORK because the first "%" in the cmd above gets removed after execution. So the resulting code in the registry is like this:

CMD /C for %i in (C:\install_*.cmd) do start "" /wait %i

This won´t work because there is one "%" missing. At least I am getting an error message when this gets executed. I then tried adding 3 %s to the cmd but this caused even worse problems. I also tried the "setlocal ENABLEDELAYEDEXPANSION" command in the cmd. For some reason it does nothing.

This is the only thing that keeps me from successfully circumventing the problem right now so if someone has an idea ... ;-)

Thanks,

Alex

[hukiller]

Vista x86/x64 I don't how to extract file any place, I don't copy to PROGRAMFILES!!!!!!