You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 193 of 213)
Topics by OverFlow User defined search
Posts found [ 4,801 to 4,825 of 5,307 ]
not a good presumtion... sysprep is subject to different limitations than windows so method is important to consider.
IE HWIDs can not be duplicated for sysprep - windows does not suffer from this limitation
therefore a duplicated HWID may be your issue and it would then also be method related...
I asked you to try it with normal driverpack integration to prove or disprove this theory since you have the hardware to do it.
You politely declined ... no i take that back it was not polite.
"no idea about 'normal' method as have no reason to use it."
I gave you a valid reason - so we might be able to help you -
even though this is not a supported method I was still going to assist you.
Seems like the best reason there is
help us to help you..
cdob...
You da man!!!
@jakeld the ris drivers may conflict with normal windows drivers - proceed with extreme caution...
@Vorenus are you useing RIS or SysPrep as well?
Hello psychok9
Welcome to DriverPacks.net
thanks for posting here...
We are not sure how to help you?
We support DriverPacks here...
That is to say our software integrates drivers into windows 2000, windows XP, and windows 2003 Installation disks.
since your OS is Vista:
you are not useing driverpacks
and not useing an OS we support.
if i were you i would contact Asrock @ asrock.com
I personaly avoid buying asrock boards. i have had issues with them many times.
you pay a little more for Gigabyte, DFI, or Intel boards but...
if drivers are installed during setup then they are cached locally on the machine, without KTD.
(windows\system32\drivers\) and (Windows\inf)
and most notably (WINDOWS\system32\ReinstallBackups)
you may use KTD to keep only the packs you wish, however i don't think you need it if you are aware of
WINDOWS\system32\ReinstallBackups
this error is fixed with the new base soon to be released.
mass storage text mode should work alone (without mass storage PnP selected)
can i get some more feedback on the failure -
mass storage textmode should be selectable even if no other packs are to be added... as long as a valid mass storage pack is available.
first thing to try would be to see if the vista counterparts exist for those drivers.
second thing to do would be to do some testing on any available platforms since vmware will not allow us to see if the drivers that seemed to integreate correctly will actually support the hardware.
I suspect that as we add vista support we will have a seperate pack for mass storage vista. however if your testing goes well we may find that a seperate pack may not be neccessary (much the same way 2k3 drivers support xp)
please keep us in the loop as you progress with this...
jhsands wrote:If DPbase extracts all the 7z files to the hard drive, is there not a way to leave them there?
Yes. The way to just leave them there after we are done is called KTD (Keep The Driver)
jhsands wrote:Why go through all that extracting, just to install all DP through KTD when you can just leave them on there?
TIA
JHS
DriverPacks does not install drivers through KTD...
In fact KTD is not recomended by me personaly. it is only good for what i call a Test Bed computer. like a technicians machine on his work bench to use for testing customers cards. (quickly identifying if an issue is hardware or software releated.)
In any other environment;
if you are adding hardware you are physically going to be at the machine and have it open anyway. might as well take the latest greatest driver?
I assume if it is new it won't need hardware added soon. why burn 1.5gig of HDD space on out dated drivers?
Turn KTD off unless you plan on rotating hardware on the machine regularly (like a test machine)
if you are running KTD on a test machine it is likely that you will be reloading it often, and would then be a good DriverPacks tester and have the latest packs all the time.
HardWare IDentification -HWID- number
That is the number that a device (like a video card) reports to windows.
Every device is supposed to have a unique HWID.
Windows uses this unique number to look for a matching number in a drivers internal list.
If the HWID in the drivers inf matches with the reported HWID from the device then the driver is considered as a valid match by plug and play.
short version
i will see if i can... not sure what is invoved yet.
sometimes yes and somtimes no...
that is my experience too
it falls under "other" for sure
I have to check out the new version now too...
it is nice work... it it's quick and easy and effective
that makes is a win in my book 
yes it does seem interesting....
I keep recomending the joshua plugin for two reasons one it has been out a long time two it is as close as we have to a universal driver
It has been out for some time and is bug free. I hoped that it would make it into the packs and reduce the total number of nvidia drivers. that will make my work easier having at least a known good starting point and i think would benifit the sysprep and disk users of base as a side effect.
That is an excellent question.
The answer is NO... the Joshua plugin will become obsolete when I release DriverPacks LAN.
Be aware that we have not created a plugin for lan yet.
Copying the packs to the network folder is quite a bit different than createing a plugin.
I don't like to type so i will not elaborate on the many reasons.
Just belive me that the problems you are experiencing will not exist in a true plugin.
I didn't bring this up before because you were having fun with it and i saw no need to be a kill joy,
that and it beats a blank by a large margin.
i am codeing my butt off ATM on base
i have fixed the M1 double \d error
the bug where the $OEM$ folder was crerated when only masss storage was selected
the HJW pack is now recognized
SP3 support (beta is out on that)
the page profiles errors (base gets lost when the back button is pressed in gui mode)
removing hardcoded folders in Chipset. (there is a new approach to chipset.)
BartPE gets; new verify path code, chipset and cpu support will now precede LAN since you guys did this.
I hope to post the alpha on this as soon as today, but i won't put it up till i am happy with it and i am tough on myself.
nothing is absolute in the drivers business...
probably is the best answer... try it and report back on the results...
Hello gvasile
Welcome aboard, and thanks for the high praise.
They are already created and have been for years...
Does this mean that we already became the "the most complete and usefull drivers collection in the world" years ago?
BTW you forgot to ask about printer, monitor, card reader, flash device and TV packs which are also already created.
blue tooth is not a good standard right now and a pack does not seem feasable until the OEMs settle down.
apparently this has been tried with little success.
LOOK ---> http://forum.driverpacks.net/viewforum.php?id=13
the search feature is already included in the forum too 
Installation platforms would be the primary category appropriate to posting about it.
The PE audience seems to be our most active usergroup that is sysprep savy. Try the new forum for PE if you like - it is somewhat related.
the Joshua plugin for nvidia will probably be teh way to go for nvidia until this is actually coded correctly as a plugin. ( in process atm)
leaky drivers?
. . . can leaky drivers be patched?
bartpe is - for certain types of drivers - yes
Posts found [ 4,801 to 4,825 of 5,307 ]
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.
[ Generated in 0.136 seconds, 5 queries executed ]