[Inki]

I attempted to slipstream KB817855 into Windows 2000 by placing:
Windowsmedia9-kb817885-x86-enu.exe in the HF-folder

While running HFSLIP 1.4.1, KB817855 flashed up it's own notification complaining about bad switches.

Can you tell me:
1. Is this hotfix supported and does it make sense to try to slipstream it in the first place?
2. Is there some obvious thing that I have missed here?

Sorry, if my question is trivial, but I am just learning what HFSLIP can do, and I have not found an answer to this elsewhere.

(P.S. Note the different numbers for the KB article and the hotfix file, look like a MS typo in one or the other)

This post has been edited by Inki: 13 March 2007 - 06:56 AM

[Tomcat76]

Are you sure about that number? The KB article gives this description:

"When you upgrade to Outlook 2003 from an earlier version of Microsoft Outlook, your international options settings are not retained."

And there is no downloadable file to fix this. They just provide some manual steps that they call a "workaround".

Nothing about WMP9...

[Inki]

Yes, it seems that there is indeed a numbers mixup.

For some reason:
- the number on the Hotfix file is 817885 as given in the first posting.
- the number on the KB article is in fact 817855.

Silly of me not to notice this straight away. (I edited the correct KB number also into the first post.)

This post has been edited by Inki: 13 March 2007 - 12:49 PM

[Tomcat76]

OK. The problem with that hotfix is that it's a Type 2 hotfix but HFSLIP thinks it's a Type 1 hotfix. If you rename the file so that the word "windows" is no longer in it, it will be treated as a Type 2 hotfix.

However, this will only take care of slipstreaming wmpns.dll and wmpns.jar. I see that the installation INF file contains a post-install command which may need to be executed. If that's the case, I'll have to hard-code support for this update.

But rename the update and try it like that.

[Inki]

OK. Thank you very much your answer and advice. I had actually thought that it might be a question of naming-based type recognition, but I was uncertain of the actual criteria.

As I don't really use Netscape, which this hotfix supports, nor am I a Windows expert, I will probably not be able to comment on the proper functioning of the update and the post-installation commands.

Still, maybe some knowledgeable Netscape user out there may have a practical interest in this case....

(Funny by the way, but I can not help wondering if there is a link between the typo in numbering and the fact that the hotfix supports Netscape, but maybe that is being too cynical)

[Inki]

Well, having renamed the hotfix file
- from: Windowsmedia9-kb817885-x86-enu.exe
- to: Wmedia9-kb817885-x86-enu.exe
HFSLIP now slipstreams the updated files nicely into the installation source.

Because the basic setup package for Windows Media Player 9 (MPSetup.exe) includes older versions of the updated files, I may boldly/naïvely assume that any post-install requirements that they may have are likely taken care of by including the installation of MP9 later in the installation sequence.

Therefore, my best guess is that the only real problem with this hotfix is its problematic naming, both in terms of deviating from the assumed type convention and its KB article number (making it more difficult to find).

[Tomcat76]

I wouldn't really call it a deviation of the naming convention. This hotfix was released before the current naming standard went into effect.

I doubt this hotfix is really needed nowadays. As far as I know, it's only compatible with the Netscape 4 API which is no longer used by Mozilla. Opera kept using it for a while but they recently changed that.

[Inki]

OK.

Thank you very much for your additional comments. I greatly appreciate the fact that you have found the the time to look into this, which must really be on the sidelines of your project.