Subject: 1.0 WHERE AM I?
Subject: 1.1 What is alt.windows.cde?
This newsgroup is dedicated to the exchange of news and information about the Common Desktop Environment (CDE) being created as a part of the Common Open Software Environment (COSE) for UNIX-based workstations. It is *not* for Microsoft Windows questions. Those belong in comp.os.ms-windows.apps or some such newsgroup.Subject: 1.2 What is this posting?
This is the alt.windows.cde FAQ list for April 11, 1995. When the alt.windows.cde newsgroup was formed, I thought that there would be constant updates posted here by the COSE vendors. This hasn't happened. This is somewhat understandable; they are extremely busy right now. Also, it was pointed out to me by one of the CDE developers that with four companies involved, it is hard to remember what is and is not public knowledge, so it is better to not say anything lest one company give away another's trade secret. What this is then is the author's, coworker's, and contributor's current understanding of the CDE and COSE in general. Although this newsgroup is about the CDE specifically, there is no COSE newsgroup (yet), so this is a logical place to describe the other COSE technology areas, too. Much of the text in this FAQ was based on a paper and briefing done in November of 1993 so if it has the feel of a tutorial rather than a traditional FAQ, that is why. If you have questions (and even better - answers/additions) you would like to see added to this list, send e-mail to: cap@mitre.orgSubject: 1.3 Legal Stuff
This FAQ list should not be construed as an official "policy" statement of my employer, the MITRE corporation. Also, all statements herein should not be regarded as undeniable facts. (i.e., You can't sue me or MITRE if they are wrong.) For one thing, several of these "facts" have changed dramatically since the (bulk of) text below was orginally written in November, 1993. Although I have updated them to the best of my knowledge at this time, I can almost guarantee some of them will change again. Since it isn't my full time job to update this list, it won't be current at all times. Also, there are a lot of trademarked names in this FAQ list. Those trademarks belong to their respective trademark holders.Subject: 1.4 What's in the FAQ?
The sections and questions below are: 2.0 COSE OVERVIEW 2.1 In general terms, what is COSE and why do we need it? * 2.2 How does COSE work / What is the "new" OSF? 2.3 How does COSE fit into the existing standards processes? 3.0 DETAILS ABOUT COSE 3.1 What all does the COSE process encompass? * 3.2 What are the Common UNIX APIs? 3.3 What is going on in graphics? 3.4 What is COSE doing about multimedia? 3.5 What is COSE doing in regards to objects? 3.6 What is COSE doing in the area of distributed computing? 3.7 What is COSE doing about system management? 3.8 What is the Public Windows Interface (PWI)/WABI? 3.9 What is COSE doing about Federated Naming? 3.10 What is COSE doing about Data Management? 3.11 How will the COSE technologies be packaged? 4.0 DETAILS ABOUT THE COMMON DESKTOP ENVIRONMENT (CDE) 4.1 What is in the CDE? 4.1.1 What is the CDE desktop? 4.1.2 What is the Front Panel? 4.1.3 What is the File Manager? 4.1.4 What is the Application Manager? 4.1.5 What is Application and File Action Binding/Typing? 4.1.6 What is Session Management? 4.1.7 How do I program with the CDE? 4.1.8 How does CDE do drag-and-drop? 4.1.9 How does CDE support remote application execution? 4.1.10 How does CDE support inter-application communication? 4.1.11 What utilities are included? 4.1.12 What applications are included? 4.1.13 What is the CDE Print Server? 4.1.14 What is the Help System? 4.1.15 Any other features? * 4.2 How do I get the CDE software for my workstation? 4.3 What do I get when I buy it? 4.4 Is CDE safe/reliable/stable? 4.5 Is an object-oriented GUI toolkit like Fresco in the works for CDE? 4.6 How does the CDE relate to Motif 2.0? 4.7 Can I license the CDE source code so that I can port it? 4.8 When is the next CDE Developers Conference? 4.9 What is going to be in CDEnext? 4.10 How do the COSE vendors maintain common look and feel? * 4.11 Will I be able to share my calendars cross platform/network? * Indicates new or significantly changed sections since the last revision.Subject: 1.5 What's not in the FAQ; what needs to be added?
Subject: 1.5.1 Actual programming experiences and tidbits
Dos and don'ts of programming with CDE and other COSE (Spec 1170) APIs.Subject: 1.5.2 Windowing Korn Shell (dtksh) example code
dtksh examples and fragments to be tried and reused.Subject: 1.5.3 Detailed questions about particular aspects of CDE and
the applications that come with the CDE.Subject: 2.0 COSE OVERVIEW
Subject: 2.1 In general terms, what is COSE and why do we need it?
UNIX has long suffered from a lack of standardization across platforms. The lack of standard application programming interfaces (APIs) force independent software vendors (ISVs) to spend up to fifty percent of all development funds on maintenance of separate code and testing for the many UNIX varieties. Absence of standardization of user interfaces causes significant user confusion and increased training costs and requirements. Finally, the lack of standard administrative procedures leads to additional training costs as administrators move between the various UNIX platforms. All of these factors have contributed to UNIX's reputation as a powerful, but arcane operating system. Over the years, a number of coalitions have formed to attempt to unify the various UNIX interfaces into a single broadly accepted, broadly available user environment. The newest of these coalitions is COSE. COSE was formed by a group of companies on March 17, 1993. The companies that formed COSE are: - Hewlett-Packard Company - IBM, Corp. - The Santa Cruz Operation, Inc. - SunSoft, Inc (SUN Microsystems) - Univel (Novell) - UNIX Systems Laboratories, Inc (Now part of Novell) Since the initial announcement, other vendors have agreed to support COSE. From this point forward, the term "COSE" will be used to refer to the collective membership of the group. While the COSE vendors purport that COSE is merely a "process", that COSE is simply acting as a "catalyst" to accelerate the standards, the reality is that in all likelyhood, COSE represents the way that standards for the future UNIX environment will be created. COSE is developing reference implementations and draft standards in all areas of open systems from kernel APIs to networking to desktop look-and-feel. Finally, it must be said that COSE was formed as the open systems vendor's response to the coming of Microsoft Windows NT. Windows NT is the first non-UNIX based operating system to be available on a number of systems architectures. The scalability of NT makes Microsoft's huge base in the Intel PC arena a threat across the entire (performance) range of systems. The availability of NT across platforms finally delivers what UNIX and open systems have long promised, a common API and look-and-feel across a broad performance range. It does so, however, at the expense of relying on a single vendor, Microsoft. The purpose of open systems is specifically to avoid such vendor dependence. Unfortunately, to this point, the open systems processes have not managed to arrive at the required common standards. COSE represents the open systems vendors attempt to speed development of such standards before Microsoft NT takes hold.Subject: 2.2 How does COSE work / What is the "new" OSF?
In March 1994, it was announced by the COSE vendors that many of the developing reference implementations and draft standards would be created by groups within OSF using OSF's new pre-structured technology (PST) processes. OSF's recently modified business model introduced the PST concept, which is expected to compliment - not replace - the traditional OSF Request for Technology (RFT) method for acquiring new technology. The PSTs are formed by paying sponsors that will use OSF to oversee the project and monitor the prime contractor chosen by the sponsors. Each PST will be led by a Project Steering Committee, whose members will often be employees of the sponsoring organizations. The development of a PST technology will be done by a prime contractor chosen by the sponsors. One or more of the sponsors may themselves be subcontractors. The creation of the PST process is intended to be an improvement upon the RFT process used in the old OSF model. There is no guarantee that any, and certainly not all, COSE projects will be accomplished through OSF RFT or PST processes. Another important event was the inclusion of former UNIX International companies, e.g. Sun, among the sponsors of the new OSF. For an official view of the PST process, try the Web page at: http://www.osf.org:8001/pst/pst-process-gd.html The original CDE 1.0 work is still being done by the COSE vendors outside of the OSF PST process, however. The initial version of CDE, CDE 1.0, was announced as "finished" at the March 1995 UniForum conference in Dallas. HP, IBM, Novell, and SunSoft were joined by TriTeal in the announcement. TriTeal is offering the CDE 1.0 environment for legacy OSes/platforms such as MIPS, AIX 3.2.5, and Sun OS 4.1.x (as well as Solaris 2.3 [and above]). An OSF PST for the follow-on to the first release of the CDE was initially formed in March 1994. Also at UniForum, the official letter of intent to develop the next release of CDE through the OSF PST process was announced. (The follow-on release has not been offically named, but the vendors refer to it as simply "CDEnext") In addition to the original four vendors (HP, IBM, Novell, and Sun), DEC, Fujitsu, and Hatachi have joined as sponsors of the CDEnext PST. The X Consortium was named as the prime contractor. For this PST, the committee chairman is David Bealby from SunSoft. I mention this only because having someone from Sun chairing a committee within OSF would have been unthinkable a year or two ago. By the end of 1994, the PST hopes to have completed the project definition and plan, submit the plan to the OSF board for approval, and make the necessary commitment of resources to the project. The COSE vendors intend to submitted the CDE 1.0 specification and sample implementation to X/Open for standardization through the X/Open Fast Track process. They hope that the specification will be adopted by X/Open in early 1995. To date, the CDE Specifications have progressed through X/Open's Fast Track review and acceptance process. The (X/Open) CDE Working Group recently passed a resolution recommending that the four specifications be published by X/Open. The CDE Specification include: - CDE Definitions and Infrastructure - CDE Services and Applications - Motif Toolkit API (v.1.2) - Calendaring and Scheduling API Other technologies being considered for transition to PSTs include the Distributed Management Environment (DME), OSF/1, Motif 2.0 (after its August 94 release), and the Distributed Computing Environment (DCE). Many of the other proposed COSE technologies such as System Management or Objects may also be started as PST processes within OSF, but no formal announcements have been made. Once a reference technology has been completed to a logical conclusion, the specification and any test suites will be submitted to X/Open (or another standards body, when appropriate) for fast tracking through the standards process. The expectation is that the standards organizations will agree to the COSE implementations and draft standards with few changes. Since the vendors play major roles in the standards organizations, this is a reasonable expectation. The technology will be licensable to outside organizations directly from OSF, and the sponsors are all inherently license for use of the technology. The sponsors will receive part of the proceeds from licensing, but this is not expected to be the driving force behind the inception of PSTs by the sponsors. Once a standard is approved, the vendors are committed to making a common behavior implementation available on all their platforms. OSF maintains that the PST process is being added to better meet the realities of the marketplace today. The goal is to streamline the open systems process and better facilitate collaborative development. In this form, OSF transitions from technology developer to project coordinator and a technology licensing body. The RFT process will continue to be used in the areas of basic research and where there is no consensus among vendors, but it is expected that the use of the PST process will become prevalent.Subject: 2.3 How does COSE fit into the existing standards
processes? COSE is sensitive to the overall standards process. Where a promulgated standard meets requirements, COSE simply accepts the standard and commits all COSE vendors to adhere to the standard. In those areas, COSE simply is guaranteeing even more openness than in the past. Customers will be able purchase any COSE "compliant" system and be assured that the open, approved standard interfaces will be available. Where the process is moving forward, COSE has tended to simply defer to the current process, and to state that COSE vendors will provide the interfaces when the standard is completed. In such areas, non-controversial solutions will be available. However, in some areas, in the interest of moving standards forward at a more rapid pace, COSE has defined APIs and interfaces that may not be consistent with the direction of other standards bodies. The decision of COSE to use X/Open instead of IEEE/ISO/ANSI/NIST for establishment of formal COSE "standards" may be a problem. The problem stems from the following sources: - X/Open is not an open process in the same way that the IEEE standards are. X/Open standards are agreed to by votes of the X/Open directors and members. Standards review and voting rights are given *only* to paying members. (When Novell agreed to turn over the UNIX trademark to X/Open, Novell sought and received a post as a X/Open director for a period of years.) The cost to be a member of X/Open varies depending on how one wants to be involved. At a minimum, it will cost $11K/year for a non-profit corporation to join the group that formulates the requirements for the specifications (but not the specifications themselves). The cost can rise to over $500K/year is an organization wants "broad brush" influence. To join the Desktop+ working group that is working on CDE issues, the cost is $25K/year. - X/Open "branding" is not free. It costs money to go through the X/Open test suite for branding as X/Open compliant. These fees are due yearly and based on the applicant's revenue. The fees are a minimum of $25K/year, which would be fairly steep for a start-up company. Initially, branding will be done against OSes for Spec 1170 compliance, but CDE compliance will likely follow soon with other specifications for multimedia and objects following later.Subject: 3.0 DETAILS ABOUT COSE
The following paragraphs introduce the technology areas that were originally identified by COSE. Several of these - most notably multimedia, objects, and distributed computing - are apparently being combined under the CDE umbrella. The first section is an overview of all of the areas as originally proposed. The following sections are more detailed information about those areas where details are known with the exception of CDE, which is found in section 4.Subject: 3.1 What all does the COSE process encompass?
COSE is addressing all areas of computer systems from networking to operating systems to user interfaces. The next several paragraphs are "one-liners" that describe those areas. Those technologies where more details are known are described in the following sections. Common UNIX APIs - The Common APIs (Application Programming Interfaces) are the operating system interfaces that will be called "UNIX." A early name for this specification was Spec 1170, which is a reference to the number of APIs in the first draft of the specification. The interfaces include UNIX kernel APIs and commands. Common Desktop Environment (CDE) - CDE includes look-and-feel, window management, messaging services in the desktop, and commands and programming APIs for windowing. It is based on Motif 1.2.3. Graphics - Graphics standardizes line drawing, 3D graphics, etc. Multimedia - Multimedia includes standards for integration of video, audio, etc. with text. System Management - System management includes standards for printer interfaces, user and group management, software installation, etc. as well as a framework. Objects - Objects includes standards for handling of objects in a heterogeneous, distributed environment. Distributed Computing - Distributed computing includes standards for underlying protocols, RPCs, and distribution of file systems. Public Windows Interface(PWI) - PWI is an attempt to force the Microsoft Windows messaging standards into the public domain. The sample implementation allows the execution of Windows software within an X Window using a combination of 80x86 emulation and translation Federated Naming - Federated Naming covers incompatible distributed naming standards, principally Sun's Network Information System (NIS/NIS+) and OSF's Cell Directory Service.(CDS). Data Management - Data Management covers issues of large scale hierarchical data storage and retrieval. Representatives from COSE vendors have indicated that there might be additional slices in the future. One particular possibility was a public Macintosh interface analogous to PWI. Apple has recently begun to market the Macintosh Application Environment (MAE), which runs Macintosh applications on UNIX workstations within a Motif (CDE) window, but with a Macintosh look and feel. With the exception of PWI, COSE implementations for addressing particular slices typically start from an existing open systems standards base, but usually add to the base. The particular criteria that COSE uses to decide how far to vary from the standards base appears to depend on the particular slice of the COSE pie and the maturity of the standards in particular areas. Where there are competing, and potentially incompatible implementations, the tendency seems to be to include all of the "standards." Inclusion of multiple interfaces has several impacts. As part of the COSE process, all COSE vendors have agreed to support all parts of COSE on their systems. However, it was agreed that pricing and packaging of particular bits of COSE would be up to the particular systems vendors. This potentially presents both problems and opportunities. For COSE to insist that SCO, for instance, include a desktop on all copies of SCO would cause significant pricing problems for them. Many SCO systems are used as point-of-sales systems with ASCII terminals attached to a single standalone machine. Requiring those systems to include and pay for X Window clients and a server with their heavy RAM and disk requirements was regarded as a real problem given the size of the SCO customer base using ASCII terminals only. Price/performance comparisons of COSE systems, however, will be complicated by differences in vendor packaging of the various technologies. On the other hand, those complications will allow users to only pay for those options that they require.Subject: 3.2 What are the Common UNIX APIs?
On September 1, 1993, many major hardware vendors and software vendors said that they would support a draft COSE API specification to UNIX called Spec 1170. The specification is called Spec 1170 because, at the time of announcement, the specification contained approximately 1170 APIs. Spec 1170 covers APIs to kernels, C libraries, networking, and command interfaces. The COSE methodology for development of the specification is representative of the overall COSE approach. COSE started from a standards base, X/Open's POSIX-based XPG4. COSE then looked at the systems calls used by the fifty most popular software packages for calls that were "missing" from the XPG4 base. Based on that review, COSE decided to add the SVID curses support, Berkeley sockets, and a number of other APIs. COSE, however, did not necessarily include everything they found in the software. If calls were rarely used or vendor "enhancement" specific, COSE did not include the calls. Note that the COSE software review was retrospective. If new interfaces are emerging, they would not be found in the current base. An example of this is the decision to not support a standard threads implementation as part of Spec 1170. Threads give significant performance boosts to applications on multiprocessor systems. However, multiprocessor systems have only recently become widely available at reasonable prices so few applications have been coded to support threads in the past. The Institute of Electronical and Electronics Engineers (IEEE) is currently working on a draft threads API in POSIX.4a. Therefore, the API committee decided to defer decisions on threads until IEEE finalizes its specification. X/Open has completed their work on Spec 1170, and it has been published. The new name of the specification is the "Single UNIX Specification" or XPG/4.2. The specification can be purchased as printed copies or electronically (via E-Mail) from X/Open at this time. The cost is $250. In the US, you can telephone X/Open at (703) 876-0044 or (415) 323-7992. In the UK, X/Open can be reached at +44 (0) 734 508311. (FAX: +44 (0) 734 500110) X/Open will develop test suites against the Single UNIX Specification standard. As part of an agreement between X/Open and Novell announced in October 1993, the UNIX trademark was transferred to X/Open so that official UNIX operating systems could be branded by X/Open against the specification using a test suite to be developed. (The official transfer of the UNIX trademark did not occur until around April or May 1994.) X/Open will brand systems as "UNIX" if and only if they pass the Single UNIX Specification test suites. No vendor can legally call their system "UNIX" unless they have passed the test suite and been branded. The Single UNIX Specification (1170) Brand is now available from X/Open. The UNIX 93 brand applies to the UNIX system products which pre-date the Single UNIX Specification. Vendors which currently carry the UNIX 93 brand have guaranteed that they will move their product to full UNIX 95 conformance.) The UNIX 95 brand applies to the UNIX system products which conform to the Single UNIX Specification. The following companies have recently registered products under the UNIX 93 profile. Amdahl Corporation ------------------ UTS Version 4 Release 2 or later running on Amdahl 5890, 59xx Series & 7300 Processors AT&T Gobal Information Solutions
AT&T UNIX System V Release 4 (SVR4) MP-RAS, Release 2.02 or later on AT&T System 3000 Family Digital Equipment Corporation
Digital UNIX(R) V3.2 running on Digital AlphaStations and Digital Alpha Servers Groupe Bull ----------- Bull ESCALA (TM) FAMILY of symmetric multi-processors & other binary compatible Bull DPX/20 mono-processing systems with AIX(TM) Version 4 & C for AIX(TM) Version 3 or later Hewlett-Packard Company ----------------------- HP-UX 9.X for HP 9000 Series 700 HP-UX 9.X for HP 9000 Series 800 International Business Machines Corporation
IBM RISC System/6000 POWERstations & POWERservers with AIX Version 3 IBM POWER, POWER2, and PowerPC(TM) Systems with IBM AIX(R) Version 4 and C for AIX version 3 or later Novell Inc ---------- UnixWare(R) 1.1 and later, running on Intel(R) i386(TM) /i486(TM) /Pentium(TM) based PCs UnixWare(R) 2.0 and later, running on Intel(R) i386(TM) /i486(TM)/ Pentium(TM) Siemens Nixdorf --------------- SINIX-Y V5.42 running on RM600 SINIX-N V5.42 running on RM200 and RM400 Sun Microsystems ---------------- Solaris 2.4 and on with SPARCompiler C 2.0.1 and on for SPARC based systemsSubject: 3.3 What is going on in graphics?
This working group is defining the standards for 2D and 3D graphics rendering under X. This is being done at the X Consortium level. The defined standard is to adopt Xlib (for 2D drawing), PEXlib (for 3D drawing), and XIElib (for working with images). These standards were already the de facto standards in the industry. COSE intends to support the standards bodies and hopes to accelerate the process. Imagery exchange and file formats do not appear to be part of this group's charter.Subject: 3.4 What is COSE doing about multimedia?
This working group is just forming. COSE plans to work through the Interactive Multimedia Association (IMA) to define standards for integrated video, audio, and text-based objects. In a meeting, HP representatives also mention the Distributed Media Services (DMS) and Desktop Integrated Media Environment (DIME) as subgroups.Subject: 3.5 What is COSE doing in regards to objects?
As part of the original announcement, all of the COSE members have endorsed the Object Management Group's (OMG) process and committed to shipping Common Object Request Broker Architecture (CORBA) compliant products. As noted above, the question that must be asked is how does the CDE interprocess communication scheme based on Sun's non-CORBA compliant ToolTalk, fit into COSE's overall distributed computing plans.Subject: 3.6 What is COSE doing in the area of distributed
computing? All six of the original companies have pledged to fully support SunSoft's Open Network Computing (ONC/ONC+), OSF's Distributed Computing Environment (DCE), and Novell Netware clients on each of their systems. The transport layer supported will be TCP/IP protocols. Of interest to government agencies, OSI protocols are not supported. Note that, while all vendors agreed to support all three distributed computing solutions, the three are incompatible with one another. Users will be guaranteed that their preferred solution will be available across platforms, but if users do not control all platforms that they must internetwork with, there will be incompatibilities at the interfaces between domains. The availability of all three also means that ISVs that want to support COSE will need to maintain all three interfaces in their software.Subject: 3.7 What is COSE doing about system management?
[This information is from the October 1993 CDE Developers Conference where the working group was in the formative stage. I have no up-to-date information on this group. Some of this is out of date. - cap] As this part of UNIX has long been chaotic with every vendor having different solutions in all areas, this group has a difficult job before them. The overall intent of the System Management Working Group is to develop core enabling technologies and APIs. Simple solutions will be developed by COSE but more complex needs will be met by ISVs developing against the standard APIs. The group has picked a couple of areas in which they think that they can have an immediate impact including: - Software distribution and installation - Software distribution and installation will be based on POSIX 1003.7.2. COSE intends to push for completion of the standard and hopes to have a reference implementation by the end of 1994. [This looks fairly unlikely now.-cap] The resulting standard will support both push and pull distribution. Policy distribution will come in later releases. - Distributed Print Services - Print services will be based on POSIX 1003.7.1 June 93 draft, ISO 10175, and ANS.1. The software will offer common APIs, GUI, and end-user desktop support. The tool is not expected to be high end, but the APIs will allow ISVs to develop high end applications. The working group expects to have a reference implementation in 1994. [The print services work within CDE was postponed until the second release. This also looks fairly unlikely now.-cap] Areas to be addressed later include: - User and group management - The user and group management will be based on POSIX 1003.7.3. This COSE subgroup is just forming [as of October 1993]. - Software License Management - Software license management standards will be available. COSE has looked at a number of current licensing schemes and has decided that none are sufficient. COSE will develop a standard approach. - Backup and Restore and Data Management - The backup and restore standard will be based on the current X/Open Backup Services API. The standard will also include hierarchical storage and retrieval standards and APIs based on the Data Management Interface Group (DMIG) and the IEEE Mass Storage Working Group Draft standards. The System Management group also is working with the recently formed COSE Data Management group in this area. Finally, the System Management Working Group plans to develop an overall system management framework. The framework is likely to consist of APIs and services on CORBA. The framework is expected in 1995.Subject: 3.8 What is the Public Windows Interface (PWI)/WABI?
COSE has committed to the development of a specification for a Public Windows Interface (PWI). The specification is an attempt to move the Microsoft Windows interfaces into the public domain. The Microsoft Windows applications are more mature, have more features, and have many more users than their UNIX-based counterparts. If COSE is successful, one will be able to develop native 80x86 Microsoft Windows code and run it on COSE compliant systems. The specification includes Windows look and feel, messaging, and 80x86 emulation. A Windows application running under a PWI implementation has the look and feel of a Microsoft Windows application within an X window. The PWI emulator intercepts Microsoft Windows graphics messages and translates them into native X Window calls. The non-Microsoft Windows code is executed either by software emulation (on a non-80x86 machine) or execution in hardware (on a 80x86 machine).Subject: 3.8.1 Current release of WABI.
The SunSoft product WABI is a sample implementation of PWI. Version 1.1 of WABI is currently available on SUN platforms and has been made available to other COSE vendors. WABI offers an emulation of Windows 3.1 and supports about a dozen of the major applications such as Microsoft Word and Excel. However, it does not offer support for DOS, DOS networking, or Object Linking and Embedding (OLE2). The current product and the applications that run under it have a Microsoft Windows look and feel. This version does not provide support for networking. The next release, version 2.0, is due out December 12th 1994 with the SMCC release of Solaris 2.4. Version 1.1 of WABI claimed that you did not have to have a copy of Windows in order to run Windows applications. In reality, some of the files (especially DLLs) needed to run some of the major applications were on the Windows disks, not the application's installation disks, so a copy of Windows was necessary. In version 2.0, you will be required to purchase a copy of Windows 3.1. SunSoft found it difficult to keep up with the changes to and increasing number of DLLs (etc.) it had to develop and maintain. Version 2.0 of PWI will provide support for networking. It will also supports OLE and DDE between Windows applications. The number of "approved" applications in version 2.0 has been increased to around 20. The list of approved applications includes Microsoft® Access 2.0, Lotus® AmiPro(tm) 3.01 and 3.0, Lotus Approach(tm) 2.1, Lotus cc:Mail(tm) 2.0, CorelDraw(tm) 4.0 and 3.0 Microsoft Excel® 5.0 and 4.0, Lotus Freelance(tm) 2.01, Harvard Graphics® 2.0 and 1.0, Software Publishing Corporation, Microsoft® Mail 3.2, Lotus Notes® 3.0c, Microsoft® Office 4.3, Lotus 1-2-3® for Windows 4.0 and 1.1, Lotus Organizer(tm) 1.1, Aldus® PageMaker® 5.0 and 4.0, Paradox(tm) for Windows 4.5 and 1.0, Borland International Microsoft PowerPoint® 4.0 and 3.0, ProComm Plus(tm) 1.02 and 1.0, Microsoft Project(tm) 4.0 and 3.0, Quattro® Pro for Windows 5.0 and 1.0, Borland International, Quicken® 3.0, Intuit, Microsoft Word® for Windows 6.0 and 2.0, WordPerfect® for Windows 6.0a and 5.2, Lotus SmartSuite(tm) 2.0, and Microsoft® Windows 3.11 and 3.1. For official information about WABI 2.0, try the WWW page at: http://www.sun.com/sunsoft/Products/PC-Integration-products/products/Wabi.html General information about WABI is at: http://www.sun.com/sunsoft/Products/PC-Integration-products/pwi/index.html For information about WABI on IBM AIX workstations try: http://www.austin.ibm.com/software/wwabissf.html (Sorry about the long URLs, but I am not the one who is so prolific with my path names.)Subject: 3.8.2 WABI Performance.
SUN claims performance increases relative to native Microsoft Windows applications. IBM has recently agreed to use WABI on its RS/6000 AIX platforms. As part of its agreement, IBM will provide access to its expertise in software emulation to attempt to increase performance. Since PWI only runs the Windows front end natively and must software emulate any calls to 80x86 processes, PWI performs much better on an Intel-based hardware than on RISC-based hardware. If processes under PWI are a significant portion of a user's job, Intel-based hardware running UNIX may be preferable over RISC-based hardware.Subject: 3.8.3 PWI Look and Feel Issues.
The current version of PWI has a Microsoft Windows look and feel. A user can launch Windows applications from within the base WABI (Program Manager) window, or can launch a WABI compatible application from a UNIX X Window desktop. In either case, the launched application has a Windows look and feel. If the user is exclusively a PWI user, the CDE login session can bring up a PWI interface that covers his entire screen. The user gets standard Microsoft Windows drivability, and the user session could be easily mistaken for a Microsoft Windows session. On the other hand, if the user is only a part-time user of PWI, the user sees applications with two different look-and-feel approaches on the screen at the same time. On a Windows NT platform that is not the case. Windows NT sessions have the same look-and-feel as Windows 3.X sessions so 3.X sessions running under NT look and act like NT sessions. The COSE vendors indicated that they had taken Windows look and feel approach rather than a conversion to native Motif look and feel approach so that users coming to UNIX from DOS/Windows will not be faced with look and feel changes. Related to the PWI look and feel issue, IXI has a product, winTIF, that allows applications written to use the Motif look and feel to display a Microsoft Windows look and feel instead. It is intended for Microsoft Windows users that need to occasionally access software developed to the Motif API from their Windows-based desktops. This solves the look and feel issue for use of UNIX displays to Microsoft Windows platforms.Subject: 3.8.4 Microsoft's Response to PWI.
As can be expected, Microsoft has responded to the development of WABI/PWI. Microsoft's response to PWI is three fold: - Microsoft has indicated that the Windows interface is theirs. Any attempt to use it by others may be open to legal action. - Microsoft control of the Windows "standard" allows for rapid movement forward. The reason that UNIX has had such problems agreeing is that UNIX vendors and the open systems processes often have conflicting interests. - Microsoft has signed an agreement with Insignia, makers of SoftPC, to build a PWI-like product. Insignia's solution offers a Microsoft Windows look and feel on UNIX RISC-based platforms. A Motif look and feel is promised in a later release. The agreement gives Insignia access to Microsoft Windows code for their development. Insignia's access offers several advantages over a PWI solution: - Insignia's solution will not be reverse engineered. Insignia's access to the Microsoft code may yield better performance since it is based on the Microsoft code. It may also yield better compatibility when initially delivered. - Insignia's solution will not tie Microsoft to a specific interface. Microsoft will be able to modify their software and Insignia's solution will easily follow along. A reverse engineered solution like PWI is likely to have time to market problems over time as the "standard" Microsoft code is "enhanced". - Insignia's solution does not face any legal challenges.Subject: 3.8.5 Potential Impact of PWI on Software ISVs.
PWI and the Microsoft-Insignia solution will have significant impacts on software ISVs. The Microsoft Windows ISVs will now be able to sell their products into the UNIX X Windows market without porting their software to UNIX. The effects of PWI on the existing UNIX market will manifest themselves in a number of ways depending on the type of application: - Applications that perform well under WABI are ones that are heavily GUI intensive. Such applications typically are end-user productivity applications. - Common Windows applications will be available at Windows prices on UNIX platforms. Because of fierce competition and economies of scale, Windows applications are typically much less expensive and have more features than corresponding X Windows applications. - Given that the size of the UNIX desktop market is about ten percent of the Microsoft Windows market and that ISVs can now service that ten percent by targeting the other ninety percent, it is questionable that ISVs will undergo the expense of porting to UNIX workstations unless there are significant performance gains to be had by doing so. The gains are for the software that is heavily computational or server oriented. For the most part, however, those ISVs are already ported to UNIX and, in fact, many applications were initially developed on UNIX and ported to the lower performance DOS/Windows platforms. Those ISVs are now porting to the scalable Windows NT platforms and obtaining similar performance to their UNIX native software. - Users with interoperability requirements with Windows systems will tend to move to the Windows applications for compatibility reasons. Note that this specifically impacts organizations that use the Microsoft Office product as their company standard since Microsoft has not ported their products to UNIX.Subject: 3.9 What is COSE doing about Federated Naming?
[This information is from the October 1993 CDE Developers Conference.] OSF's Cell Directory Service (CDS) and Sun's Network Information Service (Plus) NIS+ are supported. DEC is sponsoring this effort.Subject: 3.10 What is COSE doing about Data Management?
[This information is from the October 1993 CDE Developers Conference.] The COSE Data Management working group has recently been formed. They are working with the Data Management Interchange Group (DMIG) on APIs for hierarchical storage and retrieval. COSE also plans to make any COSE data management solution consistent with the IEEE Mass Storage Reference Model. Since that model is in draft form, COSE will work to finalize the draft.Subject: 3.11 How will the COSE technologies be packaged?
As indicated above, some of the technology areas will be offerred as options by some vendors. Persons acquiring a system on which they intend to include COSE technologies will need to determine the particular bits (technology areas) of COSE that their particular system requires in order to be able to compare vendors prices. This impacts using systems from different vendors in several ways: - In the first place, there will be technical problems. Software that assumes the presence of particular bits simply will not run without them. On some systems, these will be included, and on others, they will be an option. - Secondly, there will be problems specifying and comparing prices when purchasing systems. The purchaser will need to specify exactly which pieces of COSE are required. Otherwise, there is no guarantee that a particular vendor's bid includes all required parts.Subject: 4.0 DETAILS ABOUT THE COMMON DESKTOP ENVIRONMENT (CDE)
In the CDE, the COSE vendors (not including SCO, who doesn't appear to be involved in the CDE portion of COSE) are working closely together with each contributing personnel and technologies to the effort of producing a common user environment (desktop) that has reasonably identical (considering that different vendors have different screen resolutions, framebuffers, phosphors, etc.) look and feel across all of the platforms. COSE has taken what they feel is the best user interface and desktop technologies from all of its vendors, and is enhancing and combining them. In the process of developing CDE, COSE: - has solved the OpenLook versus Motif look-and-feel controversy; - is developing a standard UNIX desktop; - is standardizing on Sun's ToolTalk for interapplication messaging at the desktop level; - is creating a standard visual scripting language; and - is opening up the desktop specification and programming APIs for standardization through X/Open. CDE will compete with and may replace current desktop managers such as Visix's Looking Glass and IXI's X.desktop on UNIX workstations. IXI is supplying tools to convert X.desktop's proprietary configuration files and icons into COSE's CDE. The CDE is a coherent, visually elegant [in the author's opinion], open user environment that takes full advantage of the distributed multiprocessing UNIX environment. COSE expects to deliver the CDE specification to X/Open and have vendor support for the specification by the third quarter of 1994. A working draft of the CDE specification, named XCDE, was submitted in October to X/Open for review. X/Open plans to publish the specification by the fourth quarter of 1994. CDE implementations should be arriving from vendors beginning in early 1995.Subject: 4.1 What is in the CDE?
The following paragraphs highlight the functionality of the CDE.Subject: 4.1.1 What is the CDE desktop?
Upon login, the user is presented with the CDE Desktop. The desktop includes a front panel, multiple virtual workspaces, and window management. CDE supports application launching from a File Manager, from an Application Manager and from the Front Panel (also known as the Dashboard). Each of the subcomponents of the desktop are described below.Subject: 4.1.2 What is the Front Panel?
The front panel contains a set of icons and popup menus (more like roll-up menus) that appears at the bottom of the screen (by default). HP's VUE product forms the basis for the CDE desktop. The front panel contains the most used applications and tools for managing the workspace. Users can drag-and-drop icons from the File Manager or Application manager to the popups for addition. The user can also manipulate the default actions and icons for the popups. The front panel can be locked so that users can't change it. A user can configure 1-12 (or more) virtual workspaces each with different backgrounds and colors. Each workspace can have any number of applications running in it. An application can be set to appear in one, more than one, or all workspaces simultaneously.Subject: 4.1.3 What is the File Manager?
CDE includes a standard File Manager. The functionality is similar to that of the Microsoft Windows, Macintosh, or Sun OpenLook file manager. Users can directly manipulate icons associated with UNIX files, drag-and-drop them, and launch associated applications. The associations are as described below under "File Action Binding / Typing".Subject: 4.1.4 What is the Application Manager?
The user interaction with the Application Manager is exactly analogous to File Manager except that is is intended to be a list of executable modules available to a particular user. The user launches the Application Manager from an icon in the Front Panel. Users are notified when a new application is available on a server by additions (or deletions) to the list of icons in Application Manager window. Programs and icons can be installed and pushed out to other workstations as an integral part of the installation process. The list of workstations that new software is installed on is configurable. The Application Manager comes preconfigured to include several utilities and programs.Subject: 4.1.5 What is Application and File Action Binding/Typing?
CDE adds a veneer on top of the traditional UNIX file system by allowing association of icons and actions to executable modules and data files. The Action and Typing capability of CDE allows for a file's type to be set by any combination of inspecting the contents of the file and pattern matching on the name of the file. Once a file has been "typed" an appropriate icon can be displayed for the file in the front panel, application launcher, and file manager. Actions can be assigned to icons so that associated commands are invoked when an icon is clicked.Subject: 4.1.6 What is Session Management?
The session management portion of CDE is responsible for start up and shut down of a user session. Also included is a login manager based on XDM. In the CDE, applications that are made "CDE aware" are warned via an X Event when the X session is closing down. The application responds by returning a string that can be used by the session manager at the user's next login to restart the application. Currently, CDE "remembers" two sessions per user. One is the "current" session, where a snapshot of the currently running applications is saved. These applications can automatically restarted at the user's next login. The other is the default login, which is analogous to starting an X session in X11R5/Motif and having X clients started up using entries in the .xinitrc file. The user chooses which of the two sessions to use at the next login.Subject: 4.1.7 How do I program with the CDE?
To a great extent, the CDE look-and-feel and programming APIs are based on the Open Software Foundation's (OSF) Motif. There are extensions to the basic Motif APIs to cover new concepts such as multiple virutal workspaces, ToolTalk messaging, and session management. As part of the initial COSE announcement, Sun agreed to abandon OpenLook and support Motif. However, the other COSE vendors agreed that the COSE look-and-feel would be open, no longer controlled by OSF. In addition, while the look-and-feel is Motif-based, COSE addressed Sun concerns regarding drivability and support for certain OpenLook features and widgets that were not part of the Motif specification. Addition of those features eases Sun user and developer transitions to COSE. The CDE environment is able to run OpenLook applications without modification (on a Sun anyway). The resulting CDE specification is a superset of the current OSF Motif. COSE is working with OSF to merge the COSE additions into OSF Motif. COSE is also developing a look-and-feel style guide that vendors are encouraged to follow. There will also be a branding/test suite mechanism to ensure compliance. COSE hopes that marketplace acceptance/pressure will also provide inducement for ISVs to seek compliance.Subject: 4.1.8 How does CDE do drag-and-drop?
CDE's drag and drop is based on Motif 1.2.3. This will work with many current and future X/Motif applications. This facility supports the dragging and dropping of files even if they physically reside on other workstations.Subject: 4.1.9 How does CDE support remote application execution?
CDE actions (See Actions and File Typing, above.) allow invocation of remote applications across the network. Remote invocation is through a CDE specific subprocess control daemon (dtspcd). The daemon overcomes limitations of existing remote invocation mechanisms such as remote shell (rsh) by passing the entire current user environment to the remote process. The daemon also takes care of the xhost command necessary to give the remote process authorization to display on the local X server screen. Note, however, the daemon is new and is not available on non-CDE platforms, even including the COSE vendor's legacy systems. Note also, COSE has not decided whether to publish the interface definition to the daemon so that other vendor's applications can use it.Subject: 4.1.10 How does CDE support inter-application communication?
Application messaging is currently based on Sun's ToolTalk. CDE has built some convenience functions on top of the basic ToolTalk to ease its use. It was strongly recommended at the CDE Developers Conference that all vendors plan to incorporate ToolTalk interfaces into their products. The problem to be resolved in this area is that ToolTalk is not Common Object Request Broker Architecture (CORBA) compliant, while COSE has indicated that object management services should be CORBA based. It is likely that a software interface to CORBA services from ToolTalk could be developed. Sun has indicated in the past that they would provide such interfaces as part of Sun's Distributed Objects Everywhere (DOE) project so such an interface is possible. Until such an interface is available, developers may have to develop and maintain interfaces to both CORBA and ToolTalk.Subject: 4.1.11 What utilities are included?
The CDE includes a number of standard utilities. The utilities consist of: - calculator - The calculator is a Motif version of the Sun calculator. - clock - The clock is analog only and embedded in the Front Panel. A digital clock is included in the desktop utilities and can be installed in the Front Panel. - the standard MIT X clients. - A tool for file typing and icon action manipulation. - Dialog and scripting services - Dialog and scripting services are provided by the Desktop Korn Shell (dtksh). dtksh is similar to the Korn Shell, but has quite a few structured programming extensions. The COSE windowing extensions allow the shell to create, output to, and read from Motif dialog and top level windows within a script. Also, dtksh has the capability to interact with C code, which is necessary for privileged code execution for security administration such as adding and removing users. IBM's release of CDE with AIX 4.1 in August (see section 2.2) included an extension to the Application Builder that will emit dtksh scripts. dtksh will likely become the standard visual scripting language on UNIX. Projects requiring "glue" code to tie together COTS products, for example, can be developed in this language. - A terminal emulator - The terminal emulator window application supplied with CDE is dtterm, which is analogous to xterm. dtterm supports full vt220 emulation and graphics. CDE extensions to MOTIF provide developers the terminal emulator widget for inclusion into their own programs.Subject: 4.1.12 What applications are included?
The CDE includes several desktop tools: - A mailer. CDE's mailer has minimal support for multimedia. It supports MIME format for attachments, and it will also be able to read X.400 mail and Sun V3 (Sun's mailtool format) mail. (This will be true when the tool is complete -- the reference version does not provide the attachment features.) As with the desktop manager, the mail sent by this tool will be interoperable with all supported platforms. The mail tool also supports drag and drop of multimedia via ToolTalk. Non-textual objects are represented as icons imbedded in text and are accessed by clicking on the icons. Access launches an appropriate tool for the object. Tool launching is handled using ToolTalk. - A multi-user calendar. The calendar tool is based on Sun's OpenLook calendar tool, but has a new interface and added capability. The calendar has a to-do list, an appointment/meeting scheduler, which can be used to schedule personal or group appointments. The latter is done by examining the calendars of the other members of the group selected to participate in the meeting. An individual has several ways to protect the information on their personal calendar. They can make the calendar completely inaccessible to others, which defeats the group scheduling capability. They can show appointment times as being blocked out, but others in the group can not see the details of the appointment. Or the appointment and details can be read by the group. When a meeting is scheduled for a group, the person scheduling the meeting can send mail to all the participants. - A general purpose text editor/word processor. This is a lightweight tool for text editing. It will probably serve best as an auxillary application for use by the mailer and other applications. It supports text wrapping with selectable margin settings, spell checking, search and replace, X cut and paste, and file inclusion. - An icon editor. This application is a fairly full featured graphical icon (pixmap) editor. Actually, if it supported a few more output formats like xwd or tif, this wouldn't be a bad (bitmap) paint program. As it is, it is quite capable for creating icons. The screen capture capability is particularly useful.Subject: 4.1.13 What is the CDE Print Server?
The print server (to be) included with CDE is essentially a specialized X server. A few special functions were added to initialize a print session, initialize a page, print a page, and end a print job. The printed "page" is drawn using normal X/Motif commands like XmDrawString. The size of the page and the resolution of the page are attributes that the application drawing the page can retrieve. Once the page is drawn, a command to print the page is issued. The X print server calls a device specific driver to converts the printed page to the language of the printer such as PostScript or PCL (used by HP printers). Printer manufacturers need only supply a driver to convert the printer server's representation of the printed page to their printer's language. This is analogous to vendor's supplying graphics buffer drivers for their specific displays in the X server as is done today. The basic print dialog is supplied by the CDE software, but individual manufacturers are free to add to this dialog to allow for special options for their printer. This is similar to what printer manufacturers do for Microsoft Windows or the Macintosh today. In addition to the print dialog there is the server dialog and the printer dialog for selecting the server and printer, respectively, to be used for a print job. This is analogous to choosing an AppleTalk zone and printer with the Macintosh. The CD-ROM early release version supports only black and white printing on PostScript and PCL (HP) printers. At Xhibition '94, it was announced that the Print Server will not be in the official CDE 1.0 release (expected first half 1995). It is expected that it will be in the CDE V2.0 release (probably 1996).Subject: 4.1.14 What is the Help System?
CDE provides an extensible hypertext based help system. A standard GUI and widget is available and APIs are provided for loading the system and using it from within applications. The help documents are SGML-based and support both graphics and hypertext links in addition to text. The CDE Look and Feel Guide strongly suggests that all applications use the help system.Subject: 4.1.15 Any other features?
CDE includes a number of other features such as: - APIs for internationalization; - User preferences selection of colors, backdrops, fonts, and other session parameters; - ToolTalk enabled icon and text editors; and - InterClient Communications Convention Manual (ICCCM) support.Subject: 4.2 How do I get the CDE software for my workstation?
The following table lists the CDE companies and the platforms supported: IBM - IBM AIX Version 4 - Contact 800 IBM-CALL (RISC Division) - IBM AIX 3.2.5 - Contact TriTeal for further information HP - HP-UX V9.* and HP X Terminals (Available in 2Q95) - Contact your local HP sales office or TriTeal for further information - HP-UX V10.* will bundle CDE (Available in 4Q95) - Contact your local HP sales office for further information. - Also try: http://www.dmo.hp.com/csopress/14mar95a.html Sun - SunOS 4.1.3 & Solaris 2.3 - Contact TriTeal for further information - Solaris 2.4 (Sparc and Intel) - Contact (800)SUN-SOFT ext 2 or TriTeal for further information Novell - UnixWare 2 - Contact TriTeal for further information Digital - DEC OSF/1 V3.2 (includes only the developers kit - no end user stuff) - DEC OSF/1 V? (Available in 4Q95) - Contact cdefordigital@unx.dec.com for further information TriTeal - IBM AIX 3.2.5; HP-UX 9; Unixware 2; SunOS 4.1.3; Solaris 2.3; SGI IRIX 5.3; AT&T MP-RAS; SINIX 5.3; IBM, HP, NCD and Tektronix X Terminals; RDI; Axil; PC-X Terms - $425 email: info@triteal.com - Also try: http://www.triteal.com/ - look under TriTeal Enterprise Desktop (TED)Subject: 4.3 What do I get when I buy it?
A single CD-ROM disc contains the binaries as well as hundreds of pages of documentation. The environment includes: *** software / applications *** - dtwm, the "desktop window manager", which is essentially HP-VUE ported to the other platforms with some interesting other features added such as ToolTalk - a very usable file manager (with file typing and actions are nicely supported), which obviates you from purchasing one from IXI (X.desktop) or Visix (Looking Glass). - dtmail, an e-mail program that understands MIME and Sun V3 (mailtool) formats (but still needs some bullet-proofing) - dtksh, a windowing Korn shell that allows scripts like: #!/opt/dt/bin/dtksh XtInitialize TOP hello Hello "$@" XtCreateManagedWidget H h label $TOP \ labelString:"Hello World" XtRealizeWidget $TOP XtMainLoop - dtcm, a calendar/appointment manager that lets you keep your own to-do lists as well as schedule group appointments (with other people using dtcm). (based on Sun's calendar tool) - dtcalc, a calculator (based Sun's OpenWindow calculator) - dtbuilder, a GUI interface builder that handles the additional CDE widgets in addition to std. Motif 1.2.3 widgets and generates C code. Also, called "AppBuilder." - an extensive authoring facility for supporting online help - dtterm, terminal emulation widget, which supports VT200 emulation and can be added as a widget in your own software - dtpad, a simple notepad editor, which is not bad as simple editors go. - icon editor, support both xbm and xpm formats, lots of nifty icons supplied - Lots of GUI front-ends to UNIX tools like tar, df, etc. The CD includes lots of development files like includes, examples, etc. The purpose of the CD-ROM is to provide an early development environment to give ISVs a leg-up on developing for CDE. [IMHO, they did a nice job.] *** documentation *** The documentation on the CD-ROM as PostScript files includes: - Application Builders User's Guide - (COSE CDE) Certification Checklist - Internationalization Programmer's Guide - Dtksh User's Guide - Help System Author's and Programmer's Guide - Programmer's Overview - Programmer's Guide - Advanced User's and System Administrator's Guide - Getting Started Using ToolTalk Messaging I was unable to print the CDE documentation without physically attaching the (Apple LaserWriter IINT) printer directly to my workstation and printing from the CD-ROM. For some reason when trying to print across the network, the printing would stop as soon as the first figure in the documentation was encountered. I have heard that others had similar problems. The following is list of what to expect in CDE 1.0. These files may not be on the 4/94 snapshot, but will be (with some possible changes/ additions/deletions) for the first official CDE release. I added some commentary in "[]." >15: pwd /opt/cde/usr/dt >16: ls -aRF ../ appconfig/ config/ examples@ man@ .../ backdrops@ copyright include@ palettes@ app-defaults/ bin/ dthelp/ lib/ share/ ../app-defaults/C: ../ Dtbuilder Dthello Dtksh Dtsession .../ Dtcalc Dthelpprint Dtpad Dtstyle Dt Dtcreate Dthelpview Dtqueueinfo Dtterm DtCalendar Dtfile Dticon Dtscreen Dtwm ../appconfig: ../ appmanager/ icons/ types/ .../ help/ tttypes/ ../appconfig/appmanager/C: ../ ../ Desktop_Apps/ Desktop_Tools/ Printers/ ../appconfig/appmanager/C/Desktop_Apps: ../ Dtcm* Dticon* Dtqueueinfo* .../ Dtcreate* Dtmail* Dtstyle* Dtappbuild* Dtfile* Dtmanpageview* Dtterm* Dtcalc* Dthelpview* Dtpad* Dttrash* [These are action files that start the applications in /usr/dt/bin.] ../appconfig/appmanager/C/Desktop_Tools: ../ DuSort* Spell* Xlsfonts* .../ Env* Tar* Xprop* Bitmap* ExecuteCmd* TarList* Xrefresh* Compress* File* TarUnpack* Xterm* Df* Grep* Uncompress* XtermDtspcd* Diff* Make* Vi* XtermRlogin* DttermConsole* Nm* Wc* Xwd* DttermDtspcd* ReloadActions* Xclipboard* Xwininfo* DttermErrorlog* ReloadApps* XclockDig* Xwud* DttermRlogin* ReloadResources* Xdpyinfo* Dttypes* RestorePanel* Xfd* DtwmrcEdit* Rm* Xload* [These are action files that start the applications in /usr/dt/bin.] ../appconfig/appmanager/C/Printers: ../ ../ DtPrint* ../appconfig/help/C: ../ CreatAct.sdl Iconed.sdl Terminal.sdl .../ Desktop.hf Intromgr.sdl Textedit.sdl AppBuilder.sdl DesktopIntro.hf Mailer.sdl cdelogo.pm Appmanager.sdl FPanel.sdl PrtBrowse.sdl graphics/ Calculator.sdl Filemgr.sdl Sesmgr.sdl graphicsShared/ Calendar.sdl Help4Help.sdl Stylemgr.sdl [Help files used by the help viewer, dthelpview.] ../appconfig/help/C/graphics: ../ SMmouseOL.tif fparrow.tif .../ SMscrnexOL.tif fpclock.pm AudioOL.pm SMscrnnoOL.tif fpcptomain.tif BSfieldOL.tif SMstartOL.tif fpdate.pm BSframeOL.tif SMwinddbOL.tif fpeditor.pm BSlistseOL.tif SMwindowOL.tif fpexit.pm BSmenusOL.tif ScreenOL.pm fphelpfp.pm ... ... ... ... [Plus a hundred or so other graphics, deleted here.] ../appconfig/help/C/graphicsShared: ../ acfcreatOL.tif noteicon.pm tbfpersOL.tif .../ cauticon.pm tbfcontOL.tif unitylogo.pm CWwslistOL.tif fpappmgr.pm tbflconOL.tif warnicon.pm ../appconfig/icons/C: ../ Dtapps.t.bm Dtinfbk.m.bm Fpdown.m.bm .../ Dtapps.t.pm Dtinfbk.m.pm Fpdown.m.pm DtABbil.l.bm Dtapps.t_m.bm Dtinfbk.m_m.bm Fpdown.m_m.bm DtABbil.l.pm Dtaprnt.m.bm Dtinfbk.t.bm FpdownY.l.bm DtABbil.l_m.bm Dtaprnt.m.pm Dtinfbk.t.pm FpdownY.l.pm ... ... ... ... [Plus several hundred more icons with equally cyrptic names that I deleted for brevity.] ../appconfig/tttypes: ../ ../ types.xdr ../appconfig/types/C: ../ dt.dt dtfile.dt dtscreen.dt xclients.dt .../ dt.dt.org dthelp.dt dtwm.fp autoStart.dt dtappman.dt dthelptag.dt print.dt datatypes.dt dtbuilder.dt dtmail.dt user-prefs.dt develop.dt dtcm.dt dtpad.dt uxstd.dt ../bin: ../ dtlp* .../ dtmail* Xsession* ctag1* dtmailpr* dsdm* dtpad* dtaction* dtprintegrate* dtappgather* dtqueueinfo* dtappintegrate* dtscreen* dtbuilder* dtsearchpath* dtcalc* dtsession* dtchooser* dtspcd* dtcm* dtstyle* dtcm_delete* dtterm* dtcm_editor* dtcm_insert* dttypes* dtcm_lookup* dtwm* dtcodegen* error.ds* dtconfig* htag1* dtcopy* htag2* dtcreate* list_queue_jobs* dterror* list_queues* dtexec* rpc.cmsd* dtfile* rpc.ttdbserverd* dtfplist* suid_exec* dtgreet* tt_type_comp* dthello* ttcp* dthelpgen* ttdbck* dthelpgen.dtsh* ttmv* dthelpprint* ttrm* dthelpprint.sh* ttrmdir@ dthelptag* ttsession* dthelpview* ttsnoop* dticon* tttar* dtksh* tttrace* dtloadresources* uil* dtlogin* xmbind* [dsdm - drop site database manager for drag and drop; dtaction - action manager; dtappgather and dtappintegrate work are for automating the installation of CDE applications; dtbuilder - CDE "aware" GUI builder; dtcalc - Sun's calculator with a Motif i/f; dtcm* - Calendar Mgr; dtcodegen - the (C) code generator for dtbuilder; dtconfig - turn on and off the CDE desktop from coming up at boot time; dtcopy - some kind of copy utility; dtcreate - utility to create actions and file data typing; dterror - error popup routine; dtexec - execute an executable; dtfile - file manager; dtfplist - utility to list components of the front panel; dtgreet and dthello - part of login sequence; dthelp* - part of help generation and viewing system; dticon - icon editor; dtksh - windowing korn shell; dtloadresources - X resource loading utility; dtlogin - also part of login sequence; dtlp - simple lp printing interface; dtmail* - CDE mail tool; dtpad - simple notepad editor; dtscreen - screen saver; dtsearchpath - search path resolution; dtsession - session management; dtspcd - sub process control daemon; dtterm - terminal emulation like xterm; dttypes - file typing resolver; dtwm - the window manager; error.ds - another error display routine; htag* - help tag utilities; tt* - ToolTalk utilities and parts; uil - uil compiler; xmbind - virtual keyboard bindings] ../config: ../ Xconfig Xsession.d/ dtspcdenv sys.dtprofile* .../ Xfailsafe* Xsetup* dtterm.ti xfonts/ C/ Xreset* Xstartup* psfonts/ Xaccess Xservers dtlogin.rc* svc/ ../config/C: ../ Xresources sys.dtwmrc sys.resources .../ dtfile.config sys.font sys.session ../config/Xsession.d: ../ 0010.dtpaths* 0030.dttmpdir* .../ 0020.dtims* 0040.xmbind ../config/psfonts: ../ ../ ja/ japanese@ ko/ zh/ zh_TW/ ../config/svc: ../ ../ AIX.lcx CDE.lcx HP-UX.lcx SunOS.lcx ../config/xfonts: ../ ../ C/ ja/ japanese@ ../config/xfonts/C: ../ ../ fonts.alias fonts.dir ../config/xfonts/ja: ../ ../ fonts.alias fonts.dir ../dthelp: ../ ../ dthelptag/ fontschemes/ help/ ../dthelp/dthelptag: ../ helpchar.ent helplang.ent icons/ .../ helpicon.ent helptag.opt ../dthelp/dthelptag/icons: ../ ../ cauticon.pm noteicon.pm warnicon.pm ../dthelp/fontschemes: ../ help010.fns help014.fns help020.fns .../ help012.fns help017.fns ../dthelp/help/C: ../ ../ HelpKit/ ../dthelp/help/C/HelpKit: ../ ../ HelpKit.pm graphics/ online.hf online.sdl ../dthelp/help/C/HelpKit/graphics: ../ HKdlgQuiOL.tif cauticon.pm noteicon.pm .../ HKfig01.tif grid1.pm warnicon.pm HKbuildOL.bm HKmdlGenOL.tif grid2.pm HKdlgGenOL.tif HKmdlQuiOL.tif grid3.pm ../lib: ../ libDtMail.so@ libDtWidget.so@ libXm.so@ .../ libDtMail.so.1 libDtWidget.so.1* libXm.so.3* bindings/ libDtSvc.so@ libMrm.so@ libXt.so@ dtksh/ libDtSvc.so.1* libMrm.so.3* libtt.so@ libDtHelp.so@ libDtTerm.so@ libUil.so@ libtt.so.1* libDtHelp.so.1* libDtTerm.so.1* libUil.so.3* nls/ [libDtHelp - help viewer lib; DtMail - Mail tool lib; DtSvc - CDE Drag and drop service - I think; DtTerm - ; DtWidget - Those widgets not in libXm (Motif 1.2.3); libMrm, libUil, libXm - same as in Motif 1.2.3; libXt - X11R5 lib; libtt - ToolTalk support; nls - no clue] ../lib/bindings: ../ dg_AViiON intergraph ncr_vt sun .../ doubleclick intergraph17 sgi tek acorn hitachi megatek siemens_9733 xmbind.alias apollo hp motorola siemens_wx200 dec ibm ncr_at sony ../lib/dtksh: ../ ../ DtFuncs.dtsh ../lib/nls: ../ ../ msg/ ../lib/nls/msg/C: ../ dtcalc.cat dtksh.cat dtsession.cat .../ dtcreate.cat dtlogin.cat dtstyle.cat DtWidget.cat dtfile.cat dtlp.cat dtterm.cat Xm.cat dthello.cat dtpad.cat dtwm.cat dt.cat dthelpgen.cat dtqueueinfo.cat libvsm.cat dtact.cat dticon.cat dtscreen.cat ../share: ../ backdrops/ include/ palettes/ .../ examples/ man/ src/ ../share/backdrops/C: ../ Convex.pm KnitLight.pm Paver.pm SkyLight.pm .../ Corduroy.pm Lattice.pm Pebbles.pm Sprinkles.pm Ankh.bm Crochet.pm LatticeBig.pm PinStripe.pm Toronto.bm Background.bm Foreground.bm Leaves.pm RakedSand.bm WaterDrops.pm BrickWall.bm InlayColor.pm NoBackdrop.pm RicePaper.pm Wooly.pm Concave.pm InlayPlain.pm OldChars.pm SkyDark.pm ../share/examples: ../ ../ dtksh/ sys.font.iso types/ ../share/examples/dtksh: ../ EventHandlerTest* SessionTest* WorkProcTest1* .../ ListBounds1* TextCutBuf1* XdrawTest* CallDataTest4* ListItemPos1* TextDisp1* crMovesText1* CallbackTest2* ListPosSel1* TextFXYPos1* ksh93.memo DtCursorTest2* PopupTest* TransEventTest* DtWsTest1* SelBoxResTest* TransTest1* ../share/examples/types: ../ ../ IconBrowse.dt miscActions.dt ../share/include: ../ ../ Dt/ Mrm/ Tt/ Xm/ uil/ ../share/include/Dt: ../ Dnd.h Help.h MenuButton.h TermPrim.h .../ Dt.h HelpDialog.h Session.h Wsm.h Action.h Dts.h HelpQuickD.h SpinBox.h ComboBox.h Editor.h HelpTermP.h Term.h [Includes for widgets in CDE that are not in Motif 1.2.3.] ../share/include/Mrm: ../ ../ MrmAppl.h MrmDecls.h MrmPublic.h ../share/include/Tt: ../ ../ tt_c.h tttk.h ../share/include/Xm: ../ Display.h GadgetP.h RCUtilsP.h TextFSelP.h .../ DisplayP.h Label.h RepType.h TextInP.h ArrowB.h DragC.h LabelG.h RowColumn.h TextOutP.h ArrowBG.h DragCP.h LabelGP.h RowColumnP.h TextP.h ArrowBGP.h DragDrop.h LabelP.h SashP.h TextSelP.h ArrowBP.h DragIcon.h List.h Scale.h TextStrSoP.h AtomMgr.h DragIconP.h ListP.h ScaleP.h ToggleB.h BaseClassP.h DragOverS.h MainW.h Screen.h ToggleBG.h BulletinB.h DragOverSP.h MainWP.h ScreenP.h ToggleBGP.h BulletinBP.h DrawP.h ManagerP.h ScrollBar.h ToggleBP.h CacheP.h DrawingA.h MenuShell.h ScrollBarP.h TransltnsP.h CascadeB.h DrawingAP.h MenuShellP.h ScrolledW.h VaSimpleP.h CascadeBG.h DrawnB.h MenuUtilP.h ScrolledWP.h VendorS.h CascadeBGP.h DrawnBP.h MessageB.h SelectioB.h VendorSEP.h CascadeBP.h DropSMgr.h MessageBP.h SelectioBP.h VendorSP.h ColorObj.h DropSMgrP.h MwmUtil.h SeparatoG.h VirtKeys.h ColorObjP.h DropTrans.h PanedW.h SeparatoGP.h VirtKeysP.h Command.h DropTransP.h PanedWP.h Separator.h WorldP.h CommandP.h ExtObjectP.h PrimitiveP.h SeparatorP.h Xm.h CutPaste.h FileSB.h Protocols.h ShellEP.h XmAll.h CutPasteP.h FileSBP.h ProtocolsP.h TearOffBP.h XmP.h DesktopP.h Form.h PushB.h TearOffP.h XmStrDefs.h DialogS.h FormP.h PushBG.h Text.h XmosP.h DialogSEP.h Frame.h PushBGP.h TextF.h DialogSP.h FrameP.h PushBP.h TextFP.h ../share/include/uil: ../ Uil.h UilDef.h UilSymGl.h .../ UilDBDef.h UilSymDef.h ../share/man: ../ ../ man1/ man3/ man4/ man5/ man6/ ../share/man/man1: ../ dtconfig.1 dtlp.1 ksh93.1 .../ dtconvertvf.1 dtmail.1 tt_type_comp.1 dtaction.1 dtcreate.1 dtpad.1 ttcp.1 dtappgather.1 dtexec.1 dtprintegrate.1 ttmv.1 dtappintegrate.1 dthello.1 dtscreen.1 ttrm.1 dtcalc.1 dthelpgen.1 dtsearchpath.1 ttrmdir.1 dtcm_admin.1 dthelptag.1 dtsession.1 ttsession.1 dtcm_delete.1 dthelpview.1 dtspcd.1 tttar.1 dtcm_insert.1 dticon.1 dtstyle.1 tttrace.1 dtcm_lookup.1 dtksh.1 dtterm.1 uil.1x dtcodegen.1 dtlogin.1 dtwm.1 xmbind.1x ../share/man/man3: ../ .../ ApplicationShell.3x Composite.3x Constraint.3x Core.3x DtActionDescription.3 DtActionExists.3 DtActionIcon.3 ... ... ... ... [And dozens more help pages that I deleted for brevity.] ... ... ... ... tttk_Xt_input_handler.3 tttk_block_while.3 tttk_message_abandon.3 tttk_message_create.3 tttk_message_destroy.3 tttk_message_fail.3 tttk_message_reject.3 tttk_op_string.3 tttk_string_op.3 ../share/man/man4: ../ dtactionfile.4 dtsdlfile.4 dtwmrc.4 .../ dtdtfile.4 dtspcdenv.4 tttracefile.4 ../share/man/man5: ../ DtMenuButton.5 UIL.5x .../ DtSaver.5 dtfilsys.5 Dt.5 DtSession.5 dtterm.5 DtAction.5 DtSpinBox.5 tt_c.5 DtComboBox.5 DtStdAppFontNames.5 tttk.5 DtEditor.5 DtTerm.5 ../share/man/man6: ../ ../ ttsnoop.6 ../share/palettes/C: ../ Charcoal.dp Neptune.dp SoftBlue.dp .../ Chocolate.dp NorthernSky.dp SouthWest.dp Alpine.dp Cinnamon.dp Nutmeg.dp Tundra.dp Arizona.dp Clay.dp Olive.dp Urchin.dp Black.dp Default.dp Orchid.dp Wheat.dp BlackWhite.dp Golden.dp Sand.dp White.dp Broica.dp GrayScale.dp SantaFe.dp WhiteBlack.dp Cabernet.dp Lilac.dp Savannah.dp Camouflage.dp Mustard.dp SeaFoam.dp ../share/src: ../ dtaction/ dtdts/ dtterm/ motif/ .../ dtcalendar/ dthelp/ dtwidget/ template/ README dtdnd/ dtsession/ dtwsm/ tt/ ../share/src/dtaction: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN actions.c ../share/src/dtcalendar: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN attributes.c ../share/src/dtdnd: ../ Dtdnddemo Makefile.IBM Makefile.USL .../ Makefile.HP Makefile.SUN dtdnddemo.c ../share/src/dtdts: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN datatyping.c ../share/src/dthelp: ../ Main.c README .../ Main.h help/ Help.h Makefile.HP helpdemo.app-defaults HelpCache.c Makefile.IBM helpdemoHelpEnv.csh HelpCacheI.h Makefile.SUN helpdemoHelpEnv.sh ../share/src/dthelp/help: ../ ../ Makefile bike.bm helpdemo.htg ../share/src/dtsession: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN session.c ../share/src/dtterm: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN term.c ../share/src/dtwidget: ../ Makefile.IBM README .../ Makefile.NOVELL controls.c Makefile.HP Makefile.SUN editor.c ../share/src/dtwsm: ../ Makefile.IBM README .../ Makefile.NOVELL occupy.c Makefile.HP Makefile.SUN wsinfo.c ../share/src/motif: ../ clipboard/ draganddrop/ .../ dogs/ periodic/ ../share/src/motif/clipboard: ../ Makefile.NOVELL cutpaste.uil .../ Makefile.SUN cutpaste_local.uil Makefile.HP README Makefile.IBM cutpaste.c ../share/src/motif/dogs: ../ DogP.h README bark.bm .../ Makefile.HP Square.c dogs.c Dog.c Makefile.IBM Square.h dogs.uil Dog.h Makefile.NOVELL Square.uil down.bm Dog.uil Makefile.SUN SquareP.h up.bm ../share/src/motif/draganddrop: ../ DNDDemo.h Makefile.IBM README .../ DNDDraw.c Makefile.NOVELL DNDDemo.c Makefile.HP Makefile.SUN ../share/src/motif/periodic: ../ Makefile.NOVELL periodic.c .../ Makefile.SUN periodic.uil Makefile.HP Periodic periodic_local.uil Makefile.IBM README ../share/src/template: ../ Makefile.HP Makefile.SUN TemplateOpen .../ Makefile.IBM README TemplatePrint C/ Makefile.NOVELL TemplateNew template.c ../share/src/template/C: ../ template.dt template.s.bm .../ template.htg template.s.pm README template.l.bm template.t.bm Template.ad template.l.pm template.t.pm example.template template.m.bm template_icon_m.bm template-brush.bm template.m.pm ../share/src/tt: ../ Makefile.HP Makefile.NOVELL README .../ Makefile.IBM Makefile.SUN broadcast.cSubject: 4.4 Is CDE safe/reliable/stable?
I have been using the CDE snapshot (on Sun LX, IPX, SPARC 10, and SPARCserver1000) since it was handed out at the October 1993 CDE Developers Conference. If all pre-release software were this stable, I wouldn't need the "real" stuff. Except for the (very) occasional glitch, CDE has been rock solid for me. I would like to hear how stable it has been for others on other platforms. I am now using the second (4/94) release, which added more functionality such as the calendar and more functional mail. Some parts are still under development. What is present, is stable. There is a warning, however, in the documentation that the APIs are still in flux and that changes may (will likely) occur before the official release. This must be considered before starting any development with CDE. There were several changes in the APIs and file locations/formats from the first to the second snapshot.Subject: 4.5 Is an object-oriented GUI toolkit like Fresco in the
works for CDE? I have not heard anything about Fresco by name, but OpenDoc, OpenStep, and Taligent are on the minds of (i.e., being finacially supported by) those who are the sponsors of COSE. There has not been any public mention of the plans for transition from CDE as it is today to an object-oriented environment, but one is certainly needed since the COSE sponsors are heading down that path. The potential problem is that the new object-oriented environment from Sun (i.e., OpenStep) does not interoperate with the environment from IBM (i.e., Taligent) and that they have a different "look and feel." This is precisely the problem that CDE is supposed to solve. In a session at Xhibition '94, Sun held a developer's meeting in which they described the future desktop environment with CDE windows, OpenStep windows, WABI windows, etc. as a desirable thing. Sun went further to state that (and I am paraphrasing here) that developers could choose between rapid application development (and all the other good things from the object-oriented paradigm) using OpenStep or cross-platform portability with CDE. Of course, it might be nice to have both.Subject: 4.6 How does the CDE relate to Motif 2.0?
At the OSF User Environment Component (UEC) Special Interest Group (SIG) in May 1994, the status of Motif 2.0 and its relationship to COSE/CDE was discussed. As requested by the Motif SIG, Motif 2.0's scheduled release date was postponed until August 1994 so that enhancements and CDE compatibility work could be completed. (Snapshot 3 of the Motif 2.0 Beta was released in May 1994.) After the release of Motif 2.0, OSF will lay off its Motif development team and will not develop any further releases under the RFT processes. Starting a PST process for Motif follow-ons is a possibility. OSF expects that a merger of CDE and Motif into a single PST will happen at some point in the future. The most likely time frame is early to mid 1996. There will be a method to license and fund the two separately. CDE compatibility testing with Motif 2.0 reveals some incompatibilities and mismatched features. This is not surprising since CDE is based on Motif 1.2.3 with enhancements rather than Motif 2.0. The CDE enhancements are designed to increase Motif usability and ease transition from OpenLook. Some of the enhancements impact the look. Others impact the feel and drivability. None of the CDE enhancements change the Motif API, however, so Motif 1.2.3-4 applications should require only a recompilation to be CDE applications. The CDE includes as enhancements to Motif 1.2.3 several items that were to be included in Motif 2.0. For example, the ComboBox and SpinBox, and Gauge widgets from CDE are also in the newer Motif 2.0. An enhanced FileSelectionBox widget (used when opening and saving files) was added to Motif 2.0 from the CDE. Some of the other CDE enhancements can be implemented in Motif 2.0 by using and enforcing pre-existing Motif options and properties. Some CDE components such as the terminal emulation widget and help widget have no counterparts in Motif 2.0. Depending on whether or not shared libraries are used, the CDE and Motif environments can coexist to a varying degree. A dynamically linked Motif 2.0 application can exist in the CDE environment if particular attention is paid to proper installation of the libraries. Problems occur with CDE applications if the Motif shared library is allowed to replace the CDE shared library. If Motif 2.0 applications are statically linked, this problem is avoided and Motif 2.0 functionality is guaranteed in either the CDE or Motif environments. If defaults are used for resources, statically linked Motif 2.0 applications will exhibit most of the CDE behavior. Applications developed against Motif 1.2 will work in the CDE environments and have CDE behavior. The Motif Style Guide has undergone some reorganization for readability, convergence with IBM's Common User Access (CUA) and Windows environments, and alignment with the CDE. CDE enhancements incorporated into the style guide include additional mouse button and menu pulldown capabilities. Allowing cascading menus outside of the menu bar was also added for CDE consistency. Additionally, agreement on the common look and feel for the new ComboBox, SpinBox, and Gauge widgets was agreed upon. Finally, there were additions to the File, Edit, and View menus and Help menu to agree with the CDE's use of these features. The technical draft of the style guide is scheduled to be delivered to X/Open in mid-August 1994. For up-to-date information on the relationship between Motif and CDE, refer to OSF's frequently asked Motif questions at WWW page: http://www.osf.org:8001/motif/MotifFAQ.htmlSubject: 4.7 Can I license the CDE source code so that I can port
it? As mentioned above, the CDE code is being ported to other platforms than the original COSE vendor's hareware. Eventually, the CDE source code should be available from OSF like Motif is today, but the details have not been finalized. In the mean time, the source code can be licensed from any of the COSE vendors directly. However, the only contact I have at the moment is Sandi Jones at Novell. Her number is 408.577.6369. I was not able to get a quote for the costs. TriTeal licensed their CDE source from HP.Subject: 4.8 When is the next CDE Developers Conference?
The first CDE Developers Conference was held in San Jose, CA at the end of October, 1993. There has not been another since. Details about the first conference can be found via WWW or gopher at: gopher://index.almaden.ibm.com:70/0os2dsn/dsnews.93d The COSE developers from this point on will likely use the UniForum conferences for all major announcements and demonstrations as they did the UniForum 95 conference.Subject: 4.9 What is going to be in CDEnext?
(This is based on info from Michael Moore, [mmoore@x.co.uk]. I wasn't able to attend this one myself. Hope you don't mind some plagerism, Michael - cap) At OSFs SuperSIG, representatives of this Group of Seven (and Bob Scheifler from the X Consortium - the likely software house for CDEnext) gave the following features and functionality as goals for CDEnext o Thread safe X and Motif libraries o Complete internationalisation of CDE (Japanese, Chinese, etc) o A Web Browser o A new print paradigm based on Xlib o Motif 2.0 (but throw away anything that breaks backwards compatibility with CDE 1.0) Interestingly, this being OSF, the membership asked about DCE. There are no intentions to scrap ONC+ and make CDE integrate with DCE, something that didn't go down particularly well as you can imagine.Subject: 4.10 How do the COSE vendors maintain common look and
feel? The source code for CDE is maintained as a single source tree at HP in Corvallis, OR. The other vendors download the code nightly and recompile it. Changes to the configuration managed CDE code are managed by a COSE-wide configuration control board. The original code contained a lot of #ifdef statements to account for different vendors architectures, but the number of them have been reduced over time. Since all vendors compile with the same code, a high level of common look and feel is maintained. However, there have been some differences in look anyway, because the same color on different vendors monitors can look quite different. These colors are very user tailorable, so this is not a really big problem in most cases. All vendors are using CDE ToolTalk code/messaging for inter- application communication (for the supplied desktop applications anyway), so some level of interoperability is guaranteed to be available. It remains to be seen how widely this is embraced by COTS vendors, however. The COSE vendors have also all committed to the OMG's CORBA specification. [I believe that all of the COSE vendors are members of OMG, as well.]Subject: 4.11 Will I be able to share my calendars cross
platform/network? [Stolen from alt.windows.cde newsgroup discussion from jonw@austin.ibm.com] Anyone running CDE 1.0 will be able to browse and modify other calendar entries throughout the network. You can setup a calendar server analogous to a mail server or keep each individuals calendar info at their workstation. There is also a tty version that lets you browse and modify calendars from home if access to X is a problem. I have been using the calendar for over a year now and it just keeps on getting better as we near completion. I know of a few folks that are outside of SUN, HP, IBM, and Novell and are looking at interoperability with PDAs and window/mac platforms. Don't know the status here or if it is still happening but it was good to see this type of activity in the ISV community. IBM uses the tty command line version to bubble up a user's calendar on the WEB. The tty programs used to access the calendar are dtcm_lookup, dtcm_delete, and dtcm_insert. These would be familiar to OpenWindows calendar users. On the subject of exchanging calendar information with non-CDE calendars, the calendaring tool backend currently uses ONC/RPC to communicate between calendar services. It is concievable that using the calendaring APIs that any messaging bus could be used at the backend (sockets, DCE/RPC, etc.). However, those new calendar servers would need to act as a gateway to ONC/RPC so that the first round of CDE 1.0 users could participate. When the XAPIA defines the protocol and the delivery mechanism then CDE will be adapted to this. With the attachment model in CDE up and running it is possible to receive calendar appts via mail and then drag that appt onto the calendar to insert into your calendar. For example, a windows platform that supports XAPIA could also do the same. This would at the minimum allow appts to be used regardless of the platform.
Craig A. Prall, Telephone: 703.883.6125 Member of the Technical Staff Fax: 703.883.3315 The MITRE Corporation Internet: cap@mitre.org 7525 Colshire Dr. MS Z267 McLean, VA 22102-3481
Last-modified: 1995/04/11