`
`Windows
`Open Services
`Architecture
`
`
`
`ABB Inc.
`
`EXHIBIT 1010
`EXHIBIT 1010
`
`
`
`Computer Technology Research Corp.
`Page 1 of 165
`Page 1 of 165
`
`
`
`~ s ....
`
`Windows
`Open Services
`Architecture
`
`Jerry Cashin
`i,
`
`Computer Technology Research Corp.
`6 North Atlantic Whart, Charleston, South Carolina 29401-2150 U.S.A.
`Telephone: (803) 853-6460 • Fax: (803) 853-7210 • Telex: 147195
`
`Page 2 of 165
`
`
`
`
`
`OSA
`Windows Open
`Architecture
`
`Page 4 of 165
`
`
`
`
`
`“£8,
`
`wiaggawg fiameia figwfime (:33: gig? ,
`
`RFC :3wa .
`
`.
`
`E
`
`a
`
`.
`
`,
`
`a
`
`.
`
`a
`
`.
`
`.
`
`,
`
`,
`
`.
`
`A
`
`.
`
`‘
`
`.
`
`9
`
`.
`
`.
`
`e
`
`.
`
`‘
`
`4
`
`.
`
`.
`
`t
`
`K
`
`K
`
`.
`
`k
`
`“
`
`9
`
`.
`
`.
`
`.
`
`e
`
`.
`
`‘
`
`,
`
`.
`
`.
`
`a
`
`.
`
`,
`
`.
`
`g
`
`.
`
`9
`
`,
`
`.
`
`,
`
`‘
`
`,
`
`s
`
`.
`
`i
`
`D
`
`a
`
`é
`
`.
`
`g
`
`i
`
`é
`
`g
`
`t
`
`g
`
`,
`
`.
`
`.
`
`,
`
`fl
`
`,
`
`.
`
`.
`
`€31
`
`131
`
`332
`
`Qéiemfiemfl éfiaégi
`
`,
`
`§
`
`k
`
`fi
`
`.
`
`a
`
`.
`
`,
`
`,
`.
`.
`.
`RPS ngeiwmsm E’sisks;
`Ei’éiéi’fé‘iCS Seéiaéiém Laagsage .
`Baitdéng 39$ fixggééiafimg 9
`.
`.
`
`.
`
`b
`.
`s
`
`é
`
`,
`,
`.
`
`.
`
`.
`,
`.
`
`‘
`
`i
`.
`.
`
`.
`,
`,
`
`.
`
`.
`‘
`g
`
`,
`
`,
`.
`.
`
`.
`
`.
`.
`g
`
`,
`
`,
`t
`‘
`
`,
`
`.
`,
`g
`
`‘
`
`.
`.
`,
`
`.
`
`x
`.
`.
`
`‘
`
`.
`K
`.
`
`.
`
`g
`.
`.
`
`r
`
`.
`§
`,
`
`.
`
`s
`.
`.
`
`.
`
`,
`.
`a
`
`,
`
`.
`.
`‘
`
`.
`
`,
`g
`fl
`
`.
`
`.
`
`.
`.
`,
`
`.
`
`.
`
`g
`,
`.
`
`.
`
`.
`
`.
`.
`e
`
`,
`
`.
`
`é
`.
`.
`
`g
`
`.
`.
`,
`
`E
`
`t
`§
`.
`
`.
`
`‘
`.
`‘
`
`i
`
`.
`i
`n
`
`.
`
`.
`f
`t
`
`*
`
`,
`.
`x
`
`.
`
`.
`,
`.
`
`,
`
`.
`Q
`6
`
`.
`
`,
`.
`§
`
`k
`
`€36
`13?
`13$
`
`€43
`
`11.
`
`wénéaws Ewég‘gfimefit Eaéaafiffg .
`
`s
`a
`é
`e
`.
`,
`.
`s
`,
`,
`‘
`x
`.
`‘
`83$€§{§a§é
`Wafiwgg 33:. wags; {33,12 2.x ,
`
`.
`
`.
`
`a
`
`.
`9
`
`_
`
`i
`.
`
`,
`
`.
`.
`
`,
`
`a
`e
`
`.
`
`.
`
`é
`§
`
`.
`
`.
`
`.
`.
`
`.
`
`1
`
`.
`g
`
`y
`
`t
`
`.
`.
`
`.
`
`,
`
`,
`g
`
`.
`
`1
`
`.
`.
`
`9
`
`.
`
`.
`g
`
`i
`
`;
`
`.
`.
`
`,
`
`.
`
`.
`.
`
`~
`
`.
`
`.
`5
`
`.
`
`.
`
`,
`‘
`
`,
`
`a
`
`e
`,
`
`.,
`
`,
`
`.
`k
`
`,
`
`t
`.
`
`‘
`
`.
`.
`
`.
`
`.
`»
`
`.
`
`,
`i
`
`;
`
`9
`i
`
`,
`
`.
`.
`
`a
`
`g
`‘
`
`.
`
`‘
`,
`
`.
`
`.
`3
`
`,
`
`.
`.
`
`K
`
`.
`.
`
`.
`
`é
`g
`
`§
`
`.
`.
`
`.
`
`. mi
`.
`163:3
`
`‘
`
`34::
`
`éééiiégnaé Limétafisng &
`
`Ease a
`
`.
`
`t
`
`.
`
`.
`
`K
`
`,
`
`i
`
`,
`
`.
`
`,
`
`5
`
`a
`
`.
`
`.
`
`.
`
`e
`
`.
`
`a
`
`,
`
`¥
`
`,
`
`‘
`
`‘
`
`.
`
`t
`
`a
`
`i
`
`g
`
`,
`
`é
`
`,
`
`.
`
`.
`
`§
`
`g
`
`.
`
`y
`
`,
`
`i
`
`p
`
`6
`
`g
`
`.
`
`.
`
`.
`
`5
`
`.
`
`v
`
`e
`
`.
`
`.
`
`.
`
`“£45
`
`é??E?§§3§CES
`
`£12:
`a
`{3g
`CE.
`
`E.
`
`{
`.
`,
`$
`g
`.
`5
`5
`5
`g
`.
`.
`e
`a
`.
`,
`g
`;
`.
`§
`$
`K
`*
`a
`é
`9
`E
`.
`a
`SQBS Fgméém gamma}!
`égéfifiwgéaééé “58mg, égscgzéaiefi cmgggg’sgg and flégmafive {azfiséeés
`WE§§8W$ {SF Wsrkgmags a
`.
`.
`,
`,
`.
`a
`.
`§
`a
`,
`.
`.
`g
`.
`.
`,
`a
`.
`g
`.
`a
`.
`,
`‘
`.
`§
`s
`a
`‘
`Iii”? Véfgifi 33$ wéréé .
`§
`§
`g
`‘
`.
`.
`.
`,
`.
`‘
`a
`a
`.
`e
`.
`.
`.
`.
`‘
`A
`.
`.
`w
`.
`.
`.
`.
`t
`a
`3
`.
`§
`
`, mg
`3%
`‘53?“
`35?
`
`;
`.
`
`Eamkiag Systgm Venésr Cegagéi Qantacis ,
`
`.
`
`i
`
`.
`
`a
`
`a
`
`.
`
`*
`
`.
`
`.
`
`.
`
`‘
`
`.
`
`,
`
`,
`
`.
`
`,
`
`i
`
`.
`
`183
`
`Page 6 of 165
`
`€
`
`
`LIST OF FIGURES
`
`51
`
`1
`5,2
`5.3
`5,4
`6.1
`
`.. , , , .. ,. "",."" 74
`of COBe
`Basic
`, . ,. .",
`IOAPI Architecture, , , .... , , ,
`MAPI Facilitator, """ ,
`, ., " " , .,., " .... ".,.
`MAPI Vendors ....... , , , , . ,. .... ....... ..., , .. .,
`MAPI Architecture ... , .. , . , ... , , .... , ...... "
`... ". .,
`Integration of Services. . . . . . . .. ......... ..,
`, .. , . "
`.
`Software Licensing Model
`. , ... ,
`Static Linking ". " . ,
`How an
`
`80
`81
`86
`91
`96
`99
`103
`1
`18
`
`"
`
`. . . .. ..... "
`a
`
`Page 7 of 165
`
`
`
`LIST OF TABLES
`
`. .... 18
`1.1 Evolution of Networking with Windows and Microsoft LAN Manager
`1.2 Vendors Invo lved in Developing Windows SNA API .... .. ......... . . 27
`2.1 Examples of Windows 3.1 Speed Increases (in Seconds) . . . . . . . . . . . .. 35
`3.1 Products of OSF's DCE . ... ... . ...... . ........... . .......... 54
`4.1 Partial list of ODBC Drivers Currently under Third-Party Development . . .. 63
`4.2 ODBC API Conformance Levels .. . ......... .. ..... . . . . . . . . . . . . 66
`4.3 SOL Conformance Levels ........ . ......................... . . 67
`4.4 Early Supporters of the ODSC Specification . . . . . . . . . . . . . . . . . . . . . .. 68
`4.5 Representative SOL Product Offerings .. ..... . .............. . ... 70
`5.1 A Sampling of ISVs Supporting MAPI
`. ... . ......... . . .. ... . .. . .. 83
`5.2 MAPI Function Calls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87
`6.1 Sampling of Operating Systems with LSAPI-related Characteristics . . . . .. 99
`6.2 Vendors Who Support the Job of Defining LSAPI . . . . . . . . . . . . . . . . .. 105
`7.1 Principal Socket System Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
`7.2 Windows Sockets Extensions ..... . . . . . . . . . . . . . . . . . . . . . . . . . .. 115
`8.1 Supported SNA Communications Adapters .... . ................. 121
`9.1 Classes of Financial Devices ..... ... ... . .. .. ...... . .. . .. . .. . 126
`9.2 Basic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 129
`10.1 Sample of MIDL Compiler Options
`. .. ...... . . .. .. . . ... . . .... .. 138
`11.1 Windows 3.x and OS/2 2.x Technology Features .. . . . . . . . . . . . . . . . . 144
`
`v
`
`Page 8 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1. Executive Summary
`
`Figure 1.6 OOSC Architecture
`
`1
`
`Application
`
`ODBC-enabled Applications
`
`ODBC
`
`Sal Server
`
`Rdb
`
`Other
`
`1
`
`Providers
`
`DBMS-specific drivers. A driver manager sits between the applications
`and the drivers, just like a print manager sits between applications and
`print drivers. In the Windows operating system, the driver manager and
`the drivers are implemented as DLLs. Through the ODBC API,
`applications can do the following:
`
`• Establish and drop connections with remote databases.
`
`• Present a standard logon interface to users.
`
`• Find out what tables, views, columns and indexes are
`available on the remote database.
`
`•
`
`Issue commands and retrieve result tables.
`
`If) Computer Technology Research Corp.
`
`19
`
`Page 27 of 165
`
`
`
`
`
`1. Executive Summary
`
`ODBC drivers in the same manner that it accesses other database
`servers. ODBC drivers for IBM databases are under development by
`such companies as Micro Decisionware for DB2 and Rochester Software
`for SQLl400.
`
`ODBC is not a product that users buy. It consists of: a Software
`Development Kit (SDK) for application vendors wishing to take
`advantage of ODBC connectivity; a driver manager available from
`Microsoft; and individual server drivers, available from Microsoft or the
`server vendor, depending on the driver. ODBC is currently available as
`a component of the Microsoft Access DBMS. The ODBC driver manager
`will also be a standard feature of the Windows operating system.
`
`Messaging API
`
`MAPI first appeared as a Windows 3.x subsystem. It is gradually being
`ported to other platforms such as Windows NT, OS/2, Macintosh, and
`MS-DOS. Currently, however, MAPI is optimized for the Windows
`platform, i.e. user interface, memory management, file formats, etc. In
`this sense, it remains a proprietary messaging vehicle.
`
`MAPI has been designed to assure developers who write front-end
`applications or back-end services for their operating environments that
`they will interoperate successfully. This is done by publishing the
`interfaces between these services in the form of APls and SPIs (see
`Figure 1.1).
`
`All of the functionality required for E-Mail front-ends is delivered in
`MAPI by a set of calls to transport, message store, and directory
`services. MAPI provides access to multiple transports and message
`stores. This access is achieved via DLLs written to the MAPI SPI.
`
`Windows platforms supporting MAPI have initially shipped with the
`client mail application entitled Mail Manager. The latter is directly
`accessible to the user or becomes available when a mail-enabled
`application, such as a spreadsheet or word processor, is activated.
`
`© Computer Technology Research Corp.
`
`21
`
`Page 29 of 165
`
`
`
`
`
`1. Executive Summary
`
`License Service API (LSAPI)
`
`The LSAPI is a specification that allows software publishers to build
`licensing capabilities
`into
`their applications while
`remallung
`independent of any specific licensing system or model. This feature
`offers IS managers the flexibility to plug in new licensing services
`without having to modify applications on their client PCs.
`
`WOSA enables LSAPI-compliant applications to interact with licensing
`services transparently in a multivendor networked environment (see
`Figure 1.7). Thus, applications can access licensing systems over a
`variety of networks, easing the development process for programmers
`and increasing installation options for IS managers. Over 20 software
`and system vendors have proclaimed their intention to support the
`LSAPI specification, with more being added on a regular basis. The
`problem addressed by LSAPI began in earnest with the arrival of the
`first PCs into the corporate mainstream. System administrators and
`product vendors have been trying to control and manage the use of
`software applications in this setting ever since, with varying degrees of
`success.
`
`Typically, to help control software usage, vendors ask purchasers to sign
`a license agreement and then enforce the agreement through a number
`of different procedures. However, as the number of license agreements
`grows, the task of ensuring compliance with the variety of terms and
`conditions becomes overwhelming. To ease the burden, a number of
`software products have emerged that track application usage, and some
`of these can electronically enforce the terms of the license agreement.
`Some software publishers incorporate their own license tracking
`mechanisms directly into their applications without relying on third(cid:173)
`party license software.
`
`The result is a complex proliferation of different license systems, each
`with its own non-standard API. The large number of APIs creates higher
`development and maintenance costs for software publishers since they
`must write new code whenever they want to interface to a different
`license system. Likewise, the myriad licensing schemes and applications
`
`<0 Comput8f' Technology Research Corp.
`
`23
`
`Page 31 of 165
`
`
`
`
`
`1. Executive Summary
`
`support for each scheme confuse information systems departments and
`make license management more difficult.
`
`With the License Service API, an application does not need to know
`anything about the type of network in use, the types of computers in the
`enterprise, or the types of license policies available in order to enjoy
`seamless access to a licensing mechanism. As a result, even if the
`network, computers or license policies change, the desktop application
`does not need to be rewritten. In other words, the License Service API
`enables applications to connect to the licensing services they need across
`multiple computing environments in a platform-independent manner.
`
`The LSAPI is not a product of Microsoft or any other software vendor.
`It is a specification that has been developed by a group of software
`publishers and systems vendors for the purpose of standardizing the
`interface to licensing services. The License Service API effort was
`founded by Brightwork Development, DEC, Gradient Technologies,
`Microsoft and Novell. Many other vendors have subsequently become
`involved in the effort.
`
`Windows Sockets API
`
`Developed by the University of California for its Berkeley Software
`Distribution (BSD) version of Unix, sockets are a widely-used
`programming mechanism that supports data exchange over a network.
`A socket is a connection point through which data can be sent and
`received. Originally used exclusively by Unix applications for communi(cid:173)
`cations over TCP/IP networks, a variety of sockets implementations have
`appeared which function in non-Unix environments to allow information
`transfer between Unix applications and their non-Unix respondents.
`
`Window Sockets encompasses both familiar BSD socket routines, along
`with extensions specific to a Windows environment. It is intended that
`Windows Sockets provide a single API to which application developers
`can program and network software producers can conform. Ultimately,
`protocol stacks other than TCPIIP will be supported.
`
`© Computer Technology Research Corp.
`
`25
`
`Page 33 of 165
`
`
`
`
`
`1. Executive Summary
`
`Windows SNA API
`
`This specification defines a standard interface between applications for
`Windows and IBM System Network Architecture (SNA) protocols. An
`application written to these standard interfaces will run without
`alteration over many vendors) SNA connectivity products. This applies
`to any 3.x version of Windows, as well as Windows NT.
`
`Table 1.2 shows over 20 vendors who collaborated in the development
`of Windows SNA API.
`
`Table 1.2 Vendors Involved in Developing Windows SNA API
`
`Andrew Corporation
`Attachmate
`Computer Logics
`Data Connection
`Digital Communications
`Associates
`Easel
`Eieon Technology
`FutureSoft
`IBM
`ICOT
`
`International Computers Ltd.
`Microsoft
`Multi Soft
`NCR
`Network Software Associates
`Novell
`Olivetti
`Siemens-Nixdorf
`Systems Strategies
`Wall Data
`
`Developed by IBM, SNA is the pre-eminent proprietary network model
`for data interchange. The SNA protocol set was designed exclusively for
`use in mainframe-based environments in its early years, but now has
`assumed a more open, peer-to-peer stance. SNA has essentially served
`as the inspiration for all network-layered configurations in use today.
`
`The growth in the personal computer market has created opportunities
`for vendors to produce and market PC-to-mainframe connectivity
`solutions. These solutions offer users a means to access data on a
`mainframe by allowing them, for example, to emulate 3270 terminals on
`their PCs. Many of these vendors also have offered their own APls that
`allow developers to build applications on PCs that exchange data with
`mainframes. Now, through this cooperative effort, a standard Windows
`SNA specification has been defined.
`
`CCl Computer Technology Research Corp.
`
`27
`
`Page 35 of 165
`
`
`
`
`
`1" Executive Summary
`
`with database management, system services, and special purpose
`processing needs.
`
`RPC is also a tool which enables the single PC to extend its reach far
`beyond its own domain. By enabling access to all computing resources
`on the network, RPC provides users with a powerful tool for completing
`tasks and producing solutions.
`
`Microsoft RPC, as with other varieties, makes a remote access procedure
`appear to be a conventional local procedure call. In actuality, it is made
`to a "stub" that interacts with the runtime library and performs all of
`the steps required to execute the call in the designated remote
`environment.
`
`The RPC model is an industry standard, although there are variations
`in implementation. Microsoft's version is similar, although not identical,
`to that put forth by the OSF in its DCE package. Sun Microsystems'
`RPC is yet another popular version.
`
`RPC also renders network interface details transparent to the
`application developer. No longer must he or she understand specific
`network API functions or low-level communications protocols in order
`to build complex distributed applications.
`
`Data translation problems that frequently arise during interaction
`among heterogeneous networks is reduced by RPC usage. Applications
`can now ignore issues of formatting and character structuring, all of
`which is handled during RPC execution.
`
`WOSA Ex ensions For Financial Services
`
`In 1992, Microsoft formed a consortium of firms interested in financial
`services markets in order to standardize the end-user interface. Among
`these organizations were computer vendors, software houses, and
`system integrators. Labeled the Banking Systems Vendor Council, early
`members included Microsoft, Uni sys , Olivetti, DEC, and Andersen
`Consulting.
`
`@ Computer Technology Research Corp.
`
`29
`
`Page 37 of 165
`
`
`
`
`
`1. Executive Summary
`
`Microsoft plans to continue to extend the Windows operating system in
`the future. The system is being enhanced using object-oriented
`techniques to yield improved usability, a more intelligent file system, a
`more intuitive user interface, and more transparent operation in
`connected environments. Users will be able to browse network resources
`using a variety of object attributes such as content, and creation and
`revision dates. Both Windows and Windows NT implementations will
`benefit from these enhancements.
`
`Windows running in enhanced mode with MS-DOS will be extended to
`support the Windows 32-bit API. As part of this evolution, Microsoft will
`enhance MS-DOS over time, reduce memory requirements, add utilities,
`and improve networking support. In this way, the MS-DOS-based
`implementation of Windows running in enhanced mode will be further
`optimized for laptops and desktops, while Windows NT will be
`Microsoft's solution for high-end machines such as workstations and
`servers.
`
`© Computer Technology Research Corp
`
`31
`
`Page 39 of 165
`
`
`
`
`
`Chapter 2
`The Windows Environment
`
`The appeal of Windows lies in its ease of use and universality. Even
`novice users can access sophisticated programs and services. The
`learning curve is moderated by graphical interfaces. Common tasks such
`as file management and printing have been simplified.
`
`Among the graphical tools available are:
`
`• Program Manager. Manipulates and arranges icons in
`order to implement applications.
`
`• File Manager. Manages files and their associated direc(cid:173)
`tories to support user access, manipulation, and consoli(cid:173)
`dation of information repositories (see Figure 2.1).
`
`• Print Manager. Allows users to view print queues,
`change the status of print jobs, and direct output to
`specific printers.
`
`• Control Panel. Sets up communications ports, installs
`fonts, and allows customizing of visual images in terms
`of colors and designs.
`
`Among the desktop applications made available are:
`
`• Terminal. Asynchronous terminal emulation and com(cid:173)
`munications support program that includes a macro
`capability for up to 32 function keys.
`
`• Calendar. Builds a daily appointment schedule and
`monthly
`calendar which
`initiates
`alarms
`as
`appointment reminders.
`
`~ Computer Technology Research Corp
`
`33
`
`Page 41 of 165
`
`
`
`
`
`
`
`
`
`2. The Windows Environment
`
`In Windows 3.1, if a user experiences an application error or general(cid:173)
`protection fault, the Windows operating system:
`
`•
`
`identifies the source of the error.
`
`• provides the user with the option of closing the
`application or returning to the application, so work can
`be saved before closing (if the error was detected as
`being harmless);
`
`• attempts to keep the system running after the error.
`
`If a Windows-based application is malfunctioning, the user can press
`CTRL+ALT+DEL to close the problem applications without closing
`Windows. An error message appears with instructions for closing the
`application, returning to the system, or rebooting the system.
`
`If CTRL+ALT+DEL is pressed when no application is hung, Windows
`sends a warning that advises the user to quit the application with the
`correct Quit or Exit command, or by choosing the Close command from
`the Control menu. This helps guard against losing data when the user's
`system is actually functioning correctly.
`
`Windows 3.1 went through one of the largest beta programs ever
`conducted, involving more than 15,000 participants. Microsoft gave
`developers in the beta programs the SDK and Driver Development Kit
`(DDK) to allow them to implement Windows 3.1 APls for their new
`programs. A Hardware Compatibility Program included over 350 testers
`to ensure compatibility of Windows with a vast array of hardware and
`peripherals on the market today.
`
`Object Linking and Embedding
`
`An important technology for many reasons, OLE creates an environment
`in which applications can share information seamlessly. With OLE, all
`data can be thought of in terms of objects. A spreadsheet chart, an
`illustration, a table, a paragraph of text are all examples of objects. OLE
`enables applications to share these objects.
`
`© Computer Technology Research Corp.
`
`37
`
`Page 45 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Chapter 5
`Messaging API
`
`History
`
`E-mail emerged in the 1960s on various computer timesharing systems
`as users sought new methods of communication. These early initiatives
`were primitive by today's standards, typically involving only a couple of
`day's programming effort. All implementations were, of course, unique
`to their own user group. Little thought was given to potential
`interoperability needs of the future.
`
`In 1969, the Advanced Research Projects Agency Network (ARPANET)
`was created by the U.S. government. It was designed to allow research(cid:173)
`ers within industry and academia to transmit computer data to each
`other, and to initiate program execution on remote systems. If one could
`send computer files , why not shorter messages such as E-mail?
`
`ARPANET's prime contractor developed in 1970 a software vehicle that
`allowed their local mail system to communicate with independent mail
`systems at other ARPANET sites. This contractor, Bolt, Beranek, and
`Newman Incorporated, thus launched the network E-mail phenomenon.
`ARPANET users quickly became dedicated practitioners of messaging
`services. Commercial products gradually became available in the
`ensuing years.
`
`MAPI is not E-mail; it is a facilitator of E-mail. In the years since
`ARPANET, users and other interested parties have searched for a
`universal access (or API) to the voluminous mail offerings that have
`appeared in the marketplace. If an application works with one product,
`it would be beneficial if that same application could send an identical
`message to another mail service without altering parameters in the
`sending application (see Figure 5.1).
`
`~ c omputer Technology Research Corp.
`
`79
`
`Page 86 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`5. Messaging API
`
`It works similar to their print drivers, i.e., different print drivers work
`in conjunction with Windows software, rather than directly with each
`application. This allows applications to function with a variety of
`printers. MAPI's messaging subsystem employs the same approach -
`different messaging applications can communicate with a variety of
`messaging services. MAPI is one of the first to integrate its services into
`the resident operating system.
`
`When an API is initiated, a command or function call is invoked. It tells
`the underlying messaging subsystem what action is required. The mes(cid:173)
`saging subsystem does not replace functionality provided by packages
`such as X.400, Novell's MRS, etc. Rather, it performs services that
`shield the user from the distinctness present in these packages.
`
`In essence, the messaging subsystem performs the following tasks:
`
`• provides common user interfaces for sending, receiving
`and storing messages;
`
`• manages different message stores and address book
`directories;
`
`• controls various communication transports needed to
`move messages among different messaging systems;
`
`• holds messages for later transmission when a message
`system is disconnected;
`
`• sends status
`information
`messaging activities occur.
`
`to applications when
`
`Thus, software developers can create applications that work consistently
`for all users of the operating system. The same basic functionality will
`be present on every desktop. No accommodation has to be made for
`operating system users who may not have a piece of add-on software.
`The messaging subsystem is integral to that same operating system, not
`an implementation afterthought.
`
`@ Computer Technology Research Corp
`
`85
`
`Page 92 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Chapter 6
`License Service API
`
`The arrival of PCs into corporate environs bestowed great benefits on
`users, but also opened up the problem of software licensing. Generally,
`to help control software usage, vendors ask purchasers to sign a license
`agreement and
`then enforce
`the agreement
`through various
`methodologies.
`
`There are three such methodologies that apply to PC software. It can be
`licensed: 1) to the individual, 2) to the machine, or 3) for concurrent use.
`
`An individual license means, as the name implies, that the software is
`licensed to a specific individual. For example, if a network has 30 PCs,
`but only 20 of its users actually run the software in question, then 20
`licenses are required, one for each user. Problems relating to movement
`of the user, etc. are handled uniquely by different licenses.
`
`When software is licensed to a machine, that software is authorized for
`use on a specific device. If a network with 30 PCs has 20 machines with
`the software installed, then 20 licenses must be in place in order to
`maintain legal propriety. If a user decides to install that software on a
`portable device, for example, it must be erased from one of the existing
`PCs, or another license must be purchased.
`
`With a concurrent use type license, the determining factor is the number
`of copies of a software product that are in use at any given point in
`time. For the 30 PC network with 20 users example, if only 15 of the 20
`users run the software at the same time, then 15 licenses are required,
`not the 20 licenses mandated by the two previous license types.
`
`© Computer Technology Research Corp.
`
`93
`
`Page 100 of 165
`
`
`
`
`
`6. License Service API
`
`LSAPI Goals
`
`The LSAPI specification is a vehicle which software publishers can use
`to incorporate license verification into their products, in a manner
`independent of a particular software licensing system. This API allows
`vendors to create a single approach to all licensing systems that support
`LSAPI conventions.
`
`LSAPI minimizes vendor difficulty in implementing software licensing,
`potentially requiring only two function calls to accomplish the task.
`When using LSAPI, the application does not need to know anything
`about supporting infrastructure issues such as type of computers in use,
`or type of network. Instead, the application can connect to all licensing
`services needed across multiple computing environments in a platform(cid:173)
`independent manner.
`
`Figure 6.1 depicts a software licensing model in its totality. It also
`shows the model as it would operate in a client/server, networked
`environment. In a single system situation, both server and client entities
`could reside on the same platform. LSAPI deals solely with the interface
`between 1 and 2 in the Figure. Components numbered 3, 4, and 5 deal
`with the licensing system itself, along with its management, terms, and
`conditions.
`
`The specific goals of LSAPI are many, but perhaps the most
`fundamental is: Help the honest person remain honest. Other more
`precise goals are:
`
`• Provide a
`relatively simple API which software
`It should be
`developers can use
`for
`licensing.
`appropriate
`for a diverse audience of software
`publishers, licensing schemes, operating systems, and
`network configurations.
`
`• Support application interfaces
`systems.
`
`to multiple
`
`license
`
`© Computer Technology Research Corp.
`
`95
`
`Page 102 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`7, Windows Sockets API
`
`processing. There are no intermediate layers or steps incurred when a
`Socket system call is invoked.
`
`It is negative in terms of adaptability. Changes to Socket functionality
`or underlying protocol stacks requires modifying the core of the
`operating system - the kernel. This is the antithesis of openness and
`non-modularity, and is the downside of Socket integration into the
`kernel. The other API to the transport protocols (TLl) ameliorates this
`close-knit protocol association and allows broader protocol interaction.
`
`Berkeley Deviations
`
`the BSD Unix
`to
`As cited earlier, WinSock adheres closely
`implementation of Sockets. There are some deviations that have
`occurred, however, due to the unique requirements of a Windows
`environment. They include the following:
`
`• A new data type (Socket) has been defined in order to
`anticipate file needs in future Windows releases such as
`NT. It will also aid in porting applications from 16-bit
`to 32-bit configurations.
`
`• Error codes set by WinSock are handled differently
`than in BSD implementations. The latter makes them
`available by the global "ermo" variable. An API is
`utilized in WinSock which makes it more adaptable to
`future Windows evolutions.
`
`• All pointers used by WinSock applications are of one
`facilitate
`this, new data
`type
`type. To
`specific
`definitions have been provided.
`
`• Some BSD function names have been altered due to
`duplication with Windows API names.
`
`• WinSock uses a special command to close Sockets since,
`unlike BSD connections, Socket descriptors do not
`always correspond to their file counterparts.
`
`<0 Computer Technology Research Corp.
`
`113
`
`Page 119 of 165
`
`
`
`
`
`
`
`
`
`
`
`8. Windows SNA API
`
`relieving desktop PCs from many resource· consuming tasks. SNA Server
`offers numerous tools which facilitate system setup and use, regardless
`of the platforms and operating systems present in the SNA network.
`
`Some of the key features of SNA Server include:
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`•
`
`it can connect products such as Microsoft Mail and SQL
`Server to mM host mail and database systems
`
`it supports all WOSA SNA APls for Windows and
`Windows NT operating systems
`
`it supports 3270 and 5250 emulators for Windows, NT,
`DOS, OS/2, and Macintosh operating systems from
`vendors such as Attachmate, FutureSoft, Eicon
`Technology, DCA, Wall Data, and IBM
`
`it supports APPC, CPI-C, CSV, LUO and HLLAPI APIs
`in each client
`for advanced SNA applications
`environment
`
`it provides SNA session security and fault tolerance
`
`it supports client PCs across LAN and wide area
`network (WAN) bridges, routers, and NT's Remote
`Access Service (see Figure 8.2)
`
`it performs automatic load balancing in order to
`efficiently distribute workload
`
`it supports a wide variety of LAN protocols (802.2,
`IPXJSPX, TCPIIP, NetBEUI)
`
`it uses the C2·1evel security of NT to safeguard corp·
`orate data on the host. C2 is a U.S. government-defined
`security category which aids in protecting information
`resources
`
`•
`
`it supports NT platforms such as those based on Intel,
`Alpha, and MIPS processors
`
`e Computer Technology Research Corp.
`
`119
`
`Page 124 of 165
`
`
`
`
`
`8. Windows SNA API
`
`automatic data-link alerts. Bidirectional transmissions to and from
`NetVieware attained via API support. It is also possible to initiate NT
`commands at the NetView console.
`
`SNA Server device interface driver support is provided for by the
`adapters shown in Table 8.1. Support for additional adapters is supplied
`by the adapter manufacturers themselves.
`
`Table 8.1 Supported SNA Communications Adapters
`~g~P~~!::··"i, : _.: .. "S·;Ul;::\;!L
`~ J::~: .
`IBM 3278/9 Emulation Adapter
`
`Connection
`
`Distributed Function Terminal (OFT)
`
`IBM 3278/9 Advanced Emulation Adapter
`
`OFT
`
`IBM MPCA
`
`IBM SDLC Adapter
`
`IBM 3270 Connection Model A
`
`IBM 3270 Connection Model B
`
`IBM MPAIA
`
`Any NT supported Token Ring or Ethernet
`Adapter
`
`Synchronous Data Link Control
`(SDLC)/X.25
`
`SDLC/K25
`
`DFT
`
`DFT
`
`SDLC/X.25
`
`802.2
`
`Windows NT offers an advantageous platform for PC to host
`connectivity. SNA Server for Windows NT enables users to implement
`multiple SNA connectivity products without changing application logic.
`
`Future Trends
`
`Windows SNA API is an important part of the overall WOSA model.
`SNA remains the most widely installed proprietary network in the
`world. This standard interface to the SNA environment from Windows
`platforms enables Microsoft to make further inroads into enterprise
`computing. At the same time, it strengthens SNA itselfby opening it to
`a wider audience.
`
`~ Computer Technology Research Corp.
`
`121
`
`Page 126 of 165
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`10. Windows Remote Procedure Call API
`
`and auxiliary files, plus a header file for the client and server. This
`header file is appended to client and server applications.
`
`A server program is created that can both signal the client as to its
`availability, as well as monitoring subsequent client requests. A server
`termination routine must also be included.
`
`Perhaps the most important step associated with the RPC process is
`functional linking. Both the client and server entities must be linked
`with their respective stubs, auxiliary files, and runtime libraries.
`
`Interface Definition Language
`
`The IDL, specifically Microsoft's version, shown in Figure 10.3 provides
`the features needed to extend the C programming language in order to
`support remote procedure calls. MIDL is not just a variant of C. Rather,
`it is a formal language that handles control of data transmission over
`a network. Due to its simila