yogurt
-
Posts
348 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Events
Posts posted by yogurt
-
-
What I have learned thus far is that folders in which Duplicate driver files are found are safe to purge from a DriverPack. These 'now' incomplete driver folders will be satisfied by the surviving driver file / folder. Make sense since the source source files of the duplicate are identical to the source files of surviving driver / folder and their should be no adverse effects with the installation of the custom 7 build.
-
If you have space to spare on your hard drive you could try to reduce your windows partition by lets say 16gb and install your custom build and test that way on real hardware. Then once tested remove the OS using Easy Boot Manager to remove the test installation and reclaim the hard drive space. Another option would be to test on a virtual hard drive. If you search the forum, I think Ricktendo64 has a tutorial on how to install Window 7 on a VHD.
-
DotFusion... love the tools our logic and methodology was the same but yours seems really slick... I am trying it with my next set thanks
I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.
-
Thanks for pointing this out. I'll be revising my method to remove non-relevant folders prior to scanning for duplicates with Duplicate File Finder. I think the left over incomplete folders could also be deleted because the one remaining would satisfy the now defunct incomplete.
-
@DotFusion, it looks like when you did your scan you didn't remove the other OS folders before the scan. We duplicate some drivers between the OS folders in the packs intentionally.
When I get some time (maybe) this weekend I'll try your method on each OS folder on its own (not the whole pack).
You make an excellent point. Any duplicates found in the other OS folders that are deleted will most likely break that folders specific driver in the sense that they will not install properly because of the now missing driver file. Further as mooms has pointed out that the same applies for other drivers found in 01, 02, 03, etc...Thanks Mr. Smartepants for pointing this out.
-
Merci encore pour ce travail mooms.
-
@compstuff
Let me know how you make out.
-
Je ne savais pas que vous aviez ces 'packs' de mise à jour. Merci beaucoup pour les partage. Sont universels à Windows 7 EN?
-
@mooms
I did not know you had these light update packs. Thanks very much for sharing. I assume the updates are universal with the Windows 7 EN?
-
For the process of cleaning up my DriiverPacks I use two file utilities. Both of which are portable, lightweight and require no installation
1. Duplicate File Finder (to find and delete duplicate driver files)
2. Remove Empty Directories (RED) (to delete any empty folders resulting from step 1)
Example Scenario -- For this example I'll use 'DP_Chipset_wnt6-x64_1212' from DriverPacks. It's a good example because it contains quite a few duplicates. 164 duplicates are found in this pack to be exact.
The first thing I do is unpack the driver package somewhere on my hard drive maintaining the original folder structure.
The second thing I do is run 'Duplicate File Finder' to find duplicates on the folder where I unpacked the DriverPack.
As you can see from the screen shots Duplicate File Finder found 164 files that have a duplicate (Size 14mb) all with the same MD5 Hash.
The next step is to simply tell Duplicate File Finder to Select all duplicates and delete them. Optionally with the file utility you can choose to copy the dups or move them elsewhere. I choose to delete. Done! No more duplicates.
[sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry
The last step is to run 'Remove Empty Directories' as shown is the screen shot below. As you can see 'RED' found 45 empty folders in the DriverPack.
Now hit the Delete Folders Button and your done. As you can see WinToolkit shows no duplicates and anything left in the Win7 and vista folders are drivers that were not found in the ALL folder. This process shouldn't take an avid user no more than two minutes.
[sCREEN SHOT REMOVED] -- I need the online space for other stuff. Sorry
Update: I just want to bring something to your attention that I've only just realized before you try my method. Mr_Smartepants and mooms have pointed out to me that It may be wise to remove non-releavant OS folders first, prior to scanning for duplicates. You will also have to check for Incomplete folders as well. The reasons can be clearly seen in posts #20, #22, and #23.
-
You can make further customizations after Windows Setup completes by adding commands to the %WINDIR%\Setup\Scripts\SetupComplete.cmd file. This file enables you to install additional applications, run custom Windows scripts (cscript/wscript), or make other modifications to the system before a user logs on.
Note: Commands in the Setupcomplete.cmd file are executed with local system privilege.After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory.
If a SetupComplete.cmd file is found, the file is executed. Otherwise, installation continues normally. Windows Setup logs the action in the Setupact.log file.
Here's the post on how to use SAD2: http://forum.driverpacks.net/viewtopic.php?id=5336You double-click it and it works.
Otherwise you can use the "setupcomplete.cmd" method
Create the following folder structure to your Win7 disc:
%Win7-Disc%\sources\$oem$\$1\D\SAD2 (entire SAD2 folder with all DriverPacks goes here)
%Win7-Disc%\sources\$oem$\$$\Setup\scripts\setupcomplete.cmd
Add the following code to the setupcomplete.cmd file. -
Do you suggest to leave the drivers marked in blue and integrate them? Or do you recommend to delete all drivers in blue area and then integrate?
Which one is better and which one does not cause reduction in the number of drivers?
I personally don't integrate drivers that have the same MD5 Hash (Drivers Marked in Blue). The reason I don't integrate them, is because they are duplicates. Also If my memory serves, I believe DISM will ignore them. I takes me about 2 minutes to clean up a driver pack of it's duplicates and recompile a Custom Driver Pack with no duplicates. Just my 2 cents on the subject.
-
I don't think you will find anymore than what has already been discussed in the forums, The way the WinToolkitRunOnce works is relatively straight forward. When Win Toolkit integrates a silent installer it copies the silently installer to an Apps folder on the root of your installation source media then adds an entry to the registry RunOnce key which is then executed during first desktop load after windows has installed on the target machine.
Here is discussion that might help you in your quest.
-
When I integrate driverpacks into a Win 7 SP1 (7601) x64 I delete the Win 7 Folders When an All folder is present in the pack. I also delete all non-relevant OS folders.
The All folders contains drivers for all nt6.x Operating Systems so I tend to integrate those and delete the Vista, Win7, Win8 and server folders. The effect is that I end up with NO duplicates and a relatively minimal set of drivers with no unnecessary clutter. The only time I might consider a driver from another folder is when It has a newer version number than the duplicate found in the All folder -- This, however is seldom the case.
-
as far as i understand the process, the installer will be executed via a registry runonce?
But how does it works?
I know that there is the wintoolkitrunonce binary in system32, where is the config that will tell
it what to offer and install?
What are the parameter that work with the binary?
Use the Registry tool and mount this hive.
Wim Registry Editor > Wim_Software\\WinToolkit
-
When adding iconrestore.exe -restore to the silent installers list select the copy entire folder. Make sure the folder containing iconrestore.exe also contains the iconlayout.ini file. Using the copy entire folder option copies bother the binary and .ini file to the dvd. This way when WinToolkit Installer runs iconrestore.exe -restoreiconlayout.ini it will find the file. Hope this helps.
-
I've also had this issue with my integrations that involve IE 9. I have searched the tweaks section also looking for something I may have overlooked and the only thing that I can find that might effect this odd behavior is setting a custom home page. However, the problem for me seems to be random, I wish I had something more for you.
Rica, seems to have an idea, Rica, can you be more specific?
-
Thanks Compstuff for this intuitive methodology, I think I will adopt this method. I find your method to be quite sound. Thanks for sharing. I look forward to your next update.
-
Here's some news:
- Fixed a flaw which can affect greatly the chance of finding the apps folder. It would select the drive with the install.wim rather than the apps folder first. This has been fixed.
Lego, point #1 brings me back to my original question. Does this Flaw effect the current 1.4 build? The reason I'm asking again, is because in a previous post you mentioned that Win Toolkit Installer will search all drives for the apps folder. If I put the apps folder on the root of a USB drive should I also include a 'nul' (empty) Install.wim file to ensure the Win Toolkit Installer finds the folder?
-
Thanks Lego, that's what i thought but I wasn't sure. This is only in the 1.5 branch and not the 1.4 branch right?
I presume that for the time being you mean the 1.5 branch when you say "All of these changes are in the latest test build"
-
Here's some news:
- It no longers looked for 'Apps' folder but 'WinToolkit_Apps' folder instead. WinToolkit itself has been changed to suit this and automatically adjust pre-added silent installs.
I'm not sure I understand what you mean in Point #3. Can you please provide an example scenario?
-
@bphlpt
Just a thought, but I suspect that when WinToolKitRunOnce.exe initiates the scan for the apps folder. It maybe scanning for a certain string or file that would be unique to that specific apps folder identifying it as belonging to WinToolKit. Just a working theory right now, but I will test it post my results at a latter time.
-
Win Toolkit only searches the root of the DVD and not in other folders / sub-folders.
I believe this statement made by Lego pretty much sums of up where Win Toolkit scans for the 'Apps' folder.
The RunOnce installer will literally scan every drive letter plugged in for an 'Apps' folder. USB, DVD, CD, RAMDisk, pre-mapped network drive, heck even a floppy disk! As long as it has a drive letter.
-
Sorry, What I meant to say was that, maybe you could add to the description '...Does not disable HomeGroup services...' Anyhow, I think the current description pretty much implies that. Just a suggestion. Best Regards.
It already says "Removes 'HomeGroup' from left panel in explorer"
Drivers added with WinToolKit marked in blue and other another question?
in Win Toolkit
Posted · Edited by dotfusion
Not really because because the surviving driver.inf [install_section] is identical to that of the deleted driver.inf (remember they are duplicates) The surviving driver.inf that remains resides in it's OS folder along with all the source files required for a successful installation. No?