126

(10 replies, posted in 3rd Party DriverPacks)

twig123 wrote:

Maybe, split them by brand and type...
HP - Inkjet
HP - Laserjet
Canon - Inkjet
etc...

Your choise though, because you are tackeling the project wink

This is what I had suggested when the issue was discussed on the old forums as MSFN.  Fencer started the original HPLJ DP and I added a few more printers into it.  It was so long ago that I honestly don't remember how well (or if at all) I went through the .inf files.  When I looked into adding some of the HP ink printers I found that there were hundreds of different models.  There are some models that share drivers with one another, but it will involve going through the drivers manually to check for that.

If the current HPLJ DP is corrupt in some way, I still have a working copy which I use in my installs.

http://bugtracker.driverpacks.net/view.php?id=234

This issue should now be resolved.

129

(9 replies, posted in Feature Requests)

If you ever do something that requires your install CD, it's all on the hard drive and you aren't even asked for the CD.  It usually only happens when to try to add/remove windows components.

130

(9 replies, posted in Feature Requests)

I believe what he wants to do is copy the i386 folder to the hard disk and have it set as the install source.  One the scripts in my ScriptPack does this.

131

(15 replies, posted in 3rd Party DriverPacks)

The PITA part of what I was describing is the sheer number of hwids associated Microsoft and Logitech devices.  And of course all the testing to make sure it's working.

132

(15 replies, posted in 3rd Party DriverPacks)

Like it had been stated earlier, DVD-RAM drives are natively supported within XP, so they will detect and install during the PnP enumeration portion of GUI setup.  The drivers discussed here are a little bit different than drivers normally found in DriverPacks.  They're more closely related to the kind of drivers you'd find with Symantec AntiVirus or TrueCrypt.  Technically speaking, yes it is a driver, but it's not a driver that will ever be installed by way of PnP.

I've been working with DVD-RAM drives at one of my sites for years now since the first generation to the more current day models.  If you could manage to make a completely automatic installer for the drivers/software, then you could probably put an exception in the .ini file for the finisher to look for.  I've been experimenting with this concept for HID devices in order to install Intellipoint, Intellitype, Setpoint, etc.  It's a wicken pain in the ass though.

133

(2 replies, posted in DriverPack Sound)

My guess is that about 90% of the changes are additional hwids.

I've been using Method 2 with RIS for quite some time now.  There are a few considerations that need to be addressed.  You may want to check out my program AutoImage for doing this.

EDIT:  I should note that AutoImage does not support RIPrep or RIS via WinPE.  It's strictly for flat image processing.

I think that DP Graphics C is safe to leave out around 95% of the time.  It's mainly workstation drivers for professional level cards.

RunOnceEx is running as expected for me.  I assign it a value of 080 and it fits in rather nice with my ScriptPack.

137

(77 replies, posted in Site & Forum Issues And Feedback)

Google's ads are about the most unobtrusive I've seen.  It's not as though there is all kinds of flash animation, sound or pop ups or anything.  If for whatever reason somebody can't make a donation to help support the free projects that they find useful, then maybe at least they could click on an ad every so often.  Doesn't mean they actually have to buy anything advertised, just a simple click and then close out the window if you're not interested.

I donate not only to this project, but several others in our little world of unattended installs and I still click on the ads every so often just to try and help out.  Of course I also know what it's like to put in hundreds upon hundreds of hours of my own free time into projects that help out others.  Try to have a little more patience and a little more understanding.

Specifically, RC2 had the same issue with the finisher executing all exceptions, etc..  at least from the end user's point of view it's the same problem.  Perhaps under the hood it's different.

@Bashrat, it looks like the exact same issue that hit the finisher in RC2 came back.  Last time you fixed it like 2 minutes, so I think it must be something like a commented out line or a typo.  Everything seemed fine with the final RC.

mp3login wrote:

I tried to post anything that might help though I think your right, the last two files seem pretty clean.

What I mean is that the log files you posted are mixed up..  and your .ini file is listed twice.

@mp3login, I think the last two logs you posted just need a little fixing.

English as well.  The crash even has my name in it  yikes)

I wouldn't get too excited about this hotfix.  Have you read the KB article?  It fixes a MIDI issue.  I seriously doubt that this is going to fix any BSOD issue.  If it did, Microsoft would have said as much.  The BSOD issue, IMHO, is due to crappy drivers.  So long as RealTek and Analog Devices are prominent in the integrated components business, you should expect more of the same.

BTW I didn't mean to imply "right now!"  wink  I just thought it might help to have the feature request documented in the forum for later.

A substantial amount of hard disk space could be saved if the drivers stored on the local hard disk as a result of KTD were to be cabbed.  Since you have already written the code to do all of this for the creation of a QSC, it should be relatively easy to add this feature wink

146

(58 replies, posted in 3rd Party DriverPacks)

http://beeblebrox.org/hashtab/

147

(0 replies, posted in Frequently Asked Questions)

I have been doing a bit of experimentation with the KTD Patterns option in the BASE and thought that I would give a few pointers as to what I have found to work for me.

This is the patterns setting that I am using:

1394\;DOT4PRT\;FlashMedia\;HID\;LPTENUM\;Monitor\;PCMCIA\;SERENUM\;USB\;USBPRINT\

1394\  -  Firewire

DOT4PRT\  -  USB Printers.

FlashMedia\  -  I found one driver that uses this.  Most media readers use either PCMCIA or PCI.

HID\  -  PS/2 port based devices.  Mostly keyboards and mice.

LPTENUM\  -  LPT port based devices.

Monitor\  -  CRTs and LCDs.

PCMCIA\  -  As far as I can tell this designation applies to CardBus also.  I don't know how ExpressCard devices will enumerate since ExpressCard is based on PCI-E.

SERENUM\  -  Serial port devices.

USB\ - Self explanatory.

USBPRINT\ - Also for USB printers.[/list]


I should also explain that the trailing backslash is included to prevent false positives.  Specifically I found when I had "1394" without the trailing backslash, that there was a PCI based NIC driver that was flagged because the vendor ID was VEN_1394.  The hardware root always has a backslash, so Bashrat pointed out to me that this would be a good way to eliminate that problem.

I have done a bit of testing with creating Method 1 sources, but not running them as I never use Method 1 personally.  What I have found is that when using all of the official DriverPacks and some of the more common and stable unofficial DriverPacks, the OemPnPDriversPath often exceeds 7,000 characters.  This is obviously well above and beyond the 4,096 character limit.

In the past, when I did use Method 1 from time to time, I had run into circumstances where it would be around 5,200 characters.  I never had a blue screen as a result, but I did have some devices which did not install.  When I looked into why they did not, sure enough, their directory listings were past the 4,096 mark in the OemPnPDriversPath.

It's a request only hotfix so it would need a serious amount of testing.  The request only hotfixes with driver updates have given me a crapload of troubles.

The O2 Micro and the Ricoh drivers are both in the unofficial DP Misc.  I've been installing quite a few Dell laptops lately and it finds these devices.  Quite a while ago there was some discussion regarding the inclusion of such drivers within DP Chipset.

@Bashrat, I don't know what your thoughts are these days regarding such a move - to include quasi-chipset type drivers with DP Chipset.