Jump to content

Martin H

Member
  • Posts

    791
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Denmark

Posts posted by Martin H

  1. 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...

  2. 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:

    Tom doesn't want it sent to Sourceforge (it has to be him, the copyright holder, to submit it anyway).

    In fact, he doesn't want it distributed at all anymore. I'll make a more general announcement in a new topic.

    Source:

    (I'm reffering to the last line, and not the first.)

  3. 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! :)

  4. 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! :)

  5. The only way I could see the project continuing in any useful form would be to re-write the code, stripping away some things and probably removing the ability to support anything other than Windows XP. At that point I'd not even be sure that it would count as a version of HFSlip, under the same licencing or something completely different, but one thing is for sure HFSlip as you know it would definitely have stopped development.

    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.

  6. 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.

  7. A couple of posts above yours, then nh_wzg stated:

    After commented some iteatapi.sys,megaide.sys,... in TXT... & LAY..., the system installed and startup successfully with the last fileset for XP.

    the "TXT & LAY" he's reffering about is: txtsetup.sif and layout.inf.

  8. 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 :)

  9. 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.

  10. This is my first slipstream endeavor. I love the outcome.

    I still would like to remove both notepads, and install Wordpad because it read Microsoft Word documents.

    How Do I do this? What folder do I put SCRIPTEN.EXE in?

    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:

    added support for Windows Script Host 5.7

    WARNING!

    The new scripten.exe is a Type 1 hotfix so the old WSH 5.6 (if named scriptxx.exe or scripxxx.exe), which is a Type 2 hotfix, is no longer supported!

    Also, setuperr.log shows some errors related to the new WSH 5.7 files. This is a general problem (confirmed by Microsoft) and I haven't found a way around it yet. Advise: stick with WindowsXP-Windows2000-Script56-KB917344-x86-XXX.exe (or the mini KB917344 hotfix) for now, or place the new scripten.exe in HFSVCPACK_SW1.

    WSH 5.6 named as "scripten.exe" is no longer supported (the new WSH 5.7 has the same name but it's a different type; we can't support both)

  11. 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).

  12. 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!)'.

  13. 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>

    When you run a 32-bit graphical user interface (GUI) application, cmd does not wait for the application to quit before returning to the command prompt. This new behavior does not occur if you run the application from a command script.

    Console apps never waits obviously, but gui apps are gui apps no matter if they are silently executed or not...

    Notice that the operation of the START command differs from the default command shell sequence:

    First, the START command never waits for the command to complete.

    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...

  14. agree with g-force

    Think this is a situation where some apps will continue and some will not, I've tried removing the /wait and turns into a nightmatre doing 20-30 apps. even on Seven 64 bit

    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...

  15. Thanks for the link, mate! Nice detailed info there! :)

    @all

    From the above article(just to prove what i allready stated):

    Notice that the operation of the START command differs from the default command shell sequence:

    First, the START command never waits for the command to complete.

    [...]

    As described above, the START command does not wait for the new command to complete; a new command prompt appears immediately and new commands can be executed at once. When used in a script, the next line in the script executes immediately. The /WAIT switch makes the START command wait for the command to complete before continuing. This switch applies to all commands and applications, including GUI applications.

    And about cmd.exe/command.com, then there was something i didn't knew(but submix8c did, if you read his earlier post):

    The 16-bit MS-DOS shell (COMMAND.COM) that ships with Windows NT is specially designed for Windows NT. When a command is entered for execution by this shell, it does not actually execute it. Instead, it packages the command text and sends it to a 32-bit CMD.EXE command shell for execution. Because all commands are actually executed by CMD.EXE (the Windows NT command shell), the 16-bit shell inherits all the features and facilities of the full Windows NT shell.
  16. The CD's boot sector autoruns winnt.exe after you press any key to boot from CD. I guess a similar boot sector needs to be written to the thumb drive.

    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 :)

  17. 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...

  18. [...]

    nLite reads the inf inside the driver folder and compresses then copies ONLY the files that are needed by the driver.

    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.

×
×
  • Create New...