Incroyable HULK Posted November 9, 2005 Share Posted November 9, 2005 (edited) Just a small idea:Would it be possible to edit txtsetup.sif to copy our files to the hard drive instead of using the $OEM$ folder method?I wonder because after all, I don't have a lot of file in there (mainly because my drivers are compressed in a main archive).So the benefits would be: 1- the ability to do F6 to load MassStorage drivers 2- An accurate Progress bar when copying file in the first stage?There could be drawback also: 1- cmdlines.txt won't get parsed (if OemPreinstall=no in Winnt.sif) 2- Not sure if OemPnPDriversPath= is valid when OemPreinstall=no So I'd like to get your input on this Edited November 9, 2005 by Incroyable HULK Link to comment Share on other sites More sharing options...
cluberti Posted November 9, 2005 Share Posted November 9, 2005 Not sure if OemPnPDriversPath= is valid when OemPreinstall=noYou are correct, it is invalid. However, you can still set OemPreinstall = YES and not use the $OEM$ folder structure. Just omit the $OEM$ structure from your installation medium and it won't get copied. Link to comment Share on other sites More sharing options...
Yzöwl Posted November 9, 2005 Share Posted November 9, 2005 (edited) In a word, yes!At the moment I have implemented a batch file method of doing it using HFSLIP, the files however using txtsetup.sif are only copied to a folder structure within %WINDIR%. The current working method of this was submitted to tommyp possibly for inclusion into the next version of the program. The biggest setback for this is that all the files are compressed and added to the I386 source on your CD, however if you were unfortunate to have more than one file with the same name, readme.txt for instance, I'm sure that you will have problems. To date I have been unable to get dosnet.inf to recognize folder structures in order to prevent this scenario, and I don't really wish to go down the route of checking if every file exists in I386 for each entry and then go through a renaming loop. My batch file doesn't necessarily need to be run with HFSLIP, it could easily be altered in order to make the changes prior to burning your source.Another way of looking at the problem would be to use the idea from the 'drivers from cd' method and pause the setup whilst copying the files over to your preferred location, then continue the setup.If you didn't have many files to copy over, the easiest solution would be to use the following two lines beneath [GuiUnattended] in winnt.sif.DetachedProgram = CMD.EXEArguments = "/Q /C FOR /F %? IN ('%SYSTEMROOT%\SYSTEM32\MOUNTVOL.EXE^|FINDSTR :\') DO IF EXIST %?WIN51 XCOPY %?MYDIR %SYSTEMDRIVE% /S/I/Q"<Edit>Just to add, %? is your CD-ROM driveletter e.g. G:\ and MYDIR is the name of a folder in the route of your CD e.g. G:\MYDIR</Edit> Edited November 9, 2005 by Yzöwl Link to comment Share on other sites More sharing options...
Wraith Posted November 9, 2005 Share Posted November 9, 2005 At the moment I have implemented a batch file method of doing it using HFSLIP, the files however using txtsetup.sif are only copied to a folder structure within %WINDIR%.Have you tried defining ".." in [WinntDirectories] ?Seems like it'd be the candidate for doing so, haven't tried it myself, but might be something to try.The biggest setback for this is that all the files are compressed and added to the I386 source on your CD, however if you were unfortunate to have more than one file with the same name, readme.txt for instance, I'm sure that you will have problems. To date I have been unable to get dosnet.inf to recognize folder structures in order to prevent this scenario, and I don't really wish to go down the route of checking if every file exists in I386 for each entry and then go through a renaming loop.Again, with the addition of folders, couldn't we just add new entries to [sourceDisksNames] ?If someone made a batch or a small prog to automatically generate a set of source folder id's, we could use those id's to copy files from a directory structure on the CD. Again, haven't done this myself, but in this instance, I don't see any reason why it would not be possible.If anyone's done these things, care to comment? Link to comment Share on other sites More sharing options...
Yzöwl Posted November 9, 2005 Share Posted November 9, 2005 I had decided not to persue this further, and in true Scooby-Doo style, I would have gotten away with it, if it hadn't been for you!Thanks Wraith Link to comment Share on other sites More sharing options...
Wraith Posted November 9, 2005 Share Posted November 9, 2005 I believe it should've been "if it hadn't been for you meddling kids!" Link to comment Share on other sites More sharing options...
Yzöwl Posted November 9, 2005 Share Posted November 9, 2005 (edited) Incidentally, the first suggestion is a failure!Setup cannot create the folder: \WINDOWS\..<Edit>I have now, however, had some luck with using folders to hold the files, as opposed to the I386. There should now be no problem adding duplicate file names.The only problem now is being limited to the %WINDIR%</Edit> Edited November 9, 2005 by Yzöwl Link to comment Share on other sites More sharing options...
bilemke Posted November 15, 2005 Share Posted November 15, 2005 I did this a long time back.. It involved vey delicate editing of txtsetup.sif and scsi.inf in i386 folder.. I did not have any duplicate files though.. For those that I did, I replaced the old version in winodws with a newer version from a much newer driver.. I used it for a while to get away from usiing $OEM$ folder on cd.. Problem was... the f6 problem and a remainging need for winnt.sif.. I needed winnt.sif to automatically put the key in windows setup, and I figured, why not just use $OEM$ anyway. I will did through some cds to see if I can find an old version with a edited scsi.inf and matching txtsetup.sif.. One note, this will make every device driver in scsi.sif unsigned because of the changes and setup will complain if you dont shut off driver signatue checking.This method is also somewhat unclean as it will leave even unused driver files that you integrate in the c:\windows\system32\drivers folder if you integrate more then just the needed drivers for one particulair machine.Note, my current cd works in a reverse manner.. I have made it so that the only things winnt.sif and $OEM$ folder do is my scsi/raid drivers and my product key.. Otherwise, all other files are directly added to windows via addition to txtsetup.sif, dosnet.inf or the system hive files that end up being the registry. Then I make a multiboot cd with 2 options.. One option runs a setup/i386 folder with winnt.sif present and one without.. So, worst case, i run option 2 and use f6 if the driver is not on the cd, and only difference in the sequence and end result is that I have to manually type some info in to windows setup. Which, btw, I normally manually fill everything except the product key. Link to comment Share on other sites More sharing options...
ponghy Posted November 20, 2005 Share Posted November 20, 2005 I've read this interesting thread. I have a similar problem as bilemke: I'm using a dual I386 structure, one with WINNT.SIF and the other one without it.Integrating the drivers by using the WINNT.SIF is not hard... but, what about doing this without the unattended file? that is, by using the TXTSETUP.SIF file only... Is this really possible?The reason for doing this, is without WINNT.SIF I still have the repair options available (with WINNT.SIF everybody knows this is not available).Please, help. TIA Link to comment Share on other sites More sharing options...
secowu Posted December 13, 2005 Share Posted December 13, 2005 but how the txtsetup.sif copy mplayer2.exe into "C:\Program Files\Windows Media Player'?i can't find any usefull tips in txtsetup.siftks Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now