Search options (Page 152 of 213)

because it may need to be updated...

IE i cant tell you how many times i wish i had the source code for our setup.exe. I am just SOL on that one.
I am not going to do to someone else what i would not want to be done to me. ( and it has been and i hate it )
If I include something with base then the source code for it will be available to the code team, period.
   ( Wim can of course do as he pleases )
We have no intention of useing more than one language to code DriverPacks.
You and I might both get hit by a truck on the same day

for many reasons... is the reason

yes yes yes... yes and yep.

wouldnt even need a dialog if they select no packs ther is nothing for the finisher to do...
no reason to keep it - so no reason to bother asking...

-------------------------- more

It is quite a bit easier to add it to base than to start from zero and duplicate the many functions that are already included with our programs (75% of it already exists as subroutines)

For example - converting 8.3 pack names to thier full names is an existing function that is built into the code 
You are useing a data file for this. So i would not need to do that i would just call the routine .
this automates a now manual process and eliminates an unneccessary file.
by extension there is no need for you to write a routine to do this since we have one.
I cant give you code bytes or subroutines to use because you did not take the bait when i offered AutoIt as your starting point.

What you have works. It is simple and effective. that is great!

Let's see if what you have already put here generates any interest before you or I sink a bunch of time into it.

If it IS popular then I will make it a feature,

I can add the features you are suggesting with a lot less trouble / code than it would take for you. especially like the pack names and finisher pathing type of stuff that we have existing code for.

It also adds fuel to the attended setup as a supported platform as well. That has become a more popular request but still not a top ten item.

'good grief' is an oxymoron

you jumbo shrimp! LOL

same request as here sir! http://forum.driverpacks.net/viewtopic. … 142#p22142

Useing "D:\pebuilder\drivers\SCSIAdapter\ahcif6flpy32) , it didnt work there."

Is a technique that is mostly obsolete with the driverpacks plugin.
if you wish to use that method, then you can not use the Base mass storage plugin at the same time.
\drivers\SCSIAdapter or DriverPacks mass storage plugin, not Both... The likely hood your driver will have the same name as an existing file is to great. if two files have the same name the last one copied during the build process is used. (this also does not generate a build error) this can cause huge problems.

the bes thing to do is to get your driver added to the packs since we now know that that HWID is not supported lets get it and add it and then it will be supported!

Thanks for the excellent details and your feedback

Have a great day and welcome to the forum

thinking it through...

if we select all packs then we still have the same conflicts as now...
... we dont have to select all packs

if all the ati are in one pack (includeing the mobile) then we still have the same conflicts as now...
... ?

what if the new folder was G_Com (Common) and contained the main files...
then if ati mobile or GA was selected then G_Com would automaticaly be selected?

i really differ to you mr_s you are the Graphics Master and i respect your experience and viewpoint.

that error is indicateing a failure / absense of kb888111

as i said SP3 includes kb888111 - correct, it won't install on sp3

you have an issue with your source files

Hint: Google PCI\VEN_8086&DEV_284B

would you mind detailing your steps to install XP?
IE  how you modified / slipstreamed your UWXPCD...

ryanvm? nlite? driverpacks? other...?

good thinking on the file name Jaak! well done.

you always get brownie points for being observant. 2 pts awarded Twig123

Yeah i figured you didn't know about the compression, which is why i threw it out there for ya!
How would you know if someone didn't mention it?.. (shrugs) now you know, lol

I am certain it will be just fine as it is - idk exactly how much better the size would be.
perhaps very little... just something to be aware of
 
i am so glad you did this for the poster it was very nice of you
I hope we get a positive response back and can confirm a valid update of this pack

Thanks again Twig, well done

PS the brownie pt catelog will be out in the mail

Fragbert did what i am usually guilty of. he gave the correct answer. it just did not read well/nice.
he meant no harm, i assure you. We're techs not english teachers LOL. I really liked your response hee hee.
I find that if you phrase things as a question (Which you did - yay!) and say please and thank you it draws better answers.

don't worry if we use an intel or any other brand of driver. if we have established that it supports a certain HWID there is no reason to worry. drivers are matched by HWID not by name, names don't matter at all.

on some occasions especially with certain OEM (like dell), a card will have the same base hwid as a generic ( say nvida ) but the dell graphics card will only work with the dell driver. in these cases we can make edits to the dell inf to limit it to a specific card (HWID subsystem) so it coexists with the generic. This doesn't happen very often...

The best thing for everybody is to test it. If it doesnt work give us your HWID and tell us it failed...
We will figure it out and fix it.

Even better for everyone is to test it and let us know it worked!

Thanks to all of you for your help and the time you spend here.

Jeff

I dont think adding a pack is very difficult. It would take me a couple hours to code test and beta and a couple hours to modify the existing packs and create the new one. the hours that it would take to do are not as signifigant as the result. If it is worth doing then the time it takes is a secondary concern. Lets do what is the best solution for our short and long term goals.

hmmm...

i am still leaning twards upgradeing / replaceing the integrated windows driver as the best solution.

I am just not sure waht files in addition to dosnet and txtsetup need to be modified so syprep will play nicely with the upgraded files.

It is likely that a file copy is failing - file is in use, can't replace errors

just my thoughts. i still think you can make an entry in the INI and call the dell setup.exe from the finisher that should fix it. It will probably require a reboot.