Athena and shell extension
Category:Comes v Microsoft
Category:Antitrust
Category:Microsoft
Category:Novell
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 api's was based on a set of considerations which are no longer operable. the win95 shell will be on winnt and the shell extensions will run fine ther -- there is no issue about supporting on nt.
- the win95 team did "make darn 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): thdecision to not expose the shell extension api's eir changes will be merged back into the code base.
__________
From: Brad Struss To: bradsi; paulma Cc: cameronm; doughe Subject: FW. 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 thee prerelease Athena PIM, it now appears that full Explorer integration is supported in 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 beta would not be supported moving forward. This decision was based upon the difficulty the Windows NT team would have in 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 initial release of Win95 and would be doc'd as b-list appis 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 these interfaces and told them that: (1) the functionality of running in an integrated window was gone and (2) they were strongly discouraged from using the modified apis aat all because of compatibility risks. This caused significant changes in a many of their development plans, 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 Hennich Cc: Brad Struss, Jerry Drain, Tammy Steele Subject: Shell extedecision to not expose the shell extension api's nsibility and ISVs Date: 08 August 1995 10:54PM Priority: 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 to 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 an 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 reasonn 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 with 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, leverage, the works! What's strange about all odecision to not expose the shell extension api's f this is that it looks like this 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 darn sure that NT is kept in mind when they do things. The only real way for that to happen is to effort and the 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 communicaated to DRG - this 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.
Also see http://www.groklaw.net/article.php?story=20091125035600938
Date: August 1995
Synopsis
Snippet
From: Brad Silverberg [brads] 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 api's was based on a set of considerations which are no longer operable. the win95 shell will be on winnt and the shell extensions will run fine ther -- there is no issue about supporting on nt.
- the win95 team did "make darn 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): thdecision to not expose the shell extension api's eir changes will be merged back into the code base.
__________
From: Brad Struss To: bradsi; paulma Cc: cameronm; doughe Subject: FW. 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 thee prerelease Athena PIM, it now appears that full Explorer integration is supported in 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 beta would not be supported moving forward. This decision was based upon the difficulty the Windows NT team would have in 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 initial release of Win95 and would be doc'd as b-list appis 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 these interfaces and told them that: (1) the functionality of running in an integrated window was gone and (2) they were strongly discouraged from using the modified apis aat all because of compatibility risks. This caused significant changes in a many of their development plans, 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 Hennich Cc: Brad Struss, Jerry Drain, Tammy Steele Subject: Shell extedecision to not expose the shell extension api's nsibility and ISVs Date: 08 August 1995 10:54PM Priority: 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 to 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 an 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 reasonn 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 with 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, leverage, the works! What's strange about all odecision to not expose the shell extension api's f this is that it looks like this 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 darn sure that NT is kept in mind when they do things. The only real way for that to happen is to effort and the 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 communicaated to DRG - this 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.
Full Exhibit
https://techrights.org/o/wp-content/uploads/2009/11/Comes-2383.pdfAlso see http://www.groklaw.net/article.php?story=20091125035600938