[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Let's have a look at Microsoft on QuickTime bug, will you?
>
>
> Roberto Di Cosmo wrote:
>
> I am starting to get pretty annoyed with the claims Microsoft is
> making that whenever something does not work, it's somebody else's
> fault:
>
> * the ridiculous general reboot in the Wall Street demo of an NT
> network running a simulated number of transactions equal or greater than the VISA one?
> -> it's a third party driver poorly written
>
> * smart ship dead in the water?
> -> it's an application (ok, now explain me how an user-level application is supposed, *alone*
> to shut down an entire LAN. I do not pretend it's impossible, but it is damn hard to imagine
> such a thing in a unix network, unless the OS is at fault.)
>
> * RealNetworks is overridden by MediaPlayer?
> -> people at realnetworks is stupid and did not write proper installation code
>
> * QuickTime disabled?
> -> Apple engineers are stupid and did not write proper installation code
>
> Now, enough, is enough.
>
> Anybody willing to lend a hand to investigate what is really going on here? Technically, I mean.
>
Although I'd rather have my eye teeth pulled, let's have a go at it.
> Let's take the official statement made by Microsoft in
> http://msdn.microsoft.com/developer/news/quicktime.htm
> that I reproduce down here. My comments are preceded by a +
>
> ====MS document starts============================================================================
>
> Response to Allegations About Apple's QuickTime Plug-In for Internet Explorer
>
> In the Microsoft antitrust trial, Dr. Avadis Tevanian, Jr., senior vice president of software
> engineering for Apple Computer, testified that Microsoft "took several steps to sabotage" Apple's
> QuickTime multimedia player plug-in for Internet Explorer.
>
> This is a false statement, and it has been disproved in tests by Sax Software Corp. and by
> software testing and development lab Mindcraft Inc.
>
> Microsoft has written a patch that corrects Apple's errors. Mindcraft and Sax Software have also
> written patches and described the problem. STLabs, a software testing lab, has verified
> Microsoft's
> tests and patch.
>
> Mindcraft examined several cases where QuickTime multimedia plug-ins did not run as expected in
> Internet Explorer 4.0. The company discovered three root causes for the problems, including errors
>
> in Apple's code:
>
> 1. Version 2.0.1 of Apple's QuickTime Plug-In fails to provide the resources, outlined in
> Netscape's instructions, that tell Internet Explorer that it can handle files with "aifc," "qt,"
> or
> "vfw" filename extensions.
>
I checked this out and indeed Netscape has a web page that tells you how to do this. Microsoft MAY
have a point here. HOWEVER, it seems to me IIRC that on a Netscape-only Windows system QT works just
fine.Also, was this web page available at the time this version of QuickTime was made available?
Where is the Microsoft documentation that says, unless you do A,B and C, any subsequent installation
of Internet Explorer will blow your program away?
>
>
> +
> + Ok, this is recognized in Mindcraft's report, but, in view of the following 2 points,
> + appears to be rather marginal
> +
> 2. Internet Explorer automatically gives precedence to ActiveX controls (such as ActiveMovie and
> WindowsMedia player) over plug-ins (such as the QuickTime Plug-In). This can be overridden by use
> of the EnablePlugIn registry key, but Apple did not use this override key.
> +
> + So *the default* is =>screw the plugins<= i.e. 3rd party software (as MS software is not
> provided
> + as a PlugIn, but as an ActiveX control).
> + Is there any Windows guru out there who can tell us if this EnablePlugIn registry key
> + is well documented and the documentation readily available to generic 3rd parties?
>
I checked on the Search Engine at www.microsoft.com/support. This is their central documentation
point on the web and is probably the preferred way to get information on bugs, etc. Especially as
MSDN, which used to come on a single CD and contain everything a Windows Programmer needed to know
(except for the undocumented calls, of course) is now probably close to 100 CDs. Good luck if you
want to find
anything there. The Web is really the only alternative - too bad the search engine is down half the
time.However, today, it was working. I looked for "EnablePlugIn" gets 0 hits there. Even if I would
have found hits, this wouldn't be very helpful - someone out to solve the problem would have to know
the name of the registry key he was supposed to use. I also spent about half an hour searching in
other ways for information on how to do this and was unsuccessful, using all sorts of keyword
searches, natural language searches, et. al. I'm sure there was no documentation there until this
surfaced in court.
So no, I wouldn't exactly say this was "well-documented".
> +
> + Am I right in assuming here that *reinstalling/upgrading* IE would reset to the default
> behavior?
>
I think so. But I don't really know. About the time you had to know IE to know Windows was about
the time I stopped listening to Microsoft.
>
> <snip>
>
> ====MS document
> ends===============================================================================
>
> Also, I had a look at the MS c++ code, and it does a whole wealth of things:
>
> 1) deletes the activemovie reassing dialog
> (ok, I saw that annoying thing, nice to know how to kill it :-))
>
> void DeleteActiveMovieDialog()
> {
> //
> // The ActiveMovie file type reownership dialog occurs on startup. This requires a
> // link in the Start Menu's StartUp group. In order to disable the reownership dialog
> // on startup, we simply delete this link.
> //
>
> //
> // To do this, we first need the path to the Start Menu folder "StartUp".
> //
>
> 2) manipulates *a lot* of registry keys: it seems to me that this really is the key point...
> the fact that QT fails to declare some MIME types *only* is relevant in the few cases
> where the QT plugin would get a chance to be executed. The code here does a lot of
> key-wizardry essentially to insure the plugin gets called instead of the ActiveX thingies
> Here is an example:
>
> sprintf( szKeyBuffer,
> "Software\\Microsoft\\Internet Explorer\\EmbedExtnToClsidMappings\\%s",
> FileTypes[iPos].pszFileType );
>
> //
> // Deleting this key ensures that IE will not load an ActiveX Control based upon
> file extension.
> //
> RegDeleteKey( HKEY_LOCAL_MACHINE, szKeyBuffer );
>
> 3) does some other wizardry which I *really* wonder is it's properly documented somewhere
>
> //
> // Typically, changing the ProgID for .wav results in a loss of system functionality.
> // However, we avoided that above by copying the SoundRec subkeys to the QuickTime.Wav key.
> // We should therefore turn off the OS's protection key for the .wav ProgID. If this key
> // is not deleted, the OS will reset the .wav ProgID upon a later reboot.
> //
>
>
>
Consider for a moment what "proper documentation" might mean:
"If you want to make sure that your program is executed instead of the one we recommend, here's what
you must do:
..
..
."
While I'd like to think that some software houses would release documentation such as this, I've given
up expecting this from Microsoft. Their whole monopoly mindset cannot begin to comprehend that anyone
would want to do that, and to the extent they recognize the possibility, they consider any such person
an enemy not deserving of help. Microsoft cannot accept that there are good software developers who
don't work for them.
The simple truth is that Microsoft doesn't document ANYTHING sufficiently anymore. The fact remains
that these outside companies have to take Microsoft to Federal court in order to get Tech Support. I
doubt that one in ten Microsoft Tech Support reps could have solved these problems had they been asked
about them.