Jump to content

midiboy

Member
  • Posts

    703
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Austria

Everything posted by midiboy

  1. Hi Yzöwl, I have been using your code successfully for months now: for /f "delims=" %%? in ('net config work^|findstr/i "\<soft"') do call :OSis %%? if %WinOS% == Vista goto :Vista if %WinOS% == XP goto :XP :OSis echo/%*|find "2000">nul 2>&1&&(set "WinOS=XP"&goto :eof) echo/%*|find "2002">nul 2>&1&&(set "WinOS=XP"&goto :eof) echo/%*|find "2003">nul 2>&1&&(set "WinOS=XP"&goto :eof) echo/%*|find "Vista">nul 2>&1&&(set "WinOS=Vista"&goto :eof) echo/%*|find "2008">nul 2>&1&&(set "WinOS=Vista"&goto :eof) Thanks again for it ! :-) However, recently I am having a problem with this code on WinXP SP3 during runonceex. Seemingly out of nowhere the cmd stops right after this command: for /f "delims=" %%? in ('net config work^|findstr/i "\<soft"') do call :OSis %%? This does not happen on all the scripts where this code is present, just one. The strange thing is, if I press the ENTER key, it continues to run normally, no error appears, nothing. But it just stops there forever if noone presses a key. Do you maybe have an explanation for it or a way around it ? Thanks in advance, Alex
  2. Hi Yzöwl, Searchroot2 seems to work, however if SearchRoot1 is being used I get this as the result: ECHO %i: Any ideas ? maybe a typo somewhere ? Bye, Alex Edit: yeah, you had a "i" at the end of that line: For /f "delims=:" %%# In ('FWDT.exe -f aiwroot') Do Set CDROM=%%i: Changing that to a "#" does the trick. Thanks for your help !! Alex
  3. Hi Yzöwl, thanks for your detailed response. Here´s mine: 1. Well, I am using Vista mostly but everything I do should be backwards compatible so I am not sure which of your 4 methods works realiably in Vista and XP. 2. I am not only installing from CDROM but I am also using a WDS Server in a few cases so any method that only works with CDROMS will not work too well. I guess that leaved only 1 and 4. I will give them a try, however, in the meantime I would like to keep using fwdt until I have tested the above throroughly. Well, I am setting the "new" variable in the same script as the cdrom variable. I just had the idea to use a second variable, "new" instead of %CDROM:~0,2% all the time in the script for instance for the cdswitch utility. Any idea how I can get this to work easily ? If it won´t work, I will have to keep using %CDROM:~0,2% which is not the worst thing but doesn´t look as clean to me as the above solution. Bye, Alex
  4. Hi Yzöwl, one followup question: The above is working fine. However, if I am doing this: set NEW=%CDROM:~0,2% Then the new variable "New" will not contain the content of CDROM minus the backslash but ~02 instead. Any ideas, why ? Any way around this ? As always, thanks for your help ! Alex
  5. Hi ! @Kel: Sorry for mismatch with the letters :-) @reini380: Thanks for posting this. Now, we are getting somewhere.Unfortunately, I use Vista exclusivly so I cannot do anything about it. Any ideas how to troubleshoot this ? Anyone ? Bye, Alex
  6. Yzöwl, as always, you are the saviour of the day ! You already found the solution. Wonderful. Here´s the script by the way. I usually check for the existence of a file in the root of a drive using the usual method posted in this forum plenty of times. (SearchRoot2 in the example below). However, with some Dell Clients with mediacard readers, this method will provoke windows Exceptions, stopping the unattended installation. So I was looking for a way around this and found the tool fwdt.exe This tool also searches for a specific file on removable drives. However, it may be doing that too quickly for some boards/ USB drives so one has to call it a few times. Now, in order to be sure that this won´t take forever, I am limiting this to 750 times. Should fwdt not work in some cases (I have no experience with this tool so I am not sure how reliable it really is), I will then switch to the usual method. The only problem with this approach is that fwdt.exe always attaches a backslash to the driveletter, while the usual method does not. Since cdswitch for instance requires a driveletter without the backslash, I needed to find a way to remove that from the variable. So, here´s the script: SET Count=1 :SearchRoot1 FOR /f "Tokens=1" %%i IN ('FWDT.exe -f aiwroot') DO SET CDROM=%%i IF NOT "%CDROM%"=="NULL" GOTO StartSetup SET /a Count+=1 IF %Count%==750 goto SearchRoot2 GOTO SearchRoot1 :SearchRoot2 For %%i in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do if exist %%i:\aiwroot set CDROM=%%i: :StartSetup ECHO %CDROM% ECHO %CDROM:~0,2%
  7. Hi guys, I am having this problem now with my cmd script .... It is giving me a variable %CDROM% containing the driveletter in this format: X:\ Now, CDSwitch requires a driveletter without the "\" at the end. Any idea how I can remove the backslash from the driveletter so I can use it in cdswitch? I hope someone has an idea ... Thanks all for your help with this ! Alex
  8. Hi Ken, do you have the SP1 update files in the Updates folder inside the Office2007 folder ? Do you use Vista or WinXP ? Something has to be different between our setups Bye, Alex
  9. Hi everyone ! I still also cannot get this to work. I am trying to install Office 2007 incl. SP1 Updates inside the Updates folder on Vista SP1 using WPI and the autoit script by Ken (from the first post). I have tried at least 20 times now in vmware. By now I have increased the sleep time in the script from the initial 10 000 to 1 000 000. Yes, thats one million. Still, while the setup dialog displays the "installing Updates" message, WPI dies in the background. Each and everytime. I have no idea how to get this to work or how you guys do it. Obviously it has to work for some people otherwise there would be much more interest in this thread ? Thanks for your help, Alex
  10. Hi again, Mark, one last addition because that may not be clear enough yet. If this checkbox is NOT enabled by the user and the OS is 64bit then WPI should redirect the calls to the SysWOW64 folder so that the 32bit versions of cmd/regedit/etc. are called. May be clear anyway, I just thought I´d mention it again :-) Bye, Alex
  11. Hi Mark, Yeah, thats one of the reasons why you definitely should never skip the program if the checkbox is checked but OS is 32bit. More and more programs will contain 32 and 64bit components inside one common installer. Also if the user does check for the bitlevel of the OS inside his own script and start that in WPI that should be allowed otherwise WPI would impact the way people use it. One last note: I would not call the checkbox "This program is 64bit" for the above reasons. I would call it something like "enable 64bit processing" or something like that because thats what you do with it. This checkbox should enable the user to run a program or script or registry tweak as 64bit native but if the OS is NOT 64bit it should still run fine. Otherwise people would need more than one config.js depending on bitlevel of the OS and this would not be very nice The final decision if the 64bit or 32bit cmd/regedit/whatever.exe´s are used should be decided by your check of the OS (environment variables for instance). I don´t see a reason why this would not work easily because the 64bit versions of those programs are in "%windir%/system32", the same place where they are on a 32bit Windows anyway Thanks for listening ! Alex
  12. Hi Mark, as I wrote you in my last mail, I also think that this checkbox way of doing things is the right way. Just make sure that even if the checkbox is checked, it would still work without an error on a 32bit system because some of us start a cmd in WPI and have our checks in there as well so that we can start a 32bit version of a program on a 32bit system and a 64bit version of the same program on a 64bit OS. This needs the checkbox in WPI to be set to 64bit but on a 32 bit system the same config.js should work too. I guess it will, just being careful ;-) Bye, Alex
  13. Thats true until someone opens a regfile made for a 64bit system on a 32bit system. Then he might have that key in there as well although it won´t do anything. But it will confuse WPI ;-) I would rely on environment variables for instance like this: IF /i %PROCESSOR_ARCHITECTURE%==AMD64 goto x64 IF DEFINED PROCESSOR_ARCHITEW6432 goto x64 This would detect both situations on a 64bit system: either the 64bit mode or the 32bit mode. On a 32bit system this would also give the expected result. Bye, Alex
  14. Hi Mark, I see. Well, do you need me to test anything ? Since I will be on my vacation starting tomorrow I will keep Version 6.4.1 installed for the time being. I will be available for testing in about 2 weeks again ! Have a nice time and thanks for your help ! Alex
  15. Hi again, Mark, just as I thought, with WPI 6.4.1 everything works fine, either with the Wolf_Vista or the Server theme. Bye, Alex
  16. Hi Mark, first of all, everything was working fine in the versions up to 6.5 (did not test 6.5 but the one before I think, 6.1 ? was fine). Second, in post three of this thread I posted the script which I am using to start WPI over the network. Here are the relevant parts including the full paths: set share=\\server\REMINST set username=domain\Installer set password=password set WPIfolderNetwork=Setup\WPI FOR /f "usebackq tokens=2" %%i IN (`net use * %SHARE% %PASSWORD% /user:%USERNAME% /PERSISTENT:NO^|find ":"`) DO SET DRIVE=%%i start "" /wait "%DRIVE%\%WPIfolderNetwork%\WPI.hta" Both the config.js and the useroptions.js are in the default WPIScripts folder inside the WPI folder. As for the theme I am using: I used Wolf_Vista up until 6.5.1. With the new version I switched to the included "Server" theme. I am not doing anything fancy with the theme, I just specify its name in useroptions.js and make sure its folder is inside the themes folder. Just tested with the Windows theme instead of the Server theme. Now I am only getting one messagebox instead of two (only the windowoptions.js could not be found) Bye, Alex PS: Maybe I should switch to the earlier version right now or do you need me to do more tests ?
  17. Hi Mark, here´s the result! 1. First, the new Script error appears (saying that an error appeared in the script: clTheme is undefined + the URL) 2. Then the secdond messagebox and then (optionsfile) 3. The third messagebox (windowFile) Afterwards, the 2 messageboxes mentioned above appear. Is this enough info for you or do I have to check something else ? Thanks for your help ! Alex
  18. Hi again, thanks for the info. Now I did change the text in core.js according to the text in zorphnog´s message. Now I get a different error, actually two of them. Translated, they say: "Could not be saved: .\WPIscripts\Config.js and .\WPIScripts\windowoptions.js" After I acknowledge those two messageboxes, WPI starts fine and continues to run fine afterwards. Any ideas ? Did not have that problem with 6.1 :-) Thanks, Alex
  19. Hi ! Sorry to say but this error is back in 6.5.1 ! Just tried it and got the same error again. I will change the relevant code in core.js again to see if it still works. Could you fix this again please for the next version ? Also it should be working on W2K8 also, so maybe also make an exception for that OS ? Thanks, Alex
  20. 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
  21. 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
  22. No ideas ? :-( Still hoping .... Thanks ! Alex
  23. 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
  24. 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
  25. Hi cancerface ! Two questions: 1. Will this also work on Vista ? 2. Would it be possible for you to add a feature that changes the default system folders of the user one creates using your tool ? I mean folders like "My documents, my Video, audio, pictures, Desktop, Favorites" etc. This would be especially useful for Vista. On Windows XP one could use Wihu for that but there is nothing available for Vista that does something like it. Thanks, ALex
×
×
  • Create New...