heh. too late.

Will try 1.6.3 right now and report back

The date in the main post is wrong. It says July 30th, when it should say October 1.

the_guy

Heh... It took me half an hour to figure out what you meant. I was thinking of "main thread" and just couldn't find it...

Happy to report 1.6.3 is working and all is right with the world once more (yeah right!)

Thanks

Question: Is there support for the latest version of Internet Explorer 7 (the version without WGA; version 7.0.5730.13) in the latest version of HFSLIP?
Question 2: In wich folder do i have to place the roots update package? in HF?

A new test release to support the new IE7 installer is in the making. I'm now testing in a VM.

The roots update goes in the HF folder, yes.

Okeey

What is the release date of this version. Do you have any idea? I cant't wait

How 'bout now?

Ha okey!
This 1.6.3 version supports the latest Internet Explorer without WGA? Can't find it in the changelog

I was talking about a test release. Please check the first post in this thread

Now is great
Downloaded it and will give it a try soon!
Does it also prevent RunOnceEx from breaking due to integrating the new IE7?

None of the HFSLIP versions do anything to fix the RunOnceEx problem. You should just include the latest cumulative update -- which seems to work for most people.

You mean the latest cummulative update for IE7? I had that in my HF folder, but RunOnceEx didn't run. What is the latest update, so that I can check?

There is a new update for IE7 available:
Cumulative Security Update for Internet Explorer 7 for Windows XP Service Pack 2 (KB939653)

Maybe this will fix the problems with the new IE7 installer with wrong time stamps?

If you are using the latest version of the main IE7 package then you must use the latest HFSLIP test release.

Is there any reason why HFSLIP doesn't support w03a3409.dll for 2003 SP2 updates? I missed the difference until today, so is that it?

It's just a couple lines that need to be added, and another to be modified.

the_guy

You are probably referring to localized namings of w03a3409.dll.

I didn't know the file existed. It should be supported now.

RC4 gives al lot of "file not found" errors, and creates a file TEMP instead of a folder wich causes the file not found errors, manually making a temp folder during the process causes the error: TEMP\APPC wordt niet herkend als een interne of externe opdracht, programma of batchbestand (translated something like bad command or filename), serveral "random character" folders are made in the root of c:\ (probably also caused bij the temp folder thingie)

1.6.6rc4 doesn't run correctly on Japanese XP SP2.
The script is terminated at the GET LUNG section.
The 3199th line of the script is garbled in Japanese command prompt, and seems to cause the error.

Click to view attachment

@Nanasi3

Thanks for reporting this. Can you verify that it's fixed in 1.6.6 RC5?


@Glowy

Do you have the same problem with RC5? Try rebooting your system and do a chkdsk too.

RC5 -> still the same
reboot -> still the same
I'm building a new VM atm to test something else.. I will test it in the VM when it's done, maybe somethings wrong with my PC.

I see the problem. I'll fix this asap.

Edit: fixed

1.6.6rc6 works fine.
Thank you very much !

I'm testing 1.7.0 rc1. It's OK with Greek language and updates but in the hfslip process I get a "zero file copied" as you can see inthe attachment. Is it normal?

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, it's there in 1.7.0rc2.

In the system properties the automatic update tab is shown in English, but it should be Greek.
Is there any chance that this is caused by hfslip?? With older versions this didn't happened. I think that this occurs with 1.7rc versions but I'm not sure.
The snapshot is from hfslip 1.7rc4 without any other addons or driverpacks.

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?



Click to view attachment

I will do when i get home. Can you send me the 1.6rc version to test again because I have a working dvd created with that version.

edit: and the lucky number is 1033

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

I have bad news I think:

LCID = 1033
language code = enu

With older versions of hfslip I didn't had that problem (the automatic update tab).
The last good version was HFSLIP Version - 1.7.0rc1 build 71111a (I found the dvd and checked the hfslip.log) but I have deleted the cmd file and I cannot test it again.

edit: also I see with 1.7.0rc1 --> OS in SOURCESS - XP SP2 „ΆΆž¤ ΅α

1.7.0rc4 build 71112b --> OS in SOURCESS - XP SP2 English

lol now I understand what happened

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

Yeah now it's working again!! It says Greek in the log file.

I can't believe how fast you fixed it and uploaded it!!!!! Thank you again.

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

You're welcome.

Maybe this is not right place to ask but sorry from now
*i speak about not public hotfixes*

Every hotfix does not contain only one file. I have seen some hotfixes mixed each other.
Bigger KB can include a lower version number file. But other files are newer version.
And another hotfix may include newer files then bigger KB hotfix.

Crossed each other. :/

I would like to know can HFSLIP can choose newer file to slipstream or not? Automaticly i hope.

Hi Eyren. The COPY and XCOPY commands in the command prompt have a switch that allows you to only copy over files that have a newer modification date. HFSLIP incorporates this directly into the script, so you don't have to worry that files from hotfixes with higher KB numbers are overwriting newer versions from hotfixes with lower KB numbers. In cases where the file dates are messed up and we actually need a binary that was modified earlier, the necessary commands are hardcoded.

What he said...

Just i want to say.

For example.

KB33333 includes
a.dll ver: 3.5.5555
b.dll ver: 3.5.5555
c.dll ver: 3.5.5555
d.dll ver: 3.5.5555

KB44444 includes
a.dll ver: 3.4.444
b.dll ver: 3.6.666
f.dll ver: 3.6.666
g.dll ver: 3.6.666


soo.
after slipstream i have a.dll ver 3.4.444 in setup folder.
but older hotfix includes never a.dll and it overwritten by never hotfix but older file.

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.

I have a little problem with the new version. My host system now is Windows XP x64. When the script reaches the point in which DX9 is beeing processed, the install screen of DirectX shows up, I click cancel, but nothing is slipstreamed to the XP 32 source.

Any fix for that?

After a full slipstream with newest hfslip, i decided to use a directx web setup to verify if it´s allright.
This setup wants to download SDKs updates....at least 6.1mb.

Is there a way to slipstream it too?

I´m using win2k3

Another question:

Is the a way to disable / uninstall internet enhanced security with hfslip?

Are you sure you aren't confusing the extraction dialog box with the installation dialog box? If the DX9 executable would actually start installation, you should've observed the same problem with Type 2 hotfixes as HFSLIP uses the switches for Type 2 hotfixes to extract the redist too.

What is the name of the executable and how big is it?

Which are the SDK updates? I compared the versions of each file to see which DX9 binaries for 2K3 are newer/needed for 2K3SP1/SP2 in the revised code in these test releases.

HFSLIP doesn't do it, but I'd like to know that for myself. Just never had the time.

ieframe.dll problem while trying to access "some" websites including windows update.

Hi,
I have a problem while trying to access websites using a Chinese XP system slipstreamed with IE7 using 1.7.1 rc2. (It was ok with 1.7.0)

have attached a screenshot and hfslip.log

thanks.

btw, I have created a silent installer .NET framework 3.5 using winrar and .NET 1.1 installer using SNM. (both runs prefectly on a normal xp)
I put DNF11.exe into the HFSVCPACK and I put net35.exe into the HFGUIRUNONCE. I cannot check if the .NET1.1 has been installed or not. however, I am pretty sure the net35.exe haven't been installed since I dont see any screen popup after I login into the system. Do I need to put anything else into those folders to make those run? or I just need to put the exe in ?

Thanks in advance

HFSLIP hasn't changed the handling of ieframe.dll when it's slipstreamed into the source. The current test release does something special with that file, but only if the GUILOGON method is used (only then, because I haven't observed any issues myself with ieframe.dll when slipstreamed, or with the SVCPACK method).

This is beginning to smell like a serious issue with the newest cumulative update. Can you please do me a favor and retest with HFSLIP 1.7.0? Don't reuse the source that HFSLIP 1.7.0 made in the past; let HFSLIP 1.7.0 make a new source again, using your current list of hotfixes.

If you used SNM to create a silent installer for .NET 1.1 you should see two entries in Administrative Tools. If they aren't there, installation has failed.

I can't speak for .NET 3.5 yet because I haven't been able to try it thus far. Check the RunOnce key in HKEY_LOCAL_MACHINE for anything suspicious.

the 1.7.0 slipped system got the same error while using the same set of hot-fixes

attached the log for analysis

Just as I thought.

I will do some tests in my VM to see if I can somehow duplicate the problem when slipstreaming IE7. I could come up with a few test releases but that's taking things too far; I don't like to work in the dark.

Can you tell me if everything is fine if you set IE7GUILOGON=1 in HFANSWER.INI? It's not so important, but it would help knowing whether it's the same problem or not.

Thanks for the help

Do you need something tested ? I have 2k 2k3 and xp all vol license keys, I work for a school district so I can test this on different machines as well. Just let me know!

Here is some pics:










Click to view attachment

@ctpooon--

Sorry, but I couldn't duplicate it yet. Everything is fine with WinXP Dutch. I will check the binaries of the CHT IE7 package and cumulative hotfix next.


@geese howard--

That wizard shows "DirectX Runtime Optional Components" so I suspect it's installing the Managed DirectX stuff which HFSLIP doesn't support. See if you get an extra folder named "DirectX for Managed Code" (the name can be slightly different) in your %WINDIR%\Microsoft.NET folder after installation has completed.