Dumpy Dooby

I would think it would only wipe out the first partition on the PM. But I'm not familiar with auto-partition ... so meh.

This is very similar to KTools, right? Other than the ability to automagically find the script file, what's the difference between this and KTools (if there are any differences)? Thanks in advance.

It would be easier, IMHO, to write an update script if your pack was released as a zip file, since there are PHP and perl mods to extract zip files remotely. It might be worth looking into. Also, Windows can extract a zip file without the use of a 3rd part program. Just a thought. Most people have WinRar, though. So not really a big deal. It would only be an issue for a small number of people, really.

There's been quite a few hotfixes released since XPize was finalized. I know there was a problem with MSN Messenger (or was it Windows Messenger?), after there was an update. I'm wondering if there's likely to be similar problems with new hotfixes? Or have you taken precautions so you know that won't happen? Just wondering because if XPize is likely to cause problems with WU, then I shouldn't be giving it to people that aren't computer saavy.

Certainly. BTS provides setuporg.exe, setup.ex_, and presetup.cmd with his driver packs. These are used to install the drivers at that point. It's must easier to do the integration if you use BTS's packs, however, you can manually add setuporg.exe and presetup.cmd to txtsetup.sif and dosnet.inf. RogueSpear created an addon-pack which can be used with RVM Integrator (and I think nLite can do it now too), which can be found here (you want RogueSpearAddonsM2_CD_1.0.cab). Okay that will get you halfway. Now you just have to edit presetup.cmd in your i386 folder to have it decompress your own 7z packages. Personally, I use this method to replace $OEM$ folders all together. This is what my presetup.cmd looks like (I've taken the comments out to save room in this post): SET TAGFILE=\win51ip.SP2 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:%TAGFILE%" set CDDRIVE=%%i: %CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\DriverPack*.7z -o"%SYSTEMDRIVE%" %CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\C\*.7z -o"%SYSTEMDRIVE%" %CDDRIVE%\OEM\bin\7za.exe x -y -aoa %CDDRIVE%\OEM\WinDir\*.7z -o"%SYSTEMROOT%" %CDDRIVE%\OEM\bin\SetDevicePath.exe %SystemDrive%\D START %CDDRIVE%\OEM\bin\WatchDriverSigningPolicy.exe EXIT If you're not using BTS's packs, then just go ahead and delete the lines below the 7z decompression (besides "exit" of course). And delete the line that tells it to decompress driverpacks. edit: I guess I should mention that I create a themes.7z file which I put inside of \OEM\WinDir\. My themes go from 80MB to 4.34MB.

There's a lot of unorthodox code in WPI. Hopefully it doesn't have any problems with IE7. Anyone try using it in Vista? I would imagine the interpretation will remain the same ... but nonetheless, a lot of it is not proper scripting/markup.

Correction: It was over two hours later. But whatev. *shrug*

The link for Windows Live Messenger cab file seems to be broken.

I've integrated mine during right before DetachedProgram (which is T-39) and SVCPACK on seperate occassions. I also used $OEM$ folders way back in the day. All three methods worked fine for me. Anyway, the time at which you integrate your themes shouldn't be affected by his script. I think it's probably more along the lines of his script, in general. It would probably be best to integrate the theme using an IF/DO statement. I just don't know the DO part to load a theme silently.

I just realized that you could probably edit the BTS_DPs_finish.cmd file, combined with my above script, to do what you need (the 'finish' script will transfer .exe's and whatnot accordingly).

Heh, you're going to hate me. But I'm having trouble with the newest one. Everything extracts just fine and dandy. But it doesn't install. It just stalls for a bit, and then closes. I'm guessing that there's an error of some sort, but it's being supressed by your custom MSI or whatever. Could you tell me what command you use in 7zip's SFX so I can make my own installer, but use a passive method instead of quiet. I should also point out that the non-silent release installed just fine.

Now I gotta implement your idea of removing all thumbs.db files.

I am eagerly awaiting this release.

I have taken a look at your attachment and will look at producing a 'fix'. However, as I think I may have stated many moons ago the files were not produced as do everything workhorses. There will be some people who have non usual configurations etc. requiring different tools etc. And believe me filenames containing 32 or more characters should be considered as non usual! Using a second parameter does however appeal far more and if I do create a 'fix', I will implement this idea and duly note your input. The part in bold is the exact reason I modified it to suit my needs. I wasn't suggesting that you implement my fix. I was merely saying that I had a problem. I wrote my own solution. You can use my code in any way you choose. No biggie. I think >16 characters isn't unusual, which conflicts with the requirement for a bootable ISO.

I wrote a fix . I suppose you can implement my fix accordingly if you want (duly note that I changed the directory structure and got rid of the cmd and img directories and consolidated it all into one "makeiso" directory within System32 ... it shouldn't take you too long to modify my script). See the attached file. Basically, my problem was when folder names were greater than 32 characters (16 characters for boot discs), then CDIMAGE would echo back an error, and thus, no ISO was created. I solved this problem by having a script count the amount of characters in the label name. If the amount exceeded 32 (or 16 for boot discs), then the script prompts the user to change the name. A loopback is then implemented to make sure the user's input will not cause any problems. And I also made the .CMD into one file, which uses the /B switch for creating a bootable ISO. makeiso.zip

I put the following code right in the top of (just below the TITLE, actually) CD\ IF %DIRE%=="%CD%" goto CDISO CD /D "%DIRE%" And then right before the EXIT command, I add this line: :CDISO start %WinDir%\System32\makeiso\LCISOCreator.exe && EXIT On the previous line, I have a goto :eof, which is defined just above exit (to prevent the script from always executing LCISOCreator). I use this to create ISO files from an optical drive. You can Google LCISOCreator if you wanna use this script. Currently, I'm going to work on a script that won't s*** on me if the label doesn't meet Joliet standards, but instead, will prompt the use to enter in a label themselves.

For the next one, would it be possible to have optional switches to register it? If not, it's all gravy. We can stick to .reg files.

Certainly. The first line detects your CD drive by looking for the file SetDevicePath.exe in the \OEM\Bin\ directory. The second line checks to see if SetupCopyOEMInf.exe exists in that same directory. The third line tells Windows to search in \Drivers\ on your CD drive. The fourth line allows unsigned drivers to be installed. The fifth line copies all of the INF files that are found in the \Drivers\ directory to your %WinDir%\Inf\ directory. The sixth line disables unsigned drivers from being installed. The rest just tells Windows to start looking in %WinDir%\Inf for drivers. The only problem is, however, when you run this, you aren't copying over any of the exes or anything that some of the drivers require. ATI drivers probably wouldn't work, same goes for RealTek. I use the above method for installing RealTek drivers onto customers' computers, but my script extracts them and copies the .exes accordingly.

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:\OEM\bin\SetDevicePath.exe set CDROM=%%i: IF EXIST %CDROM%\OEM\bin\SetupCopyOEMInf.exe ( %CDROM%\OEM\bin\SetDevicePath.exe %CDROM%\Drivers START %CDROM%\OEM\bin\WatchDriverSigningPolicy.exe %CDROM%\OEM\bin\SetupCopyOEMInf.exe %CDROM%\Drivers TASKKILL /F /IM WatchDriverSigningPolicy.exe ) ELSE ( %CDROM%\OEM\bin\SetDevicePath.exe %SystemRoot%\Inf ) %CDROM%\OEM\bin\SetDevicePath.exe %SystemRoot%\Inf I think that will work.

Certainly. You can make a 7zip SFX if you want (hopefully you know how to do that). I'll try to walk you through it. Before creation: Create a directory to work in. I'll refer to it as working directory. For SFX, you'll want to put necessary files in here. Step 1: install.cmd cls @RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 128 .\WGA.inf @Fedit -rem -f "%WinDir%\inf\sysoc.inf" -l:o WGATool @Fedit -add -create -f "%WinDir%\inf\sysoc.inf" -s Components -l "WGATool=ocgen.dll,OcEntry,WGA.inf,HIDE,7" @regsvr32 /s "%WinDir%\system32\LegitCheckControl.dll" exit Step 2: WGA.inf [Version] Signature=$CHICAGO$ Providor=%author% [Strings] Product="WGA Validation" Version="1.5.512.0" Author="Dumpy Dooby" Copyright="Copyright © Microsoft Corporation. All rights reserved." [DestinationDirs] WGAFiles=11 [SourceDisksNames] 55=%DISKNAME% [SourceDisksFiles] GWFSPIDGen.dll=55 LegitCheckControl.dll=55 [DefaultInstall] CopyFiles=WGAFiles [WGAFiles] LegitCheckControl.dll GWFSPIDGen.dll Step 3: Copy LegitCheckControl.dll and GWFSPIDGen.dll from your System32 folder to your working directory. Step 4: Copy Fedit.exe to your working directory. Fedit.exe Step 5: Create your SFX accordingly. You'll want to direct it to run install.cmd after extraction.

Here's what I ultimately plan on doing: Boot disc to a set of options asking to run diagnostic tools or install XP Before installing XP, it will load WinPE and execute a batch file that asks for a username, password, cdkey, timezone, etc. After answering the questions, an answer will get created and saved to the RAM drive. Thereafter, XP Setup will be run from WinPE and the answer file will be used for install. If a second partition is detected on the system with enough space, then XP install will be copied locally before installation. WinXP gets installed. All settings are fine and dandy. Everyone is happy. If any of that seems impossible, please let me know what. I have little-to-no experience with WinPE, but I'm fairly confident I can handle this project. If an answer file cannot be put on the RAM drive and used to install WinXP, then how would I go about putting it onto the user's HDD and run that way? I'm not asking for a complete guide on how to do ALL of that. I mostly just want to know how to run a WinXP install from WinPE and tell it to use a seperate answer file without rebooting (since the answer file will be in a RAM drive). The batch files and scripts I can do myself, though.

Whoa, let's not jump the gun here. Like I said, I'm not sure if that's right. It just seems like it would be (I'm going by the "Last Modified" date). I could be way off, though.

I have 3.5.1 floatin' around somewhere. But that's a little TOO old, huh?

Just to clarify something.... v2.50.2x the 64bit version. v2.50.4x the Win32 version. His version is NOT over a year old. The definitions are just old. It seems as though updates are put in %programfiles%\ESET\updfiles\ - So see about adding those files to your disc. Maybe you won't get the error. Otherwise, you could write a script that checks for an internet connection, if one doesn't exist, then updates get disabled. That would probably work too. You will get an error if you reinstall fresh with no updates. Its definitions simply aren't up-to-date. The release is too old.

OH SNAP!