whitehorses

@TC - I see you have changed it in the newest test release. Unfortunately it wasn't quite succesfull, at least to say FOR /F "TOKENS=* DELIMS= " %%I IN ('FINDSTR/IR "Time.Zones\\ " TEMP\UPDATE\_TZC.inf') DO ECHO>>WORK\928388A.TXT %%I FINDSTR[color="#FF0000"]/VI[/color] "America.Standard.Time.Dynamic.DST...2 Brazilian.Standard.Time.Dynamic.DST...2" WORK\928388A.TXT>>SOURCESS\I386\HFSLPHIV.INF ECHO>>SOURCESS\I386\HFSLPHIV.INF [Strings] FINDSTR/IR "_STD.*= _DLT.*= _DISPLAY[^_]*=" TEMP\UPDATE\_TZC.inf>>SOURCESS\I386\HFSLPHIV.INF This code is a bit different in some aspects than what I suggested, AND... beside that minor formating difference, that you left the spaces in front of the [string] section entries, by not adding that FOR in front of the last FINDSTR, ... which is not an error... ... there is one indicated with red: a missing /R. Though it's much smaller problem than it was before, since this one only just results in four additional entries in the strings section, which is harmless. But if you don't care about it, just ignore the whole line EDIT: Sorry I will be really annoying I know, but I'm even a bit angry, because I was turned down when I said my installs are not behaving as they should. There are a LOT of such mistypings,as the above, even more serious. Call it bug or ERROR does not matter. Explain this for example: FINDSTR "\." SOURCE\I386\DRVINDEX.INF>WORK\DRV0.TXT Yes this is at the end of :CLOSURE, ("New binaries" it says) Should I be surprised if there a no "new binaries" processed when I install my shiny new Windows? I don't clearly see what's the exact results of this code, but I think it can be serious. Hasn't ever anyone noticed something strange about this? EDIT 2: Ok here is another subject guys: EFFICENCY. Not as important as correctness and validity, but important too. FINDSTR ",,," SOURCESS\I386\TXTSETUP.SIF>WORK\SRC0.TXT FOR /F "TOKENS=1 DELIMS== " %%I IN (WORK\SRC0.TXT) DO ECHO>>WORK\SRC1.TXT %%I FOR /F %%I IN (WORK\SRC1.TXT) DO ECHO>>WORK\FULLSRC.TXT %%I why would you write SRC1.TXT line by line to FULLSRC.TXT without making any processing on the text, instead of: FOR /F "TOKENS=1 DELIMS== " %%I IN (WORK\SRC0.TXT) DO ECHO>>WORK\FULLSRC.TXT %%I Have you tested what's the difference? Well I did! On my 1,4GHz PentiumM the second for cycle on a w2k txtsetup.sif takes 30 seconds!!!! THAT'S A LOT EDIT 3: I did not want to offend anyone, I just want a clean install, and maybe help others to have so. EDIT 4: here's the ... more efficent, less... script: FOR /F "TOKENS=1 DELIMS== " %%I IN ('FINDSTR ",,," SOURCESS\I386\TXTSETUP.SIF') DO ECHO>>WORK\FULLSRC.TXT %%I FINDSTR /I /B /R "[^=][color="#FF0000"]*[/color]\." SOURCE\I386\DRVINDEX.INF>>WORK\FULLSRC.TXT EDIT: the * is needed, sorry for omitting it first

Hmmm... I just don't see why... FINDSTR/I "Time.Zones" supposed to find strings like: TIME.zones time.ZONES TiMe.ZoNeS But never ever will it find the string with a space, which was probably what it intended to: Time Zones I checked the inf file in concern manually, and at least if you want this command to find something you should not search for /I Time.Zone literally. The "." in regex means any character, including space, so it will return the line you need. Altough this works, there is absolutely no need to use RegEx here, by the way. It would be more efficent and convinient to simply write: FINDSTR /I /C:"Time Zones" Using regex searches is just a waste of cpu power, so I suggest only using it when neccessary. EDIT : So it turned out that findstr takes dots as wildcards by default, and I used total commander's search when I said that I found no occurance of "Time.Zones".

@TP - could you explain it a bit more... 1. the mistyping I mentioned is in the original HFSLIP, not my modded one. 2. I'm exactly sure there could be problems with writing the parameters next to the command. (i had one issue around hfcleanup, with a findstr i think. the one who wrote hfcleanup also knew something, since all commands there are separated for reason) 3. I understand that my problem above is not your concern in a way like if it happened with the current stable release, so I just asked for your oppinion about it. Can you scetch the dependecies of inf files during installation? which is the root? what calls it? What is IIRC you mentioned? By the way I don't make modifications to the script too much, just reidenting and reading it...khm and I had probably this issue for a year, long before I started thinkering the script...khm... EDIT: Maybe I'm annoying, sorry for that. I wrote this, to be put in the end of :TZ928388 : FOR /F "TOKENS=* DELIMS= " %%I IN ('FINDSTR /I /C:"Time Zones\\" TEMP\UPDATE\_TZC.inf') DO ECHO>>WORK\TZCEXTRACT1.TXT %%I FOR /F "TOKENS=* DELIMS= " %%I IN ('FINDSTR /I /R "_Std.*= _Dlt.*= _Display[^_]*=" TEMP\UPDATE\_TZC.inf') DO ECHO>>WORK\TZCEXTRACT2.TXT %%I FINDSTR /V /I /C:"South America Standard Time" /C:"Central Brazilian Standard Time" WORK\TZCEXTRACT1.TXT >> SOURCESS\I386\HFSLPHIV.INF ECHO/>>SOURCESS\I386\HFSLPHIV.INF ECHO>>SOURCESS\I386\HFSLPHIV.INF [Strings] TYPE WORK\TZCEXTRACT2.TXT >> SOURCESS\I386\HFSLPHIV.INF At least ON MY "STRANGE" COMPUTER it's working this way correctly. Maybe I'm wrong sorry for that. EDIT 2: changed to work without RegEx in the 1st and 3th line

In the latest stable version there is an error in timezones update processing. I don't know if it's corrected already or not: line 1117 - FOR /F "TOKENS=* DELIMS= " %%I IN ('FINDSTR/I "Time.Zones" TEMP\UPDATE\_TZC.inf') DO ECHO>>WORK\928388A.TXT %%I I think you intended to write FINDSTR /R /I "Time.Zones\\ ", because without /R it ain't won't not find nothing. note the "\\ " I added(a space is there!). This way you can use three less of those search-strings on the next line EDIT: also I think it's not wise to write the parameters immediately after the command. I had found lots of issues, I can post some if you'd like, but maybe it's just because my cpu is buggy, or maybe it was "feature" not bug... like the above... dunno I happen to have some issues too. I have rewritten HSLIP a bit, so it might be that i made this bug, but maybe someone can help me where look for solution: SOURCES with FDV + HFCLEANUP +DX9 (an absolutely conservative general minimal install should be) 1, during install it pops up dirver signing dialogs (i set DELCATS). 2, many services are not removed, for example Utility Manager, which should be by Applications_AccessibilityOptions.inf, and many others. I found out that HFSLIP folder exists in WINDOWS folder, full of inf files. Now when I installed them manually by doubleclicking them, after a restart the entries in Services MMC are removed, so these infs were not processed for some reason during install. As I know the whole folder (WINDOWS\HFSLIP) should be removed by HFSLIP.CMD. Any idea what is the cause? How does the install process goes exatly? SYSSETUP is called first, and it calls HFSLIPWUF or how? Is it possible that the whole hfslipwu.inf were not processed, or the issue might be with hfslip.cmd? Where should I start looking?

TC - my pleasure to help Would someone check this one too. It seems harmless, but I think that "work" is not needed there. EDIT: found something else... around slipstreaming 2003 sp1... well IF "%SOS%"=="W2K3SP0" IF EXIST [color="#FF0000"][b]HF[/b][/color]\*889101* GOTO :HFSPACK3 ... IF "%VERSION%"=="2003" ( ECHO SLIPSTREAMING SERVICE PACK 1 INTO WINDOWS 2003. PLEASE BE PATIENT. FOR /F %%I IN ('DIR/B HFSPACK\*889101*.exe') DO START/WAIT [color="#FF0000"][b]HFSPACK[/b][/color]\%%I /Q /X:SP\ ) I think that HFSPACK folder should be changed HF, shouldn't?

I start to believe that my computer is cursed or something... thank you guys for giving me so much from your time, I think I stop this for now. By the way I managed to solve few things: - the BIGGEST problem was that I copied the source from CD, and it was read only. After I corrected that everything went on much better. The ISO size was around 110 MB, and very few errors I had. - Unfortunately the syssetup.inf was overwritten this time too, and "that very strange thing" happened again. After compressing .in_ files in FDV's fileset inside FDVFILES everything was OK. I think it's safe since I haven't seen HFSLIP modifying them, only during hfcleanup. This way it even works with nlite if I don't select IE for removal... probably thanks to the few structural changes in the past few months either in fdv's or in nlite. "...or am I wrong?" I suggest *.??_ files should be compressed in fdv's before copying them to sourcess\i386, or hfcleanup should recognize the uncompressed files but it's more complicated. (By the way what about my test files? If it runs OK w/o compressing syssetup.inf for others, then it's sure that the problem is with my system.) EDIT: the last thing... there is a line around 2466 in :CLOSURE like: IF "%LNG%"=="ENU" (TYPE WORK\HIVESFT.TXT>>SOURCESS\I386\HIVESFT.INF) ELSE It gives me an error during slipstreaming, because there is no HIVESFT.TXT inside WORK. Is this a problem or not important?

TOMMYP - This is going to be technical... 1 - I found something I don't understand in hfslip-1.2.1.cmd line 1831. There is somthing like: ... del work /q /f work\red\%%jf ... why is work there? It won't do anything, or I'm wrong? 2 - I had a very strange thing happening to me. I will check it once more, but I would like to know that you know about it. During the processing of .rin files I was watching what was going on inside WORK\RED folder. (exapanded INF files and TXTSETUP.INF therein) Almost everything was processed according to the script, exept ie.inf, nettcpip.inf, and mplayer.inf. I don't know exactly what happened, but as I looked away and back I saw that they were renamed to ie.iny, nettcpip.inp, and mplayer.in . I don't see how the heck could that happen since I don't find it in the script anywhere... Can you confirm that it's ok?

TP - I will send another one after this process finishes I'm running currently. PM: I will continue on the other topic ("issue with HFCLEANUP") since I think this isn't connected to FDV's

Please try the batch inside test.zip. The syssetup.inf is the one from my HFSLIPPED FDV w/o HFCLEANUP cdimage. If you re-makecab it manually it works fine. (The filter.txt is made by me just for testing purpose) test.zip

I will try... I'm realy dumb for foruming HFSLIP.zip

Hi Oleg_II Yes I have tried both w/ and w/o selecting to clean up FDV's. I tried the latter only a few times so currently I always select to clean it up. ... It seems to me that all the problems come from around processing rin files in this case. For example after all the service removal files I put in HFCLEANUP the process leaves everything untouched, and if I install this HFCed SOURCESS on a VM, all the services are there. Strange because some things get removed, (sounds, and accesibility), and even stranger that some things got screwed up, for example the start menu, which should have been customized according FDV's shell.inf. Maybe the whole issue is because my system. Can regional settings affect how the script runs for example? (I have really weird settings for that )

I had that issue not long ago, when for some reason syssetup.inf was removed accidentaly by hfcleanup. I digged the code and found out why: I used FDV's fileset. For some reason during the slipstreaming process HFSLIP forgot to compress it (syssetup.inf only... strange). This was the root of the problem, because when HFCLEANUP parsed the file: Echo Updating SYSSETUP.INF EXPAND -r sourcess\i386\syssetup.in_ >NUL del /q /f sourcess\i386\syssetup.in_ ren sourcess\i386\syssetup.inf syssetup_temp.inf findstr /v /i /g:WORK\RED\filter.txt sourcess\i386\syssetup_temp.inf > syssetup.inf MAKECAB syssetup.inf /L SOURCESS\I386 >NUL del /q /f sourcess\i386\syssetup_temp.inf del /q /f syssetup.inf "EXPAND -r sourcess\i386\syssetup.in_ >NUL" gives an error, but the code continues, then "ren sourcess\i386\syssetup.inf syssetup_temp.inf" does nothing too, but "findstr /v /i /g:WORK\RED\filter.txt sourcess\i386\syssetup_temp.inf > syssetup.inf" creates an empty file, and "MAKECAB syssetup.inf /L SOURCESS\I386 >NUL" creates a cab from that empty file, unfortunately overwriting the original. Hope this helps. I will try to find out why my syssetup.inf was not cabbed during slipstream...

I know, and I'm using those. I just know that Oleg had made that mini02 fileset a long time ago, and I was just curious about it. Means something because I'm doing the same...

That is exatly what I wanted to hear, though with this I'm more frustrated: why then it's not working for me? All the same exept FDV. The SOURCSS should be around the same size. EDIT: What kind of removers did you use? I haven't tried your mini02 set jet, should I?

tommyp - Merry Holy-day for you and thank you for responding this time. - I use full english version of every hotfix on W2KSP4eng source - I dont use anything beside current up-to-date hotfixes and DX9 - as I said, the FIX folder contains ntldr + ntdetect.com from 2003 and an usbport.sy_ patched to 500hz - I tried only slipstreaming neccessary hotfixes and DX9 with HFSLIP then process it with nlite. These runs gave promising results, but not the one I realy dream of. (my current system is one from these, though it's just an experimental version: I removed EVERYTHING of nlite's list exept DHCP, activedir, some multimedia codecs and calculator!!! It haven't crashed for half a year surprisingly, though some error popups come up every logon) - I have tried the same with XP and if there would be no other choices than hfslip+nlite I would prefer XP. But there is FDV fileset for 2K... - I LOVE the FDV fileset! It perfectly represents my needs and philosophy. The problem is that there is no way of cooperation between nlite adn it, as I know. - I even tried to create an FDV-like fileset from scratch, which wouldn't interfere with nlite, but after few months of trial and errors I gave it up - There is no other option but hfcleanup, which unfortunately never really worked for me. TommyP are you exactly sure that it's not the script which is buggy under some circumstances? I mean I tried to undarstand the script, but it's so cryptic for me I was unable, and this behaviour I experience is at least peculiar. Either my system must have some oddities (the above mentioned) or something in the script, since the components I slipstream represent the most convetional set I think. (no problematic component, no HFEXPERT, just hotfixes) I tried every possible combinantions in the past, so I don't have any ideas more by myself. - I would like to understand how hfcleanup works exactly. Can you please explain me the process in words. (extensively) I would need it because its too hard for to understand from source without any guides. I know there is a timetable of the process inside one of the filesets, but I would need to understand it more deeply. Does the method of hfcleanup depend on other methods inside the script? - Is there a possibility that FDV fileset can interfere with - for exaple - a full hfcleanup.zip? as I see there are re-removed entries... isn't that a problem if I re-remove ie or mplayer2.exe with ZZZZ or such? I don't care about compatibility just want to know if there is the possibility of interference... PM: sorry if I'm talking/asking too much in one turn PM2: You said your source is 200 megs? W2KSP4 is 316 as I know... did I miscalculate something?

Merry Christmas to all of You!!!

I'd like to hear some happy-end stories about someone hfslipped a full 2K with all bells-and-whistle hotfixes, FDV fileset, AND afterwards SUCCESSFULLY used a full HFCLEANUP. I think I heard once someone did something like that, from TAiN maybe, but he run off before I could ask him how I tried another desperate move tonight: created a full slipstreamed FDV-2K. Everything was ok, shiny-shiny install on VM. Checked almost every file and folder after install, and I can tell it was beautyful. Then I tried to run HFCLEANUP using AHTEST=HFCLEANUP switch on the sourcess. I swore I used only the removers included in hfcleanup.zip and ..2kextra.zip. I processed them in small packs, for example one for the apps, one for the drivers, one for the services. Everything seemed ok, but the result was catastrophic: HFSLIP somehow deleted syssetup.inf!!! There are ABSOLUTELY NO entries for that, that's crazy, then how did that happen. When I run HFCLEANUP with almost all removers I never had my source folder below 230Mb, which - as I heard from others - is almost double the size that it should be with such set up. Might my processor have some aberations or what?!?! Should I give it up EDIT: it wasn't deleted though, just the whole file was empty. Grrr EDIT2: issue resolved here

I have strange issues with FDV fileset + HFCLEANUP. I'm using a slightly modified fdv fileset, without any major changes which should affect the outcome. First of all I use a 2000 source, integrating DX9, using the following hotfixes: IE5.01sp4-KB925454-Windows2000sp4-x86-ENU.exe IE5.01sp4-KB925486-Windows2000sp4-x86-ENU.exe MDAC253-KB911562-x86-ENU.exe OE5.5sp2-KB923694-Windows2000-x86-ENU.exe rootsupd.exe Windows2000-KB842773-x86-ENU.exe Windows2000-KB891861-v2-x86-ENU.exe Windows2000-KB893756-x86-ENU.exe Windows2000-KB896358-x86-ENU.exe Windows2000-KB896423-x86-ENU.exe Windows2000-KB896424-x86-ENU.exe Windows2000-KB899587-x86-ENU.exe Windows2000-KB899589-x86-ENU.exe Windows2000-KB900725-x86-ENU.exe Windows2000-KB901017-x86-ENU.exe Windows2000-KB901214-x86-ENU.exe Windows2000-KB904706-DX9-x86-ENU.exe Windows2000-KB905414-x86-ENU.exe Windows2000-KB905749-x86-ENU.exe Windows2000-KB908506-x86-ENU.exe Windows2000-KB908519-x86-ENU.exe Windows2000-KB908531-v2-x86-ENU.exe Windows2000-KB911280-v2-x86-ENU.exe Windows2000-KB912919-x86-ENU.exe Windows2000-KB913580-x86-ENU.exe Windows2000-KB914388-x86-ENU.exe Windows2000-KB914389-x86-ENU.exe Windows2000-KB917008-x86-ENU.exe Windows2000-KB917344-x86-ENU.exe Windows2000-KB917422-x86-ENU.exe Windows2000-KB917537-x86-ENU.exe Windows2000-KB917736-x86-ENU.exe Windows2000-KB917953-x86-ENU.exe Windows2000-KB920213-x86-ENU.exe Windows2000-KB920670-x86-ENU.exe Windows2000-KB920683-x86-ENU.exe Windows2000-KB920685-x86-ENU.exe Windows2000-KB920958-v2-x86-ENU.exe Windows2000-KB921398-x86-ENU.exe Windows2000-KB922582-x86-ENU.exe Windows2000-KB922616-x86-ENU.exe Windows2000-KB923191-x86-ENU.exe Windows2000-KB923414-x86-ENU.exe Windows2000-KB923689-x86-ENU.exe Windows2000-KB923980-x86-ENU.exe Windows2000-KB924191-v2-x86-ENU.exe Windows2000-KB924270-x86-ENU.exe Windows2000-KB926121-x86-ENU.exe Windows2000-KB926247-x86-ENU.exe WindowsInstaller-KB893803-v2-x86.exe Windows-KB909520-v1.000-x86-ENU.exe WindowsMedia6-KB925398-x86-ENU.exe WindowsMedia-KB911564-x86-ENU.exe WindowsRightsManagementServicesSP2-KB917275-Client-ENU-x86.exe WindowsXP-KB928388-x86-ENU.exe wmfdist.exe wmp6cdcs.exe The FIX folder has 2003 bootfiles, and an usbport.sy_. The whole stuff installs as it should without hfcleanup. After applying the hfcleanup files on the next run, I was dissapointed about the results: 1, first of all the installer was complaining about signatures, and I had to click OK to every component... 2, This is my greatest and long enduring problem with hfcleanup: it simply does not work for me! Never ever! I've been trying it for more than a ear in vain The service removal files had absolutely no effect... every service is still there, and many other removals are quite buggy, like for some strange reason the my documents folder (which was perfectly removed by fdv) reappeared, and so a ghost folder for task scheduler on the control panel. Any suggestions? PM: atached the modified fdv fileset for the sake of a precise diagnosis EDIT: oops... I'm a noob, and can't do that for some reason

Does this affect anything? If the quotation only valid till end of line, then I think it isn't a big issue since the key is not that important, is it? Yzöwl Yeah, Christmas Spirit... lets do some valueable instead... for me at least. I was told I'm a selfish bastard today, so I decided to burry myself under this wincrap instead. ... Jesus ... By the way, can you help me? I'd like to modify the folder names under User profiles (Application Data, etc..) and maybe for the default and all users forlders. How can I do that, since I wasn't able to find any entries about that. I've tried to do it extensively a few months ago without success...

Nope... in my editor thats line 626. I said 828: HKU,".DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders","History" Notice I marked the missing quote. Hope it helps. PM. well if it does... i would ask you a bit more about your fileset in exchange

I have found this issue in around september, but I see it's still not corrected in FDV's fileset: In the file IE.IN_ at line 828 a " is missing. I don't know how the installer parses the inf file, but at least that line was affected by this issue. EDIT: Or am I wrong?

Hey FDV! I am amazed as always from your style and the knowledge behind it. It's a pitty that - as you said - this knowledge is "not very usful". I mean it's amazing for someone to study something such deeply just for hobby, without getting paid for it, but in the end it turns out that every one thinks you are crazy to invest that much in it. I had this feeling, when my father told me this summer to stop "tweaking". What a shame... Last year I was digging deeply inside too, rewritten the fdv fileset, trying to make it to my taste, but in the end I had a screwed up install I even tried to make an alternative fileset which works with nLite. Wasn't succesfull though. Someone with half this knowledge in the linux camp is called a guru... that's a shame too.

Whohoohoooo! Where can I download the older versions of Procexp?

I'm happy to at least know, that I made something wrong. Thanks

Hmm... yeah, I was expecting that for some reason the folder size of mine was abnormal... I think i should give it another try. I think I will do the following: I will make a new cleaned-up source, then compare some of the key files (like ie.inf layout.in, syssetup.inf and such) with the originals to find out what has happened. By the way, just as an experiment once I commented out a few other services in HIVESYS.INF like eventlog and protected storage and other stuff, but I haven't tested it jet. Imho, I had a Win2000 running under VMware a few weaks ago, which booted up without RPC... Started with around 19Mb commit, hell. Though I had to open taskmanager, and start explorer.exe from there if I wanted a destop, hehe