What is the difference between Security Update for Windows XP (KB904706) and Security Update for DirectX 9 for Windows XP (KB904706), and which one really applies?

The first one is for SP2 and SP1 if you didn't install DX9. The second one is for SP1 if you did install DX9.

the_guy

All right, thanks.

@Tomcat, another quick note: In the preface on your basic howto page, privileges is spelled with an extra 'd'.

Uh? Your browser's cache must be way behind, then. It was last updated on the 18th and "priviledges" is written "priviledges" in both the Preface and in Step 8.

Sorry, my fault - shouldn't have said "new", just meant "newer" (than the original that came with SP2). Yes, I was really referring to the one year old KB898461.
Regards,

Tomalak

I guess I should have made my point a little clearer . I was trying to say that 'privileges' should not be spelled with a 'd'.



Oh, did anyone notice that for some reason you don't need to be logged in anymore to view this forum?

OK. Updated. Keep the corrections coming, but please don't do it in this thread. I'll start a new one.

OK. "HFEXPERT\PROGFILES" is ready for consumption, hehe. Let the reports roll in...

The program files will cause countless errors from users. I would strongly recommend to delete this section of code and not rebloat hfslip.

EDIT - TC informed me that he thoroughly tested this feature. Nevermind.

We're slowly heading for a new release. I don't intend to add any more to it in this round, so... let us know if something broke. Comments on the new HFEXPERT\PROGRAMFILES feature would be nice too...

I'll test these test release asap, I was busy.

I had to use hfslip this morning to make an XP SP2 CD. My first iso was bad because I used a CD with SP2 sent by Microsoft and the name of the pack was "XPSP2.EXE".
I then renamed it but I think it would be better if HFSlip recognized this too.

Thanks.

I'm going to agree.

Maybe modify the code for XPSP2 to

just an idea. It might be sending it to the wrong part though.

the_guy

The XPSP2 installer can be named xpsp2*.exe from now on if MS ships it like that. The old *835935* from the MS Download Center still works, of course.

Woooooow ....... alot of changes and new features. So, i´ll have to spend some time in the next future to see and to learn.
One Question i have before i start. Theres the need for me to copy one file during syssetup or during first logon in to %windir%. Please, how is the best way to do that??? Could hfslip help???
Thx for your answer.

wela - please refer to the HFEXPERT page for fine details. Short answer, create a folder structure alongside your hfslip cmd file: HFEXPERT\WIN. Place your file in that folder.

@tommyp. THX for the short answer. It helped.

Made a first test install with german Xpsp2 and the new feature Progfiles.
Works great.
Very good work guys!!!

Made a final install with new features. My son is happy, WU is happy, i am happy.

test release has been kinda quiet recently ... ... looks like all's fine

When you the least expect it...


I'm waiting for TommyP's results. Then we can release a new one.

What was wrong with fetching the boot image?

I forgot to report back. I had no issues with that last file you sent me. Sorry dudes.

It didn't work for me -- neither in HFSLIP, nor in another program I'm currently working on. I actually never noticed this because I don't use HFSLIP to make an ISO. When I noticed the problem in that other program, I tested it in HFSLIP and it didn't work there either.

I see. I wonder why no one reported that problem. Maybe not many people actually use the feature?

Or they did it once a couple of months ago. There's no need to create it again if you already have it.

ey ... kinda got lost there ... i'll second what Super-Magician didn't notice this all along ... i always create an ISO via HFSLIP to test it with other ISO created by another app ... maybe because i don't touch anymore my HFTOOLS folder which has it there (actually there's a .bin & .img there ... probably because i used to have mkisofs & cdimage both in the folder) ...

ah ... just the same ... i was right ... a new final!

No wonder you never noticed... You already have a boot.bin file.
Move boot.bin out of the HFTOOLS folder and then use an older version of HFSLIP. It won't make a new boot.bin.

hi TC!
i actually exprimented on boot.bin & boot.img over the weekend ... with these files (and/or) in HFTOOLS folder ... no ISO was created ... no wonder the cmd file finished faster ... but when i took those 2 out with bbie & mkisofs still in HFTOOLS & leaving the original source CD in the drive, boot.bin was recreated & ISO was created as well ...

as for the presence of the boot.bin there, i have never removed since i 1st used HFSLIP ... i got curious because of the posts i read prior to taking my days-off from work

oh btw, this was using 60803 ... i'll ask related questions in the appropriate thread: ISO creation fails with 60803

*silent bump*

Suggestion for 917008: Remove the MUI files and just treat the rest like a normal hotfix. Is this possible, or not?

the_guy

I like that better.

Done.

Probably agree too.

edit : I knew I had something stupid to do :

^^

... again

I copied a working i386\ASMS over the buggy one and tried again.
... would have been better if I did not forget to recreate the iso/


edit: went ok, checking HFs.
edit2: I probably woke up too early... I forgot to add Hfs. I should probably go back to bed. :/



And VirtualConsole for Avedesk is working. However, it can be CPU hungry, especially with makecab.

Everything seems to be OK on XP SP1a.


I'll try to find what the problem with ASMS compression is.


Thanks a lot.

@Camarade...

What I find strange is that Windows complains about an error in a manifest file, but it names a catalog file instead. Are you sure that isn't a typo?

That folder contains:
gdiplus.cat
gdiplus.dll
gdiplus.man

The manifest file is gdiplus.man.


When reducing the source, does nLite also delete files from ASMS?

It has already happened.

nLite's help says ASMS recompression may cause bugs.
I don't know if it is hfslip's fault or not. I'll make some new tests soon. I only learnt makecab outputs a different file, depending on where the source file is stored!

This bug is also really funny : it complains about one file. You replace this file with a working one. Then it complains about another file. You replace that one with a working one too and it complains about a third file (the 3 files are in 10\....). And once you have replaced all files in the folder, it complains about "ASMS" folder itself.

I'll see if T-39/DetachedPrograms+Filemon is of any help.

edit: now installing a non-nlited iso.

Ok. In fact, this is a problem with hfslip (and I think I already had it last month, CPU is stable and this happened on more than 5 isos)
-> Filemon.

hi Camarade Tux! try not to recompress ASMS ...

I second that! I wouldn't do too much experimentation with HFSLIP + nLite if I were you .

I tried without nlite and I still got the error and I think hfslip cabs the files itself.

I'm slowly debugging that. Extracting files one by one. Hopefully, I don't have to go through the whole textmode part of setup.



edit : I had to extract the content of 4 folder to get this back.
Now, I wonder what the error is. I suspect it has something to do with compression method.

PS: T-39 is later on and filemon is now running : 260.000th entry in the log has been reached. :woot:
Err.... 300.000 entry I mean. No, 310.0000...

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT !

I finally got it, ... thanks to Tomcat.
The worst thing is he gave me the solution immediately : *.MAN files have to remain uncompressed. That's all.

No, I have to check if hflsip cabs this file on its own. :?

I can confirm the error is in hfslip.
Or at least in a hotfix : my man files are CABbed.

KB917008 for Win2K is not OK. I'll revert to HFSLIP_60808a once I get my computer running again (spilled coke on the keyboard... again!). I'll then try to figure out how to have it slipstreamed properly.

@Camarade: I'll check it out.

@Camarade: Try 60809a...

Workign, but why not compress everything except .man files ?

Have a look at this page for ready-to-use implementation (thanks hp38quser).

Correction for your link

this page

Correction for the code given

CODE

FOR /F "DELIMS=" %%I IN (
  'DIR/B/A-D %LOCATION%^|FINDSTR/EVIL ".CAB .CMD .INI .MAN _"') DO (
  MAKECAB /D CompressionMemory=…etc.

Thanks for your corrections.

I wonder how I ended up with "http://page" in my link. :?


And you're incredibly fluent with BATCH, much more than I will ever be.
And why "/EVIL" ? Is it just something like foobar ?

E = end of line
V = exclude
I = case insensitive
L = literal search

L is probably used so you can do without a backslash in front of the dots in these search strings.

I was thinking of having HFSLIP compress new ASMS files anyway but just exclude *.man files. But I don't know how nLite copes with a source of which some ASMS files are already cabbed and some not so I thought it safer to just leave all files uncompressed.

On second thought, I think it isn't such a good idea to compress the new files (except .man). Either you compress both old and new ASMS binaries, or neither. There's no point in just compressing the new ones as people who'd care would prefer to do them all so they'll use a different program for it anyway.

just wanted to say:

latest test release works fine, everything is beeing slipstreamed perfectly!

In nlite, there's an option for that and the corresponding tooltip says it may create bugs. I thought it was an old comment and asked if it could be changed. Nuhi told me some OSes would still bug if one of the file was compressed.
Better safe than sorry, in the end, it is probably better not to cab everything.


And now, I can say this test releases is working perfectly.
Thanks again.