From: Brad Silverberg [bradsi]
Sent: Friday, August 11, 1995 2:08 PM
To: Brad Struss: Paul Maritz
Cc: Cameron Myhrvold; Doug Henrich
Subject: RE. Shell extensibility and ISVs
- athena is part of windows don't know what you mean about athena as "a
product to be sold in the near future", athena is just part of windows
and windows can and will use the shell extensions.
- the decision to not expose the shell extension apis was based on a set
of considerations which are no longer operable, the win95 shell will be
on winnnt and the shell extensions will run fine there - there is no
issue about supporting on nt.
- the win95 team did "make dam sure NT is kept in mind" from the
beginning for the shell, which is why it ported so easily, we have the
x-platform responsibility and we deliver on it. we have one shell team -
the psd shell team, which dropped off the code to bsd to do the nt
adaptation, they are not to be "enhancing it", just a straight
adaptation (unicode, tweaks for portability, etc); their changes will be
merged back into the code base.
From: Brad Struss
To: bradsi; paulma
Cc: cameronm; doughe
Subject: F’W: Shell extensibility and ISVs
Date: Thursday,August 10,1995 4:18PM
Last fall Bill made the decision not to expose the ability to extend the
Explorer. In looking at the prerelease Athena PIM, it now appears that
full Explorer integration is supported on both Windows NT and Windows
95. This obviously has ISV impact and we are potentially exposed here
from a PR and trust perspective.
To.recap the history, it was decided last fall that the Explorer
extensibility mechanism that had been documented in early betas would
not be supported moving forward. This decision was based upon the
difficulty the Windows NT team would have supporting these interfaces
and on the need for MS to figure out our general extensibility strategy.
Since the MSN team was dependent upon using these interfaces, a
compromise solution was agreed to that allowed a modified version of the
interfaces to support MSN to come up in a separate explorer window (vs
the old way of actually being listed in the left hand pane of the
Explorer window along network neighborhood, etc).
These interfaces were not planned to be supported beyond the intial
release of Win95 and would be doc’d as b-list apis to be given out on
special request so that other ISVs could develop an app similar to the
MSN client if they so desired. As a result of this change, we
proactively notified ISVs (Stac, Symantec, Netsoft, Oracle, etc.) who
were actively developing using interfaces,and told them that (1) the
functionality of running in an integrated window was gone and (2) they
were strongly discouraged fromn using these modified apis at all because
of compatibility risks, but they understood and pushed forward. The
prerelease Athena PIM now displays capabilities contrary to what we have
been telling our ISVs.
Can you please advise on our strategy for these interfaces moving forward?
Brad
From: Scott Henson
To: Cameron Myhrvold; Doug Hennch HS98 0]20900
Cc: Brad Struss; Jerry Drmn. Tammy Steele
Subject: Shel extensibdity and ISVs
Date: 08 August 1995 10:54PM
Pnonty: High
This mail is intended to summarize what I am seeing internally on this
[subject and to voice a STRONG concern for our ISVs!
The problem is that approximately a year ago we told ISVs that a set of
interfaces (known as namespace extensions) were no longer going to be a
part of the standard Win32 API set - they were moved an an unsupported
status or "b-list". The rationale at the time was that the interfaces
were difficult to support especially on NT. The specific reason is that
when a ISV implements a namespace extension they live in the process
space of the operating system. Thus, if an ISV writes their namespace
extension poorly they can bring down the entire shell. This is still the
case today. Another reason was that the Ren team (Office 96 PIM) was
going to hold the key for all future shell innovation (thus the split of
the Cairo shell team). Given this, we went and told the ISVs that there
was a lot that they could do in the system with respect to extensibility
BUT they COULD not integrate into the explorer (like the control panel
and briefcase) as we had previously mentioned was possible.
So for the last year we have been distributing "b-list" documentation to
ISVs that were interested in the interfaces but always told them that
this was not a desirable thing to do because these interfaces would most
likely disappear in the future and there would be an equivalent way to
do this in the future when the problems were solved. In the meantime
there has been interest throughout the company in extending the shell in
the way that the control panel and briefcase do.
So the PSD shell team has given them the docs and told them that we have
distributed this ISVs and that they are writing to these extensions and
they would most likely become part of the standard Win32 API set. For
the most part this is fine from my perspective because MSN already has
buyoff from the NT team to implement what they are currently using on
Windows 95 which is to instantiate themselves into a separate instance
of the Explorer. From a robustness perspective this is fine because if
the app is bad, then they just bring down that instance of the explorer.
HOWEVER
This is not the limit of what is going on internally. As I mentioned
there is a lot of internal development going on where various groups are
implementing these interfaces to varying degrees. Again I don’t mind if
these various groups are doing this development work as long as it is in
the way that MSN is doing it (coming up in their own view, separate from
the system).
We can then move the interfaces back to the standard Win32 set and with
a little ISV re-education on our part all is well. Today my perception
changed drastically. I have just installed Athena (the lightweight PIM
from the PSD group) onto my system and to my dismay they are not only
using the namespace extensions but they are also displaying themselves
in the scope (left) pane and view (right) pane. This is the EXACT thing
we told ISVs they could (and should) not do! "
In short we have a product that will be sold in the very near future
that will implement interfaces that we told ISVs they should not use
because we would not be able to support them moving forward. In the
meantime we were developing a product that did exactly that. I can’t
even express how BAD this is! We loose everything when we do this!
Credibility, trust, lever-age, the works! What’s strange about all of
this is that it looks like th s product works fine on NT as well,
< SO WHAT NEEDS TO BE DONE? >
Assuming that we are going to support these APIs as a part of the
standard Win32 API set we should document them - QUICK! Our ISVs are
already months behind. They key thing we need to understand is if we
want ISVs to extend the shell in the way that Athena is doing it
currently or the way. From my perspective this is a reflection much
larger problems. We need to get our act together internally on a shell
extensibility strategy. Is Office going to ever be key holder for shell
innovation? Is this going to continue to come from the PSD shell team?
If so, we need they need to make dam sure that NT is kept in mind when
they do things. The only real way for that to happen is to combine the
BSD effort and PSD effort into one team. Otherwise there is no forcing
function for development issues like this. Otherwise one team constantly
plays cleanup and only the short-term approach wins. Not good. The other
problem is that none of this seems to get communicated to DRG - this is
is important. We have to hear a rumor from someone and then run around
like crazy trying to figure out what’s going on. For cryin’ out loud -
the NT folks did not even know what Athena was!
In any case the decision to unify our teams and strategy needs to take
place at a higher (and much more objective place). Any input you might
have is greatly appreciated.
- Scott
< A SIDE NOTE >
We also need to get our PIM strategy together. Why in the world do we
have Schedule +, Ren, Pegasus (I understand this somewhat), and Athena?
This is going to be phenomenally confusing for our customers.
|