Bâshrat the Sneaky

Huh? In your topic start, you say that you're using method 2?

Djees isn't the driverpack like twice as big now? it was in the news 6 months ago ATi would do this... no more CP.... only bloated CCC BTW I install .Net Framework at T12, because RunOnceEx is started directly after cmdlines.txt (this is faster and looks better). the control panels are installed after the restart, when most peoples RunOnceEx is started, I have a second (very very tiny) RunOnceEx that installs control panel and some codecs The DriverPack has increased with about 25%... That's alot of additional bandwidth, if you know that DriverPack Graphics is the most downloaded DriverPack after DriverPack MassStorage and LAN... (several thousands of downloads each month...)

I'm afraid we'll all have to accept that ATI has decided to completely discontinue the traditional Control Panel in favor of its fancy brother, the CCC. I don't like it either, but I don't have much of a choice. I believe it's possible to keep using an older Control Panel in combination with a newer driver than it's originally designed for, but I won't do that to avoid possible conflicts in the future.

Sorry for the late reply. When you use method 2, the OemPnPDriversPath in the winnt.sif file is NOT used, thus not modified. BUT the DevicePath in the registry IS altered, just before setup starts. I'll contact nuhi to ask if he has modified the default DevicePath to get those drivers installed...

You don't have to start it. We're creating backend software along with a C++ version of the DriverPacks BASE, to make it easier to add new drivers and keep everything updated, etcetera etcetera. Please have some patience until then. My suggestion is that you just bundle the drivers YOU need for now...

Please attach the driver. I'll see if I can hack this annoying piece of crappy software out of it without voiding the WHQL signing.

I didn't read the entire topic, but... I may not be creating new DriverPacks ATM (because too many things have to be handled manually and thus keeping all DriverPacks up to date is too much work to handle). *BUT* I am collecting links of drivers, certainly of the weird ones (since they're often harder to track). That seems to be the case for this driver as well: I cannot seem to find that keyboard driver on HP's support page for the ZT 1000-IC. Could you please attach a .zip file that contains the driver? If it's too large, you can mail it.

Yes indeed! Request already implemented, topic closed.

True, but I can't do much to solve this. I'll add this to the guide soon! I've only been notified of this issue shortly. One thing is sure: we're working on a C++ version of the DriverPacks BASE and that one won't have this problem anymore!

@tchuyev: added to my TODO list. @KerguelanAvon: yes, another topic has been started about that: link. Thanks anyway!

Please post your HWIDs. Check my signature for a tool with which you find them.

It's possible that the server that's hosting that particular file went down for maintenance. Now I'm working on a load balanced downloading system with quite advanced features, which will prevent problems like the one mentioned in this topic, and it will also prevent servers from exceeding their bandwidth. It should be online and running in a week or two, three. Problem solved, topic closed.

Request implemented, topic closed.

Request implemented, topic closed.

Request implemented, topic closed.

Request implemented, topic closed.

Request implemented, topic closed.

I also think it wouldn't be of any good to MSFN. Many (thousands) new dummy account is not an insane's fantasy, it'd be the reality. I agree that we need a way to prevent all the spam on this board, but this would certainly not give us the results we'd have hoped for. And of course: just ANOTHER hack...

You cannot possibly compare that. Drivers are already by default relatively minimalistic, or at least in that point of view that you cannot reduce their size by removing or editing files (cleaning them up) without breaking the WHQL signing. If you can live without some of the control panels though, I could indeed reduce them to half the size.

Every methods integrates textmode drivers (your "F6-drivers") using the same method. The used method only applies to the Plug 'n Play drivers included. (If you're installing Windows XP on a system with multiple mass storage controllers, the one to which your HDD (onto which you're installing Windows XP) is connected, will get installed as a textmode driver, since it's already required during textmode setup, the other mass storage controllers will get installed as Plug 'n Play devices, thus using the Plug 'n Play drivers). I hope the above is clear to you.

Every method is completely compatible and "undangerous"... If the slipstream method wouldn't be compatible, it wouldn't be included.

True. Didn't think of that right away. This will also work since Windows XP has the built-in capability to read CABbed files. If you choose this method, you will only consume half the size of a CD.

You don't have to worry about any of that, if you use the DriverPacks BASE to slipstream the DriverPacks: it handles everything for you. That's the reason for its existence. There's a [ur=http://www.uawiki.org/doku.php?id=wxp:ua:drivers:driverpacks:tutorial#slipstreaming_bts_driverpacks]tutorial that explains you how to use the DriverPacks BASE.

Secure? How do you mean, secure? It's not like somebody is going to hack your UWXPCD... You can find more about all methods in the official tutorial.

That's correct. Change lines 19-24, which are by default: IF NOT EXIST %C%A\1 GOTO DPGA2 IF EXIST %S%atioglx1.dll ( %C%A\1\ATICCC.exe -y -o%DPS_TMP% START /WAIT %DPS_TMP%\ATICCC.msi /qn /norestart RD /S /Q %DPS_TMP% ) to REM IF NOT EXIST %C%A\1 GOTO DPGA2 REM IF EXIST %S%atioglx1.dll ( REM %C%A\1\ATICCC.exe -y -o%DPS_TMP% REM START /WAIT %DPS_TMP%\ATICCC.msi /qn /norestart REM RD /S /Q %DPS_TMP% REM ) And it won't install!