Jump to content

Djé

Member
  • Posts

    359
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    France

About Djé

Contact Methods

  • Website URL
    http://

Djé's Achievements

2

Reputation

  1. SOL ! A few hours after me finalizing the list, M$ released 5 new Office 2003 updates, replacing 5 other ones in it. First post updated with the new list including those patches.
  2. Here's an update for the FRENCH version of Office 2003. (I don't think there's much difference with the ENU one appart from the language, anyway). It contains the SP2 pack and the 18 actual post-SP2 hotfixes, as of 2007-05-09. Obsoletes ones are removed: only useful stuff in there. But only for the main office apps: (almost) nothing for Visio & Co. As a side note, PVMSXM5.msp in KB924424 is specifically for those special apps, while MSXM5.msp in the same hotfix is for the main office apps. If you try to slipstream PVMSXM5.msp in an Admin Installation Point for the main office, you will get an error message saying that the target application is not found. So if you use a script to automate the slipstreaming, you may want to set an exception to delete PVMSXM5.msp before the script slipstream it. An error also happened with the SPECIALDICTIONARYNLDff.msp package of KB913571, I think because those special dictionaries are for the Dutch language and may not exist on the (French) version of Office I used to test the install. Same solution. Last, as far as I found on M$ website, KB924085 doesn't replace the same Outlook files as KB913807 so this last one is not obsolete. But both have msp packs with the same names. So if, as I've seen doing, you first extract all the the hotfixes in a same location before slipstreaming them, one will overwrite the other... which won't be installed ! Better to extract and slipstream each pack one after the other. office_2003_x86_fra_20070509.zip
  3. I thought I'd post a link in here too. Avast 4.7 home Silent registration script (language independant). http://www.msfn.org/board/index.php?showto...id=594759
  4. [size=4][b]Avast! 4.7 home[/b] Silent Registration script:[/size] [b]- Language independant![/b] - To be compiled with a recent version of autoIt - Check that the avast program foler is correct (Dim $avastDir = "...") before compiling 3 possible usages: -1) Just uncomment (remove the semicolon ";") the end of the first line (Dim $key ;="XXX...") and replace the Xs with your registration key. Then compile the script and simply run it: [code]avastReg.exe[/code] -2) Run the compiled script with the key as a parameter: [code]avastReg.exe XXXXXXXXXXXXXXXXXXX-XXXXXXXX[/code] -3) Ask the compiled script to look for the key in a file: [code]avastReg.exe "d:\path to\private.ini" Djé avastkey[/code] 1st parameter: .ini file to look in (no path -> has to be next to avastReg.exe) 2nd parameter: .ini section to look in 3nd parameter: .ini key to look in
  5. Import wizard shows up when there's no profile. Either copy back a backup of your profile, or make firefox create a "Default" profile for you: "%ProgramFiles%\Mozilla Firefox\firefox.exe" -silent -CreateProfile Default
  6. For the commands, have a look at the handleCommand() function in installer.js. For the variables, it's in the ReplacePath() function of core.js. Both files are in the WPIScripts folder. You'll need almost no JSCRIPT knowledge. Just a little wit. Gambatte!
  7. You may want to import the attached reg file into your registry before calling WPI. hta.reg Or just call WPI this way: C:\WINDOWS\system32\mshta.exe Z:\WPI\WPI.hta
  8. That is an absolutely good idea Sorry for not having a specific demand on some installer. I just wanted to add that we could also very easily detect .reg (not only in regb & rega), .inf and .msi files and run the correct program to install them, without asking the user to input the complicated commands for those types of files. I'm already using such simplification in my Progs List Manager and it's working very well. I'm pretty sure we could adapt it to WPI. For example, instead of having to type these long commands as it is now: cmd1[pn]=['REGEDIT /S Shareaza\\ShareazaSettings.reg']; cmd2[pn]=['rundll32.exe setupapi,InstallHinfSection DefaultInstall 128 SystemTools\\CBin\\CBin.inf']; cmd3[pn]=['MSIexec /i Useless\\application.msi']; We could just have: cmd1[pn]=['Shareaza\\ShareazaSettings.reg']; cmd2[pn]=['SystemTools\\CBin\\CBin.inf']; cmd3[pn]=['Useless\\application.msi']; And WPI would know how to deal with those files (after checking that they do exist). Now, pushing the idea further and joining with sadicq on the embedded use of USSF, we could just -for the recognized installers- ask WPI to add the correct silent switches on the fly at install time. For example, instead of having: cmd1[pn]=['Runtimes\\jre-1_5_0_06-windows-i586-p.exe /s /v/qn']; We could have cmd1[pn]=['Runtimes\\jre-1_5_0_06-windows-i586-p.exe']; ussf1[pn]=['yes']; Meaning that, if possible, we want WPI to find the silent switch by itself (and of course not run the installer if it can't find it). Without the ussf1 line, WPI would just run the command anyway.
  9. As the installation sources are not under WPI_5.3\install, I use this to reference them: regb[pn]=['%wpipath%..\\TWEAKS\\disablestartandexitsounds.reg']; The folder structure under my E:\INSTALL : GAMES ... UTILITIES TWEAKS WPI_5.3 I agree. You absolutely don't need to have the install folder inside the WPI folder. In fact, it doesn't even need to be called "install". and there is an even simpler way to call your commands: 1st, Call WPI through a WPI.cmd looking like this: @cmdow @ /HID 2>NUL ||@ECHO OFF SETLOCAL ENABLEEXTENSIONS PUSHD D:\SPECIFIC\PATH\TO\MY\PROGS D:\WPI\WPI.hta POPDWhere you have to adapt the PUSHD instruction to where your progs are and the WPI one to you know what. 2nd, simply have your commands like this: cmd1[pn]=['"Mozilla\\Firefox Setup 1.5.0.6.exe" -ms'];for an installer being in: D:\SPECIFIC\PATH\TO\MY\PROGS\Mozilla\Firefox Setup 1.5.0.6.exe No need to have any environment variable in your path any more The PUSHD instruction sets the current path to the wanted location for you. (and the POPD instruction switch it back to the previous one once WPI is done)
  10. Kel, you don't want to leave us but rest assure of the other side: we are all with you! All your friends here are supporting you.
  11. Yes, autoIt used to have problems with delays on heavy loads sometimes. What about a loop forcing it? If $cmdline[0] Then While ProcessExists($cmdline[1]) ProcessClose($cmdline[1]) WEnd EndIf Anyway, I was just mentioning this as Kel is looking for 'universal' solutions: we don't want bug reports saying TaskKillS is not working on some machine . If you prefer to stick to the attached exe and fear an issue with the licence, maybe Process.exe (25Kb, freeware) from Beyonlogic is a good choice...
  12. Hey do you mind if I add this to the tools archive? Kel & sadicq, please note that taskkill is only for XP Pro. XP home has a tskill instead. I'd reckon to use AutoIt's ad hoc function which will work in any case (see the AutoIt help file for the 'ProcessClose' function): If $cmdline[0] Then ProcessClose($cmdline[1]) Compile it with the same name and use it the same way.
  13. Hey guys, I'm saying since 2 weeks that the problem is lying there... @wixfigura: Would you have replied to my questions that it would have been fixed in 5.3... This $winnt$.inf file is written by windows setup with the variables used during installation (most of them are coming from winnt.sif). In there, the dospath variable records the location of the source of the windows files actually used during installation. The code added in 5.1 was a new feature allowing the use of that location as a variable in WPI. Compared to the %CDROM% variable, it has the big advantage to exist whatever the type of install is (CD-based, HDD-based, network installation, local source, etc.), and doesn't require the use of the marker files such as wpi.hta, win51 or drivers.cab. @wixfigura: DJPro deleted the file. what about you? How come you don't have it? nLite? Use the fix below to keep going without minding for that file (it will skip the variable if the file is not found): * New ReplacePath() function in generate.js: function ReplacePath(v) { position="generate.js"; whatfunc="ReplacePath()"; var i; var rs = new String(); cddrv = FindCDRom(); sysdir = WshEnv("WINDIR") + "\\system32"; var dospath = new String(); //Exact location from which windows was installed (works with CD-based install & winnt(32).exe based install) if (FileExists(sysdir + "\\$winnt$.inf")) { var winntinf=fso.OpenTextFile(sysdir + "\\$winnt$.inf", 1); // It's recorded in the 'dospath' directive of the [data] section of \system32\$winnt$.inf. var matches = winntinf.ReadAll().match(/\ndospath=(.*)/i); winntinf.Close(); if (matches) { dospath=matches[1]; if (dospath.substring(dospath.length - 2, dospath.length - 1)=="\\") //dospath may have a trailing slash ... or not (depending on the location) dospath = dospath.substring(0, dospath.length - 2); // So let's remove it if it's there } } rs = v; //Replace WPI's special environment variables rs = rs.replace(/%wpipath%/gi,wpipath); // same as before rs = rs.replace(/%cdrom%/gi, cddrv); // same as before rs = rs.replace(/%sysdir%/gi, sysdir); rs = rs.replace(/%dospath%/gi, dospath); //Replace other (standard) environment variables (either global or defined in the process calling WPI) var envarname, envvars = rs.match(/%[^ %\f\n\r\t\v]+%/gi); // find ALL substrings enclosed in '%' and not containing '%' itself or a white space character if (envvars) // if any match { for(i=0; i<envvars.length; i++) // loop on the matches { envarname=envvars[i].substring(1, envvars[i].length - 1); // strip the match from its enclosing '%' rs = rs.replace(envvars[i],WshEnv(envarname)); // replace it by the corresponding environment variable } } return rs; }
  14. I agree with that, but according to the line number shouldn't it rather be a problem with 'fso.OpenTextFile' on the 'system32\$winnt$.inf' file, as I already said in a previous post?Actually, there is one glitch with this instruction: the file is not closed after reading, which is not very clean and may lead to problems. @wixfigura: - can you add this line in genarate.js after line 122 and test again: var winntinf=fso.OpenTextFile(sysdir + "\\$winnt$.inf", 1); // It's recorded in the 'dospath' directive of the [data] section of \system32\$winnt$.inf. var matches = winntinf.ReadAll().match(/\ndospath=(.*)/i); winntinf.Close(); // <--ADD THIS LINE if (matches) -Can you also tell us what is the error message in english?
  15. @wixfigura: Can you please read and do the test mentioned there so we can try to debug this? ps: line number is now 120 in 5.3
×
×
  • Create New...