Martin H

If I remember correctly, then fdv added support for referencing dosnet.inf besides txtsetup.sif also, for his fileset, but hfslip dosen't do that for the files it processes, as it's solely meant for CD installs...

Just to rap up what i've previously posted about my feelings towards this, then I just noticed this older post from the HFSLIP test-releases thread, which I haden't seen before: Source: (I'm reffering to the last line, and not the first.)

LOL! Anyway, couldn't agree more!

tain was hosting the site for him, and additionally I was also reffering to the removal of download links from the MSFN HFSLIP threads. If not because of the above, then obviously I would fully understand it!

Really? -Then they wouldn't be understanding anything about FOSS licensing and make a complete joke out of themselves in the process! Anyway, I would suggest that FDV made a stickied post with the link of latest hfslip and a post about seeking new maintainers/developers, or else I really don't see the point of this forum, truth be told! Ppl go here for help, instrutions and download links! Especially now when the main page is down. TP did an amazing job and is a really nice guy, and I fully respect that he has decided to quit maintaning hfslip, but honestly, then i'm pretty disappointed about the way he left, i.e. the wording in the last hfslip-post edit, the removing of the download link for hfslip and finally for clossing the website! What is that about - trying to "punish ppl for not donating to his freeware project?"... Granted, he has every right to do so, but my point is just what kind of a message that states! PS: Thanks for adding me to your friends list mate!

His license dosen't govern him that right...

I fully agree with that, except that I don't think a rewrite is a top-priority for the XP-core-updates slipstreaming part, as that works fine and can eassily be extended as is, to feature non-supported updates, but to strip out all non-XP and Non-core-updates out, and release as a HFSLIP fork under the same license, would defenetally be a good move IMHO. I'm not using Windows and hence, HFSLIP myself anymore, but I used to be very interessted in this project when I did, so i'm sad to see it "blowing in the wind" like this(or whatever the right expression is )... For the Win2k users still holding the fane high(best Windows version IMHO, especially when coupled with fdv's fileset or hfcleanup, but unfortunetly, because of missing new driver and app support, coupled with non 2+ dual-core support, makes it a non-choise for many with newer machines unfortunetly), then a seperate Win2k fork could be made there also, if the interest was available.

Well, the good news is that HFSLIP is both Open-Source + written in plain cmd syntax, which makes modifications/additions much eassier to be made, and to a much larger audience, than if e.g. written in C/C++. Now you guys just need someone who will be willing to host and support this project, and in the mean time, whenever an update fails to slipstream, then someone willing and in the know, could post the diff, for others to incorporate. To be honest, then I have full understanding for if getting tired of a project and hence, quitting it, but my oppenion is just that if wanting/exspecting to get payd for your work, then don't release freeware, and if not wanting to answer stupid license questions, then just don't give out your mail-adress, and ignore dumbass forum-posters etc. Btw, the thread-title is a little of IMHO, as there's nothing illegail with distributing hfslip, in contrary to bootlegs, but that's just nitpicking i know. Just my 2 cents.

From looking at it's feature-list, then it dosen't appear to support file-placement optimization(but does consolidate free-space however) and so based on that, then I would personally preffer MyDefrag over defraggler, but that's just my oppenion.

A couple of posts above yours, then nh_wzg stated: the "TXT & LAY" he's reffering about is: txtsetup.sif and layout.inf.

You're most welcome, mate! Well, since FDV haven't replied yet, then I have just quickly glanced at a wordpad.inf file I found on the net(i've changed to GNU/Linux and isn't using Windows anymore), and from that then I can see that you also needs to uncomment 'write.exe' from layout.inf/txtsetup.sif, as else wordpad.inf will fail to launch, since it needs that file. If it still dosen't work after a reinstall(use a VM e.g. VirtualBox), then open sysoc.inf from '%windir%\INF' and remove the 'HIDE' from the 'MSWordpad' entry you uncommented earlier and then see if you can install it from add/remove Windows components... Good luck

Yes, but it should also be in "%programfiles%\Windows NT\Accessories". Are you sure that you uncommented the 'wordpad.*' files in txtsetup.sif/layout.inf + the 'wordpad' entry in sysoc.inf? This would make the OC manager run wordpad.inf during install, which copies the files to their needed destination and makes the shortcuts and file-associations... If you've done that, then i'm affraid it's out of my reach, and you'll have to wait for FDV to ellaborate further.

Untill fdv replies, then i believe for adding wordpad back-in you'd uncomment these from layout.inf/txtsetup.sif: ;wordpad.chm = 1,,,,,,,,3,3 ;wordpad.exe = 1,,,,,,,,3,3 ;wordpad.hlp = 1,,,,,,,,3,3 ;wordpad.inf = 1,,,,,,,20,0,0 And uncomment this line from sysoc.inf: ;MSWordPad=ocgen.dll,OcEntry,wordpad.inf,,7 Then for removing notepad i believe you'd comment out these from layout.inf/txtsetup.sif: notepad.exe = 1,,,,,,,1,0,0 ; where it really lives notepad.exe = 1,,,,,,,2,0,0 ; put a second copy here notepad.lnk = 1,,,,,,,,3,3 ;new And comment out this line from syssetup.inf: %notepad% = notepad.exe,notepad.exe,,0,%notepad_infotip% About scripten.exe, then since i couldn't find it in the Win2k update-list, then i searched the hfslip-changelog and found this:

With xable's pack there's nothing "useless" left. xhelper.exe and xudpack.inf is automatically removed and even the xudpack.inf entry in sysoc.inf is also removed post-install(nLite dosen't even do that for it's nlite.inf). That pack is very "cleanly" made! Yes, xable's pack brings an Xp-SP3 source completelly up-to-date with all high-priority updates, except IE8 and WGA(but WGA can be added with xable's WGA addons). If you need IE8 there are slipstream addons available from other parties(search).

It's impossible to say which is the best as it's entirelly a matter of personal prefference. However, here's some pointers about both to help you decide. xable's pack is build from the GDR branch(google it, if in doubt), whereas nLite slipstreams the binaries from the QFE branch when integrating updates. With xable's pack then all updates are slipstreamed in the most effecient way(except for the timezone update which is set to run at T-13), whereas nLite integrates some of the updates with the ineffecient /integrate switch. Lastly, then xable's pack only slipstreams the actually needed reg-entries and omits the rest as they are useless to a slipstreamed install(the needed reg-entries are the ones for e.g. WU/MU and qfecheck.exe etc. in 'HKLM\SOFTWARE\Microsoft\Updates' and the useless omitet ones are e.g. 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix' ones(for the very few where this is needed i.e. when no other entries set, then it's included!)'.

THANK YOU jaclaz, my friend! Finnaly someone who understands what i've been saying for two pages now... (sorry, Yzöwl as ussual also does...) Please everyone, READ before posting!!! Edit: I didn't even have to, but anyway i've just tested this and obviously you know what the result was...

Well, then lets agree to disagree then... Btw, please give me an example of ANYTHING where "start /wait" makes a difference in cmd, and i will test it out... Also, so you guys are not believing msft when they say in their technet article> Console apps never waits obviously, but gui apps are gui apps no matter if they are silently executed or not... And hence, the /wait switch when using it... Said in another way, the /wait switch modifies the start commands normal behaviour, but NOT the command shells behaviour in any way... If that was the case, then there would instead be a switch for cmd.exe itself to change that behaviour obviously... Anyway, im done with this now if not getting an example, as i have proven it previously in this thread both with tests and technet quotes, so unless im givin an example to prove wrong, i dont want to continue repeaing myself here...

You havent read what I have stated throughout the whole thread then... "start /wait" makes ZERO difference in BAT/CMD files... YES, some apps dosent wait, but thats besides the point, as "start /wait" dosent fix it... Lastly, you should not remove "/wait", but "start /wait"... @submix8c "start /wait" dosent cover the bases and are always 100% redundant in cmd/bat files...

@g-force Exactly, mate! (as X stated, if you by "no switch" means no START command in no.3, which i'm sure you do...)

Thanks for the link, mate! Nice detailed info there! @all From the above article(just to prove what i allready stated): And about cmd.exe/command.com, then there was something i didn't knew(but submix8c did, if you read his earlier post):

Just for reference, then the CD's boot-sector runs ntldr which is the boot-loader for CD/DVD-based installs and which dosen't use dosnet.inf(layout.inf+txtsetup.sif), while winnt/winnt32 is the DOS/Windows installers for non-bootable-CD/DVD based installs and which does use dosnet.inf... Just in case others were interested, but as -X- said, theres a complete forum for USB installs elsewhere on MSFN

Thanks, didn't knew that!

I've read-up on it(on this other subject)... .BAT's are run fully by cmd.exe... The recommendation for using the .CMD extension is for avoiding the file to be able to run on Win95/98 systems(e.g. command.com will fail to set %errorlevel% after certain commands.)... command.com is only supplied on NT systems for the 'compatibility option'(running old apps) and for making a MS-DOS startup disk... As for rapping up the main topic of this thread: Everyone please understand that "waiting" is enabled by default in CMD/BAT files, so the use of 'start "" /wait' is redundant. In the cases where "waiting" dosen't seem enabled, then 'start "" /wait' will not help, as the reason is the program has started another process while clossing the previous and so instead e.g. ping can be used...

Sorry, but are you absolutelly sure of that? In my experience, it cabs and uses all files except a select few predefines(readme.txt etc.). Sorry for off-topic, but to answer my own question(which others maybe also would be interessted in), then here's the results from having tested this: Nvidia graphics driver: 56 files 20.2mb After integrating above driver with nLite: 46 files 14.4mb After running the un-nLited driver through DriverCompressor: 16 files 6.49mb So, running DriverCompressor before integrating the drivers with nLite will save you additional space and cut down on the files, as nLite dosen't strip the INF-unreferenced files out, but just uses a built-in exclude-list, like e.g. TXT files and some few others. Also, as the files are already cabbed, then this also cuts down on the nLite processing time.