Tomcat76

@Acheron Well, you know... Those are the commands that are used by Microsoft in the hotfixes. If those are altered, I want to be sure that they still work. Also, the second command is no longer triggered from HFSLIP.CMD but from HFSLIPOC.INF in HFSLIP 2.0 so the syntax you propose may need to be changed again. @Smiley89 I don't really know what else could be the problem. I can't duplicate it with an English or a Dutch source.

If those files are responsible it can only be WindowsUpdateAgent30-x86.exe. Download it again to make sure that the one you had is not corrupt.

Did you include the one for DirectX7 or the one for DirectX9? Did you also include DX9?

You don't mention .NET 2.0 so I'll give a double answer.1) .NET 3.0 requires .NET 2.0 to be installed first 2) As specified in the introduction thread, if you install .NET 1.1 first and then .NET 2.0, .NET 3.0 can't be installed immediately afterwards because the combination of .NET 1.1 and .NET 2.0 causes Windows to report to other programs that .NET 2.0 isn't installed until the next reboot. Theoretically, this should've worked. But why are you trying this at T-13? .NET 3.0 SP1 and .NET 3.5 are not SVCPACK-compatible.

You could also just try Silent .NET Maker which supports language packs, and then put the resulting file(s) in either HFSVCPACK or HFGUIRUNONCE. Be advised that .NET 3.0 SP1 and .NET 3.5 can't be installed at T-13 so they should be placed in HFGUIRUNONCE.

You should be able to find the info you need in the SNM thread. It also depends on what you want to install. General rule: .NET 1.1 and .NET 2.0 SP1 are OK to be installed at T-13 (during Windows setup) but later versions are not; those should be installed afterwards. So DNF11.exe and DNF20.exe (or the combined package obtained by using MERGE_FRAMEWORKS=12) can be placed in HFSVCPACK. DNF30.exe and DNF35.exe (or an all-in-one package obtained by using MERGE_FRAMEWORKS=FULL) should be placed in HFGUIRUNONCE (or HFFIRSTLOGON in the pre-alphas of HFSLIP 2.0).

Can't see anything wrong in the log. What is 12CPRODEV_setup.msi? It isn't handled by HFSLIP. Are there any errors in <drive>\WINDOWS\setuperr.log on the system on which you installed the new source? I think that the problem is that the Windows Update Agent dlls weren't registered. Registering them manually may fix this but that doesn't say that there aren't any other problems. Try removing the addons.

Smiley89-- Everything seems to be in place for the Windows Installer 4.5 update. I could only spot a few unnecessary hotfixes but it's not certain that those are the culprit. WindowsXP-KB949269-x86-ITA.exe [Windows XP doesn't have ADAM] WindowsXP-KB951978-x86-ITA.exe [only for XPSP3 with IE6 - manual installation is blocked if IE7 is detected] You could also remove WindowsXP-KB944043-v3-x86-ITA.exe and WindowsXP-KB951830-x86-ITA.exe but I don't see anything out of the ordinary with those so try removing only the other two first.

@Smiley89 Do you still have the SOURCESS folder? If so, ZIP TXTSETUP.SIF and HFSLIPOC.INF from SOURCESS\I386 together and put the ZIP file online (either here or elsewhere). @Acheron I need to discuss that with TommyP.

Look at the dates of the posts. They are comments to all test versions that were released since the thread was started.Anyway, it doesn't matter. I didn't let the recent change go through into the final HFSLIP 1.7.8. I think I will do something with MFC42xxx.DL_ in the future since it is a usable file for all versions of Windows that are supported by HFSLIP. I only need to see if there are any problems with Chinese (Hong Kong) and Spanish. Thanks for the suggestion. In the mean time, specify LCIDD=1037 in HFANSWER.INI. That will force HFSLIP to use Hebrew.

To my knowledge, that is normal but I'll check again.

It was removed on the 11th.

You shouldn't edit FP40EXT.INF; it is a setup information file. In fact, now that I think of it... Can you copy the text in your original PRODSPEC.INI and post it here? Maybe there's still something in there that HFSLIP can use.

HFSLIP checks FP40EXT.INF (2K/XP) or FP50EXT.INF (2K3) to know the source language because it requires less workarounds than when PRODSPEC.INI is checked. PRODSPEC.INI is only checked if the language could not be determined from FP*0EXT.INF. Your FP40EXT.INF file probably has the localization set to English (just like on Greek sources) so HFSLIP 1.7.7 won't bother to check PRODSPEC.INI additionally which is why editing the file has no effect for you. But if both FP40EXT.INF and PRODSPEC.INI have the localization set to English on Hebrew sources, it's going to be difficult. If you keep the change you made to PRODSPEC.INI then you can use the latest test release, which does an additional check for the word "Hebrew" in PRODSPEC.INI.

Slight misunderstanding... I updated the text in the first post.

These are SVCPACK-compatible switchless installers I made for Microsoft Silverlight 1.0 and 2.0 beta 2. Silverlight 1.0 Silverlight 2.0 beta 2 ATTENTION: These are not compatible with each other. You should install either 1.0 or 2.0.

You can try the latest test release at the top of this forum. No other changes are planned so it should be out as a final one of these days. As far as Microsoft Update is concerned... I don't know if this is the source of the problem but you don't have Windows Update Agent 3.0.

I haven't tested them yet. Will do that today or tomorrow, and update the list as well.

Sorry; I forgot to add it. It's there now. Why the log?

HFSLIP can only work with a clean source (original or with SP). The SOURCESS folder can't be reused by HFSLIP.

Problems should be fixed now with the latest test version.

The problem is that I was making use of destination folder ID's that apparantly only exist for English XP/2K3 sources. The next version will fix this. But there's an additional problem. I tested it on a German Windows XP source and it appears the German security catalog file for this update is fubar; you'll get three errors reported in setuperr.log. To work around this, I will have to enforce the use of 7za.exe for Windows XP and Server 2003 host OS's as well in order to get the English CAT file in every circumstance. This is namely a special hotfix that contains INFs and CAT files for all languages Windows XP was released in, but normal extraction will only extract the INF and the CAT in the language of the host OS; eg, if the host OS is German, normal extraction will cause only the German INF and CAT file to be extracted. I can only get the English CAT file for non-English host OS's by using 7za.exe. Also, by adding support for Windows Installer 4.5 I broke the handling of Windows Installer 3.1 for Windows 2000. In the mean time, you can get around this by placing 7za.exe in the HFTOOLS folder.

What's "xxx"? Windows Installer 4.5 is not supported by HFSLIP 1.x or HFSLIP 2.0 older than 80605a so you won't notice the problem there. I'll look into it. I have an idea of the cause, but I must admit I didn't expect it. I only tested WI 4.5 with an English Windows XP source. I'll try with other languages now.

The Service Pack is applied to the source in the SOURCE folder. Then the source is copied into the SOURCESS folder. Then the binaries from hotfixes and updates are copied into the SOURCESS folder, overwriting existing ones. @jvidal It isn't an error. First of all, the source in the SOURCESS folder contains the same Service Pack. Secondly, it would be wrong to write "OS in SOURCE" because you can have HFSLIP create a backup of the source before the slipstreaming takes place; near the end of the HFSLIP run, the backup replaces the updated SOURCE folder again after which the source in the SOURCE folder will no longer be at the mentioned Service Pack level.

Include the ones that WU wants you to have. The rest is up to you.