fdv

It's also, as far as I know, the only open source program that can do what it does. Many eyes = fewer bugs and added functionality over time.

Which one would work best? HKCU,"Software\Microsoft\Windows\CurrentVersion\Controls Folder","Presentation LCID",0x00010001,09,04,00,00 or HKCU,"Software\Microsoft\Windows\CurrentVersion\Controls Folder","Presentation LCID",0x00010001,"409" or HKCU,"Software\Microsoft\Windows\CurrentVersion\Controls Folder","Presentation LCID",0x00010001,"00000409" I am adding the top one but maybe you'll know before I try it. Thanks Martin

Let's see... 1. "Then the next observation i've done, is that i've now gotten all those unregisterable files to register by running an inf which used the same registering-method as used in mplayer2.inf" I added this to my MPCODECS.INF file, many thanks 2. HKCU\Software\Microsoft\Windows\CurrentVersion\Controls Folder The HKLM is created by HIVESFT.INF. No specific INF creates the HKCU key. So, I have added it to HIVEDEF.INF. Not sure what's going on with this key, but it's no effort to create it, so I added it. 3. "I can't remember if it was the same with fileset-8e" ;-) I can't either. I tried at some point last year to pull out all of the media stuff from the main install files so that if someone wanted a codec-free Windows installation, stripped down as much as possible for, say, file storage, they could do it. In doing so, as TommyP notes, I have jumbled a very sensitive order of things, hence the odd codec behavior with registering files, etc. 4. "Btw, from reading the fileset-changelog, then it states that hivesft.inf in set-7 includes "fixed timezone-information" untill Jan '08, but does that then mean that the timezone update on Tommy's list isn't needed then?" Correct, that update is not needed. It doesn't hurt anything, though, so I don't really tell people not to use an update in that case. I only want people to avoid updates that actually make the computer slower, like the update that adds an ActiveX patroller thread whenever the shell is running, which is totally unnecessary. Thanks for all of your input on this! Time for a revised set 8 I guess

This just blows my mind. You did quite a bit of detective work! I guess it gets tiring after a while; TP has even created a template to assist himself and I know by the volume of updates that it's quite a bit of work for him. 2003 isn't too bad for me, since I don't get into IE7 or any addons. I can understand why most of these guys are either behind or decided to throw in the towel. Green pages FTW!

The fact that you cannot register the dll doesn't mean anything of any consequence. Post your version; it should be 2.10.35.35. This dll is for really old programs -- having AOL software isn't helping things. More likely than not it's the chief source of your problem. The toolbars are also a problem; if you don't know which kind they were, it's not even close to possible to tell what's going on with your system. Reinstall (I don't say that lightly) and set her up with a non-admin account so that she has to depend on you to install things; that way you can control what goes on her PC and prevent what doesn't belong there.

This is truly strange; I don't recall ever seeing some sort of DLL dependency where something has to be present for registration success. Or if I do know I am not remembering. I mean, clearly, when you register these files, they are looking for some other file my fileset rips out. I have to be honest, it's really too much trouble to fix. I have modified my INF file to deal with acelpdec.ax. Other than that, I have to make the presumption that most people will install dx9. The only other thing I can do would be to have HFSLIP "see" which dx is being installed, and then call a special install section and include two [DefaultInstall] sections, like: [DefaultInstall] ... RegisterDlls = register.dx7,register.dx9 [dx7install] ... RegisterDlls = register.dx7 Etc. Too much work, though, to make HFSLIP mod an INF and call a dx7 installer if the dx9 cabs are not present.

This is actually a bug in a codec. I wrote that INF file based on DX9 files. In MPCODECS.INF, under [register] , all of those files (the DX9 versions) listed will normally register without errors. Somewhere there is a DX7 codec file that isn't registering. My rewritten INF file is definitely causing the issue, and to fix it, you would have to comment out RegisterDlls = register from [DefaultInstall] and then register each file manually to see which one throws an error. I am guessing that DX9 fixes a buggy codec file and the bugfix never got released for DX7. I couldn't tell you which file however because I never did a direct compare of codec files between both DX versions. Does DX9 really use that much overhead that you prefer not to use it? Anyway it might also help to attach the error log from Media Player Classic so I can see it, that might give the filename too. I'm not sure.

Hey man! Sorry to say, there is not. (Trivia: the only nonpublic version of HFSLIP that was ever created and not publicized was for Windows NT 4.)

It seems like you have to use a hacked DLL. I really don't recall; I have been using hacked DLLs forever. I wouldn't think of doing it any other way.

in the [sCSI.Load] section at the bottom list Add all the Id's loaded by uniata in the [HardwareIdsDatabase] section change PCI\CC_0101="pciide" for uniata add PCI\CC_0106="uniata" but not lucky Here are some instructions on manual integration from Windows 2000. It works the same exact way as XP.

There's a reason he seems to know what he's talking about. Look for some of his past posts. He's spent a lot of time examining what files go with what Windows components, and documenting names of DLLs. But have a look in the nLite forum wayyy back and see other MSFN members' experiences with posting to his site. He's not into component removal before installation (that's one reason he took down his batch files for a while). There is a bigger back story but if I were to be truthful about the matter it might be viewed as badmouthing him. Suffice to say that Nuhi, Vorck, and joedeboek all saw his project when he started it. As for Fred Langa, you might let him know about MSFN; he would do well to read all of the content here. No, that's called spamming. Don't.

Can you guys see if your [Data] section has UnattendedInstall=Yes in it? Yeah, it might be obvious but it's worth checking

100% certain it's a false positive. Many antivirus programs use checksums of various file versions and flag anything that doesn't match the checksum of a known version. nLite modified sfc_os and so the checksum doesn't match the known SP2 or SP3 or whatever version of the file you're using. I suggest you add a rule in your AV software to prevent it from checking your entire nLite directory so that the software doesn't try to "help" you out by quarantining/autodeleting this or other dlls.

IMO you are in for endless headaches trying to run Server as a desktop. Yes, there is a thread telling you how to do it -- I don't have it handy -- but ultimately, there are indeed programs out there that will refuse to run on Server, and you cannot always change them or fool them using the available tools. As for the difference between foreground / background performance, this is what those buttons are adjusting: execution quanta. As for stability, I think both are pretty darn equal.

I host an (alternate) list compiled by TommyP, the HFSLIP creator.

Here you go. They all link to KB's so you can get any language you like. Here is the software to slipstream them into an XP SP3 source.

Now that the update lists are in place at my site (see the pinned topics), and given that Windows 2000 is the oldest OS with the greatest number of hotfixes for it, it's probably time for HFSLIP users who use Win2k to weed out obsolete hotfixes -- and there are a LOT of them. The current Win2k list has, at the bottom, a list of obsolete fixes, and it's a long one. Since the list won't be retroactively tracking obsolete hotfixes, the best thing to do, IMHO, is for everyone who uses Win2k to delete the hotfixes in their HF folder, and re-download everything listed here. That way, we'll start clean for 2009. KB files to be removed / do not use 890046 896424 904706 908523 911562 911567 912919 916281 917159 917422 917734 917736 917953 918899 920958 921503 921883 922616 922760 923689 923694 924191 925454 925486 926122 (incorrectly listed -- you actually do want this one) 928090 929969 931768 932168 933566 935966 937143 938829 939653 941202 941568 941644 941672 942615 944533 946538 947864 948881 950759 950760

I wish there was a guide that explained what files nLite manipulates for every different thing it removes, but I can't find any. Any such guide would greatly accelerate development. Can anyone help me with this? I think I can tell you the obvious without incurring Nuhi's wrath. He very meticulously found what files belong to which components. Some files install as "base" (i.e. they are put onto disk by LAYOUT and then TXTSETUP copies them to where they belong) and some components are called by individual .INF files. Expand SYSOC.INF and look at the "Optional" components that are listed. They install automatically but have checkboxes when called by Add/Remove Components. Commenting them out (or deleting them) will prevent them from installing at all. Now expand and have a look at SYSSETUP.INF. Find [infs.Always] Here you will see a LOT of components that you just do not need. To see what one does, find the INF file listed, expand it, and examine it. Some components are a problem: look at IE.INF. There is NO list of files in it! That's because Microsoft has put the files into TXTSETUP and LAYOUT so that IE files are put onto your system no matter what. Nuhi's software edits all of the files I have mentioned, and more. I haven't really given anything away I don't think, because when you run the software, you can see just by filedate what has changed. As for the batch files, it was Joe Deboeck IIRC. My fileset for Windows 2000 dates from November 2001. I modified SETUPAPI.DLL to be able to make changes to these INF files. Before that mod, I had to change INF files and then run a service pack slipstream to avoid digital signature errors. Nuhi does not alter SETUPAPI, but uses a different DLL. One must avoid signature checking to have altered INF files work. LAYOUT is a special case, and to modify it, you must globally replace ,_x, with ,, (in other words, delete every occurrence of underscore X between two commas in the entire file). nLite does not change LAYOUT, only TXTSETUP. Most likely Nuhi did this for speed. As a by-the-way, you can actually copy the entire file list from TXTSETUP and paste it into LAYOUT. It will work fine, you do NOT need those file byte counts, and your setup will go much faster since LAYOUT and TXTSETUP copy files twice.

Hi all, I think I posted this a while back but a forum search resulted in 21 pages, and I'm not going to go hunting for my own post... Anyway, all of the files listed under the [Files.NoWin31.System32ToSystem] section in SYSSETUP.INF can be deleted. This is true for all Windows versions, 2k, 2k3, and XP... they can all be removed. They are all copied to SYSTEM (not 32, just system) and are legacy, left over from Windows NT 3.1 (there really was an NT 3.1!) I have had an empty SYSTEM directory in all three OS's for a long time now and can confirm that nothing calls these files. It's not that they take a lot of space, but I put little utilities like Process Explorer there by making an OEM structure like this: $OEM$ \ $$ \ system because it's easier to find them there than it is in SYSTEM32, and because SYSTEM is already defined as a valid path in the Windows variables.

What happens when you add cpqarrary.sys to the "Keep" files box?

Yes, you need the Rollup. However. The Rollup installs file system filters and a bunch of useless reg keys called explorer templates. But it's a hotfix that is 95% good, so apply it anyway. Win2k works fine without the file system filters (as does XP, if you know how to rip this component out -- no, nLite doesn't offer it). Getting into the specifics of how to edit the Rollup to remove the explorer templates and the minifilters is way more than I want to type, but just wanted to say yes -- you should apply the Rollup. As for a firewall, I'd recommend a hardware one. I will be honest and tell you that when I installed Win2k without IE on my sister-in-law's laptop, and visited her a year later, I noticed she had it plugged directly into the cable modem and was bypassing the router/firewall she'd bought (for whatever reason). Her ISP did not provide any sort of port hiding. She'd never had any problems whatsoever. As for a default install of win2k, one with IE, I'd want to use a firewall. Note that the default in the tcpip setup file is to run NetBIOS over TCP/IP, for one thing. Etc etc.

No, IIRC that was Win 2003. That method was experimental and we took it in various directions as something to try. It didn't prove very popular because most 2003 users use nLite. Which is fine, we were just trying stuff out. I love nLite myself, but I wanted to apply the knowledge I've gained with 2000 to XP to see what I could do. I'm looking to remove as much as will make XP pretty much just like 2000 -- it's a personal goal anyway, so I can run things like Adobe CS3 which will not run on Windows 2000. Unfortunately, the DLLs like shell32 and browser and shdocvw all have mega-huge REGINST sections that fill the OS with crap, much more than 2000 ever did. So I am going to have to also issue text files to replace those sections (since those DLLs tend to be replaced by hotfixes). I have tried every possibile combination of 2000 and ReactOS DLLs in XP to see what would work, and the verdict is that Explorer won't launch with other OS DLLs in place (although the OS will work otherwise). nLite is a great tool but I felt it would be kind of silly to repeat what I did for 2000 that I was going to do anyway just to learn and not share it with people to mess with and also learn from. Doesn't the code in IE.INF take yours out? Does yours show up? I haven't seen Favorites as a menu item in Explorer in a really long time. I forgot it was even "supposed" to be there. TweakUI 1.33: I opened it just now and I see that it has a shell enhancements checkbox. I've never used it. If you have a regmon or reg snapshot program, see what key(s) it changes. Now that I'm going to do anything with the info, since my fileset literally destroys the ability of the OS to display IE shell enhancements, but I am curious anyway.

Ah! I see the mistakes now. Thanks, I have included the fixes in a new update.

Thread will be unstickied December 1, 2008 unless comprehensive updates are made in the initial post.

@Martin H I understand. I will revert the SP level to 4. I will also default the IE level back to 5. This will be user-settable in IE.INF and will have four different versions to choose from. @Brabant The MSI you saw is not essential. It's my XML4, and honestly I can;t even remember why I have it anymore Here are the 2 keys to change Windows to SP4: HKLM,"SYSTEM\CurrentControlSet\Control\Windows","CSDVersion",0x00010001,0x400 HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion","CSDVersion",,"Service Pack 4" Here are keys to make Windows "see" IE6 fully patched: HKLM,"Software\Microsoft\Internet Explorer","build",,"62900.5512" HKLM,"Software\Microsoft\Internet Explorer","Version",,"6.0.2900.5512" HKLM,"Software\Microsoft\Internet Explorer","W2kVersion",,"6.0.2900.5512" HKLM,"Software\Microsoft\Internet Explorer\ActiveX Compatibility","Version",,6.01 HKLM,"Software\Microsoft\Windows\CurrentVersion\Internet Settings","MinorVersion",,";SP1;" HKLM,"SOFTWARE\Microsoft\Active Setup\InstallInfo","Version",,"6.0.2900.5512" HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ieupdate","RequiresIESysFile",,"6.0.2900.5512" HKLM,"Software\Microsoft\Active Setup\Installed Components\%CLSID_IESHELL%","Version",,"6,0,2900,5512" HKLM,"Software\Microsoft\Active Setup\Install Check","IE40",,"6.0.2900.5512"