Jump to content

HFSLIP - Test releases

Tomcat76

By Tomcat76
in HFSLIP

 Share

Recommended Posts

Tomcat76

Tomcat76

Posted
  • Author
Posted

OK. Forget about the GUILOGON problem for now. The ieframe.dll issue is more important.

Please unset IE7GUILOGON in HFANSWER.INI (remove the "1") and run HFSLIP 1.7.1rc7 (new version). Test with DELAY_IEFRAME=1 in HFANSWER.INI. Hopefully that resolves the problem.

Link to comment
Share on other sites

ctpooon

ctpooon

Posted
Posted (edited)
OK. Forget about the GUILOGON problem for now. The ieframe.dll issue is more important.

Please unset IE7GUILOGON in HFANSWER.INI (remove the "1") and run HFSLIP 1.7.1rc7 (new version). Test with DELAY_IEFRAME=1 in HFANSWER.INI. Hopefully that resolves the problem.

nope, it doesn't

ieframe.dll still crashes my ie while accessing windows update even after a manual restart.

HFSLIP.zip

Edited by ctpooon
Link to comment
Share on other sites
Tomcat76

Tomcat76

Posted
  • Author
Posted

I have checked this out a bit more. If the problem is really with ieframe.dll, I don't think it's a problem with the file itself (at least in the slipstreaming context). This file is in English for every IE7 package so everyone should have your problem in that situation.

I think there's only two possibilities left. I'll start with the one that's easiest to test...

When slipstreaming IE7, ieframe.dll is supposed to be registered from a RunOnceEx key at T-13. You are clearly having problems with RunOnce(Ex) so it's possible that this registration never took place. Open a Run prompt on the newly installed system and execute the following commands, one at a time:

regsvr32 "%ProgramFiles%\Internet Explorer\ieproxy.dll"

regsvr32 /i /n ieframe.dll

regsvr32 actxprxy.dll

Click OK on each message box that appears (succeeded or failed). After that, reboot and try again.

The second possibility is a problem with ieframe.dll.mui. What is the version of ieframe.dll and of ieframe.dll.mui in the system32 folder?

Link to comment
Share on other sites
ctpooon

ctpooon

Posted
Posted
I have checked this out a bit more. If the problem is really with ieframe.dll, I don't think it's a problem with the file itself (at least in the slipstreaming context). This file is in English for every IE7 package so everyone should have your problem in that situation.

I think there's only two possibilities left. I'll start with the one that's easiest to test...

When slipstreaming IE7, ieframe.dll is supposed to be registered from a RunOnceEx key at T-13. You are clearly having problems with RunOnce(Ex) so it's possible that this registration never took place. Open a Run prompt on the newly installed system and execute the following commands, one at a time:

regsvr32 "%ProgramFiles%\Internet Explorer\ieproxy.dll"

regsvr32 /i /n ieframe.dll

regsvr32 actxprxy.dll

Click OK on each message box that appears (succeeded or failed). After that, reboot and try again.

run those command, restarted, problem doesn't solve.

The second possibility is a problem with ieframe.dll.mui. What is the version of ieframe.dll and of ieframe.dll.mui in the system32 folder?

ieframe.dll - 7.0.5730.13

ieframe.dll.mui - 7.0.6000.16414

Link to comment
Share on other sites
Tomcat76

Tomcat76

Posted
  • Author
Posted
ieframe.dll - 7.0.5730.13

ieframe.dll.mui - 7.0.6000.16414

7.0.5730.13 is the version from the main IE7 package, which means ieframe.dll didn't get updated at T-13. I suppose you still have ieframe2.dll in the SYSTEM32 folder.

Your problem is even more severe than I thought. The change from ieframe2.dll to ieframe.dll is done from HFSLIP.CMD. HFSLIP.CMD is called from SVCPACK.INF, so the registry is not involved in this. In other words: SVCPACK.INF failed to run.

Can you compress SVCPACK.INF and SYSOC.IN_ from SOURCESS\I386 and HFSLIP.CMD from SOURCESS\I386\SVCPACK into a ZIP package and upload it here?

If these files turn out to be OK, I can only conclude that your source is corrupted. The odds that HFSLIP would break nearly everything there is to break are really slim...

Link to comment
Share on other sites
ctpooon

ctpooon

Posted
Posted (edited)
ieframe.dll - 7.0.5730.13

ieframe.dll.mui - 7.0.6000.16414

7.0.5730.13 is the version from the main IE7 package, which means ieframe.dll didn't get updated at T-13. I suppose you still have ieframe2.dll in the SYSTEM32 folder.

Your problem is even more severe than I thought. The change from ieframe2.dll to ieframe.dll is done from HFSLIP.CMD. HFSLIP.CMD is called from SVCPACK.INF, so the registry is not involved in this. In other words: SVCPACK.INF failed to run.

Can you compress SVCPACK.INF and SYSOC.IN_ from SOURCESS\I386 and HFSLIP.CMD from SOURCESS\I386\SVCPACK into a ZIP package and upload it here?

If these files turn out to be OK, I can only conclude that your source is corrupted. The odds that HFSLIP would break nearly everything there is to break are really slim...

ieframe2.dll is still in the system32 folder.

attached the files u requested.

how to tell if my source is corrupted?

have fun :)

fw.zip

Edited by ctpooon
Link to comment
Share on other sites
Tomcat76

Tomcat76

Posted
  • Author
Posted
how to tell if my source is corrupted?
By opening a command prompt (Start > All Programs > Accessories > Command Prompt) and running this command:

chkdsk c: /r

(assuming that your HFSLIP working folder is still on drive C:)

You will be asked to do this at the next reboot if your system is installed on drive C:.

When that is finished (may take a while if your hard disk is large), remove the SOURCE folder and copy over the CD again.

The files you attached last are fine. I just realized I forgot to ask to include HFSLIPWU.INF too, so if you can... :)

Link to comment
Share on other sites
ctpooon

ctpooon

Posted
Posted (edited)
how to tell if my source is corrupted?
By opening a command prompt (Start > All Programs > Accessories > Command Prompt) and running this command:

chkdsk c: /r

(assuming that your HFSLIP working folder is still on drive C:)

You will be asked to do this at the next reboot if your system is installed on drive C:.

When that is finished (may take a while if your hard disk is large), remove the SOURCE folder and copy over the CD again.

The files you attached last are fine. I just realized I forgot to ask to include HFSLIPWU.INF too, so if you can... :)

attached the hfslipwu.inf

my file system seems to be ok, I just removed the source folder and copied from the CD.

compiled using hfslip-1.7.1rc9_71212a.cmd ... same result.

also attached the file structure of my cd .. in unicode big endian format

HFSLIPWU.zip

list.zip

Edited by ctpooon
Link to comment
Share on other sites
fenyo

fenyo

Posted
Posted
(1) Show Desktop icon created in special way for certain languages when handling IE7

If your source OS is Czech, Hungarian or Turkish, and you let HFSLIP slipstream IE7 (Windows XP) or create an IE7 installer (Windows Server 2003), please let me know if HFSLIP 1.7.0 was able to create the Show Desktop link without spelling mistakes or not.

My XP source is Hungarian, and i slipstreamed IE7, and HFSLIP 1.7.2rc2 was able to create the Show Desktop link without spelling mistakes. So its perfect.

Link to comment
Share on other sites
Tomcat76

Tomcat76

Posted
  • Author
Posted

HFSLIP 1.7.1 and newer copy the whole content of SHELL.INF into a new INF file to create the Show Desktop shortcut for Hungarian sources. HFSLIP 1.7.0 and earlier versions took only two lines from SHELL.INF but this appeared to be problematic for languages which have special characters in the "Show Desktop" string. I don't have an Hungarian source at hand to test, so I assumed the Hungarian SHELL.INF also has special characters in the translated "Show Desktop" string and decided Hungarian to be part of the list of languages for which the whole SHELL.INF content should be used.

The point of my comment in the initial post in this thread is to find out if HFSLIP 1.7.0 was able to create the Show Desktop shortcut for Czech, Hungarian and Turkish sources when slipstreaming IE7 with its name correctly spelled. If things were fine with HFSLIP 1.7.0, I want to avoid copying the full content of SHELL.INF into the new INF file for these languages.

Link to comment
Share on other sites
fenyo

fenyo

Posted
Posted

Oh, right.

But i've already overwritten my hfslip with the newest.

If you can give me a link to hfslip 1.7.0 then i will test it to show desktop.

BTW, yes there are special characters in the hungarian version: "Asztal megjelenítése". (just two)

Link to comment
Share on other sites
Tomcat76

Tomcat76

Posted
  • Author
Posted

There's nothing wrong with the Spanish Show Desktop shortcut.

I noticed recently that some special characters (not all) get lost when using FIND.EXE to copy the "ShowDesktop" string from SHELL.INF into another file. If I copy the entire content of SHELL.INF into another file (using TYPE.EXE), these characters don't get lost. Since I don't have a Spanish Windows XP source, I couldn't tell if there were no problems with the Spanish "ShowDesktop" string so I decided to let HFSLIP 1.7.1 copy the entire SHELL.INF content for Spanish sources just to be on the safe side. Thanks to [~Ga$h~], I now know that the Spanish string is fine too.

Example of a problem:

The Polish "Pokaż pulpit.scf" becomes "Pokaz pulpit.scf" (the ż becomes a z). And the Japanese string becomes a series of question marks.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...