Search options (Page 11 of 77)

Obviously the answer is yes. More developers on the BASE can only be good. Especially that you're already familiar with AutoIt (and its sometimes odd pros and cons) is a plus.

I personally don't have much time to guide you through, but I've thought already a lot to OverFlow, who's the one who did virtually all the coding for the BartPE support. The documentation on the BASE's code is pretty bad in the sense that there's no general walkthrough. But I'm sure OverFlow and I can provide you with that. The code itself is properly documented.

One last thing though: what exactly are you proposing? I don't see how Jeff's coding isn't flexible enough. A LOT has changed since December/January, the time you created that script (extract DP MassStorage and see that .ini to see what I mean). All those strings you parse manually actually CANNOT be parsed manually, because we have to take a multitude of work-arounds into account. That's why this project's progress has always been so slow: there's no way to automate the entire process...

I think you merely need to copy/paste Jeff's code and make some changes to it to suit your needs.

I see that you want to support "VistaPE". I suppose that'd be a PE based on a normal Vista, so NOT the official WinPE 2. That would imply that you would like to work on Vista support, which is GREAT. I've already received a basic script that slipstreams drivers into Vista. To my understanding, OverFlow would like to work on this too. So that is: a starting base + a bunch of devvers.... that should equate to a nice solution

I'll get you an SVN account, but you'll have to work on a separate branch, for obvious reasons. Please mail me (admin at driverpacks dot net) for those details.

I'd say: welcome aboard

Nope, MSFN has either removed or blocked the DriverPacks forums, although I requested them to keep it online... nothing I can do about that.

No problem.

les, I will create an extra directory on the subversion repository for your work, so your work won't get lost. Simultaneously, you'll have access to all our code and thus to our functions, including the one that parses version numbers

EDIT: just made you a member of the Code Team already

This seems to be a discussion of "If it ain't broke, then don't update." VS "Keep it as up-to-date as possible.". I support the latter. Why?

1) Because it often avoids problems that only arise after some time. I.e. version 2 can be working just fine, but version 3 might add better performance or (more likely) fix some bugs. Note that for many drivers, we don't get changelogs. So we can assume, that if the .inf file didn't change, it was bug fixes. And as wel all know, bug fixes are of critical importance.

2) It's true that we can't always (actually not even often) verify updated drivers, simply because we don't have all the devices. But in general, updated device drivers do not create more problems, they solve problems. See 1).

So, in my opinion, updates are important.

I always tend to use the official site, or at least the site of a trusted brand (ASUS for example provides JMicron drivers as well). Only in very, very rare cases I will accept files from sites such as station-drivers.com.

Yes, documentation is really bad ATM. That will change when the new site will go live!

And you're right. You can just do a normal slipstream, the DriverPacks BASE will first unslipstream all previous ones.

Are you sure you aren't pushing things too far immediately? Unless you're a genious programmer (and even then), you should start with getting the foundations right first, then add extra things

Since you haven't mailed me, I suppose you don't need/want my "HWID transform" function?

Have you rebooted already? You may have to reboot once.

The method suggested by les (and of which I have thought myself too already, of course, but "just" haven't implemented yet) would be faster in 2 ways:
1) By using an index, it will find the correct driver faster than Windows itself. (Note that windows caches parsed driver .inf's! See the INFCACHE.1 files. But we're creating an index, which can be used right away, which is obviously faster.)
2) By using that index, we can selectively extract files. This is the main benefit: now we have to decompress less drivers (decompressing = CPU intensive) and hence we only have to write a fraction of the normal amount of files to the HDD (writing the files = HDD intensive).

@les: the DriverPacks BASE and the Finisher were written in AutoIt. But of course, since you'd be writing it, you're free to use the language you'd like to use. No Java or C# though please, since they have too specific requirements for the program to be useful at all stages.
And by the way, I already have the code that transforms HWIDs into their "different levels of precision" (I think you know what I mean), it's in use by the Finisher, and thus it's written in AutoIt.

I agree with hilander999. Silence equals (virtual) flawlessness in this case. Otherwise this forum (or at least UBCD4WIN's) would have been flooded with support requests/bug reports.

@hilander999: if you don't mind, I won't create that forum at the current site, but only at the new site, which is quite close to be finished. If you disagree, no problem, I'll create a new forum right away.

It's included and enabled in 7.04. Check your DPsFnshr.log for confirmation. (If you can't find it, post yur DPsFnshr.log (which resides in %SystemRoot%) here.)