mritter

That is the bug I fixed. It has nothing to do with that particular code, but in a totally different location. It has been fixed for a while now and will be in the next release. Not sure when that will be......keep adding new stuff like it was going out of style. If you want to test it send me a message. I do want to make sure this is fixed for network shares.

I built in a new function: isInstalled() with the above code. Thank you, crahak! isInstalled("Adobe Reader 8.1.2") returns true or false As said above: it can be slow. It took 6 seconds to search my install list of 40 programs. Checking the registry would be much better, but, it's here now.

There is now a function call for Cond/GCond to check for existence of internet connection: ConnectedToInternet() returns true or false

There will be! Good idea. Will write the code tonight and will be in next version.

I am not familiar with WMI. Do you have an example script you can send me? Maybe I can build it in to WPI and make it a call like: IsProgramInstalled("Adobe Acrobat 8.0")

The bug has been fixed. I hope you saw that in other posts. You may also want to try the full path: ExecutePath=W:\Windows\System32\mshta.exe C:\WPI\WPI.hta just to see if that is needed.

First: midiboy, fixed the bug with cddrv = WshShell.RegRead("HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Setup\\SourcePath") + "\\"; Now does a proper Vista check as suggested a month ago. I never updated the code. My bad. Second: I, too, agree with zorphnog that the code for finding cddrv (%cdrom%) sucks. Right now it does 3 checks for CD, only the first is really reliable. So, take out other 2? (core.js) Then, when you have a %cdrom%\\blah.exe in a your config, if WPI was not started from a CD/DVD cddrv is blank. Install fails. What about: if (cddrv=="") cddrv=wpipath; This will at least give it a better chance in working. Yes? No? Keep it as is?

Alex, Re-read your last email...I see why you want to launch a 64 bit program on 32 bit system: Installer may have both 32 and 64 versions in one package. I think the final "decision" will be how to 100% determine the OS bits, not taking mshta into account.

Alex, I understand your needs, but I think what you want is not possible. If the checkbox is checked then this program, and all it's sub-commands and reg calls, are 64 bit. WPI will use the 64 bit versions of cmd and regedit. WPI will check if it is run on a 64 bit OS, not caring what mshta was used (will take some extra testing on my part). If the OS is 64 bit, use 64 bit commands in System32 folder, not SysWOW64 folder. Now, if the OS is 32 bits, and the checkbox is checked, this program should be skipped. WPI will do it internally. Still do a Cond/GCond to hide them. I can have it add this automatically when check the checkbox. So, I don't see why you want to still be able to launch a 64 bit program or script on a 32 bit system.

Could point on regkey. Will stick my processor check method. I have been talking with a few people and the easiest way we have come up with to tell WPI when to use 64 or 32 bit cmd/regedit is to add a checkbox to the Config wizard: [ ] This program is 64 bits. If checked, use 64bit commands, else 32 bit comands. This will be saved with each entry in config.js. The default is unchecked, so will NOT affect anyone's current config file. The new lines will be added the first time you re-save with the new version of WPI. This seems to be the easiest, most full-proof, simplest method. Will be very easy to implement and 100% backwards compatible. This will also be good because if WPI was launched with 32bit mshta on a 64bit system, then the proper calls will still be made. I still recommend doing a Cond/GCond check to hide 64bit programs on 32bit systems. What do you think? Have a better idea? Post them here.

It's not just UAC, it was a bug on my part. It's fixed in next version. I will say: this is like the 5 topic started on this. Doesn't anyone read the forum, or just post complaints? Seems like whenever I post a topic for help, 200 people read it but only 1 or 2 will reply. Help is a two way street, people.

In XP, a simple window would pop up asking to run this program or not (.exe) much like UAC does in Vista. Thi reg key WPI set temporarily would by-pass the check so installs would not be interrupted. Kels told me that it is not necessary in Vista, that sources folder and UAC take care of it.

ras_dk, thanks! That is exactly what I needed to check for!

The reboot works fine for me, with the delay. Do you have "Restart delay" set to something other than 0? Obvious, I know, but you never know sometimes........Once the install process is done, it should open the shutdown window for X seconds, then reboot. Unchek "Do NOT load desktop" since that reboots immediately. That is a hard forced reboot. If you want, try this, too: installer.js if (!RestartType) cmdLine='shutdown.exe -r -f -t '+RestartSeconds+' -c "'+getText(ComputerWillRestart)+'"'; else cmdLine='shutdown.exe -s -f -t '+RestartSeconds+' -c "'+getText(ComputerWillShutdown)+'"'; change to if (!RestartType) cmdLine=sysdir+'\\shutdown.exe -r -f -t '+RestartSeconds+' -c "'+getText(ComputerWillRestart)+'"'; else cmdLine=sysdir+'\\shutdown.exe -s -f -t '+RestartSeconds+' -c "'+getText(ComputerWillShutdown)+'"'; That will make it the full command path C:\Windows\system32\shutdown.exe It shouldn't need it, but let me know if it helps.

In XP WPI sets a registry key "LowRiskFileTypes" which tells XP (Outlook, actually) what file types are not dangerous. Does Vista need this? From what I could tell it does. Someone verify this...?...?

Good on regedit. Here is where I got my basis for 64bit code: http://blogs.msdn.com/david.wang/archive/2...ss-Bitness.aspx I need to be able to tell via the registry. I can't launch those programs from WPI and check.

From what I have researched so far, the ARCHITEW6432 seems to be the defining variable for 64/32bit. I don't think there is a registry entry that says "this is 64bit windows", as far as I know. Something I will look in to. I just found out that the 64bit mshta.exe has to be associated with .hta files, then it might reflect AMD64 and 64bits. Else it says it's a 32bit system. I assume that because .hta files aren't programs, they are "web pages". ===== When I browse to Windows\Systems32 I only have regedt32.exe for 64bit. In Windows\SysWOW64 I have the regular regedit.exe AND regedt32.exe. I would think they would be the same, too, but don't seem to be. Unless it is an "alias" that Windows recognizes natively. Keep the info coming!

This is what I have come up with for paths: windir = "C:\Windows" (normally) var cmd64bit=windir+"\\system32\\cmd.exe"; var cmd32bit=windir+"\\syswow64\\cmd.exe"; var regedit64bit=windir+"\\system32\\regedt32.exe"; var regedit32bit=windir+"\\syswow64\\regedit.exe"; This look right? Of course it will be updated more, just getting the basics down.

I have been updating the installer the last few weeks and have come up with some new ideas and look for it. I want your opinion on them. Here is the current installer with the new breakdown of commands for each program: Here is what I propose to update to, with the new command breakdown as above: (use your imagination) The top line is the actual command line. The X's and checks will be gone by default but could still be used in place of Success and Failed. It's wider and taller, but I feel looks more "professional" and "up to date". The audio player would be on the same line as Pause and Abort buttons. The window is now scrollable. The top image is customizable. All the texts are customizable. Post your opinions!

I have Vista64 installed now and have started to do some checks for 32 or 64 bit systems. My results are confusing me: Architecture=x86 ARCHITEW6432=AMD64 Bits=32 ArchName=AuthenticAMD ArchNameString=AMD Athlon 64 Processor 3200+ ArchNameIdentifier=AMD64 Family 15 Model 4 Stepping 8 ComSpec=C:\Windows\system32\cmd.exe What I am trying to figure out is why it tells me I have an x86, not an x64, system running only 32bits, when it should be 64bits. ARCHITEW6432 tells me correctly that I have a 64bit system, so should I be going by that alone? If it not a 64bit system then this flag is UNDEFINED. What I also need to know is: cmd.exe for 32 bit = ????? cmd.exe for 64 bit = ????? regedit.exe for 32 bit = ????? regedit.exe for 64 bit = ???? What are the paths and filenames for the appropriate programs? I will be doing a check in the installer like: if (sysArch6432=="AMD64") { use 64 bit commands } else { use 32 bit commands } All input is welcome.

I just got Vista64 installed tonight and doing all the updates and such. I hope to be back up to speed in the next couple of days. I forgot how much work it can be to............I need to get my WPI back up to date!

I would try it and look in to it, but my main computer is a blank harddrive. Working on that as I type.......

I sent a bug fix to midiboy to test out, he never replied back; he is on vacation. The default paths were not being set properly and a bug Kel found that I fixed made it worse. I think I have corrected, I will send you a link to dowload the latest version.

I just installed Vista Home Premium today, first time using it. I am having a problem with WPI: It won't save any files WPI creates to %systemdrive% variable, such as: %systemdrive%\\history.js I do an alert() to check path, is C:\history.js as it should be. It just will not save it. This is happening with 3 files that try to save to this path. The config.js, useroptions.js and windowoptions.js save just fine; they are not in C: root. Any ideas? I know a few of you have posted comments about C:\rb_config.js not being saved. Is this a Vista thing because it works fine on XP. Is there a different path I should use for Vista?

I just ran into this problem last night. It is caused by something new in the last few releases because my older "Corpotate" version works fine. I found this because the installer was not setting the reg entry for this option if has to do a reboot. I am looking in to it. On the surface I see nothing that would be the culprit........probably some tiny little thing...always is.