Tomcat76

Do you have Office 2007?

Those three are the same and 22-Nov-2007 = 2007-10-22. So do you have opuc.dll in your SYSTEM32 folder after installation? Is it version 12.0.5543.1000?

It isn't supposed to change. Both subkeys should exist.

The proper subkey if you're using the Classic Start menu is ClassicStartMenu. I suppose Windows automatically copies this, then. If not, it's a new bug.

Which site are you downloading Office updates from? Needed for Microsoft Update: OGAControl.cab (05-Mar-2007) Needed for MS Download Center: OGAControl.cab (05-Mar-2007) Needed for Office Update site: OGAControl.cab (05-Mar-2007) and OPUC4.CAB (22-Nov-2007)

You need to think of the people that may have the same problem you have. They don't wanna read through an entire topic which speaks of something totally unrelated.[post moved] The only way I can imagine the renaming process to fail with the current version of HFSLIP is if you DON'T include KB925876. HFSLIP only renames lhmstscx.dll if the file tscinst.vbs is also present. This is only the case if KB925876 is slipstreamed as well. I just did a test with both KB925876 and KB941603-v2 in the HF folder, and lhmstscx.dll (which is the version from KB941603-v2) was properly renamed to mstscax.dll.

Is that the version from July 31, 2007? (right-click WindowsUpdateAgent30-x86.exe > Properties > Digital signatures) MS have recently started to push through LegitCheckControl.cab from October 11, 2007. Make sure that's the one you have.

Version 1.6.4 was released on October 14, version 1.6.5 on October 25, and version 1.7.0 was released just the other day... No biggie, though... You are supposed to put it in the HFTOOLS folder, so HFSLIP can automatically create the ISO when it's done. That's what Step 6 in the Basic How-to is all about. If you want to do things manually, that's your call... HFSLIP automatically deletes an existing SOURCESS folder when it's started. I believe the comment you're referring to is that you shouldn't copy the content of the SOURCESS folder into the SOURCE folder next time as HFSLIP is only made to work with a clean source. Do you get the same problem when you start from scratch again? If you show me your HFSLIP.LOG file (please ZIP it), I can tell you if you need it or not.

Now I'm beginning to wonder... Do you actually have the original Microsoft EXPAND.EXE in your system32 folder? If it is not the original MS version, or if you have another version of EXPAND.EXE in a different folder for which a system path is configured, extraction by HFSLIP will fail if it uses different switches. Make sure that the first system path which contains EXPAND.EXE contains the original EXPAND.EXE from Microsoft, or place it in the main HFSLIP working folder.

Are you using HFSLIP 1.7.0? Can you check in HFSLIP.LOG if HFSLIP detected your language correctly? The link is actually not changed. It's just that the Windows Update site automatically redirects to the Microsoft Update site if that is installed. This also happens when you go to the Microsoft Update site yourself.

If you had to do this manually then there's either something wrong with the file in your source, or your host system does not support extracting of Windows-compressed files from the command line (though I wouldn't know how to break that myself). That command only checks whether your sysoc.inf is in Unicode or not. If it's Unicode (as is the case for non-English systems), a silent error occurs which is intercepted by the "IF ERRORLEVEL 1" command and then sysoc.inf is treated differently. If the error is not silent for you, there must be something strange with your system configuration. I'll have HFSLIP check if that file exists before handling it in the next version, but I won't make it a quick-fix release because that file is there by default on all sources. HFSLIP is made to work with original/clean sources only.It would help if you ZIPped your HFSLIP.LOG file and attached it here...

It depends on whether you have the default Start menu or the Classic Start menu.

HFSLIP checks the time the file was created (just see for yourself which date Windows is showing) and slipstreams the newest. HFSLIP can't check the version number. If a.dll version 3.4.444 was created more recently than 3.5.5555 (which happens from time to time), 3.4.444 will be slipstreamed by mistake. Special exceptions already exist in HFSLIP but they only cover specific situations. This will work: a.dll version 3.5.5555 created on 12-January-2007 a.dll version 3.4.444 created on 1-January-2007 This works because 3.5.5555 has a newer date. This will fail: a.dll version 3.5.5555 created on 12-January-2007 a.dll version 3.4.444 created on 15-January-2007 This fails because 3.5.5555 has an older date.

What he said...

That's the advantage of having a multiple personality disorder. You can split the workload... You're welcome.

RC5 should work for you. Please run it and then check in HFSLIP.LOG...

So FP extensions are in English for you... Nice. Can you download the attachment in my previous post (updated) and run that? It also reports the language code. I hope that's not "enu", hehe...

What is your OS language according to HFSLIP.LOG? Can you extract the attached ZIP file into the HFSLIP working folder, run it, and report back the number that's displayed? testloc2.zip

What if there is already something you can use? HFANSWER.INI: DELCATS_OVERRIDE=<name of cat file without extention> The DELCATS_OVERRIDE variable was introduced in HFSLIP 1.6.2 and is discussed on the web site, right here. I'm not sure if IE7 itself is problematic, but I know someone else reported this before you and the problem was the cumulative update for IE7 then, so you should definitely use: DELCATS=1 DELCATS_OVERRIDE=KB939653-IE7 If you need to set more than one, do it like so: DELCATS=1 DELCATS_OVERRIDE=ie7 DELCATS_OVERRIDE=KB939653-IE7 The cat name for the IE cumulative update may change tomorrow on Patch Tuesday.

Well, it's there in 1.7.0rc2.

Yes, it's normal in that situation. HFSLIP 1.6.4 and newer force-copy ieframe.dll.mui, jscript.dll and vgx.dll from IE7 hotfixes because they have an older creation date than those in the new IE7 installer. After that, HFSLIP does a "normal" copy of the remaining files, but you see "0 File(s) copied" because vgx.dll is the only file inside IE7-WindowsXP-KB938127 (there is nothing else to copy). The same applies to IE7-WindowsXP-KB933873 which only contains jscript.dll. However, DOS allows copying of files created on or after a specified date, so I will experiment with that feature a bit now. Maybe it will make it in the next version.

Well... There are a few things you should maybe know... HFSLIP is a DOS program so it can only go by the creation date of files (using the XCOPY command with the /D switch) without additional tools. If you have a hotfix containing a file named filename.exe which was created on April 1, 2003, and another hotfix with the same file but created on June 1, 2007, then HFSLIP will take the newest, even if it has a lower version number. HFSLIP only makes exceptions for "known issues" such as IE7 for WinXP and the KB899591 update for Win2K Server. Also, this creation date comparison is only done between files coming from hotfixes and updates; files inside the original source and the Service Pack (like USP 5.1) are not taken into account: they are overwritten with whatever turns out to be "the newest" from hotfixes and updates. Old hotfixes are composed differently and may not be supported as a result. They may also contain AddReg and DelReg sections in their installation INF files which have a name that isn't covered by HFSLIP. If they contain new files which are not part of the source and need to be placed in a location other than "the defaults" that HFSLIP handles, they are not supported. HFSLIP does have hard coded support for some, but only for files related to current mainstream updates and hotfixes. If they contain long file names, they are only supported for sure if HFSLIP already has in-built support for those specific files. If HFSLIP does not yet have support for one or more of those long file names, they are only supported with CD-based installs (and if they need to be placed in one of the "default" locations) because floppy installs and network installs use DOSNET.INF, which can't handle long file names. If files need to be renamed, they are only supported if HFSLIP already covers those files.

What switches are you using with cdimage? I'd still like you to try HFSLIP 1.7.0rc1 and post a new log file if the problem remains. Did you remove obsolete and not supported updates?

I notice a few problems with your log file. MDAC253-KB927779-x86-ENU.exe MDAC281-KB927779-x86-ENU.exe I don't know whether USP 5.1 contains MDAC 2.8 SP1 or not. If it does, you should remove the hotfix for MDAC 2.5 SP3. If it doesn't, you should remove the hotfix for MDAC 2.8 SP1 (or remove the hotfix for MDAC 2.5 SP3 and include the MDAC 2.8 SP1 package). I also see quite a few hotfixes that do not appear on my hotfix list. Be careful with those.

That's actually ironic, because nVidia is usually coupled with data loss...