5,226

(88 replies, posted in Feature Requests)

I have to go with Helmi on this

Most of my clients have many systems and are not going to go out and buy hundreds of copys of an OS and switch all their machines redevelop thier software and retrain their users. Since I could use the money why don't you see if you can talk them into it for me.

5,227

(5 replies, posted in Feedback and Support - DriverPacks Base)

well yeah - it's a very strange one for sure - probaly something stupid like it's just a loose connection

5,228

(5 replies, posted in Feedback and Support - DriverPacks Base)

i ususaly like to install my keyboard - hee hee

5,229

(4 replies, posted in Translations Team)

Great, SoKoOLz, thanks! welcome aboard sir!!!!!

jtdoom wrote:

hi

my mistake
I was preparing a version without folder swaps, and got interupted.
I'll correct it
I've had no "go" nor "don't" signal on folder swap changes, but can tell you that when swaps are done, the supported device list on the site also has to be changed, and I wanted to spare Bâshrat the Sneaky this extra work.

I was talking to Bâshrat the Sneaky about flattening the structure to extend mode 1 support and he liked it. but it fell on the floor when i was codeing bartpe plugin.

me wrote:

I think it would also help us and them if we flatten our folder structure a little. I know I read somewhere that you were planning on doing away with method one but I like it and use it from time to time. Certain drivers like the SoundBlaster drivers for example are included with windows but are older and won’t get the newest drivers from the pack if method one is not used. They get the default windows drivers instead of the pack drivers and then you have to go to device manager and “update” them manually. I run into this when I test stuff in VMware using method two, my WPI won’t play the music file I have for that because the windows SoundBlaster driver that gets installed when using method 2 isn’t appropriate. I digress. We have over 950 folders. So there is considerable room to shorten our path statement. For example in the mass storage we have now is D\M\3\1\O that is 9 characters for the path name if we made them D\M\31O, D\M\31, D\M\32 there would still be 127 folders but D\M\31O is two characters shorter for the path statement. Following this logic we could shorten the path statement by over 150 characters just in mass storage. I don’t believe there is a danger of hitting the max file limit per folder.  If we did this to all the packs we could reduce the path statement by well over a thousand characters maybe almost two thousand. The flattening of the folder structure would also be a benefit for both network and mass storage integration to BartPE. I believe this would help both projects.

Bâshrat the Sneaky replied wrote:

The "path optimization" you're suggesting is quite interesting though. I've already optimized it very much over time, but this would indeed shorten the path and still keep things manageable.

Somthing to think about since you are totaly restructureing the packs.

JSE wrote:

Yes, you are right, I did not completly understand this functionality, but please note:
1. It was not me, who used this ms_1_exc_disabledIfOS="wxp", I was only the one who wrote that this option caused the problem of commenting out _all_ drivers, not only that one, that had this option applied that follow this driver.

2. What I still would call a (possible) bug is that an option, regardless if it is usefull or not at the point it had been used acts on all the following drivers. And if you dont like the word bug then let's call this unpredictable behavior we should be aware of if it happens again.

I disagree it it does what it was designed to do it is neither a bug nor unpredictable.

it is used for w2k to prevent drivers from loading into ram to prevent ram from being used up and it does.
We have yet to add enough drivers to find these limits on XP or 2003 and is not needed or supported.
if you put Garbage Into the .inf file you will get Garbage Out (GIGO). that is not a flaw with the base it's user error. the "meat" virus.

Lets agree it was just not well documented.

Id like that!

This happens quite a bit with method 2 - the drivers are not available early enough in the setup. and teh driver itself resets the screen rez. when it installs

5,234

(5 replies, posted in Feedback and Support - DriverPacks Base)

We have been seeing this intermittently

(i see it on my installs to) i'll look at the disabler script and see if i can figure it out.
any info you may find may be helpful

5,235

(5 replies, posted in Installation Platforms)

the plugin created by base must be in the bartpe\plugin\(here) folder and can be verified with pebuilder  prior to build by checking the plugin list- driverpacks plugin must be available in the list before you build.

WINPE has not been tested... It may be possable.... but we are still in beta for bartpe.  YOU TELL ME!

5,236

(19 replies, posted in Other)

an easier way would be to have the drivers setup method 1 style on a cd/dvd - if desiredyou may use oempnp path pointing to the cd/dvd but probably not needed since the cd/dvd will be searched anyway by new hardware wizard.

then drivers would only be copied to disk if "new hardware found" installatin wizard found them on the cd/dvd.

in the post below SKIP the batch files and just Copy the OEM\$1\D folder from the slipstreamed source to a CDRW

IE run the install "method one" to a temp windows install folder then copy only the "\d\" driver folders to your cd/dvd. Probably will have to be a dvd as in this format the driverpacks are around 600 meg.
                 
full directions here for making a disk that DOES copy drivers from this cd to windows
(you dont have to run [or even create] the Batch files)
http://forum.driverpacks.net/viewtopic.php?id=960

because you dont understand something does not mean there is a bug in the base.

disable was not what you wanted
ms_1_exc_skipIfOS=  or set  ms_count = 0  are to "Disable"  a driver (from your perspective) 

the ms_1_exc_disableIfOS= "wxp" means something totaly different to the Base program.

"load the driver for plug and play but; in a DISABLEd state during text mode setup."
We have never needed to do this for any OS except windows 2000.
the only reason we do this is because at a certain point windows 2000 runs out of available memory to load additional text mode drivers additionaly this is only a problem in text mode . so we want the drivers available to windows but not windows setup. so we _disableIfOS on some drivers to free ram.

i would NOT do that the ini is not done correctly

[I-1]
ms_count             = 1
ms_1_deviceName        = "IBM ipsraidn ServeRAID Adapters (Windows 2000/XP 32-bit)"
ms_1_tag            = "ipsraidn"
ms_1_sysFile        = "ipsraidn.sys"
ms_1_hwids            = "PCI\VEN_1014&DEV_002E&SUBSYS_022E1014&REV_10,PCI\VEN_1014&DEV_002E&SUBSYS_002E1014&REV_0D,PCI\VEN_1014&DEV_002E&SUBSYS_00000000&REV_04,PCI\VEN_1014&DEV_002E&SUBSYS_00000000&REV_03,PCI\VEN_1014&DEV_002E&SUBSYS_00000000&REV_02"
ms_1_isBusExtender    = false
ms_1_exc_disableIfOS= "w2k"
ms_1_exc_replaceIfOS= "w2k,wxp"
ms_1_exc_skipIfOS= "W2k3"

That Is wrong.... replaceIfOS= "w2k,wxp" 
implies that ipsraidn.sys exists in a native w2k or XP install and must be backed up removed and overwritten. it is not natively supported in either and is not a replacement. 

This may seem a small detail but it will totaly blow up the slipstream of driverpacks base. It affects which entries in which files get changed during the slipstream process. Skip does mean don't use at all, as you thought. You also did not indicate that you had properly groomed your files before making the folders.

There is actually a long list of things wrong but I dont want to seem to be flaming you.

So

1) all of your ini's are done incorrectly and although may work on your OS and PC will not work as intended (on ANY OS / machine)

2) your files are probably not technicaly "ready" for the pack (but probably work). 
Please add [REQ] in front your first post title and well do it correctly for you!

I would REALLY REALLY REALLY like to thank you for being so thorough and spending so much time putting this together. very nice documentation of what you did. (other than the fact it is trashed i like it)

Perhaps you would like to join the team and we can assist you with adding and testing drivers.
Muiz (Leader of the Packs- hee hee) is always looking for motivated people who can document thier work.


These two have a second thread running here too

also please read jaaks post at the below link and understand more of what im not trashing him about!
http://forum.driverpacks.net/viewtopic. … 029#p10029

WE support windows 2000, windows xp, and windows 2003.

If you use any of the three above listed OS's then
the proper drivers for your OS will be used (if we have them)

IE if you choose a 2003 OS in the Base as your OS then only 2003 drivers will be used for the slipstream

if you are useing the driverpacks we address this issue.

jsut be sure slipstreaming the driverpacks is the last step

Please do Stuball56

and Muiz worked very hard to put up a test driverpack and nobody would test it, the topic was closed.
If you create an XP installation CD useing the Driverpacks base AND the test driverpack referenced in the post, it may help lots of others who seem to be in the same boat.

We don't have every possable type of hardware avialable to us for testing.
We need people with the hardware at hand to test the packs.
We can't add drivers to the packs if we dont know if they work.

I thought so...

there is quite a lengthy post about this here -->

http://forum.driverpacks.net/viewtopic.php?pid=8701

a google search for the line below takes you right there too

PCI\VEN_8086&DEV_27D8&SUBSYS_FF311179&REV_02

your "Sound Card" is a
(Microsoft UAA Bus Driver for High Definition Audio)

5,243

(38 replies, posted in BartPE - UBCD4Win - WinPE)

No news...   Might be...   Good News...

in this case!!!!

You will find a few suggestions to get you started scattered around in different threads
Sorry they are not all together in one spot but as you realized already it's not primarily what driverpacks is designed for.

Fortunately we aren't very strict.    big_smile

@helmi
Maybe we could get all these together in a topic?

try this too 
http://forum.driverpacks.net/viewtopic.php?id=641
http://forum.driverpacks.net/viewtopic.php?id=1291

Let us know if you get stuck!

HWID's please and well see about those drivers (use link i posted above)

a simple search for sysprep might have served you well!

http://forum.driverpacks.net/viewtopic.php?id=768

http://forum.driverpacks.net/viewtopic.php?id=227

try those twothreads  to start then try the <search> feature! before reasking questions that are answered already

keywords RIS and SysPrep.

post hwid's please!!!

cdob is correct BartPE has never been supported before

and he is also correct that the plugin created only has drivers for mass storage text mode.

any other driverpaks including regular mass storage drivers (the non text mode support drivers) will be ignored when creating a plugin.

this will change once the mass storage text mode drivers prove to be stable and no bugs show up.

are you using a program other than IE to get yoru files? are you using a download accelerator?

the server has been under quite some load with the new releases too

doesnt sound too tough to code actually - but how neccessary is it? - i for one probably wouldnt use it.

Id find out it was broke when i tested in VMWare. lol