Search options (Page 30 of 99)

Since I downloaded from the index page, which is mentioned in the opening post, I clearly did.

WELL..
I would get lost.
Please don't quote our Signature lines.
MY signature line line links to two tutes in one link and to a far away site and none of those [[ VERY SAD ]] would  have direct nor indirect redirects if you closed the web page you was reading.

WE GO POOF.

MY signature line should say.. TRY to stay here. IT is a challenge.
Hmmmmmmmmmm. sounds good.

Hi
the main reason current NT5x (aka 86-32 DriverPacks) have so few vista in them is that a LOT of pruning was done in folders, and also X64 was often removed for they was seen as "unwanted" bloat.

The vista pack should not drop X64. Never.
The reason I say that is because the 2008 releases will use the vista drivers when they cannot detect the hardware in the upper levels of the OS install. (The Kernel of server manager 2008 sits on X64 metal, the "driver repository" partition is at a higher level and can be populated with third party.) (There is a X32 version of server 2008, but X32 won't have server manager. X32 is more or less a client and can be remotely managed with the manager tool in a X64 version.)

Hi
I think I know what he means.
I have seen this white line (where the progress should show) while windows starts on other old computers, way before I used DriverPacks, and installing the driver did not get rid of that.

Can you let us know if there is a problem once windows runs?
Did the driver load OK?
If NOT.. Does removing "our" driver and installing another driver fix this?

hi
http://www.blackviper.com/WinVista/Serv … ervice.htm

quote
Dependencies:
What service World Wide Web Publishing Service needs to function properly:

HTTP
Windows Process Activation Service
Remote Procedure Call (RPC)
DCOM Server Process Launcher

I would want to know what happens when you do this, because LNV7 may be the problem for you.

Hi
for SP1 you need WAIK 1.1.

it is more advanced than waik 1.0
This should contain a powershell "compliant" tool which can export the unattended.xml for you.
(and you will need an xml for each OS, not just ultimate... You can actually also configure the unattended.xml so it looks for the images and files on a deployment server.)

@ OverFlow; There is a bit of good news.
Vista drivers should work for server 2008, and the WAIK 1.1 can handle 2008 just fine.
The server manager tool in 2008 and powershell/waik tools work seamlessly together.
I will soon start toying with things like this and the presentations I saw at techdays will be of help.

Hi
I apologise.
I thought you wanted to change the way finisher looks when it runs.

I found this:
You should do this in winnt.sif, and add the proper files to the source.
http://articles.techrepublic.com.com/51 … 13860.html

quote
If you wanted to make a custom setup that had your corporate logo or something like that, you would need to place two files directly into the $OEM$ directory. The files are called ourlogo.bmp and backgrnd.bmp. The ourlogo.bmp file should be roughly 175x175 pixels and the backgrnd.bmp file should be 640x480. Both files should be in a normal BMP format. After dropping these files into the $OEM$ directory, you would need to modify the installation script so that Setup will use the new images. To do so, you would add the following lines of text to the script:

[OEM_Ads]

Logo=ourlogo.bmp

Background=backgrnd.bmp

GREAT.
However, I want the report on BOTH systems.
Full report if possible. (we need the relevant HWIDS in the system you tried this on.)

I fixed this for MC67, and hope it still works for MC630a...

Thanks galapo.
I have not forgotten the short-lived testpack.
Galapo knows we tried a private test of mass storage with unique INF, unique service names, unique systemfile names... We found out this is dangerous to the project (cannot publish), is not easy to do in private, and the tests have to be done per driver, on hardware for each separate driver.

We cannot be the solution for everybody. BUT... We do want to learn about WHAT works.

We are currently trying to do write-ups of very useful knowledge, summarised or in dedicated topics so as to get good info easily found.

Hi
I see you posting all over the place..
I don't know if you use an ISO or run install from a burned DVD while you are testing in VPC.
You might want to first use memtest.
http://www.memtest.org/

If you run setup from a DVD, you could have a bad burn, a bad DVDwriter, or a bad reader.
(they do get bad and won't always throw an error during burn..)
BUT, you could also have some faulty RAM, and that can cause faulty reads/extracts.

Hi
maybe you did something wrong.
This is our plugin build tute, by overFlow.
http://users.pandora.be/jtdoom/basetute … lpFile.htm

We provide a tool to collect hardware IDs.
When I look at your description I think your hardware is supported, but you could post the HWID tool output just the same.. (HWIDs of the machine you cannot use UBCD4WIN on.)

I welcome you with something experimental as well.
We call it a TESTPACK.
This may work better than the current released pack (8021).
http://dev.driverpacks.thesneaky.com/dr … 32_803C.7z

Here is an addition to above. (When you arrived here following a link, you might as well scroll up.)

TRIMMING TIPS
-------------------

If you are going to TRIM  (aka prune) the Mass Storage driverpack, extract it in a separate folder because later on you have to recompress * its content.
(When finished, you make a new 7z archive.)

When you TRIM (in other words, when you want to delete folders from mass storage.) you will have to look at the content of the DriverPack_MassStorage_wnt5_x86-32.INI, because if you remove folders and do not edit the DriverPack_MassStorage_wnt5_x86-32.ini you will get a critical "file not found" error during slipstream.

Renaming a folder also results in "file not found" if you do not change the section header for its foldername in the DriverPack_MassStorage_wnt5_x86-32.ini.

In Mass storage, ALL folders have a section in DriverPack_MassStorage_wnt5_x86-32.ini.
The section header [3-1] corresponds with D\M\3\1, and [X-X-1] would point to D\M\X\X\1
Header [31] would correspond with D\M\31 and Header [SiS1] would correspond with D\M\SiS1

In short. When you are pruning folders from the tree you must remove their sections in INI.

You can, however, remove a section in the INI and leave the folder in the pack.
This will not create an error during slipstream.
(Disable by using MsCount=0 (zero), or commenting out all lines for the section has the same effect.)
- - - - - - - - - -

CUSTOMISE TIP
You can also MOVE around sections in DriverPack_MassStorage_wnt5_x86-32.ini.
You must have noticed the section at the bottom loads last during TXTmode.
You may also have noticed the INI sections are not in alphabetic order.

If you were to move the [3-1] section to bottom of DriverPack_MassStorage_wnt5_x86-32.ini, you would then see that it loads after VMware driver [VM] during the TXTmode part of windows Setup.

We can use this technique to load the driver we want after another of which we know it supports the exact same chip, or same type of chip, or same chip with different firmware.
(I will mention you sometimes simply cannot flash to latest firmware, and we included BIOS -aka firmware - specific drivers when we learned it was needed.)
We had to include drivers for different modi of a chip in the pack.
SoftRaid, RAID, and standard IDE mode are three control modi a chip can handle.

It is obvious that when we include a driver for each mode, we have one mode load later than its other mode.
The other choice was we don't include the other mode at all, and that was unacceptable.
The one loading later will sometimes be the one used for access to hard disk during TXTmode, even if you BIOS setting has set the chip to another mode.
(An example; This is what Silicon Image sometimes does. We fought a "sillycone Hyll battle" with help from some users.)

You may wonder why we did not alltogether drop drivers of which we know they sometimes "take load, when they should not".
Well, IF we did, you would not have the choice. Users have always been "allowed' to edit/prune/customise DriverPacks and we do our best to have minimum issue with maximum availability.
(consider for one second what a forced DriverPacks build control would do to you. You would not be able to fix. These txts here tell you that you can do, and how..)

If you want to see how the section placement in mass storage INI changed driver load order, you can look at/compare streamed source's TXTSETUP.SIF files in which you locate the [SCSI.load] section.
<very advanced> Some people edit this file and comment the offending driver... And then they also have to edit dosnet.inf <did I say very advanced?>

; tip for noobs, about commenting out ;
The ; character in front of a line comments out a line, ; it is not seen as "to be processed..".
It basically gets seen as a remark, and you can actualy find commented out information lines in the INI.

AFTER CUSTOMISATION or TRIMMING
I will recommend you stream a new copy of a source.
Primo; it is best practice to work on a non-DriverPacks streamed source.

Secundo; This will make comparison possible.
TIP: keep a copy of each important stage.
That way you can have a copy you did not yet slipstream DriverPacks to available to you at all times.

Tertio:
A build that did not work for you should not be re-streamed with experimental work.
The end result of that would not be same when compared to a "clean" stream with the experimental..
We had a hard time figuring out errors users reported, and then we learned that re-streaming could introduce errors.
OverFlow has been working on a much better cleanup routine, which was released as DriverPacks BASE 805.
EDIT December 2008; However, in real life, nothing anybody can code is perfect.
All I am saying here is that a "re-streamed" build compared to a clean streamed build can show differences, and IF you don't tell us what YOU did, we find ourselves looking for an issue while put on the wrong foot. We are then perhaps looking for a solution in a DriverPacks INI while the coder should be looking in the DriverPacks BASE code.

OK, now you know a lot of what can be done.

* You have to recompress the Pack.
DPs_base uses the driverpacks, not the extracted folders.
The name you give the recompressed pack must follow the naming convention for a driverpack.
Suppose you unpacked xxx8041, you could call it xxx8042 so as not to accidentally overwrite the original.
I figure you would want the original in case your modification was not succesful.
Its higher version will be useful anyway.
However, if I were you I would use 804a because that will immediately show it is customised, and 804a will be higher than 8049.
(This behaviour is nowadays commonly taken advantage of when we upload testpacks.)

NEVER rename DriverPack_MassStorage_wnt5_x86-32.ini

I let 7zip unpack it to folder so it creates a new folder wich has the name of the pack..
Then I rename that folder, changing the version number to a higher version.
After that I can do what I want to do in that new folder.
(Examples: add a driver and its section, move sections to change load order, prune unwanted drivers, make it not skip a driver, disable a driver and keep it for PnP and so on.).
When you are done you select the D folder and INI file so that both get highlited, and rightclick to use 7zip on selection.
It will automatically suggest the name of the folder, which was already renamed to higher version..
7z, ultra, max dictionary, 273 word size, LZMA, SOLID.

Let us know what you had to fix, and how you did it.
Help us help you.