RogueSpear

I've been making an msi installer for Nero/NeroVision for quite a while now. I combine the two products into one installer, but I strip out all the superflous garbage like Photosnap, CD Cover Desginer, etc. I DO leave in the three little Nero tools which I find pretty handy. It's not that easy of package to make in comparison to some other repacks I do. I use AdminStudio to do it and I use the two part snapshot method. You then have to go through the entire registry file and clean it up before building the msi. At the moment I'm two versions behind. I usually wait and make a new package every other version because it is rather time consuming to make.

Just from the looks of it, I would say that Dexter's methodology is superior to mine. Mine is more of a custom "hack", whereas his appears to be far more "stock".

Never done it before. I assume this RapidShare is rather self-explanatory? Do I have to register or give them any personal info?

I repack my apps because I like to have them preconfigured to my liking. As a part of the package I can set all of the settings, put the shortcuts where I want them, named as I want them, and end up with a single MSI file that I can deploy via GPO. Or I can do an AIP and make a 7zip silent switchless installer. With Nero for instance, I have a single MSI file the combines both Nero and NeroVision Express. But it leaves out all the crap like CD Cover Designer, PhotoSnap, etc. And all of the accompanying registry entries are cleaned out too. So instead of fiddling around with all of these setup switches followed by importing a bunch of registry entries or making some convoluted AutoIt scripts, this is how I go about it. Anyway, back to topic. First shot, I repacked build 813 with Messenger Plus! and patched with V.05 of the ++ patcher. It all worked beautifully. So this shouldn't be a very hard program to keep up with when new versions are released.

Using M3, the only issues I seem to be having are that the WINNT.SIF gets mangled up. Well specifically, the big long drivers path. I haven't even checked on the txtsetup or dosnet files yet because I figure there has to be outstanding issues with fedit.exe.

I think that this additional cab file method is what's going to be necessary for there to be a monitor driver pack or a printer driver pack. Using the latest DPs and one custom DP of my own (which is not big), I am right up to the 4096 limit of OEMPnPDriversPath. It would seem that the precious little room left in the path should be reserved for the existing DPs to be able to accomodate future drivers. And honestly this true integration method is perfect for things like monitors and printers. So I'm wondering since I have not tinkered with this yet - do we have a rock solid solution here? Something that can be replicated most, if not all, of the time?

An impatient fellow considering you've probably automated 90% of the setup process to begin with.

@Mark49, I know this may seem obvious, but is your Drivers.cmd file in the $OEM$\$1 directory on your source media so that it gets copied to %SYSTEMDRIVE% ?

I've repacked literally dozens of applications with Installshied AdminStudio. It's an incredibly expensive package, but I'm lucky enough to have an employer who bought it for me. About the only thing I have not been able to repack so far is Google Toolbar believe it or not. Everything else no problem. Nero, PowerDVD, Winamp, Oracle Client V9.02, and the list goes on.

Might be easier to just repack it using AdminStudio. I'll give it a shot tonight..

I use my own batch with M3 and I don't put in the CMD /C and it runs just fine. DetachedProgram="%SYSTEMDRIVE%\Drivers.cmd" Drivers.cmd is as follows: @ECHO OFF set tagfile=\WIN51 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: %SystemDrive% cd \ Start /WAIT 7za.exe x -y -aoa %SYSTEMDRIVE%\DriverPack_*.7z -o"%SYSTEMDRIVE%" Start /WAIT 7za.exe x -y -aoa %SYSTEMDRIVE%\000_AllUsers.7z -o"%ALLUSERSPROFILE%" Start /WAIT 7za.exe x -y -aoa %SYSTEMDRIVE%\000_ProgFiles.7z -o"%PROGRAMFILES%" Start /WAIT 7za.exe x -y -aoa %SYSTEMDRIVE%\000_WinDir.7z -o"%SYSTEMROOT%" Del %SYSTEMDRIVE%\*.7z /F /Q All runs as expected.

Ok, I thought since it was a secondary issue to another post in the wrong forum that maybe I should place it here. Sorry 'bout that.

This is along the same lines of the SoundMAX issue. I have encountered some Gigabyte mobos with embedded Promise Ultra133 controllers. It appears that the existing driver from DPM is good enough to boot the Windows setup, but during the device detection phase of setup the controller is not found. After your first reboot, you get a blue screen. I went to the Promise web site and in their fine print it says that they do not support any Promise controllers embedded on mobos. Nice. So I went to Gigabyte's web site and tried their drivers. It worked perfectly. I'm not an expert in this or anything, but I'm wondering if the inf and cat could just be renamed and copied to the D/M/P/8 folder (or would this break the driver signing?). The Ultra.sys file is indeed a different version from what you get from Gigabyte, but like I said it seemed good enough for that initial boot up. Anyway, Gigabyte has three different Promise drivers on their web site. It looks like Ultra66, Ultra100, and Ultra133. They can be found here.

I can't even believe it but I got this blue screen the other day on a Dell Inspiron 1000 using a M3 CD I made. None of the drivers worked either, I had to go to Dell for them. I sent a PM to BTS reporting the failure. What got me though was the BSOD. I thought we had rid ourselves of that one.

I voted for the corporate environment. I do have a primary employer (where I actually use the DPs with RIS) but I do a lot of consulting on the side as well and I never know what twisted hardware I'm going to run into. Very very helpful to me. Thanks a million!

Regarding Method 3. I did an install on a machine with a P4-2Ghz 1Gig RAM and a Promise Ultra133 controller on the mobo. With this machine the DP extraction from the CD did not complete before the device detection started. On the good side of things, the decompression seems to go alphabetically for me which means the chipset and mass storage drivers were extracted in time and the remainder were extracted before their detection routine began (Sound). What I did for a fix. I put all of the DP archives in the $1 directory so that they would be copied to the root of %systemdrive% and modified my batch to reflect that. This did a couple of things; first it let the archives decompress faster since the DVD drive was unable to keep up with how fast 7za was working and second it did a pretty good job of keeping the hard drive "busy" so that the concurrent setup couldn't progress very far. Sure enough all decompressing was done with plenty of time to spare before the device detection routine started. While I'm talking about this machine and specifically about an embedded Promise controller. The DP for mass storage worked in as much that it allowed the use of the embedded Promise controller intially. But after the GUI portion of the setup completed and the computer rebooted, I recevied a blue screen. I then did an install from the standard IDE controller to try and resolve the issue. NONE of the Promise drivers would work from the DP. So I went to the Promise web page and noticed in fine print that Promise will not support any controllers embedded on a mobo. With that I decided to head over to Gigabyte's web site and I downloaded the drivers from them. Bingo it worked. There were only two sets of drivers from Gigabyte, the Ultra66 and Ultra133. I have not had time to verify this, but I'm almost guessing that the .sys file is identical to the one contained in D\M\P\8 but the .inf file doesn't contain hardware ID, thus requiring the .inf from Gigabyte. Here is the link where the drivers can be downloaded: http://www.giga-byte.com/Motherboard/Suppo...ver_Promise.htm

I had this problem happen to me a while back. It took me forever to pin it down but it ended up being WinAmp. Not the retail package mind you, but a custom repack I did using AdminStudio. As it turns out, since WinAmp can burn CDs, it makes registry entries for that purpose including what sort of CD burner you have. I did the repack project in a VM and didn't see (or forgot) to remove the offending registry entries. So the lesson here is that if you are installing something that has burning capabilities and it makes some bogus registry entries, this can happen to you. The UpperFilters fix is what I used to get my drives back, but in the end I went back and repackaged WinAmp properly.

I was going over a bunch of stuff today and suddenly it hit me. How frequent would it be that someone is going to add an expansion card to their computer? And if they did, wouldn't they want to visit the vendor's web site to get the newest driver available? I thought about it for a while and came to a few conclusions: Drivers for things like monitors and printers don't change very frequently, but these are exactly the kind of devices that I could see someone plugging in. Monitor drivers take up practically no space at all. Printer drivers, especially when poorly authored, can. So maybe printers could be a concern in terms of extreme bloat in a KtD scenario. Almost anything with firewire, USB, or PCMCIA interface would be a good candidate. There's nothing worse than slapping in someone else's USB device and then not having the drivers necessary to run it. So it would seem like we could save a lot of time and space (and maybe even complexity) by cutting down drastically the number of devices included in a KtD project. Thanks for reading my rambling thoughts

NetBEUI is officially NOT SUPPORTED by Microsoft starting with Windows XP. It's almost a shame because it really works great for a very small network (like in a home) and it's relatively secure since it won't cross a router.

What I said is that WMI is not available during that part of Windows XP setup (cmdlines.txt).

It's a little earlier than what I was hoping for, but I'll try to get all my stuff together and post with 24 hours. I just wanted to make sure everything was properly documented first. But the short answer is that yes you can run a vbscript from cmdlines.txt.

My cmdlines.txt and all of my RunOnceEx stuff is done in VBscript. I'm actually getting it all together in preparation to post here. As far as cmdlines.txt you need to be aware the you can only use cscript, not wscript. Also WMI is not available at that point either.

With a lot of recent laptops that have Intel NICs, the MS supplied driver won't work. I know there are others too but I just can't remember them off the top of my head.

I've been using Method 1 with RIS for quite a while now. It works almost exactly like using a CD. The only differences I can think of off the top of my head is if you have a pretty new NIC you may have to get that new driver onto your source. That whole process has been described in several threads previously and you can find it with a search. The other difference would be that instead of using as WINNT.SIF file, you'll be using a SIF file located in i386\Templates. The easiest thing to do is to modify the ristndrd.sif file. The OemPnPDriversPath works exactly the same as with winnt.sif and CD installation.

Not sure how this didn't seep into my brain the first time I read it. Good point you have here. Perhaps a decompression could be done for that purpose only. In my experience what takes so long with Method 1 is the cabbing of all the driver files. @DigeratiPrime, the big difference, for me anyway, is that this method does not use a hacked setup.exe or run two other executeables during the setup process. I gave up on Method 2 when I had some errors during the GUI portion of the setup happen a couple of times. I had no way of determining if these errors were due to the executeables or some other issue, but it just made me leery of using such a method. Call me paraoid or call me purist, I just like this method more because it seems more "stock" for lack of a better term. EDIT: @BTS, it looks like we were posting at the same time I'll give that a shot in the morning. Well it is kinda morning here... lol bedtime for me.