Tomcat76

It doesn't really work too well. A registry key is checked to determine the OS language and it exists on the two computers I tested the script on, but it doesn't exist in a VM. The script then defaults to the English XML file.

The service pack is slipstreamed into the source in the SOURCE folder directly so you can keep using it. Next time, HFSLIP won't slipstream the service pack again. What are these files doing in your HFCABS folder? directx_dec2006_redist.exe WindowsXP-Windows2000-Script56-KB917344-x86-sve.exe

Are you trying to push DOS to the limits? Check the latest test release...

To replace an existing file permanently, overwrite the original file yourself in the SOURCE folder. To replace a compressed file that would exist in SOURCESS\I386 near the end of an HFSLIP run, place the new compressed file in the FIX folder. To replace an uncompressed file that would exist in SOURCESS\I386 near the end of an HFSLIP run, place the new uncompressed file in the FIX folder. There is also HFEXPERT\APPREPLACEMENT. The new files should always be uncompressed. ModifyPE is run on files in APPREPLACEMENT before they are slipstreamed.

This happens to me too when I switch browser or use the same browser in different Windows accounts. I suppose the board stores a different cookie in the various browser caches, so decides you are a different user if the cookie differs from the one that was last recorded on the server. Might be a security feature.But this has already been the case before the forum upgrade.

Do you still get that error message when using the latest test release?

It's from an addon. XPSP2 has 103 predefined in its TXTSETUP.SIF so I presume the addon maker didn't bother to specify the destination dir. Win2K's TXTSETUP.SIF doesn't have the 103 destination folder specified. You can add this line into the [WinntDirectories] section at the bottom but I suggest you just don't include the addon. 103 = system32\1033

Very easy... Thanks...

That's OK... Other issue... I can't seem to be able to reply to a PM. Any ideas? Opera 9.02...

I'd like to test this too. The description in the KB article doesn't reflect the thumbnail problem I experienced but you never know.

I can't add support for any installer type out there. Is it used a lot?

@pouraduff I'm 99% sure the error you're seeing is due to the existence of a *.EXT file in your HFCLEANUP folder that isn't intended for Windows XP.

Just go HERE and choose Posting Settings > Type of text editor to use when posting ... Rich Text Editor requires either IE6+, Mozilla / Firefox or Opera 9+ > and choose standard editor As I said, it's already on "standard editor." And there's also a toggle in the top right corner of the Post reply box (a button with a reload icon).

BTW... That file isn't copied by Windows setup since it's not in your TXTSETUP.SIF. It must be something that's added on top (a hotfix not intended for XPSP2 or an addon).

I can't reproduce this and I have no idea what HFSLIP could've done wrong to cause this. So I can't really help. My guess is that something went wrong during the service pack slipstreaming but you already said that you lost the original so you're kind of stuck there. The only thing I can suggest (but without guarantee that it will solve your problem) is this: 1) Download the network install of SP2 into the HF folder 2) If these files exist, move them out of the SOURCE\I386 folder: SP1.CAB, SP1.CAT, SP2.CAB and SP2.CAT 3) Run HFSLIP, then verify that you have SP2.CAB and SP2.CAT in SOURCE\I386

The standard editor is enabled by default for me. Maybe I set it like that the moment I signed up... Don't remember. The rich text editor is junk, though. When clicking a smiley, it gets inserted but you can't type anything AFTER it. So I'd first have to compose my entire post and then add smileys....

It's harmless. That (and the line above) is a remnant of the first code I used to embed the new timezone updates. Thanks anyway for reporting this; I'll have it removed.

HFSLIP doesn't slipstream IE7 anymore. Please use the latest version which has it installed at first GUI logon (info). You can't uninstall something that was slipstreamed.

What do you mean by "it"? IE7 installation or other installations?HFSLIP doesn't slipstream IE7 but has it installed at first GUI logon (by default), meaning that any RunOnce and RunOnceEx lines initiated from Windows setup should still work as they are executed before IE7 is installed. But if you entered IE7SVCPACK=1 in HFANSWER.INI then IE7 is installed before the final reboot of Windows setup which might give you a broken RunOnce(Ex). This never happened to me, but it apparantly does happen to other people. If this is the case, I'll see what I can do about it.

COPY HFEXPERT\AUTOIT\%AUTOEXE% SOURCESS\I386 copies the executable into I386. Are you saying now that there's more executables? Don't know if it's of any use, but I was also thinking of expanding the feature a little by allowing more than one subfolder starting with "AUTOIT" (eg, AUTOIT2, AUTOIT3, AUTOIT4, etc) in case people need to use scripts that haven't been updated yet. This is trivial but I need to know if it can be considered useful or not.

Confirmed for Opera. It looks like Opera is not being fed that part at all. Just look at the source code. Why is Opera being sent stripped down code? I was wrong. The graph shows as intended after clicking "Show results." I saw it in IE and Mozilla because I wasn't logged in with those browsers.

Guests cant download attachment or see it. I see. Then I'll just make a locked dummy post with an attached image and hotlink to that image instead. Thanks.

When not logged in, embedded attachments don't show properly unless hotlinked from another post. I uploaded a round graphic with an arrow in it as an attachment in the main post of this thread and it's showing within the post if you're logged in. However, it shows up as a square with a Quicktime logo in it when not logged in and the text winval.png ( 558bytes ) is shown beside it. Strangely, it does show properly when not logged in in the main post of this thread. The difference here is that I'm hotlinking to the graphic that I uploaded in the other post. Tested with Opera 9.02, Gran Paradiso 3.0 and IE6 SP1.

It's there in the HTML page but I was hiding it through the CSS file for one reason or another. Should be fixed now. Thanks for reporting