|
|
|
| Authored by: Anonymous on Sunday, August 12 2012 @ 11:03 AM EDT |
<p>From: Gary Hein<br/>
Date: Sat, May 30, 1998 3:34 PM<br/>
Subject: Fwd: NDS for NT / LDS Church</p>
<p>Don’t know if you guys have seen this document
yet, but it’s just another example of lies propagated
by MS. There are some very disturbing remarks, including:
</p>
<p>Although it is possible to establish bi-directional
trust, the trust connection can not be used for
administering remote, unmigrated domains. This means that
centralizing management with NDS for NT requires a wholesale
conversion of the entire enterprise</p>
<p>GH: False</p>
<p>Note that NT servers would need to run IPX/SPX to support
NDS for NT as well as TCP/IP to access other network
reqources and to comply with current standards.</p>
<p>GH: False - NDS for NT works over IP - no need to add
IPX. This is a scare tactic.</p>
<p>Service Pack updates are questionable at best. MCS has
not yet released Service Pack 4.0, however we suspect it
will replace the existing samsvr.dll. To protect against NT
Service Packs replacing samsrv.dll, NDS for NT checks at
shutdown time and replaces samsrv.dll with the Novell
version. MCS believes potential for failure is very high, as
soon as any dll starts depending on new exports from
samsrv.dll. Replacing this one critical dll could case the
system to fail to boot and recovery could be very difficult.
</p>
<p>GH: Perhaps advance knowledge of SP4?</p>
<p>Microsoft has repeatedly stated that it will support
their NT customers and NT’s basic functionality, but
in areas that NDS touches, namely security and
authentication, Microsoft will refer customers to Novell.
<br/>
This has the potential of creating some confusion in the
resolution of issues revolving around security and
authentication.</p>
<p>GH: Scare tactic</p>
<p>Also, comments from PeopleSoft should be solicited to see
if PeopleSoft and Tuxedo are supported in environments where
NDS for NT is in use as well as the IntranetWare client.</p>
<p>GH: Is it possible that MS is telling NT developer that
they should not support their products with NDS for NT?</p>
<p>Windows NT has a feature where anonymous logon users can
list domain user names and enumerate share names. Customers
who wanted enhanced security requested the ability to
optionally restrict this functionality. Windows NT 4.0
Service Pack 3 and a hotfix for Windows NT 3.51 provide a
mechanism for administrators to restric the ability for
anonymous logon users from obtaining system information.
<br/>
These anonymous connections are also known as NULL session
connections. During the installation of Novell’s NDS
for NT, the samsrv.dll is replaced. Novell NDS for NT
currently does not include support for restricting anonymous
connections. MCS see this deficiency as a security weakness.
</p>
<p>GH: This is the Red Button attack, which MS
‘claims’ is fixed with SP3, but really
isn’t. Again, this is completely incorrect - using NDS
for NT will not impact the security flaw mentioned in this
document.</p>
<p>Anyhow - I don’t know if this is of any use to you
but I thought I’d forward it over anyway.</p>
<p>Thanks,</p>
<p>Gary</p>
<hr/>
<p>From: Loren Bishop <BishopLK@chq.byu.edu>
<br/>
To: HUB-OREM1.SLC(BRICHAN)<br/>
Date: Wed, May 27, 1998 7:52 AM<br/>
Subject: Fwd: NDS for NT</p>
<p>Here is the document from Microsoft Consulting Services.
We need a similar document from Novell. Please keep this
confidential. I don’t know that Microsoft would
appreciate me sharing it with you.</p>
<hr/>
<p>From: Eugene Morgan <emorgan@microsoft.com>
<br/>
To: "Kenji Suzuki (E-mail)"
<ksuzuki@chq.byu.edu>, "‘b...<br/>
Date: Thu, May 21, 1998 4:43 PM<br/>
Subject: NDS for NT</p>
<p>Attach is the final version of the document that
addresses NDS for NT. If you have any questions please call
me.</p>
<p><<NDSForNTConcerns.wpd>></p>
<p>Eugene Morgen<br/>
Microsoft Consulting Services<br/>
Rocky Mountain District<br/>
(801) 540-4907</p>
<hr/>
<p>The Church of Jesus Christ of Latter-day Saints</p>
<h1>NDS for NT:</h1>
<h2>Microsoft’s Consulting Services Concerns</h2>
<p>Prepared By:<br/>
Eugene Morgan<br/>
Microsoft Consulting Services<br/>
May 1998<br/>
Document Version 1.2</p>
<p><strong>Table of Contents</strong></p>
<p>1.1 Introduction<br/>
1<br/>
1.2 Minimizing the Number of Directory Services<br/>
2<br/>
1.3 Global Administration Through One Administrative
Console<br/>
2<br/>
1.4 Concerns With NDS for NT<br/>
2<br/>
1.4.1 Administration<br/>
2<br/>
1.4.2 Disaster Recover<br/>
3<br/>
1.4.3 Scalability<br/>
4<br/>
1.4.4 Upgrade and Update Capability<br/>
5<br/>
1.4.5 Speed<br/>
5<br/>
1.4.6 Reliability<br/>
6<br/>
1.4.7 Security<br/>
6<br/>
1.5 Conclusion<br/>
6</p>
<h1>NDS for NT - Microsoft Consulting Services Concerns</h1>
<p><strong>1.1 Introduction</strong></p>
<p>As the Church contemplates the deployment of NDS for NT
there are some things to consider. There has been some
questions about NDS for NT directed to Microsoft Consulting
Services regarding NDS for NT from Novell. This document
will hopefully articulate our concerns with regard to this
product.</p>
<p>First consider the problem we are trying to solve,
mainly, "the administration of user accounts within the
Utility." As the Intranet has begun to be an important
resource it has become necessary to use NT Domains in order
to control access to this and other NT resources.
Additionally, WinFrame administration has also been an
issue. Simply stated, managing NT domains effectively is
becoming more and more a necessity within the Church. This
necessity has come about because of the recognized value of
NT to address important business functions within the
Church. It’s interesting to consider that NT’s
success has also brought about the need to possibly alter NT
in a manner that Microsoft feels would be contrary to
NT’s design.</p>
<p>From an MCS perspective there are two ways to ease
management concerns: minimize the number of directory
services the Utility supports or find a tool that will allow
the administration of multiple directory services from one
console. Let’s examine the pros and cons of both
approaches.</p>
<p><strong>1.2 Minimizing the Number of Directory
Services</strong></p>
<p>The major advantage of minimizing the number of directory
services the Utility supports is that administration can be
accomplished for from one point, but can it really? Can the
Church standardize on one directory service? The answer is,
not really. The use of the many operating systems within the
Church Utility, MVS, VMS, OS/2, NDS, and NT make it a
formidable task to do so.</p>
<p>The other problem with this approach is that the current
user account management process does not support this
approach. Currently, the NetWare team handles account
administration of NDS; the VMS and MVS team handles account
administration of their respective environments, and the
Security Administration Team handles NT account
administration.</p>
<p>The security team would like to take ownership of user
account administration and currently does some account
administration on practically all platforms. However, they
are currently not in a position to offer the 7x24 hour
support that is necessary to support the Church’s
operational environment.</p>
<p>It should also be pointed out that the Help Desk also
does some account administration on practically all
platforms, but under break/fix conditions. Also, their
administrative privileges are severely restricted to the
basic rights necessary to provide basic account
administration as dictated by the limitations of the
respective operating system.</p>
<p><strong>1.3 Global Administration Through One
Administrative Console</strong></p>
<p>The next approach would be to utilize tools and
technologoes that allow for the administration of all
directory services through the use of one console or a
minimum number of consoles. This can be accomplished to some
degree by adopting an enterprise management approach.
Adopting this approach would require both changes in the
process model for account administration and a deployment of
enterprise management solution rather than point solutions
that are currently in place or are being deployed.</p>
<p><strong>1.4 Concerns With NDS for NT</strong></p>
<p>Microsoft has published a number of documents on NDS for
NT, unfortunately most are internal and not available to the
public. In addition, there has been a considerable amount of
discussion on the various e-mail aliases within Microsoft.
The following represents a distillation of the various
documents and discussions and enumerated what MCS feels are
areas of concern.</p>
<p>1.4.1 Administration</p>
<p>Multiple tools for administration due to missing
functionality. Novell’s NWAdmin does not give access
to the full set of Windows NT security capabilities; in
particular, there is no way to manage trust links with
external (unmigrated) domains, and no way to manage local
policies. The administrator uses NWAdmin for most tasks, but
must use User Manager and Server manager for trust and local
policy management.</p>
<p>Although it is possible to establish bi-directional
trust, the trust connection can not be used for
administering remote, unmigrated domains. This means that
centralizing management with NDS for NT requires a wholesale
conversion of the entire enterprise.</p>
<p>Password synchronization: Since NDS for NT must support
all Windows NT clients, not just Windows NT clients with the
IntranetWare client installed, Novell must maintain two
passwords for every user: a Windows NT password and an NDS
password. From Novell’s own announcement documents it
is clear that this is a compromise solution that is far from
transparent to the user. It important to point out that it
is possible for the passwords to get out of sync. This could
cause additional problems for uses as well as the Help Desk
and other operational teams supporting the Utility.</p>
<p>ACL (Access Control List) confusion: In the case of a
single NDS user being granted access to multiple domains,
the same user, "BobSmith" would appear in the
context of each "trusted domain" selected. A
Windows NT ACL could have entries for Domain1BobSmith,
Domain2BobSmith, and Domain3BobSmith. All three are in
fact the same user, but with different SIDs (NT Security
ID’s).</p>
<p>Also, in NDS for NT it is possible to create case-
sensitive account names, for example "bsmith" and
"BSmith". Because NT is not case sensitive for
user names only one of the accounts would be accessible even
though both would exist within NDS for NT. This could be a
security issue and would also be confusing to administrators
and others managing user accounts and of course customers.
</p>
<p>Multiple group paradigms: Windows NT Groups are not NDS
groups. To make a group visible in Windows NT the
administrator must create an IWSam group as a child of a
domain object. Only users can be added to IWSam groups.</p>
<p>No immediately obvious scripting support: ADSI supports
NDS, but ADSI does not expose the SID, password residue, and
other items required to migrate a Windows NT domain to NDS.
This means the migration process is via the user interface,
and the current user interface makes this quite laborious.
</p>
<p>1.4.2 Disaster Recover</p>
<p>MCS is concerned with the effects NDS for NT has on
recoverability in the case of a system failure. Because NDS
for NT moves all of the directory information from the
registry to the NetWare Directory, if the NT Primary Domain
Controller fails, the following steps would be necessary to
recover.</P>
<blockquote>
Do a reverse migrate to all the BDCs in the Domain.<br/>
Promote one of the BDCs to a PDC.<br/>
Reinstall and restore the original PDC as a BDC and restore
files and applications.<br/>
Promote the restored BDC back to a PDC.<br/>
Reinstall NDS for NT on the PDC and each BDC in the domain.
</blockquote>
<p>This process seems rather involved and would cause a
severe interruption of services and applications hosted on
NT. It’s important to point out that some of these
applications are mission critical, PeopleSoft for example.
Furthermore, if any NT backup domain controllers are located
remotely to facilitate faster WAN login and lower WAN
traffic, as in the case of England and Australia, this
becomes an even more complex process. (Note: Novell has said
that they will have a fix for this at some point.)</p>
<p>MCS offers the following disaster recovery advice; prior
to implementing NDS for NT thoroughly test the above
scenario and update the disaster recovery plan on how to
recover in the advent of a failure.</p>
<p>1.4.3 Scalability</p>
<p>MCS has not heard of any large implementations of NDS for
NT. Considering what it takes to architect a large NDS
implementation, MCS questions what effects NDS for NT will
have on the existing NDS infrastructure. MCS would suggest
interviewing early adopters of NDS for NT prior to
implementing NDS for NT. Furthermore, it would be important
to understand the impact of NDS on NT would have on the
existing NDS servers and supporting network infrastructure.
Note that NT servers would need to run IPX/SPX to support
NDS for NT as well as TCP/IP to access other network
resources and to comply with current standards.</p>
<p>NDS has partitioning requirements to keep from
overloading its database as well as replication limitations.
The NDS data is threaded through several files, remarkably
similar to the file structure used by Microsoft directory
service prior to moving NT’s directory to utilize the
JET database engine in 1991. Our concern is that the
duplication of objects in the NDS directory will impact
performance significantly for all NDS authenticated users.
</p>
<p>It’s also our understanding that in NDS for NT
there is a limited one to one relationship between an NDS
container and a Domain. Therefore if an enterprise has users
spread across multiple NDS containers it may be necessary to
implement separate NT domains that are related to the
respective NDS containers.</p>
<p>With NDS for NT, NT domains become NDS groups. It is
MCS’s understanding, based on Novell recommendation
that NDS groups should not have more than 2000 members. This
does raise the question about the scalability of NDS for NT.
Will this group limitation be an issue for the Church?</p>
<p>Given that NDS for NT converts NT domains to NT groups,
it is recommended that interdependence between these NDS
groups be tested in order to ascertain that the necessary
relationships between these NDS created groups.</p>
<p>As the Church begins to develop large applications, the
Church my find it reasonable or necessary to deploy NT on
Alpha systems in a effort to scale an application to meet
demand. There is no support for NDS for NT on Alpha NT
servers. Novell has indicated this is, "a hard
problem" and has offered no guarantees and little hope
that it will be addressed in the future</p>
<p>1.4.4 Upgrade and Update Capability</p>
<p>Service Pack updates are questionable at best. MCS has
not yet released Service Pack 4.0, however we suspect it
will replace the existing samsvr dll. To protect against NT
Service Packs replacing samsrv dll, NDS for NT checks at
shutdown time and replaces samsrv dll with the Novell
version. MCS believes potential for failure is very high, as
soon as any dll starts depending on new exports from samsrv
dll. Replacing this one critical dll could case the system
to fail to boot and recovery could be very difficult.</p>
<p>Also, if for what ever reason the new samsrv dll is left
in place after a service pack install on a PDC or a BDC the
potential of causing login and security problems is high. If
the upgraded server is a primary domain controller there
would be the possibility that no one, including the NT
administrators, would not be able to log onto the system,
potentially a very disastrous situation. We realize this
sounds like a lot of FUD but the weakness created in the
system by the replacement of this critical dll should be
clearly understood and MCS would be remiss in its
responsibilities to our customers if this fact was not
pointed out.</p>
<p>Novell claims that customers will be able to upgrade to
NT 5.0 from NDS for NT without any consequences. This is
true if the customers migrate or imports a domain into NT
5’s Active Directory, but that simply brings the same
directory objects over to the Active Directory Domain. The
upgrade from Windows NT Server 4.0 to Windows NT Server 5.0
converts the SAM by reading it directly, not by calling SAM
APIs. The users and groups created in NDS will not be picked
up in the upgrade (assuming the upgrade can even begin with
the modified SAMSRV.DLL installed, which is unlikely). NDS
for NT users will be faced with a second migration after
installing Windows NT Server 5.0, to bring the NDS users
into Active Directory. Furthermore, there are multiple paths
into the authorization and authentication system in Windows
NT Server 5.0, there is no single place to trap and redirect
these operations. A Windows NT Server 5.0 version of NDS for
NT will require a total rewrite, and there is little
motivation for this since Windows NT Server 5.0 comes with
its own very robust directory service, Active Directory.</p>
<p>It should be noted that there are issues with
supportability of an NT environment that has been
implemented utilizing NDS for NT. Microsoft has repeatedly
stated that it will support their NT customers and
NT’s basic functionality, but in areas that NDS
touches, namely security and authentication, Microsoft will
refer customers to Novell. This has the potential of
creating some confusion in the resolution of issues
revolving around security and authentication.</p>
<p>1.4.5 Speed</p>
<p>Because all security calls are redirected from the PDC
and BDC, to NetWare, users may experience additional delays
in any operation that requires any type of NT
authentication.</p>
<p>At a recent Novell event, Brain Share1, a demonstration
of NDS for NT was given. It was observed that at the
demonstration it took 35 seconds for a user to log on
against a (presumably) unloaded server in a tree with under
ten users. This, naturally, raises concerns about speed and
response time, not only for user authentication but also for
any application that requires NT authentication.</p>
<p>1.4.6 Reliability</p>
<p>In order to install NDS for NT it is necessary to install
the IntranetWare Client. Based on past performance,
Microsoft does not recommend the IntranetWare Client for
installation on servers, especially servers that also host
mission critical applications. MCS feels this is a high risk
and should be considered carefully. It’s also
important to know that there are issues with using TCP/IP
with Novell’s current IntranetWare client. This is one
of the main reasons the Church has had to maintain its
dependence on IPX/SPX.</p>
<p>It will also be necessary to retest any NT server based
applications that runs on NT for reliability. COH will need
to be tested; DHCP, WINS, and DNS services will all need to
be tested.</p>
<p>Also, comments from PeopleSoft should be solicited to see
if PeopleSoft and Tuxedo are supported in environments where
NDS for NT is in use as well as the IntranetWare client.</p>
<p>1.4.7 Security</p>
<p>What are the implications of calls that used to go
between the samsvr.dll and the registry now being redirected
across the network? Do the passwords retain their encrypted
state that they were originally transmitted in? If they are
encrypted, is that encryption secure?</p>
<p>Windows NT has a feature where anonymous logon users can
list domain user names and enumerate share names. Customers
who wanted enhanced security requested the ability to
optionally restrict this functionality. Windows NT 4.0
Service Pack 3 and a hotfix for Windows NT 3.5.1 provide a
mechanism for administrators to restrict the ability for
anonymous logon users from obtaining system information.
These anonymous connections are also known as NULL session
connections. During the installation of Novell’s NDS
for NT, the samsrv.dll is replaced. Novell NDS for NT
currently does not include support for restricting anonymous
connections. MCS see this deficiency as a security weakness.
</p>
<p>Conclusion</p>
<p>To summerize the major points:</p>
<ul>
<li>NDS for NT is a poor technical solution that
fundamentally alters NT Server by replacing its security and
authentication mechanism.</li>
<li>NDS for NT make the migration from NT 4 to NT 5 more
difficult.</li>
<li>NDS for NT is not an interoperability solution but a
point solution.</li>
<li>NDS for NT may have an adverse impact on network
response time.</li>
<li>NDS for NT does not simplify the administrative process
but futher complicates it.</li>
</ul>
<p>It is the feeling of MCS, as well as many others in the
computer industry, that NDS for NT is not a mainstream
product. It is a point solution that is designed to appeal
to NetWare customers with an expanding base of Windows NT
servers and applications in a NetWare legacy environment.
While NDS for NT appeals to some of these customers as a
stopgap measure to provide more centralized administration
of Windows NT domains, the substantial expense, questionable
stability, and dead-end nature of the implementation all
argue against it.</p>
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, August 12 2012 @ 03:49 PM EDT |
<p>Subject: QuickTime, Win 98, and Media Player<br/>
Date: 7/21/98 9:09 AM<br/>
To: Cristiano Pierry, cpierry@microsoft.com<br/>
Eric Engstrom, ericeng@microsoft.com<br/>
CC: Tim Schaaff. tims@apple.com</p>
<p>Cristiano, Eric,</p>
<p>When you guys visited us several weeks ago, you indicated
that you thought you had fixes for the problems we were
experiencing with QuickTime and your new Media Player. We
tested the revised version you sent against QuickTime.
Unfortunately, it did not behave any differently.</p>
<p>I wanted to get back to you try to make some progress on
this. It’s a big issue for Apple.</p>
<p>The basic problem is very simple. When QuickTime is
installed by a customer, we want to be able to associate the
QuickTime Plug-in with the various MIME types QuickTime
supports. In Netscape Navigator this is handled
automatically by the browser plugin API. With IE 3.0, this
varies somewhat. However, with Windows 98 and with your
latest Media Player software, this standard plug-in
mechanism seems to be completely ignored.</p>
<p>It appears that your software is using info from the
Windows Registry to determine what MIME types get routed to
which pieces of software. As you know, the Windows Registry
is not publicly documented. To the extend that Internet
Explorer 4 relies on this undocumented info from the Windows
Registry to determine which software should be involved in
process different MIME types on the web page, third-party
developers, like Apple, are getting hurt.</p>
<p>We do not experience this problem with .MOV files (though
we do with .QT files). However for all the other file types
we support (e.g., AVI, WAV, AU, AIFF, MIDI,...). Your
software either ignores the plug-in settings or overrides
our attempts to manipulate the registry to achieve the
desired behavior.</p>
<p>Either IE needs to properly implement support for the
plug-in API or Microsoft needs to tell us how to set the
registry to achieve the behavior we are getting
automatically in Navigator. It’s unacceptable that
everytime a new version of the Media Player, or Direct X, or
Windows itself is installed that QuickTime is getting
overridden by your software.</p>
<p>Can you help me solve this problem?</p>
<p>Thanks,</p>
<p>Tim</p>
<hr/>
<p>Subject: Fwd. QuickTime, Win 98, and Media
Player<br/>
Date: 7/28/98 8:02 AM<br/>
To: Eric Engstrom ericeng@microsoft.com<br/>
Cristiano Pierry, cpierry@microsoft.com<br/>
CC: Tim Schaaff, tims@apple.com</p>
<p>Hi Guys,</p>
<p>Not sure if the following e-mail I sent last week ever
made it to you, so I'm sending it again. Please let me know
if there's someone else I should be working with to find a
resolution. We’re pretty anxious to resolve the
problems outlined in my note, so I’d really appreciate
a response.</p>
<p>Thanks</p>
<p>Tim</p>
<p>---------------- Begin Forwarded Message ----------------
<br/>
<p>Date: 7/21/98 9:10 AM<br/>
Received: 7/21/98 9:10 AM<br/>
From: Tim Schaaff, tims@apple.com<br/>
To: Cristiano Pierry, cpierry@microsoft.com<br/>
Eric Engstrom, ericeng@microsoft.com<br/>
CC: Tim Schaaff. tims@apple.com</p>
<p>Cristiano, Eric,</p>
<p>When you guys visited us several weeks ago, you indicated
that you thought you had fixes for the problems we were
experiencing with QuickTime and your new Media Player. We
tested the revised version you sent against QuickTime.
Unfortunately, it did not behave any differently.</p>
<p>I wanted to get back to you try to make some progress on
this. It’s a big issue for Apple.</p>
<p>The basic problem is very simple. When QuickTime is
installed by a customer, we want to be able to associate the
QuickTime Plug-in with the various MIME types QuickTime
supports. In Netscape Navigator this is handled
automatically by the browser plugin API. With IE 3.0, this
varies somewhat. However, with Windows 98 and with your
latest Media Player software, this standard plug-in
mechanism seems to be completely ignored.</p>
<p>It appears that your software is using info from the
Windows Registry to determine what MIME types get routed to
which pieces of software. As you know, the Windows Registry
is not publicly documented. To the extend that Internet
Explorer 4 relies on this undocumented info from the Windows
Registry to determine which software should be involved in
process different MIME types on the web page, third-party
developers, like Apple, are getting hurt.</p>
<p>We do not experience this problem with .MOV files (though
we do with .QT files). However for all the other file types
we support (e.g., AVI, WAV, AU, AIFF, MIDI,...). Your
software either ignores the plug-in settings or overrides
our attempts to manipulate the registry to achieve the
desired behavior.</p>
<p>Either IE needs to properly implement support for the
plug-in API or Microsoft needs to tell us how to set the
registry to achieve the behavior we are getting
automatically in Navigator. It’s unacceptable that
everytime a new version of the Media Player, or Direct X, or
Windows itself is installed that QuickTime is getting
overridden by your software.</p>
<p>Can you help me solve this problem?</p>
<p>Thanks,</p>
<p>Tim</p>
<p>------------------------------------------------<br/>
Tim Schaaff<br/>
Senior Director, Interactive Media Group<br/>
QuickTime, QuickTime VA, QuickDraw 3D<br/>
<br/>
Apple Computer<br/>
1 Infinite Loop, MS S02-3K3<br/>
Cupertino, CA 95014<br/>
USA<br/>
<br/>
E-Mail: tims@apple.com<br/>
Voice: 408-862-7753<br/>
Fax: 408-974-5426<br/>
<br/>
http://www.apple.com/quicktime/<br/>
------------------------------------------------</p>
<p>---------------- End Forwarded Message ----------------
<br/>
<hr/>
<p>Subject: RE: QuickTime, Win 98, and Media Player<br/>
Date: 8/5/98 11:36 AM<br/>
Received: 8/5/98 11:45 AM<br/>
From: Christiano Pierry, cpierry@microsoft.com<br/>
To: Tim Schaaff, tims@apple.com<br/>
Eric Engstrom ericeng@microsoft.com<br/>
CC: Cristiano Pierry, cpierry@microsoft.com</p>
<p>My answers are in blue below.</p>
<p>Please let me know if this answers your questions. And
feel free to contact me again if you have any other
questions.</p>
<p>Thanks.</p>
<p>Cris</p>
<p>----- Original Message -----<br/>
From: Tim Schaaff [mailto:tims@apple.com]<br/>
Sent: Tuesday, July 28, 1998 9:09 AM<br/>
To: Eric Engstrom; Cristiano Pierry<br/>
Cc: Tim Schaaff<br/>
Subject: Fwd. QuickTime, Win 98, and Media Player</p>
<p>Hi Guys,</p>
<p>Not sure if the following e-mail I sent last week ever
made it to you, so I'm sending it again. Please let me know
if there's someone else I should be working with to find a
resolution. We’re pretty anxious to resolve the
problems outlined in my note, so I’d really appreciate
a response.</p>
<p>Thanks</p>
<p>Tim</p>
<p>---------------- Begin Forwarded Message ----------------
<br/>
<p>Date: 7/21/98 9:10 AM<br/>
Received: 7/21/98 9:10 AM<br/>
From: Tim Schaaff, tims@apple.com<br/>
To: Cristiano Pierry, cpierry@microsoft.com<br/>
Eric Engstrom, ericeng@microsoft.com<br/>
CC: Tim Schaaff. tims@apple.com</p>
<p>Cristiano, Eric,</p>
<p>When you guys visited us several weeks ago, you indicated
that you thought you had fixes for the problems we were
experiencing with QuickTime and your new Media Player. We
tested the revised version you sent against QuickTime.
Unfortunately, it did not behave any differently.</p>
<p>I wanted to get back to you try to make some progress on
this. It’s a big issue for Apple.</p>
<p>The basic problem is very simple. When QuickTime is
installed by a customer, we want to be able to associate the
QuickTime Plug-in with the various MIME types QuickTime
supports. In Netscape Navigator this is handled
automatically by the browser plugin API. With IE 3.0, this
varies somewhat. However, with Windows 98 and with your
latest Media Player software, this standard plug-in
mechanism seems to be completely ignored.</p>
<strong>
<p>As you are aware, Internet Explorer prefers the use of
ActiveX controls. These controls are registered in the MIME
database. Your QT 3.01 control is not registering itself as
an ActiveX control in the MIME database. Since our controls
do register as ActiveX controls, they will be given
preference over all other applications. My recommendation is
that your create an ActiveX control for Internet Explorer
and register it correctly.</p>
<p>Example<br/>
[HKEY_CLASSES_ROOTMIMEDatabaseContent Typeaudio/aiff]
<br/>
"Extension"=".aiff"<br/>
"CLSID"="{22DEF312-B0F6-11D0-34A8-0080C74C7E94}"</p>
<p>Where the CLSID listed is the CLSID of the QT 3.01
control.</p>
<p>For more information, please check out the following web
page:</p>
<p>http://www.microsoft.com/workshop/components/activex/regi
stration.htm<br/>
<http://www.microsoft.com/workshop/components/activex/reg
istration.htm></p>
</strong>
<p>It appears that your software is using info from the
Windows Registry to determine what MIME types get routed to
which pieces of software. As you know, the Windows Registry
is not publicly documented. To the extend that Internet
Explorer 4 relies on this undocumented info from the Windows
Registry to determine which software should be involved in
process different MIME types on the web page, third-party
developers, like Apple, are getting hurt.</p>
<strong>
<p>The method used in take over IE 4 MIME types is clearly
and explicitly documented in the IE SDK.</p>
</strong>
<p>We do not experience this problem with .MOV files (though
we do with .QT files).</p>
<strong>
<p>We have not been able to repro your experience with the
.QT files. The exception being on IE 3.0 where they do not
playback through your plugin when you are installed over the
?? of Windows. In all other cases the .QT ??? played back
through the QT plugin.</p>
</strong>
<p>However for all the other file types we support (e.g.,
AVI, WAV, AU, AIFF, MIDI,...). Your software either ignores
the plug-in settings or overrides our attempts to manipulate
the registry to achieve the desired behavior.</p>
<strong>
<p>Why would you take over WAV, AVI and MIDI? These are
Microsoft Windows formats. It is surprising to us that you
would take over Windows formats. To answer your question, IE
gives precedence to the files registered in the MIME
database as ActiveX controls.</p>
</strong>
<p>Either IE needs to properly implement support for the
plug-in API or Microsoft needs to tell us how to set the
registry to achieve the behavior we are getting
automatically in Navigator. It’s unacceptable that
everytime a new version of the Media Player, or Direct X, or
Windows itself is installed that QuickTime is getting
overridden by your software.</p>
<strong>
<p>Again, please refer to the following web page for the
proper way to register media types.</p>
<p>http://www.microsoft.com/workshop/components/activex/regi
stration.htm<br/>
<http://www.microsoft.com/workshop/components/activex/reg
istration.htm></p>
</strong>
<p>Can you help me solve this problem?</p>
<strong>
<p>Please let me know if this answers your questions. And
please don’t hesitate to contact me again if there is
anything else that I can help with.</p>
<p>Thanks.</p>
<p>Cris</p>
</strong>
<p>Thanks,</p>
<p>Tim</p>
<p>------------------------------------------------<br/>
Tim Schaaff<br/>
Senior Director, Interactive Media Group<br/>
QuickTime, QuickTime VA, QuickDraw 3D<br/>
<br/>
Apple Computer<br/>
1 Infinite Loop, MS S02-3K3<br/>
Cupertino, CA 95014<br/>
USA<br/>
<br/>
E-Mail: tims@apple.com<br/>
Voice: 408-862-7753<br/>
Fax: 408-974-5426<br/>
<br/>
http://www.apple.com/quicktime/<br/>
------------------------------------------------</p>
<p>---------------- End Forwarded Message ----------------
<br/>
<hr/>
<p>Subject: RE: QuickTime, Win 98, and Media Player<br/>
Date: 8/5/98 2:04 PM<br/>
To: Cristiano Pierry, cpierry@microsoft.com<br/>
CC: Eric Engstrom, ericeng@microsoft.com<br/>
Tim Schaaff, tims@apple.com</p>
<p>Cristiano,</p>
<p>Thanks for the response.</p>
<p>Short of rewriting everything as an ActiveX control, I
would like to understand how to achieve the desirec effect
with our current plug-in. You didn’t address that
issue at all.</p>
<p>>As you are aware, Internet Explorer prefers the use
of ActiveX controls.</p>
<p>It didn’t use to. What if I just want my existing
QuickTime Plug-in work properly? I would have at least
expected you to maintain good compatibility with the
existing, widely accepted standards, such as the Netscape
Plug-in API. Besides, ActiveX is only supported on Windows
and only with Internet Explorer. That’s a bit narrow,
don’t you think?</p>
<p>>Why would you take over WAV, AVI and MIDI? These are
Microsoft Windows formats.</p>
<p>Why would you take over QuickTime movies? These are
Apple formats. The fact is that thirty of these file formats
have become ??? ??? standard formats. As such, Apple wants
to be able to ??? some of the unique benefits of QuickTime
is these formats. By the way, MIDI isn’t a Microsoft
format at all. MIDI was created by the MIDI
Manufacturer’s Association (MMA). The MMA is industry
consortium of which both our companies are members. The MIDI
format is an industry standard like MPEG.</p>
<p>Tim</p>
<p>------------------<br/>
Cristiano Pierry 8/5/98 11:38 AM</p>
<p>> My answers are in blue below.<br/>
><br/>
> Please let me know if this answers your questions. And
feel free to contact<br/>
> me again if you have any other questions.<br/>
><br/>
> Thanks.<br/>
><br/>
>Cris<br/>
><br/>
><br/>
> ----- Original Message -----<br/>
> From: Tim Schaaff [mailto:tims@apple.com]<br/>
> Sent: Tuesday, July 28, 1998 9:09 AM<br/>
> To: Eric Engstrom; Cristiano Pierry<br/>
> Cc: Tim Schaaff<br/>
> Subject: Fwd. QuickTime, Win 98, and Media
Player<br/>
><br/>
> Hi Guys,<br/>
><br/>
> Not sure if the following e-mail I sent last week ever
made<br/>
> it to you, so<br/>
> I'm sending it again. Please let me know if there's
someone<br/>
> else I should<br/>
> be working with to find a resolution. We’re
pretty anxious<br/>
> to resolve<br/>
> the problems outlined in my note, so I’d really
appreciate a<br/>
> response.<br/>
><br/>
> Thanks<br/>
><br/>
> Tim<br/>
><br/>
> ---------------- Begin Forwarded Message --------------
--<br/>
> Date: 7/21/98 9:10 AM<br/>
> Received: 7/21/98 9:10 AM<br/>
> From: Tim Schaaff, tims@apple.com<br/>
> To: Cristiano Pierry, cpierry@microsoft.com<br/>
> Eric Engstrom, ericeng@microsoft.com<br/>
> CC: Tim Schaaff. tims@apple.com<br/>
><br/>
> Cristiano, Eric,<br/>
><br/>
> When you guys visited us several weeks ago, you
indicated<br/>
> that you thought you had fixes for the problems we were
experiencing with<br/> > QuickTime and your new Media
Player. We tested the revised version you sent<br/>
> against QuickTime. Unfortunately, it did not behave any
differently.<br/>
> I wanted to get back to you try to make some progress
on<br/>
> this. It’s a big issue for Apple.<br/>
> The basic problem is very simple. When QuickTime
is<br/>
> installed by a customer, we want to be able to
associate the QuickTime<br/>
> Plug-in with the various MIME types QuickTime supports.
In Netscape<br/>
> Navigator this is handled automatically by the browser
plugin API. With IE<br/>
> 3.0, this varies somewhat. However, with Windows 98 and
with your latest<br/>
> Media Player software, this standard plug-in mechanism
seems to be<br/>
> completely ignored.<br/>
> <br/>
> As you are aware, Internet Explorer prefers the use of
ActiveX controls.<br/>
> These controls are registered in the MIME database.
Your QT 3.01 control is<br/>
> not registering itself as an ActiveX control in the
MIME database. Since<br/>
> our controls do register as ActiveX controls, they will
be given preference<br/>
> over all other applications. My recommendation is that
you create an<br/>
> ActiveX control for Internet Explorer and register it
correctly.<br/>
> <br/>
> Example<br/>
> [HKEY_CLASSES_ROOTMIMEDatabaseContent
Typeaudio/aiff]<br/>
> "Extension"=".aiff"<br/>
>
"CLSID"="{22DEF312-B0F6-11D0-34A8-0080C74C7E94}"</p>
><br/>
> Where the CLSID listed is the CLSID of the QT 3.01
control.<br/>
><br/>
> For more information, please check out the following
web page:<br/>
><br/>
>
http://www.microsoft.com/workshop/components/activex/registr
ation.htm<br/>
>
<http://www.microsoft.com/workshop/components/activex/reg
istration.htm><br/>
><br/>
> It appears that your software is using info from the
Windows<br/>
> Registry to determine what MIME types get routed to
which pieces of<br/>
> software. As you know, the Windows Registry is not
publicly documented. To<br/>
> the extend that Internet Explorer 4 relies on this
undocumented info from<br/>
> the Windows Registry to determine which software should
be involved in<br/>
> process different MIME types on the web page, third-
party developers, like<br/>
> Apple, are getting hurt.<br/>
> <br/>
> The method used in take over IE 4 MIME types is clearly
and explicitly<br/>
> documented in the IE SDK.<br/>
><br/>
> We do not experience this problem with .MOV files
(though<br/>
> we do with .QT files).<br/>
><br/>
> We have not been able to repro your experience with the
.QT files. The<br/>
> exception being on IE 3.0 where they do not playback
through your plugin<br/>
> when you are installed over the ?? of Windows. In all
other cases the .QT<br/>
> ??? played back through the QT plugin.<br/>
><br/>
> However for all the other file types we support (e.g.,
AVI,<br/>
> WAV, AU, AIFF, MIDI,...). Your software either ignores
the plug-in settings<br/>
> or overrides our attempts to manipulate the registry to
achieve the desired<br/>
> behavior.<br/>
><br/>
> Why would you take over WAV, AVI and MIDI? These are
Microsoft Windows<br/>
> formats. It is surprising to us that you would take
over Windows formats.<br/>
> To answer your question, IE gives precedence to the
files registered in the<br/>
> MIME database as ActiveX controls.<br/>
><br/>
> Either IE needs to properly implement support for
the<br/>
> plug-in API or Microsoft needs to tell us how to set
the registry to achieve<br/>
> the behavior we are getting automatically in Navigator.
It’s unacceptable<br/>
> that everytime a new version of the Media Player, or
Direct X, or Windows<br/>
> itself is installed that QuickTime is getting
overridden by your software.<br/>
><br/>
> Again, please refer to the following web page for the
proper way to register<br/>
> media types.<br/>
><br/>
>
http://www.microsoft.com/workshop/components/activex/registr
ation.htm<br/>
>
<http://www.microsoft.com/workshop/components/activex/reg
istration.htm><br/>
><br/>
> Can you help me solve this problem?<br/>
><br/>
> Please let me know if this answers your questions. And
please don’t<br/>
> hesitate to contact me again if there is anything else
that I can help with.<br/>
> <br/>
> Thanks.<br/>
><br/>
> Cris<br/>
> Thanks,<br/>
><br/>
> Tim<br/>
><br/>
><br/>
> ------------------------------------------------<br/>
> Tim Schaaff<br/>
> Senior Director, Interactive Media Group<br/>
> QuickTime, QuickTime VA, QuickDraw 3D<br/>
> <br/>
> Apple Computer<br/>
> 1 Infinite Loop, MS S02-3K3<br/>
> Cupertino, CA 95014<br/>
> USA<br/>
> <br/>
> E-Mail: tims@apple.com<br/>
> Voice: 408-862-7753<br/>
> Fax: 408-974-5426<br/>
> <br/>
> http://www.apple.com/quicktime/<br/>
> ------------------------------------------------<br>
><br/>
><br/>
><br/>
> ---------------- End Forwarded Message<br/>
> ----------------<br/>
><br/>
<hr/>
<p>Subject: Well-behaved Video Digitizers<br/>
Date: 8/12/98 11:23 PM<br/>
To: Eric Engstrom, ericeng@microsoft.com</p>
<p>Eric,</p>
<p>My team is asking for advice on how to ensure that a
video digitizer will always ??? live preview ??? inside the
window. Today when the preview window is moved, we do not
receive notification of the change in window’s ???
area. This can sometimes lead to video preview ??? being
shown outside the window bounds.</p>
<p>I assume you have solved this problem and that there is a
standard mechanism that HW capture cards are supposed to use
to avoid this problem.</p>
<p>Can you point us at some relevant info or ??? ??? ???
someone else I should talk to? I’d appreciate any
pointers you can provide.</p>
<p>Thanks,</p>
<p>Tim</p>
[ Reply to This | Parent | # ]
|
|
|
|
|
