sorry for the long time since last reply, -  but this was the actuall deal,

the whole point of driver packs it not just for 1 cdrom for all hw,  but also (in my opinion)  for simplicity of installing.
if you need to install multible systems in say a corporate inviroment  its really helpfull to build a cdrom that atomates the install for a certain deal..

but in the same time you would want to have sufficient space left on your disks to incorporate other software (like  netframeworks - pdf readers -  zipfile support (i use 7zip). and some other default tools..

if your an experienced user,  you'd know  what your target machine is like...   therefor having a  all nvidia-chipset  cdrom would be of more value than to have  sis via intel and amd  as well.. 

id rather build a set of disk  based on my targets    1 cdrom for  nvidia (chipset grafics  lan sound  etc)    another  one for  amd  (with ati grafics and such).   and one for the rest (intel via sis etc) ...

in the topic its called a per machine  pack,  but id recoment a per  platform  pack instead...  (or even better)  spitting  ALL packages up
for people to select driver sets themselves...   

how unusefull and unpractical is it, to have about   200mb of drivers on your cdrom that youd never use...  (for example if your an amd fan, or perhaps an intel fan, )

2

(11 replies, posted in DriverPack Mass Storage)

probably  (not realy)   the whole reason why  "method 2"   uses a fake  setup.exe  instead of  (whatever .exe )  is because   running one at the end of txtmode is still not possible  at this point i'd recoment  one of 2 choice 
either you  use the F6 key   or you would  nead to create a magic multiboot  cdrom  - there in fact the only noticable diference would be   the set of drivers that you include...   

the 1 thing that i DO wonder is if its possible  ( i never checed )  to instead of useing a flopy disk  it would be possible  to use some kind of  supdir on your cdrom  or  usb-pendrive ...

at the current dp-base  it only checks for  a few names....  dp_grafics_A etc...
but to me this is rather un-usefull   and i would rather see way to un-merge this packs to for example chip-specific (nvidia   ati  sis  intel   etc)  packs... 

also, the handling the exeptions  in this case  'sh'could  be handled from a file within each individual package, 

sure this would  make handling the packages a bit more complicated  but it also enables system administrators to better target a driverset incorporated into the iso,
leaving more space for aditional software...

at this time i believe it could be a usefull next step for all driverpacks  ECCEPT the mass-storage pack (witch isn't to big and should be kept for simplicitie's sake just as it was)...

yet maybe this becomes a problem for drivers that mix into more than one vendor,
this is why at the same time it might be usefull to  rename packages to the chipset names of an interface card rather than a vendor name...

an updated wiki could easily provide info  what package to use for what device...
specially usefull for most lan and wlan drivers ....

well i dont want to go into a debate about  what windows source people should use, (or not use),  but the last time i check ubcd had some tools like cdburning apps and other that where hard to get a licence for...

*its been a long time since i checked, an i usualy have to look at it from a  'professional ' (comercial) point of view ....

and to be honnest - i probably wasn't thinkin about how my prev post would sound like, something i didn't meen to say...

The thing is that i wanted to mention that using bartpe instead would have you not install plugins that you dont have a licence for...

well to be honnest -
iv been working with live cd's for a long time now (mostly based on damn smal linux in the early days...  and i always tell people, -  carring cdroms, with you al day is a .... b@#tch -  now day's  i usualy try to fit it all intal a 1gb iso limit... 

this leaves you 2 choices.   the first is a wallet size 3inc mini dvd ...  the second is a 1gb usb stick..   

this 1gb is a rather fun size limitation... 
from the point of a windows xp perspective  and the multiboot way (in the way that 3in1 cdroms are created)... this should leave you about 600mb of space for driverpacks,  and aditional software.   

Do note that i find to have a verry usefull reason for  choosing mini dvd's over full size dvds...
Its not just because you can, or  because they are cheaper than fullsize dvd's
(in fact they are actually more expencive),   the main reason for using mini dvd is that its small, and fits into you pocket more easy.. 
But also because a smaller cd-case is less likely to break and scratch the dvd...
(by making it more transportable, you also make it safer against damage)...

all this just as a side-note,

well 30.000 drivers now and in a year from now, there will be  3 new cpu's   probable also about 5 new  lan and wlan chipset (to even be able to get to windows update youll need those).   a whole lot of storage chipsets for  sata and raid 

within its lifespan vista WILL need driverpacks...
and it will need lots of them. 
there is not a single doupt about it..

my other posts merely state that i dis agree to  Driverpack Base   being vista compatible..   vista just has a verry diferent setup systeem with lots of new tricks and pulls, 

i state that there SHOULD be a Vista version of the Driverpacks ...
but i should be for vista and vista only  and it should be based on tricks that are as native to vista as possible  preferable with as little hacks (and hacked files) as possible..

apart from UBCD being way beyond illigal wink,   
with any PE builder that  makes you have to use your own windows cdrom,
it could (or maybe even should) be possible to add more drivers. the problem at this point IS though that adding these (uncompressed) drivers to your boot  would almost completely kill all the space on your BootROM (dvd),   

So overall,  these 'cd' driverpacks might just be  a real pain. 
i wonder what would happen with a programm like PE builder  when  Storage drivers are cab'ed and then included in  txtsetup.sif   -  and the pe-builder is  given That (instead of a virgin cdrom) as its  source..

i still never realy understould,  why al the complicated scipts... 
because if i just run a lowlevel sysprep (and remove all the driver-stuff... )

there shouldn't be any thing wrong with setting pnp driverpath to   %windir%\driverpacks  -  the only things i DO have to worry about is that ALL userdata  stored in a profile  like   documents and settings\THIS USER\aplication data\   should be moved to the  %alluserprofiles%,   to prevent users from having to  'register' and stuff like that..

setting the hall is supposed to be done but the native windows installer -
after any sysprep action...

can i care to dis-agree to this topic

oke here goes the arguments..
its been quite a while sins i last visited these forums, mainly mos of my pc are linux based now-a-days, but im still  interested in running BTSDP for 'clients' who still use windows based..  for older pc's (below 1,5ghz and 512mb ram) i still tend to install windows 2000 with a whole bunch of Opensource Alternatives to windows programme's ,  just for this reason its verry usefull stil to have  DriverPacks at hand..  and even still  in my honest opinion there is still mutch that might be
possibly improved

for example maybe:  smaller, and more specific - driverpacks  - or more os specific driverpacks  (removing files for 9x 2000 if installed to an xp target or stuf like that),   

the Bâshrat the Sneaky way has be verry mutch improved,  for the  windows NT 5 (2k / xp / 2k3) 
generation of windows...and we should NOT in any way want to F*ck that up .....

Vista is a complete new system that is WAY diferent in setup and the installer proces has evolved into an entirely diferent thing...  and i care to ask if its even wise to try and do the same to the vista installer to what we did in xp (method 2),

That is why i suggest investigating the vista install process verry thoroughly befor ever thinking about the way to extend its driversupport... as it may well be virtualy  a world of diference with xp...

be sure to use the correct sysprep level though....  read its documentation, to see witch levels there are...

not so hard -
step one, is easy,
step 2 isn't hard either,
step 3 and 4 - i gues youl manage.

> setup 5:
run the setup managers found in deploy.cab,  youll get an answer file,
carefully read that file and see what, where and when it doen stuff.
and whicht parts of the origin are avail, (try to setup a time line if you will,

im not shure about syspreped systems though,  - but in normal mode there is an option to set the custom driver paths, to c:\d\*\* 

Bashrat alrealy made 2 examples

> the one in the answerfile (witch sysprep will most likely support in full, 
> and the   custom aplcation used in method 2 [small(to regimport the paths)[/small]...  -  im not shure if that would work....

but since you probably verry mutch know what drivers are used, - i guess it would be smart for you to do the work and make your only driverpacks  for  vga and sound to save a bit of space and bandwith on your ghost-casting.

11

(2 replies, posted in Feature Requests)

so verry possible,  but the question is,  do you want it to automatically check for any  dp****.7z in a loop,  or dont you care about that and just want a cdgui that uses a config file (will take a bit more time to update your cdrom (or dvd) - (cause you may have to update your  settings file...

with the help of my favorite tool ( W.A.I.T ) its not all that hard to do,

quick reply ist only SO VERY D*mn easy to add text or a logo to the dp stuff,  - because the creation of these progress bars is dont with  7z.sfx files,   translating them is as simple as,  using resourcehacker to 'change' the text (or image),  adding those *few* extra  language things would hardly take mutch space,

what i wonder though, (has anyone ever tried??? ) *  - is what happens if you just  put a whole bunch of langauge codes,   - wouldn't windows autmaticaly select its own langID if avail,

*afaik it should work, *

just my 2cts. -  if you get to have a virtual private server- with root-access,   be smart and install a torrent tracker + a seeding client on your server, -  if your even, smarter set it to super seed... only.. that way youll only have to support the  'hard to get' parts and let  peers be responsible for giving the better part.  (even if it only saves you  10% of bandwidth its worth it... no?)

with regards...

it wouldnt be hard to create a litle VB4 or vb5 (lets keep it safe, so old compatible)...
dialog that  looks for  all  *_driverpack.exe  in %SourceLocation%  and list them and thair size...  and an overall progress bar... -  there are realy good API's avail for 7zip .... but than again - is it worth it...

vista is not something you want to support in driver packs, as it is verry diferent in setup,
if you want vista support, i guess its al about starting from scratch. 

please dont ad vista to the  2k xp version it will only mess things up,

i was more or less thingking about,  supmitting it as feature request as it is rather stupid that it isn't implemented yet.
(for a real programmer, its no more that, addin 1 exta  function call to check for,  (almost an exact copy op the target function -  just with other variables ... and ofcaurce a dif handle after the var is set ... (if only it was in kyx / delphi or basic - id be able to do this in an hour... )....

- but in the mean time yea it is for now just a matter of,  hex-editing it...  (1 for every dp)....

btw, strangely enought i cant even find a comand string in the 7z.sfx  that support   comandline argumented text.

for example   

example_7z.exe /q x /d"c:\temp\" /text "extracting example_7z [1 of 5]"

or something like that...

verry nice script. but but when i looked a bit closer at the driver-pack  base,  it works just a bit diferend...
(thus making your scrup un-usefulll ... ) because the driverpack base itself already toutches the driverpacks... and murging them in new order...   so after the dpbase  takes a file and creates a new one its litle work to just  copy $file + 7zip.custom.sfx  newfile.exe ....

but i do like your script.. it looks nice...  cleans up its mess and is code neatly...

its only just shortly that vista went to RTL (final) stage... - it will take a while before most hardware wil have stable OEM- drivers for vista  (als it will be harder to include non-signed drivers - but it should still be possible...

i like your 2nd method as its clean and easy ...  it will not be really hard to change to this,  (as it wil only ad 1 line to the dp base 

copy %package% + custom.sfx driverpack.exe

why didn't we figure this sooner ... :S

*

Why not replace completely PRESETUP.CMD with an AutoIT

*
i have to dis-agrea here though,  there are so many better ways.. 1 for instance is a compiled ' Visual basic '  program,  i would recommend an early version like VB5 though, im not sure what versions will run this early, and in windows 2000, as it MAY lack vb-runtime files.

an other, (maybe better) way is a compiled  batch of quickbasic  script.  it will run (without doubt), but it will not look as pretty, as vb5 ...  >> quckbasic or compiled-batch doesn't nead runtime files so that makes it better for the job, also i'd suspect it to be easier to code than auto-it scripts... 

a thing though is that i cant think of any way to query for a status ... (like the  ..% extracted in 7zip)
>> unless you use sfx files (self extracting archives) ...
with sfx-files you would be able to show a popup window with the <cancel> button disabled...
and with some resource-editing in the text  saying... 
"extracting: $file_name [1 of 6]  " /  " extracting: $file_name [2 of 6]  etc.

- but i wonder if its worth this much trouble....

ow btw - if you also need the lan drivers, you migt nead to take a look at some inf file or something,
im not sure how pe is configured  (to use pnpdriver paths for  non txtmode  drivers...

mass storage could work allready loaded in the blue (dos) part,  but lan is done later ...

and thus - we never heard from it again smile,  by the way, id never consider trying to install windows from a linux source - or even a dos source (winnt.exe) for that matter,   if id want this,  i would most certainly build an installer like the  9in1 or even 35in1 cd / dvd's that already exist,  as there are perfect tools that  use  symlinked files if they exist more than once on a cdrom, (just the way MS does 't).

in theory it would enable me to store as mutch a 50 diferent windows xp sp2 configs on 1 dvd  and even have more than sufficient space to add (unattended) aplication- sets ... 

i could even use nlite to modify every single one of them  with a custom set of modifications.   (that at most would sost me perhaps as less as 5mb per version (only the inf files will change - and thus stored more than once) 

at least it would be soo mutch easier,  (by the way if you use isolinux to start the diferent chains  ... there would probebly be some sort of gui that could should text or pictures to preview ....

i might be mistaking but if you slipstream mass storrage drivers in  dosmode  (and after that use the slipstreamed  source to build you WINPE iso from...  shouldn't it just work ...

i havent looked at bartpe for quit a while, -  (but if you use PE-builder  after a method 1.  it could work  -

Tnx for your reply.

than i wonder,  what if you'd merge method 1,  (all drivers in  %systemdrive%\DP
a reg-installer from DetachedPrograms -

if that would work youd have the advantage of  method 1,  Without the MaxChar-Limit ?????
as well as it 'might' be 'fully' compatible with  sysprep?????