Overflow both A and B have "ATi" listed. without knowing the exact video card you have you have look that up and come to the website to search through it every time. That is hardly ideal when the information could be easily added to the packs themselves/the program. It can be confusing when you're building for a machine you don't know everything about and arent sure if it has a buisiness class video card or an IGP.

Mr smartypants thank you, that helped me a ton in understanding each packs role. If even that was added next to the packs I'm sure plenty of people would be helped. They'd say to themselves "It's a dell workstation...it's a workstation class card, B it is then"

Thanks for the help guys.

Please have more readily available descriptions of the driverpacks contents. Both in the program and on the site. I go here and just see "graphics A, B, C" all of which have ATI drivers, making it difficult to know offhandedly if I need B and C. Thats just one example.

Ty.

I know but I wanted to check to be sure that's what was causing problems, isn't SAD the stand alone drivers project? How would that affect KTD?

In any case I've since built another one with it disabled and everything installed fine.

I just built a new disc from scratch and when I integrated Bâshrat the Sneaky it completed in 2 seconds - which made me go "huh" so I ran it again and it took 12 seconds... which sounded better to me so I burned it and it did that thing again with the driver warning and the little counter (number of times warning box closed 300+) I had ktd enabled

heres the log: DPs_BASE.log (7 KB)

Edit: figured out the problem, I had both 803 and 902 in my driverpacks folder, dpbase must default to the older version for whatever reason while checking the newer one against the update checker... a little wonky, maybe a bug.

Took awhile to finish, started at 4:42 and ended around 5:15, not bad though. There were problems. I left the disable driver signing checking option in nLite on (meaning it DID disable SFC) and this time the warning boxes didnt come up. so go figure.

Drivers that successfully installed:
-videocard ati mobility radeon 9000 (5/3/2006)
-Broadcom 570x Gigabit Integrated Controller
-Intel Pro 2200BG wireless

Failed:
-Sigmatel audio controller
-IDE ATA controller (both the primary/secondary and the intel listing show they're using the 2001 microsoft driver)

Shouldn't sound B and mass storage (or maybe chipset) have taken care of those 2?
Also the usb stick (ocz diesel 16gb) that ive been using to xfer stuff like drivers etc detected but didnt install on the laptop, instead a yellow ! came up in device manager next to it and only after going through "update driver" did it install =/

HWIDs.txt - in case anyones wondering. I cant figure out how to link to dells support page but its an inspiron 600m laptop.

Thought it best to make a new post to avoid confusion, ignore the last one or if you're an admin please delete it.

I started with an OEM copy of xp pro with sp2 integrated. I dont know how to identify its exact license. It's volume title is VX2POEM_EN and its 586mb, maybe someone recognizes it. I mounted it in daemon tools and extracted to a new folder

Fired up nLite and slipstreamed sp3. - recieved a warning that hotfixes were present and they would be deleted, hit ok.

Then Added ryanVM's 1.0.3 post sp3 update pack along with the directX9c addon

No drivers were integrated for the sake of bug detection - though I'd like to add a few (touch point, modem etc)

Misc tweaks/settings - Heres the nLite configuration file: Last_Session.ini (13 KB) - the installation was reduced by 154mb for a total size of 479mb

RVM 1.5.4_b09 to integrate OEMSCAN_1.4.1_MR_SMARTEPANTS_ADDON_MULTIOEM_1.8.07.7z - Heres the ini for that integrator.ini (406 B)
I was tempted to check "optimize system files" but thought better of it. Heres the log: RVM_Integrator_1_5_4_b09.log (3 KB)

I deleted DPBase to avoid confusion/problems. DPs_BASE.ini (2 KB) and DPs_BASE.log (7 KB)
Using DriverPacks Base 8.12.4 I integrated the following packs:
Chipset, Graphics C, LAN, Masstorage, Sound B, and Wlan - all the latest versions

Created the image with nLite (left the create iso page open the whole time) and burned with nero with verification on. It burned fine. Beginning install now.

I dont use nLite for driver removal or integration. Why should I set nLite to leave driver signing on? It's disabled by default... I think a few other people would have had problems by now if it was to blame. Can anyone tell me if thats causing problems how its doing it?

Edit: I'm going to make a new post

Were is the list of drivers included? I cant find it =/

11

(2 replies, posted in Feature Requests)

Has this been done yet? Or was it broken?

I get this: http://img252.imageshack.us/img252/1677/grey1mi.jpg

I'm trying to make a kickass BartPE disc with all network drivers included.

Also it would kick MAJOR ASS if it were possible to have a basic app (nothing fancy, just a button per DP) run from a CD to extract a given driver packs worth of drivers to a temp folder/windows folder for when you need to get a comp working again (especially network hardware as obviously you cant get to the net). Maybe another button to do them all and update the windows search path so it finds them automatically as well.

Nono, I mean RELEASE the backend stuff and let other people worry about hosting it. The program would just have the ability to input the server url manually.

Well, if you left the back-end software open, anyone could host it, maybe some nerd out there has some spare bandwidth (heck even I knew a guy with 2 T1's at his house up till a few months ago). Also have you looked into any of those torrent API's? Awhile back I remember hearing about one being made for programs so developers could integrate it into apps. Understandably most drivers aren't very large so maybe torrents aren't optimal, but its an idea.

Not so much a feature request for driverpacks base but it would be incredibly helpful. If you could look at one of those open source driver updaters out there, maybe improve on their detection a little (even the payware ones tend to tell me I have hardware installed that I dont), and get it to use driverpacks as its source... well that would kick ass.

The windows driver update/installation method is kinda broken, 85% of the time it wont find newer versions of a driver online, defaults to older m$ drivers even when you have WFP turned off etc.

Sorry but what exactly is this section of the options for? Finishing touch?

I take it this is running the script to change the install paths so windows can automatically find drivers in the D folder?

Will this clear any other GUIRunOnce enteries?

Nlite first (along with RyanVM, ive never had any issues doing that), then driver packs using Bâshrat the Sneaky Base GUI.

Anything to say? Any comments at all?

If nothing else I really think Bashrat, RyanVM and nuhi with nLite should get together and consider creating something that would remove the need for your guys to be so vigilant about things that will be updated for years to come (drivers, windows xp updates etc) if you guys could create a program much like nlite, a user could keep their ultimate windows xp cd up to date with a few clicks.

h*ll with the right settings file they could have one click update their driver packs, get the latest post SP2 update pack, the latest update pack addons (packs that can be nLited that install applications automatically) and all the little tweaks nLite lets your do all at once. Then it could spit out an ISO image for burning that would, well, be silly awesome for the end user and all you guys would have to do is manage your own areas of expertise. I'd bet that with your combined knowledge you guys could pull it off, or if nothing else learn a few interesting things from each other.

This is addressed to Bashrat since I cant find his email.

I like that you've added the GUI, much more pleasant to work with than the scripts. Though as a user of nLite and someone out to create an ultimate windows XP install CD, it occurred to me that it would be time saving if you could get in cahoots with nuhi and work out some sort of stage in the nLite process to integrate driver packs.

On the sound driver packs: have you considered making one pack for built in sound solutions and another for cards? Your current setup is very close to that already and this way seems better as it conveniently splits the packs into a physical decision (do i have a built in card? will i add one? will this CD be used for a comp that has one?) once the person answers those 3 questions they dont have to worry about the other pack.

You might want to rethink your driver update/cataloging method. Don't get me wrong I love that you've singlehandedly collected most drivers anyone could want, but have you though about how draining and inefficient that is? You not only have to find them all yourself but you also have to constantly get the new ones and update them, and of course update the driver packs in turn. You've gotta admit that someday you won't want to do that anymore and most Bâshrat the Sneaky driver pack users will kinda be left hanging (obviously its not that incredibly hard to do but unless SOMEONE keeps things up to date).

One idea I had was to create a program or website where people could, following guidelines, submit drivers which could then be added to the packs which could be released weekly or something. Another advantage of adding a layer like this would be driver rollbacks, if a driver was found to have issues you (or if you made this open someone else) could just select the previous driver instead of the problematic one and the decision could automatically be made apparent in the pack content list. Something like this would also give the ability to filter by other criteria such as WHQL certification. At any rate you wouldn't be responsible for hunting down the latest driver releases and ensuring that your packs are up to date.

Also if you DID get something with nLite worked out and you DID create this user-dependant-submission-interface working it could give people the ability to just select the drivers they wanted for their own computers and then have an install disc customized for that computer (not practical I know but some people might want it).

Another idea is to change the driverpack distribution model to a bit torrent based system, if you integrated a basic BT client into your driverpacks BASE users could ensure they had the latest packs on hand with the click of a button and your bandwidth needs would drop considerably (you could even use some other tracker than your own).