Redocumenting the undocumented shell extensions
Date: August 1995
- 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.
Synopsis
Snippet
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.