[Tomcat76]

What file? Nobody's been talking about the FIX folder here...

[the_guy]

I meant the HF folder. 912945 causes a lot of things to break, all because of the mshtml.dll file. You can install it fine in Windows, but do not integrate it.

the_guy

[Tomcat76]

Oh, but HFSLIP has experience with that.

Try 60314b. If it's what I think it is, that version should work around the problem.

[tain]

I ran 60313a yesterday and just got around to looking for any problems today. An odd problem has popped up that I never noticed before...

These are the files that I have in /WIN/SYSTEM32:

D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\2ksp5.htm
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\ARJ.EXE
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Arj32.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\calc.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Cyclone.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\drempels.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Euphoria.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\EXTRACT.EXE
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\FieldLines.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Flocks.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Flux.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Helios.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\hfnetchk.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\logon.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\matrix-camtech_binaries.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\mplayerc.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\myuninst.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\notepad.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\oeminfo.ini
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\oemlogo.bmp
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\pkunzip.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\pkzip.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\Plasma.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\qchain.exe
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\scrnsave.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\SolarWinds.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\ssstars.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\winhttp.dll
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\wordpad.exe

Almost all of them get copied into c:\winnt\system32...but these ones do NOT get copied over:

D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\logon.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\ssstars.scr
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\winhttp.dll
D:\HFSLIP\HFEXPERT\WIN\SYSTEM32\wordpad.exe

I have some other stuff in /WIN/CURSORS and /WIN/FONTS but they all get copied over fine.

Some of the apps in there, like notepad, may be better off in APPREPLACEMENT but I have them in there because they get removed by HFCLEANUP and I want to put them back. They are the stock files...it is just easier to have them in there while I am addressing HFCLEANUP issues than to keep deleting HFCLEANUP, re-adding the default pack, and re-deleting the files I want to keep. Does that make any sense?

Anyway, I found this interesting and thought you guys might like to see it. Cheers!

This post has been edited by TAiN: 14 March 2006 - 09:58 PM

[troy]

Tomcat76, on Mar 14 2006, 09:00 AM, said:

troy, on Mar 14 2006, 08:39 AM, said:

Testing HFSLIP_60313a

• SVCPACK\HFSLIP.CMD seems to be in good order
  
• On setup, there was a copy problem with HFSLP255.INF - It's not in the I386 folder

Was the latter also the case with 60310 or is that something you don't know given the path problems you were having before? Does it still happen if you only include hotfixes in the HF folder?

Grr... this is going to be a serious PITA.

Apparently, the boot folder needed for a multiboot has it's own TXTSETUP.SIF, which has a reference to HFSLP255.INF. I was using an old boot folder.

For my next test image, I guess I copy over the TXTSETUP.SIF to the boot folder and see how it goes.

There has got to be an easier way to build and maintain a multiboot disk. Maybe I'll try constructing my own boot folder without having to run setup, and see how it goes.

[tommyp]

Tain, It looks like you are building your own OS using HFEXPERT. hehe. I really can't answer your Q, but I think you have to be careful that you don't overwrite an existing file using the hfexpert. What I am thinking is that after the text mode copy, the sub-installation infs are moving files from the temp location to their final spot. My advice would be to use appreplacement if the file already exists in the source. I'll have to update the hfexpert page to identify this issue.

[Camarade_Tux]

Hi,

Quote

Changes in test builds released between the current test release and the current final release:
- removed reference to SP cab file from DOSNET.INF when merging it with driver.cab

Does it have anything to do with the problem I mentionned with nLite ?

[Tomcat76]

TAiN...
The solution depends on what the actual problem is.

1) The four files in question reside in the CD's I386 folder but they are not copied over into SYSTEM32

2) The four files in question do not reside in the CD's I386 folder or the version is wrong/different

I can figure that out myself if you send me your txtsetup.sif file...


@Camarade_Tux
No. When merging driver.cab with the SP cab, the reference to the SP cab was not removed from DOSNET.INF. It may have affected people who install from a floppy but I'm not sure of that. Either way, that's corrected now.

This post has been edited by Tomcat76: 15 March 2006 - 08:05 AM

[Camarade_Tux]

Tomcat76, on Mar 15 2006, 03:05 PM, said:

@Camarade_Tux
No. When merging driver.cab with the SP cab, the reference to the SP cab was not removed from DOSNET.INF. It may have affected people who install from a floppy but I'm not sure of that. Either way, that's corrected now.

Ok. Thanks for the reply.

[dziubek]

little OT:
@Camarade_Tux
What do you use theme in your OS?

dziubek

[Camarade_Tux]

dziubek, on Mar 15 2006, 03:57 PM, said:

little OT:
@Camarade_Tux
What do you use theme in your OS?

dziubek

(Longhorn) inspirat from: http://crystalxp.net...ie/en.cat.3.htm

Also check the Vista one.

And some bricopacks :
http://crystalxp.net/bricopack/en.htm

[tain]

Quote

TAiN...
The solution depends on what the actual problem is.
1) The four files in question reside in the CD's I386 folder but they are not copied over into SYSTEM32
2) The four files in question do not reside in the CD's I386 folder or the version is wrong/different
I can figure that out myself if you send me your txtsetup.sif file...

Scenario two is correct. The only file in the 'problem set' that ever exists natively is wordpad...but it gets removed by HFLCEANUP in my config. The other files are alien to stock windows.

[Tomcat76]

Check the latest release, TAiN. This one allows the HFEXPERT\WIN folder (and its subfolders) to act as some kind of "backdoor" to slip in files that are removed with HFCLEANUP.

Consider this basic rule:
Do not place files in HFEXPERT\WIN that you are removing with HFCLEANUP. If you add them anyway, those files will not be removed.

This makes more sense to me and it makes HFSLIP more flexible. It's easier to add in a few files in HFEXPERT\WIN than it is to edit removal filesets. It can also help with debugging problematic filesets.

This post has been edited by Tomcat76: 15 March 2006 - 01:20 PM

[tommyp]

I don't mean to sound like an a$$hole here, but the name HFEXPERT was coined meaning that you need to know more than the average person about the windows installation process. If you don't know about it, then blindly using it will cause failed installs. This is why the instructional webpage is hidden in FDV's site.

Tomcat, do NOT take the liberty to change the hfcleanup/hfexpert routines. Period.

[Tomcat76]

I don't really know what you mean by "routine", but if you think I switched them around then I have to say I didn't. Everything is still in order.

I always thought that the purpose of HFEXPERT\WIN was to add files, and the purpose of HFCLEANUP to remove files. This apparantly wasn't the case as TAiN found out.
IMHO, I think it's illogical that HFCLEANUP removes stuff you add through HFEXPERT\WIN. It defeats the purpose of HFEXPERT. All I did was fix this "collision"...

I'll undo it if you still want it...

[tommyp]

TC, please undo. The way it worked before is far better. Let's say for instance you run a reducer for some file. The reducer also reduces some extra files too, in addition to installation infs (if there is one). There are too many cross-references and only asking for trouble. The only way around this would be to hardcode all the inter-relations like nlite. It's way too much work to implement and not worth the extra effort. Nlite is easier to use for reducing, and there is lots of support for it already.

Bottom line, it's a catch 22 situation. Delete first and then add -or- add first and then delete. I chose the latter, because of all the installation infs and the interdependancies. For example with Tain's case. He ran the wordpad reducer, meaning he didn't want it. He also had it in the hfexpert. So either he wants it or he doesn't want it. See what I mean? Catch 22.

[Tomcat76]

Isn't the purpose of HFEXPERT\WIN to just add files to the source... no registration, no special stuff done to them?

Please note that I'm not talking about HFEXPERT\CODECS nor HFEXPERT\APPREPLACEMENT. These are "special". No installation INFs are created for files in HFEXPERT\WIN...

Did I get this wrong?

[tommyp]

TC, I understand that it is only the hfexpert\win folder. I guess it's a matter of how the user interprets hfcleanup and hfexpert, and which came first the chicken or the egg.

I suppose you have a point though. However, it *may* break the special functionality of hfcleanup that I frequently use (maybe others too).

Perhaps you should set up a poll and ask the community which they prefer. Ask if they want to add then remove -or- remove then add. Or in other words, which takes priority, hfexpert or hfcleanup. Right now, hfcleanup has precedence. Perhaps I assumed incorrectly when I first coded in hfcleanup and hfexpert (and built reduction files that work with it).

This post has been edited by tommyp: 15 March 2006 - 08:08 PM

[Tomcat76]

I don't intend to break anything. Just let me know of potential issues and I'll see if they can be fixed.

I don't think that the question should be "which comes first". It's more a question of "which is allowed to undo changes of which".

In the previous releases of HFSLIP, HFCLEANUP (additionally) removes files that are added through HFEXPERT\WIN. Maybe I see it wrongly, but to me that totally nullifies the use of HFEXPERT\WIN. Why would one place files in HFEXPERT\WIN if they may be deleted?

I think that the only interaction between them which should/could be allowed is to force-add files that are deleted by one or more reduction filesets. This way, you don't need to edit filesets to try out different things.

The basic purposes are not changed: HFCLEANUP is used to remove stuff and HFEXPERT is used to add stuff.
I'm only changing a con into a pro:
Old con = HFCLEANUP removes files that are added through HFEXPERT
New pro = HFEXPERT\WIN can be used (misused) to override decisions of HFCLEANUP

[Tomcat76]

How's KB912945 doing?


@dziubek
Is everything OK with CDImageGUI?