zorphnog

Yeah. It loads all the config stuff into arrays in memory.

Oh, I didn't know you were refering to a custom CDROM variable. Your way works fine, I just prefer to use my way because it is more dynamic (will work for CD/DVD, USB, network, etc...).

I have noticed a bit of a lag by running it on the network (30 seconds max), but not nearly as long as you're saying. I think it mainly comes down to network speeds and the number of config entries you have. As far as WPI only recognizing a set range of drive letters, I do not believe that holds any truth. I won't say for sure, but I have gone through much of the code and have seen no such limitation.

This is in direct correlation with the size of your config.js file. The more config items you have, the longer it takes to load. I'm not sure that there is much that can be done to speed up the process. I would say that it is a limitation of javascript, but thats just my two cents.

The reason you cannot use %CDROM% within your .cmd file is because it is a WPI variable, not a ms-dos variable. A quick fix to get around this would be to pass the CDROM or WPIPATH variable to the .cmd file: WPI config.js prog[pn]=['Audacity']; ordr[pn]=[17]; desc[pn]=['Create Music or Change File Extensions']; uid[pn]=['AUDACITY']; dflt[pn]=['no']; cat[pn]=['MultiMedia']; forc[pn]=['no']; cmd1[pn]=['%WPIPATH%\\APPS\\Audacity\\Audacity126.exe /SILENT /SP-']; cmd2[pn]=['%WPIPATH%\\APPS\\Audacity\\Audacity.cmd "%WPIPATH%"']; pn++; CMD file cmdow @ /HID @Echo Off MKDIR "%ALLUSERSPROFILE%\Start Menu\Programs\Audacity\" XCOPY /Q "%1\APPS\Audacity\lame_enc.dll" "%SYSTEMDRIVE%\Program Files\Audacity\" /Y XCOPY /Q "%ALLUSERSPROFILE%\Start Menu\Programs\Audacity.lnk" "%ALLUSERSPROFILE%\Start Menu\Programs\Audacity\" /Y DEL /Q /F "%ALLUSERSPROFILE%\Start Menu\Programs\Audacity.lnk" DEL /Q /F "%USERPROFILE%\Desktop\Audacity.lnk"

Nope. You gotta map it. Check out this topic.

After looking at it further, I misinformed you about execute after. The execute after executes before the registry is reset so that is why you got the same error. The only alternative I can think of is to reset the registry in a script so that WPI will not resume on reboot. You can reset the registry keys during your reboot script since you know that it will be the last configuration item to run. Here are the entries you need to modify: [HKEY_CURRENT_USER\Software\WPI] Set ResumeInstall = 0 Delete LastExec Delete CurrentInstall Delete LastTopLine [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx\001] Delete entire key You may want to bring up a feature request for v5.7 that allows you to turn off the reboot functionality.

Make sure you are using the full path to the config file. Additionally, the config= command line parameter is intended to be used as a on-demand configuration loading mechanism. Thats why you will not see it show up in the registry. If you want to permanently load a specific configuration. Load it in the configuration editor using the load button and then save it.

So you wrote your own Reboot script that you enter as an application that you run at the end of installations? If that is the case, the easiest way around that is to call the reboot script or whatever you have as the execute after script. You can add this by going to the tools tab in options. This will allow the resume WPI functionality to disable before you reboot. If that is not the case you have, here is a technical explanation of what is happening. WPI has resume after reboot functionality built into it to deal with installs that require a reboot. A RunOnceEx registry key is created each time you begin an installation. This key is not removed until the installation is complete. If you reboot during the middle of an installation, Installer.hta will begin after logon.

From what I can tell, it doesn't appear to be a quotation problem. Have you tried to run the command manually? Additionally you might want to try running it using msiexec.exe. msiexec.exe /i %wpipath%\Install\Applications\PhotoShop\Setup\Adobe_Photoshop_CS2.msi /qb

I'm not quite sure if I understand you fully, but I believe you are asking about the DriveType() function. The DriveType function returns one of the following: 0=Unknown 1=Removable 2=Fixed Disk 3=Network Share 4=CDROM 5=RAM Disk All optical drives, whether CD-ROM, CDRW, DVD-ROM, DVDRW, etc. will show up as CDROM.

You can also load a config file by passing an argument to WPI. For example, in your RunWPI.cmd you could have called WPI int the following way: REG ADD %KEY%\999 /V 1 /D "mshta.exe '%wpipath%\WPI.hta' config='%wpipath%\WPIScripts\konffi.js'" /f

I'm not familiar with the version you are using. Depending on how modified the original WPI code is and how old it is, you may be able to determine the version by doing the following: Open WPI.hta with a text editor and look for the "<HTA:APPLICATION" tag. There should be an entry for the version in that tag.

You use them just as you would use the corresponding DOS command. For example, FileCopy is just like the copy command in dos. Therefore the WPI command "FILECOPY C:\testfile.txt C:\testfile.txt.bak" is equivalent to the DOS command "copy C:\testfile.txt C:\testfile.txt.bak". The corresponding DOS command for the WPI commands are as follows: - FILECOPY = copy - FILEMOVE = move - RENAME = ren - DELETE = del - MAKEDIR = md - DIRCOPY = xcopy /I /E /Y - DELDIR = rd /S /Q For usage information about the DOS commands used, like the switches used for DIRCOPY and DELDIR, open a command prompt and type the DOS command followed by " /?" (no quotations).

@Ninja750 This functionality already exists. WPI should automatically resume after a reboot during an install via a runonce registry entry WPI makes at the beginning of the installation process. You should not have to manually restart WPI. If it is not behaving this way you should post a topic to resolve the issue.

I don't know how advanced your vbscript skills are, but if you know how to write files via a script this wouldn't be too hard. The main problem you have is that your CD-ROM cannot be located at D: prior to starting WPI. One way I think you can get around this is to write a script that moves the cd-rom to a temporary drive letter and writes a vbs file to change it back to the original drive letter. Run this script prior to running WPI, and make sure that the file it writes is saved to the hdd, something like C:\cdromfix.vbs. If Set CD-ROM or Create D: Partition are selected, the cdromfix.vbs file is replaced with a script that moves the cd-rom to the appropriate location. Run the C:\cdromfix.vbs script at the end of your WPI installation.

The better way would be to write a command into WPI to exit WPI gracefully and still save the reboot information. Something like a %MANUAL_REBOOT% command that would exit WPI but still maintain the installation list and other reboot information. That would be the way that I would do it. I wrote the reboot code so it would be easy for me to make sure that all the reboot information is kept. If you would like, I can write this functionality and pass it on to @mritter. Although, as you said WPI is not going to work without IE fully installed, so I don't know if its worth implementing or not.

I'm not sure I quite understand what you are trying to do. You basically want to delay the reboot for an infinite amount of time until the user manually reboots and then have the installer pick up where it left off? If so, I may have a better solution that I could incorporate into WPI. The reboot code changed slightly in 5.5 but if I understand what this wait.exe does correctly it should not cause any problems.

What is the exact value of the registry string you are entering? My guess is that its not reading the command line arguments when it is run from your registry entry. If you haven't already tried, use this as your entry: mshta.exe "<pathtoWPI>\WPI.hta" options=useroptions_una.js If that doesn't work try it with the full path to your options config file. P.S. - Just for future reference, there is a Bug tracker subforum for posts like this. Although I don't think this is a bug.

How did you go about adding WPI to your cd? Make sure to maintain the same folder structure for WPI.

The Ultimate theme is made specifically for the 1024x768 resolution. The background, which contains the sidebar image, is 1024x768. Therefore when you go to 1280x1024 the background gets streched and produces the less sharp and larger sidebar. The only way to fix it is to either make a duplicate background with a 1280x1024 resolution or make a separate image for the sidebar that looks like current one and rearrange the html code to show it dynamically. I'm afraid neither one is going to easy or worth the trouble. I think I would try to contact the author of the theme and ask for a 1280 size background. Its worth a shot at least.

Insert some breaks above the first button. Use:

Where is your WPI folder located (Hard Drive, CD, DVD)? Sounds like you do not have write access.

You can enter authentication using the net use command. Net use will map the share to a specified drive with the authentication you want. Here's the syntax. The syntax of this command is: NET USE [devicename | *] [\\computername\sharename[\volume] [password | *]] [/USER:[domainname\]username] [/USER:[dotted domain name\]username] [/USER:[username@dotted domain name] [/SMARTCARD] [/SAVECRED] [[/DELETE] | [/PERSISTENT:{YES | NO}]] NET USE {devicename | *} [password | *] /HOME NET USE [/PERSISTENT:{YES | NO}] //An example NET USE z: \\MyNAS\public MyPassword /USER:MyNAS\Admin

Could have just been a bad burn. Have you tried burning it again?