Search options (Page 80 of 99)

Aha? Bâshrat the Sneaky also liked it..

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 unaware of that too, and I made that error in [C]

One could call it "growing pains", and I really think this should be made "more robust" against such "user" error.

I would NOT have posted RUUDBOEK's text had this project not become open-source.
The end user has had this possibility to edit the INI in all releases for a while now, and little in depth information was public.
Give me the choice between PM or chat, for help... Then I will choose public discussions. Always.

Long time ago, on other boards, some long discussions got summarised, and posted.
A summary like that was welcomed (Came with all relevant links, and all posts or helpful parts posts that got included were credited to the original poster.)

you can bet there are people using snips of posted tips to write their own reference txt.
I am one of those...

mass storage test releases after 70410 and before 70418 (files you got from rapidshare) contain an error.

a fixed mass storage 70418 for TESTING purposes was uploaded, and later versions made me pull this link.

I'll be dxmned
not a single ; commenting out drivers after I fixed [c]

thanks, I did not think of that.

a condensed version is actually in DOCS folder, when you extract Base

reference.ini

70417 can be tested,
it was bad
pulled

trying to make txtmode match what pnp does later on, is what I thought what needs to be done, and it is not easy.

txtmode uses the mass stor INI
and pnp uses the inf
some drivers are unsigned because the version of that sys supports several oems using same sys for their inf, and they got merged, which broke signing.

after somebody pointed it out, I realised that when a conflicting signed one with matching generic hwid in inf is left signed (by not removing generics) then one can get bsod.

people like I, (fairly new at helping with packs) need guidance.
I rather try explain the changes I did, and learn, and when I get it wrong, i take blame and learn.
Being in the dark is not gonna help helpers.

erm, where's the sunglasses when u are in the limelite, eh?

soryy, i am Flemish, and seldom get myself across, but I do hope you see that what you tell me helped me and future helpers.
keep it coming.

hmmm
if D-3 is signed, keep
if SYS for those is different, definatetly keep
unsigned generic versus proprietary? keep signed proprietary

filter (mass INI), that can indeed be changed to not use non-signed lsi-4 for hwid signed in D-3

conflicting generic? (dupe generic HWID)
like Bâshrat the Sneaky said, coffee, and good judgment.
generic signed, keep, unsigned toss away

bad cases, make a silly signed unsigned by killing the generic (keeping the specified subs), if the other supports a lot more specific HWIDs and generics as well.

I think that is what I tried to do, and I also think that is what is best.
I would need feedback on this by specialists like Bâshrat the Sneaky and DDK developers.

Q: What does the entry "ms_count = 1" mean?
A: The number next to the "ms_count =" entry represents the amount of .sys files
that are present underneath the section and should be used during the slipstream.
This entry can also be used to exclude a driver from the slipstream.
Do do this, simply add a zero next to the "ms_count =" entry.
For example:

"ms_count = 0"

Q:What does the "ms_1_deviceName" entry mean?
A:The "ms_1_deviceName" entry represents the full drivername.

One driver can often support multiple hardware devices.
For example: "IBM ServeRAID 4H Controller" and "IBM ServeRAID 3H/3L Controller" both share the same driverfiles.

The "ms_1_deviceName" entry enables you to specify one name representing all these different hardware devices. This name is displayed during the loading of the masstorage drivers for textmode setup.
Since this name has no impact on the proper functioning of the driver itself, it is possible to make up a name by yourself.
It is however strongly advised to use a name similar to the name that is used by the driver manufacturer.

Q:What does the "ms_1_tag" entry mean?
A:Most of the time the "ms_1_tag" represents the name of the .sys file included in the driver.
This name is used to create the compressed files which are located in the I386 folder (example: SI3124.SY_).
This compressed file is decompressed during text mode setup and loaded into memory so that storage media is accessible.
Textmode setup is the blue screen part at the beginning of the installation and enables you to, for example, partition your hard drive.

In some cases there are .sys files present from different drivers, yet have duplicate filenames.
They can not be compressed and placed into the I386 folder using the same filename, because the resulting compressed files would bear the same filename also.

In that case a workaround is needed. The resulting compressed files should get different filenames from the original .sys filename.
The "ms_1_tag" entry enables you to specify different filenames for the resulting compressed files.

Q:Where can i find the "ms_1_sysFile" entry in my driver?
A:The "ms_1_sysFile" entry represents the name of the .sys file which should always be included in your driver.
If there is more then one .sys file present in the driverpackage, please bear in mind that only the BUS driver is relevant.

Often you will find .sys files which include the following in their names:

    filter, filt, fltr, filtr, etc

For example: xfilt.sys.

Those .sys files are called filters and are NOT bus drivers. They can therefore be ignored.

Often you will also find .sys files which includes the following in their names:

    64

For example: videX64.sys

Most of the time that value means that the .sys file was built for the 64-bit version of Windows XP.
Since the driverpack masstorage only supports the 32-bit version of Windows XP, those .sys files can also be ignored.

Q: What does the "ms_1_hwids" entry mean?
A: The "ms_1_hwids" entry represents all the hardware id's that are associated with the driver.

Q: Where can i find the correct hardware id's for my driver?
A: You can find the hardware id's inside a file called txtsetup.oem or in the .inf files of your driver.
It is strongly recommended to always use look inside the txtsetup.oem file. Only when a txtsetup.oem file
is not present you can look inside the .inf files of the driver.

When looking inside a txtsetup.oem file:
Look for a section with the following in its name : HardwareIds.SCSI
For example:

[HardwareIds.SCSI.Si3112_XP]
id = "PCI\VEN_1095&DEV_3112&SUBSYS_31121095", "Si3112"
id = "PCI\VEN_1095&DEV_3112&SUBSYS_34238086", "Si3112"
id = "PCI\VEN_1095&DEV_3112&SUBSYS_311215D9", "Si3112"
id = "PCI\VEN_1095&DEV_3112&SUBSYS_B0021458", "Si3112"

The actuall hardwareid's are located underneath the specified
section ([HardwareIds.SCSI.Si3112_XP].
Hardwareid's always start with PCI\...
In this example the correct hardwareid's are therefore the following:

PCI\VEN_1095&DEV_3112&SUBSYS_31121095
PCI\VEN_1095&DEV_3112&SUBSYS_34238086
PCI\VEN_1095&DEV_3112&SUBSYS_311215D9
PCI\VEN_1095&DEV_3112&SUBSYS_B0021458"

When no txtsetup.oem file is present you need to look inside the .inf files of the driver.
In this case open the .inf file(s) and look for a section called [Manufacturer] inside the .inf file(s).
Underneath that section you should find the name of the section where the actuall
hardwareid's can be found.
For example:

[Manufacturer]
%ITE%   = ITE.Mfg

In this example,  we will thefore find all the hardwareid's in the following section:

[ITE.Mfg]

Sometimes more then one section is specified underneath [Manufacturer]. Bear in mind that if one of those sections include the value 64, in most cased that specific section can be ignored, since it it most probably represents 64-bit Windows XP, which is not supported.

The actuall hardwareid's themselfs are located at the end of each line located underneath the specified sections.
For this example:

[ITE.Mfg]
%ITE.DeviceDesc0% = iteraid, PCI\VEN_1283&DEV_8212&SUBSYS_00011283
%ITE.DeviceDesc0% = iteraid, PCI\VEN_1283&DEV_8212&SUBSYS_00000000
%ITE.DeviceDesc0% = iteraid, PCI\VEN_1283&DEV_8211&SUBSYS_82111283

Hardwareid's always start with PCI\...
In this example the correct hardwareid's are therefore the following:
PCI\VEN_1283&DEV_8212&SUBSYS_00011283
PCI\VEN_1283&DEV_8212&SUBSYS_00000000
PCI\VEN_1283&DEV_8211&SUBSYS_82111283

Hardware id's should be added to the "ms_1_hwids" entry in one line and each hardwareid should be seperated by a comma.
The complete line should also start with double quotes and end with double quotes.

For example:
ms_1_hwids= "PCI\VEN_1283&DEV_8212&SUBSYS_00011283,PCI\VEN_1283&DEV_8212&SUBSYS_00000000,PCI\VEN_1283&DEV_8211&SUBSYS_82111283"

Q:What does the entry "ms_1_isBusExtender" mean?
A:The "ms_1_isBusExtender" entry specifies wether the driver is a busextender or not.

Q:How can i find out if my driver is a busextender?
A:Open the .inf files which should be included in the driver.
Look for a line similar to the following:

LoadOrderGroup = System Bus Extender

If that line is present, your driver is a busextender.

Q:What does the entry "ms_1_exc_skipIfOS" mean?
A:The "ms_1_exc_skipIfOS" entry represents the operating system to which the driver(s) does not apply.

For example:
ms_1_exc_skipIfOS= "w2k"

In this example the entry will prevent the specified driver from being slipstreamed when the OS to be slipstreamed into, is Windows 2000.

Q:What does the entry "ms_1_exc_disableIfOS" mean?
A:The "ms_1_exc_skipIfOS" entry represents the operating system in which the driver should not be included during textmode setup.

For example:
ms_1_exc_disableIfOS= "w2k"

In this example the entry will prevent the specified driver from being loaded into memory during textmode setup when the OS is Windows 2000.
After slipstream the entry of the driver will still be present in txtsetup.sif and dosnet.inf, but the entry is prefixed by a semi-colon which will cause setup to not load that driver.
Excluding driver to be loaded during textmode setup can be quite usefull.
Windows 2000, for example, is limited in the amount of memory that can be allocated for loading textmode drivers.

Q:What does the entry "ms_1_exc_replaceIfOS" mean?
A:The "ms_1_exc_replaceIfOS" entry represents the operating system in which the specified driver should replace an already existing driver.
Some operating systems already contain drivers for textmode setup by default.
For example, the operating Windows XP contains a driver called "Mylex AcceleRAID 160 Disk Array Controller".
This driver can be found in the I386 folder under de name dac2w2k.sy_.
If you want to overwrite this driver by a newer driver you can use the following entry to tell the slipstreamer to overwrite the existing dac2w2k driver:

ms_1_exc_replaceIfOS= "wxp"

btw, JSe?
Thanks.