WOSA/XMC MCAPI and MCSPI
`
`ANALYSIS SPECIFICATION
`
`Revision:
`Author:
`Date:
`Project:
`Project Location:
`Document Name:
`Description:
`
`Second Draft
`Dave Brown
`Friday, July 15. 1994
`MOTlON.100
`\\rgbsrvr_2\master\cmpnt
`\doc\ana\ana__2\analysis.doc
`This document describes the summary business plan for the Motion Control WOSAIXMC
`MCAPI/MCSPI working model and specification.
`
`Revision History: 4/15/94 (DB)
`7/1 5194 (DB)
`
`Initial writing.
`- First Draft:
`- Second Draft: Split analysis off small business plan, incorporated suggestions.
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BIV Corporation. All rights reserved.
`
`ROY—G—B|V CORPORATION
`
`EXHIBIT 2010-2
`
`ABB V ROY—G—B|V
`
`TRIAL |PR2013—00O62
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGBO0055881
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`This is a preliminary release of the documentation. It may be changed substantially prior to final commercial release. This
`document is provided for discussion purposes only in strict confidence and subject to the non-disclosure agreement executed
`between ROY-G-BIV Corporation and Compumotor, a division of Parker Hannifin on, dated May 19, 1994.
`
`ROY-G-BIV, WOSAlXMC, MCAPI, and MCSPI are trademarks of ROY-G-BIV Corporation.
`
`Microsoft, Microsoft Visual C++, Microsoft Visual Basic, WIN32, and Microsoft Excel 5.0 are registered trademarks and
`Windows, Windows NT, WIN32s, WIN32c, and OLE are trademarks of Microsoft Corporation.
`
`Borland and Borland C++ are trademarks of Borland International, Inc.
`
`Printed in the United States of America.
`
`•
`
`•
`
`•
`
`ROY-G-BIV Corporation Confidential.
`© 1994 ROY -G-BIV Corporation. All Rights Reserved.
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055882
`
`2
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`•
`
`• Table of Contents
`
`2.0 Project Vision
`
`TABLE OF CONTENTS .............................................................................................................................. i
`
`1.0 OVERVIEW ............................................................................................................................................. 1
`
`1.1 DEFINITIONS ............................................................................................................................................... 1
`
`2.0 PROJECT VISION ................................................................................................................................. 3
`
`2.1 PROJECT GOAL .......................................................................................................................................... .3
`2.2 PROJECT BENEFITS ..................................................................................................................................... 3
`2.3 SOFTWARE MODEL. ................................................................................................................................... .4
`2.4 PROJECT STRATEGY ................................................................................................................................... 5
`2.4.1 Project Phases .................................................................................................................................... 6
`
`3.0 DEVELOPMENT .................................................................................................................................... 8
`
`3.1 DESIGN GOALS ........................................................................................................................................... 8
`3.2 TARGET PLATFORMS .................................................................................................................................. 8
`3.3 FOUNDATION SOFTWARE TECHNOLOGY USED ........................................................................................... 9
`3.3.1 OLE 2.0 ............................................................................................................................................... 9
`3.3.2 WIN32 ................................................................................................................................................. 9
`
`4.0 MARKETING ........................................................................................................................................ 11
`
`• 4.1 STRATEGy ................................................................................................................................................ 11
`
`4.2 MATERIALS .............................................................................................................................................. 11
`4.3 METHODS ................................................................................................................................................. 12
`
`5.0 INTEGRATION .................................................................................................................................... 12
`
`•
`
`ROY -G-BIV Corporation Confidential
`© 1994 ROY-G-B1V Corporation All rights reserved.
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055883
`
`3
`
`

`
`..
`•
`
`•
`
`•
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`1.0 Overview
`This document describes the WOSA API/SPI software model and specification, otherwise known
`as the WOSA extension for Motion Control or WOSAIXMC, which is a software model used by
`software applications to control motion control hardware. The model gives each application a
`hardware independent motion control solution. In addition to hardware independence, the model
`is easily extensible for new motion control hardware.
`
`The goal of this document is to create a foundation for a standardized motion control software
`model. Four main sections, described below, outline the goals of the model, how it is to be
`implemented, and how it will be introduced to the market. The main sections are the following:
`
`Project Vision - Included in this section are the overall project goal, a high-level description of
`the software model designed to fulfill that goal, and the planned path to bring the developed
`software to market.
`
`Development Plan - This section discusses general software design issues. Included in this
`section are general disscussions of the design goals, target platforms, and the foundation
`technology used. This se6tieR E!is6l:lsses the sefu'lare E!esigR iR E!etail. IRsII:lE!eE! iR this sestisR are
`E!essrifltieRs efthe FRam ebjests iR the systeFR, hew they iRtera6t with eash etiler, aRE! tile OLE 2.Q
`iRterfa6es the~' Sl:lflfleFt, whi6h m611:lE!e sfle6ifisatieRs far beth the FRetieR 6eRtrei at3flli6atieR
`flregraFRFRing iRterfa6e salleE! MCAPI aRE! the FRetieR 6eRtrei sePo'i6e flreyiE!er iRterfa6e 6alleE!
`MCSPI.
`
`Marketing Plan - In this section, the overall marketing plan is discussed, which includes
`describing the marketing strategy, the methods of marketing to be used, and the marketing
`materials needed for each method.
`
`Integration Plan - This section discusses the methods used to integrate the model with both new
`motion control hardware vendors, and new motion control application developers.
`
`1.1 Definitions
`WOSA - Windows Open Service Architecture - this is the Microsoft open service model
`supported by Microsoft Windows to allow third party vendors a method of consistently extending
`Microsoft Windows.
`
`WOSAlXMC - WOSA extension for Motion Control - this is the extension for Microsoft
`Windows used to manipulate and control Motion Control hardware.
`
`MCAPI - Motion Control Application Programming Interface - this is the specific set of functions
`called by applications using Motion Control. The Motion Component provides the majority of the
`MCAPI functions, which are all hardware independent. Several functions in the MCAPI, used to
`access the current driver environment, are provided by the Motion Control Driver Administrator.
`
`MCSPI - Motion Control Service Provider Interface - this is the specific set of functions called by
`the Motion Component supporting the MCAPI. Each MCSPI software driver is hardware
`dependent for it directly communicates with a specific hardware implementation using the
`hardware implementations motion control language and communication registers or ports.
`
`Motion Driver Administrator - The Motion Driver Administrator is an independent Windows
`application used to install/remove Motion Device Drivers. The user may also toggle API
`diagnostic logging, for debugging, through the Motion Driver Administrator. In addition to
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-B1V Corporation All rights reserved.
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055884
`
`4
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`providing driver management services to the user, the administrator is used by all applications,
`using the WOSAlXMC software, to access the current Motion Device Driver environment. This
`environment is later used in conjunction with the Motion Component to control specific motion
`control hardware. The environment creation functions make up a small subset of the MCAPI
`mentioned above.
`
`Motion Component - All applications using the WOSAlXMC software model communicate
`directly with the Motion Component. The Motion Component is a hardware independent
`implementation of the motion control abstraction specified by the MCAPI. Both the functions
`supported by the Motion Component and those supported by the Motion Driver Administrator
`together make up the MCAPI.
`
`Motion Driver - The Motion Driver is the actual hardware dependent software driver that uses the
`motion control command language to communicate with the motion control hardware that
`supports it. Every Motion Driver supports a set of functions called core functions. These are
`primitive functions required by all motion applications. The core functions are a subset of the
`MCSPI. The remaining set of MCSPI functions are called extended functions and are not required
`to be implemented.
`
`Motion Driver Stub - The Motion Driver Stub is a secondary Motion Driver supplied to support
`all MCSPI extended functions not supported by the Motion Driver. A software algorithm is used
`to implement the functionality that doesn't exist in the underlying motion control hardware.
`
`..
`
`•
`
`•
`
`•
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BiV Corporation All rights reserved.
`
`2
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055885
`
`5
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`2.0 Project Vision
`This section describes the overall vision of the motion component, a high level description of the
`software model, and an overall strategy to bring the project to market.
`
`2.1 Project Goal
`The overall goal of the MCAPIIMCSPI WOSA extension for Motion Control (WOSAlXMC)
`model is to create and standardize a hardware independent, software interface used to manipulate
`motion control hardware in the motion control industry.
`
`Such a solution will broaden the motion control software market from applications that only
`support one specific hardware vendor's motion control implementation to that of all hardware
`vendor's supporting the model. This will vastly increase the value of the motion control software
`built on the software model.
`
`In order to fulfill this vision, the model must be easy to integrate into motion control applications.
`An easy application integration path will be provided by supporting current popular software
`development tools such as Microsoft Visual C++, Borland C++, and any high-level language or
`macro language supporting OLE 2.0 Automation such as Microsoft Visual Basic 3.0 or Microsoft
`Excel 5.0.
`
`2.2 Project Benefits
`There are several benefits of the WOSAlXMC software model that will help hardware vendors
`implementing motion control hardware, software developers creating motion control software
`applications, and end users operating motion control software applications. The benefits for each
`are described in this section.
`
`Hardware Vendors - Hardware vendors who want to add support for Windows 3.1, Windows
`NT, and future versions of Windows, to their motion control hardware will benefit from much
`lower development costs. In order to become a participant in the WOSAIXMC software model,
`each hardware vendor need only create a Motion Driver that supports the MCSPI. If a hardware
`vendor has several different hardware implementations, again they only need to create MCSPI
`Drivers for each one. Each hardware vendor will save the effort of developing both the Motion
`Component and the Motion Driver Administrator which both provide the hardware independent
`solution to applications.
`
`Software Developers - Software developers will benefit by having a hardware independent
`solution for motion control. Instead of focusing on the intricacies of a particular hardware
`implementation, the software developer will be freed to focus on the actual motion control
`problem at hand.
`
`End Users - End users will benefit for now they will have a hardware independent motion control
`solution to run their motion control applications on. If one particular implementation of hardware
`is not optimal for their application, they can easily plug in a different hardware implementation
`that implements more motion control hardware functionality, without having to purchase a
`different software application for the new hardware.
`
`•
`
`•
`
`•
`
`ROY-G-BIV Corporation Confidential.
`© 1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`3
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055886
`
`6
`
`

`
`• •
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`2.3 Software Model
`The general WOSAlXMC model consists of four main entities which include the Hardware
`Administrator, the hardware independent Motion Component supporting the MCAPI, the
`hardware dependent Motion Control driver supporting the MCSPI, and finally the applications
`that run use the Motion Component to solve motion control problems. As you will see in section
`3.0 Development, the model below is a high-level model describing the main entities in it and how
`they interact. Users can easily plug-n-play hardware device drivers in and out of the system,
`without affecting the software running on the model.
`
`-----r-----
`------------------------
`Motion ontrol
`M
`I
`Hardware
`Implementation t#1
`
`I
`
`I
`,
`
`---------,----------~--
`Ion Control
`Motion Control
`I
`Hardware
`Hardware
`Implementation t#3
`Implementation t#2
`
`I API Layer
`
`I SPI Layer I
`
`I Hardware
`
`•
`
`•
`
`Figure 1 General WOSA API/SPI Model known as WOSNXMC
`
`Applications directly communicate with the Driver Administrator and Motion Component. The
`MCAPI provides the communication link between the applications and the Driver Administrator
`and Motion Component. The Driver Administrator is used by the application to access the correct
`driver state data which is then passed on to the Motion Component for all further motion control
`interaction. From the applications perspective, all motion interaction is independent of the actual
`hardware implementation carrying out the requested actions. For example, if the Application
`wants to request the motion hardware to tune the servo settings, it invokes one of the Motion
`Component's functions to do so. The application doesn't need to know what hardware is being
`tuned. In some cases, the hardware may not even support servo tuning. When ever an MCSPI
`function is not supported directly by the hardware, as in the Tuning example, the Motion
`Component calls the Motion Driver Stub which then attempts to carry out the functionality
`requested by calling required, core MCSPI functions located in the Motion Driver.
`All MCSPI supporting Motion Drivers are required to implement a core set of functions to
`participate in the WOSAIXMC model. Depending on the hardware support for motion control
`functionality, many Motion Drivers will support some or all of the extended interface supported
`by the Motion Driver Stub, increasing motion control efficiency.
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BiV Corporation All rights reserved.
`
`4
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055887
`
`7
`
`

`
`• •
`
`•
`
`•
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`For example, consider the following scenario:
`A.
`
`I MCSPI Stub I
`
`3 Since the Hardware supports
`Countour Moves, the MCSPI
`directs the hardware to carry
`out the contour move.
`
`Hardware
`
`Figure 2 MCAPI, MCSPI, and MCSPI Stub Interaction
`
`As shown in diagram A of Figure 2 above, the Application calls the MCAPI Contour ()
`function to perform a contour motion. The MCAPI in tum, calls the MCSPI driver's
`Contour () function. Since the hardware driven by this particular MCSPI implements contour
`moves, the MCSPI function sends the appropriate hardware language statements to the hardware
`telling it to perform the contour move. On the other hand, in diagram B of Figure 2 above, when
`the MCAPI Contour () function calls the MCSPI driver Contour () function, the MCSPI
`notifies the MCAPI that it cannot perform the operation because it is not supported by the
`hardware. After being notified of the hardware deficiency, the MCAPI calls the MCSPI driver
`Stub to perform the requested action through a less efficient software algorithm. The MCAPI
`calls the MCSPI driver Stub's Contour () function which follows the contour path and
`incrementally calls the MCSPI's MoveAbs () function which is a core function.
`
`Every MCSPI supporting Motion Control driver must support the core MCSPI functions in order
`to participate in the WOSAlXMC model. Core functions are all functions absolutely necessary to
`solve a motion control problem. Hardware initialization, Moving, and Stopping, are a few
`examples of core motion control functions. In addition to supporting a core functions, the MCSPI
`may support several or all of the extension functions. Extension functions are all functions that
`can be performed by sequencing together core functions to carry out the requested action. For
`example, Contour () , CurveTrace () , and MoveRel () are extension functions for each
`requested action can be performed through a software algorithm that uses core functions to carry
`out the action on the motion control hardware. Of course the software solution of an action
`provided by the MCSPI driver Stub will me much less efficient than one directly supported the
`motion control hardware. The core and extension MCSPI are discussed in more detail in 3.0
`Development.
`
`2.4 Project Strategy
`The overall project strategy is to create the WOSAlXMC software in a way that not only targets
`each of the various evolving Windows platforms, but does so in a way that encourages hardware
`vendors to participate in standardization process. Particular target Windows platforms will help
`entice each hardware vendor to participate. The following are the planned target environments for
`the model:
`
`• Version 1.0 targets Windows NT 3.1lDaytona and Windows 3.1 through WIN32s.
`• Version 1.5 targets Windows 4.0/Chicago.
`• Version 2.0 targets Windows NT 4.0/Cairo.
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY -G-BIV Corporation All rights reserved.
`
`5
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055888
`
`8
`
`

`
`..
`•
`
`•
`
`•
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`But having access to the fmal software making up the MCAPIIMCSPI WOSAlXMC model is not
`enough to entice each hardware vendor to participate in the open forum. Participating hardware
`vendors will be able to learn and integrate pre-release software making up the model. In addition
`participants are encouraged to actively give feedback on improvements necessary for the model to
`better work with their implementation of motion control hardware.
`
`ROY-G-BIV
`Corporation
`
`InItial Specification
`
`Improvements, New
`
`Vendor
`
`<f'~'~ :>
`
`Venlon 1.0 S cIfIcatlon
`
`WOSAIXMC,
`MCAPI,
`MCSPI
`nefinition
`
`Manage
`WOSAIXMC,
`MCAPI,
`MCSPI
`evolution.
`
`Develop
`WOSAIXMC
`MCAPlfor
`WindosNT
`
`nevelop
`MCSPI
`supporting
`drivers for
`WindosNT.
`
`2.4.1 Project Phases
`There are several planned phases in the WOSAlXMC software model. Before describing each
`individual phase an overall phase cycle is described. Figure 3 describes the general evolution of
`each phase in the WOSAlXMC model evolution: As a rough outline, the general phase cycle
`begins with the feature specification for the target version of the software. Next, through
`interaction with all participants in the
`forum, the specification will begin to
`evolve and eventually solidify. Once
`the specification becomes relatively
`solid, development of the software
`begins. Pre releases are passed out to
`all participants who in tum should
`respond with any bug reports found in
`the software. After the software
`development reaches a code freeze, a
`structured testing process begins. All
`the while, participants are encouraged
`to send in improvement and bug
`reports. After the structured testing is
`completed, the software will be ready
`for a final release. And, after the fmal
`release, a post-mortem process is
`started to evaluate the overall phase
`and decide how to improve it before
`the next phase begins. The following
`describes each of the three planned
`phases:
`
`and Wi032S·C' ;::' ~~~Pr~e~-A~I~h~a~R~el~ea~s~e ;::--~E:=J
`
`Driver AdmInIstrator,
`MCAPI, and MCSPI driven.
`
`DevclopMC!
`supporting dri
`
`Integrate WO
`software into
`control softw.
`applications.
`
`Phase I.
`During this phase we plan to
`collaborate with several key motion
`control hardware vendors to improve
`and integrate version 1.0 of the WOSA
`extension for Motion Control. The
`target software platforms are both
`Windows NT 3.1lDaytona and
`Windows 3.1 through WIN32s. At this
`time, the participating hardware
`vendors should both participate in the
`MCAPI and MCSPI evolution and start
`integrating the software model into
`their current motion control software
`applications. If possible, hardware
`vendors will also be encouraged to
`integrate current software drivers into
`ones supporting the MCSPI.
`
`structured
`Testing,
`Bug fixes.
`
`A ha Release
`Driver Administrator,
`MCAPI, and MCSPI
`driven for Windows NT 3.1.
`
`Beta Release
`Driver AdmInistrator,
`MCA-PI, and MCSPI
`driven for Windows NT 3.1.
`
`Bug Reports
`
`f'
`
`r~==}-1Fm~al~R~e~le~as~e~v~era;l~on~1.~0~~~~
`Maintenao"
`Driver AdmInistrator,
`MCAPI, and MCSPI
`Releases
`drivers for Windows NT 3.1.
`Post-Mortem Reports
`to improve process,
`communication, etc.
`
`Preparation for
`next Phase.
`
`<a tic'
`Figure 3 General Phase Cycle
`
`Application B
`
`ApplictionM
`
`Distrihution
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BIV Corporation All rights reserved.
`
`6
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055889
`
`9
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`Phase II.
`During this phase we plan to open the forum to more hardware vendors and several application
`developers specializing in the motion control industry. Again, feedback from all participants will
`be important in order to evolve the MCAPI and MCSPI towards a standard. At this time, version
`1.5 of the model will come to fruition with full backward compatibility to version 1.0. This
`version wiII add support for an additional target software platform, Windows 4.0 or otherwise
`known as Chicago.
`
`Phase III.
`During this phase we plan to continue opening up the forum to hardware vendors and application
`developers. Feedback from all participants wiII continue to shape the MCAPI and MCSPI which
`should be fairly stable by this time. Version 2.0 will be created in this phase and support will be
`added for Windows NT 4.0 known as Cairo. At this time Client/Server remote access will also be
`added to the model.
`
`•
`
`•
`
`•
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY-G-BIV Corporation All rights reserved.
`
`1
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055890
`
`10
`
`

`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`3.0 Development
`
`3.0 Development
`This section describes the general design goals target software platfonns and foundation
`technologies used to build the Motion Software Component For a detailed description of the
`Motion Software Component's internal design see the Motion Control Component Design
`Specification document.
`This seetieR Eleseriees the ElesigR geais, target seft' .... are piatferms, sefu'l'are ElesigR, anEi iRterfaee
`speeifieatieRs efthe 'HOSAlXHC seftware lReElel.
`
`3.1 Design Goals
`The following are the design goals to the WOSAlXMC software model:
`
`1. Hardware independent software solution for motion control.
`2. Easily integrated into high level languages such as Visual Basic and Excel's App Basic.
`3. Binary compatibility on the Windows NT, Windows 3.1, and Chicago platforms.
`4. Full OLE 2.0 support and enabling.
`5. Easily extensible for new hardware and new hardware features.
`6. Optimal performance on all platforms supported.
`
`Of the above goals, the top two are critical to create a path toward standardizing WOSAIXMC
`solution for motion control applications. A hardware independent solution wi!! open up the
`motion control market, and giving high level languages easy access to the model wi!! help it
`proliferate in the broadened market.
`
`3.2 Target Platforms
`Currently there are four main target platforms, of which two exist today. Windows 3.1, Windows
`NT 3.1 are target platforms currently out in the market. Chicago, a future release of windows wi!!
`be a critical target platform for it wi!! change the software model provided by supporting a deep
`integration of OLE 2.0. Finally, Cairo, a future version of Windows NT 3.1 wi!! be targeted.
`Cairo, wi!! bring NT up to date with the changes implemented in Chicago. See figure 4 for a
`description of the planned target order for each software entity in the WOSAlXMC model.
`
`Motion Control
`Driver Administrator
`ay
`In
`S
`(W1N3VOLE2.0)
`
`Motion Componmt
`(MCAPI)
`ayona
`In
`S
`(WIN3VOLE2.0)
`
`Motion Control Driver
`Stub
`ayona
`S
`III
`(WIN3VOLE2.0)
`
`Motion Control Driver
`(MCSPI)
`
`s.
`III
`(WIN 16/0LE2.0)
`
`ay
`In
`(WIN3VOLE2.0)
`
`~OWS3.1
`
`(WINI6/0LE2.0)
`
`~WS3.1
`
`(WINI6/0LE2.0)
`
`~S3.1
`
`(WIN 16/0LE2.0)
`
`Oiicago
`(WIN3VOLE2.0)
`
`Cliicago
`(WIN3VOLE2.0)
`
`Cairo
`(WIN3VOLE2.0)
`
`Cairo
`(WIN3VOLE2.0)
`
`Cairo
`(WIN3VOLE2.0)
`
`'1=igure 4 WOSNXMC Target Platforms
`
`NOTE: Currently the PC Bus is the assumed motion control hardware target. Since the WOSAlXMC model
`supports Windows NT, other hardware busses can be easily integrated into the overall model.
`
`•
`
`•
`
`•
`
`ROY -G-BIV Corporation Confidential.
`© 1994 ROY-G-BIV Corporation. All Rights Reserved.
`
`8
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055891
`
`11
`
`

`
`•
`
`•
`
`•
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`3.3 Foundation Software Technology Used
`There are two foundation software technologies that the WOSAlXMC software model is built on.
`Both technologies are fairly new and have been included in the latest released of both Windows
`3.1 and Window NT 3.1. In specific, the technologies are OLE 2.0 and WIN32. This section
`describes what each technology is and what the benefits are to using them.
`
`3.3.1 OLE 2.0
`OLE, which stands for Object Linking and Embedding, is a component based technology that uses
`standardized software interfaces to communicate with software entities in an object oriented way.
`Each software entity or component is an object. As in most object oriented languages, each OLE
`object has data and methods that operate on the data. Although, OLE is a little different that
`standard object oriented languages such as C++ or Smalltalk in that only Interfaces ,or groups of
`standardized functions, are exposed to software that communicates with the object. No data is
`exposed. Data is only manipulated within the internals of the object. This model decouples the
`software component from the application using it, which makes the component more reusable in
`other applications.
`
`Microsoft is making a significant effort to adopt the OLE Component Object Model in future
`versions of Windows. For example, Chicago, the next major release of Windows, will contain
`OLE extensively throughout its operating system. According to the main message projected at a
`recent Microsoft Strategy seminar, OLE is the future of Windows.
`
`Several benefits to building the WOSAIXMC model on top of OLE 2.0 technology are listed
`below:
`
`•
`
`Future versions of the Windows and Windows NT operating systems are moving towards
`completely supporting OLE 2.0 technology. Eventually Windows operating systems,
`will be completely implemented with OLE technology. For example, Chicago has
`complete OLE 2.0 support and Cairo a future of Windows NT will be completely
`implemented using OLE technology.
`• By supporting OLE 2.0 it will be much easier to hook into the operating system. For
`example, to add support for operations such as drag and drop, an OLE Component need
`only implement the IDragSource OLE 2.0 interface.
`Supporting OLE 2.0 will give high level programming languages such as Visual Basic
`and Microsoft Excel 5.0 easy access to the component. For example, by implementing
`the IDispatch OLE 2.0 interface, high level languages can automatically create and
`manipulate the component.
`The OLE Component Based model makes software more reusable by decoupling the
`software component from each application that uses it.
`
`•
`
`•
`
`3.3.2 WIN32
`WIN32 is the application programming interface used to program 32 bit Windows programs.
`WIN32 is a superset of the original Windows API that allows 32 bit applications written for
`Windows NT to run on Windows 3.1 through WIN32s. WIN32s implements a thunking layer that
`translates WIN32 calls made by the 32 bit application to the corresponding 16 bit, Windows 3.1
`API function.
`
`WIN32 is as much a future of Windows as OLE 2.0, mentioned above. For example, Chicago, the
`next version of Windows 3.1, will be a 32 bit operating system that implements a large subset of
`WIN32. Currently, Windows NT implements the full set of the WIN32 API.
`
`ROY-G-BIV Corporation Confidential
`© 1994 ROY -G-BIV Corporation All rights reserved.
`
`9
`
`7/24/94
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055892
`
`12
`
`

`
`WOSAIXMC MCAPI and MCSPI Analysis Specification
`
`2.0 Project Vision
`
`Several benefits to building the WOSAIXMC model using WIN32 and a 32 bit software model are
`listed below:
`
`•
`
`• Current and future version ofthe Windows operating system are moving towards the 32
`bit model and will either completely implement or implement a large subset of the
`W1N32 API.
`The 32 bit programming model is easier and more efficient for it uses a flat memory
`model. Segments and offsets are not used.
`Supporting W1N32 will ease the portability between different Windows operating
`systems. For example, code compiled to run on Windows NT will run on Chicago
`unchanged.
`
`•
`
`•
`
`•
`
`•
`
`ROY ·G·BIV Corporation Confidential
`© 1994 ROY·G·BIV Corporation All rights reserved.
`
`10
`
`7124194
`
`CONFIDENTIAL OUTSIDE COUNSEL EYES ONLY
`
`RGB00055893
`
`13
`
`

`
`, '." . •
`
`•
`
`•
`
`WOSA/XMC MCAPI and MCSPI Analysis Specification
`
`3.0 Development
`
`4.0 Marketing
`This section describes the planned strategy, materials, and methods used to market the
`WOSAIXMC software model implementing the MCAPI and MCSPI. Not only is marketing to
`sell each released version of the model, it will also be useful for gathering input from current or
`prospective user on how to improve the model in a way that will help it gain a wider acceptance in
`the market.
`
`4.1 Strategy
`As mentioned earlier in section 2.0 Product Vision, there are three planned phases of the
`WOSAIXMC project. Each phase is outlined below from the marketing perspective:
`
`Phase 1 - In the first phase, an open process may involve several key hardware vendors who help
`evolve the MCAPI and MCSPI. In addition some of the hardware vendors will be encouraged to
`create their own MCSPI supporting Motion Device Drivers. Version 1.0 of both the Motion
`Control Driver Administrator and the Motion Component should be bundled with applications
`built on the model and sold in the application's target market. In addition, the Motion Control
`Driver Administrator, the Motion Component, and all MCSPI supporting Motion Drivers will be
`sold with an accompanying WOSAIXMC software development kit targeted at motion control
`software application developers.
`
`Phase 2 - In the