The Analysis and Design for an ARCnet, CAMAC, and Tevatron Clock Service under Windows 95 and Windows NT
The Analysis and Design for an ARCnet, CAMAC, and Tevatron Clock Service under Windows 95 and Windows NT
David M. Kline
The ARCnet, CAMAC, and Tevatron (ACT) Service is the mechanism by which applications access the services supported by the PCARC board [1]. The software aspect of the Service consists of a Virtual Device Driver (VDD) representing the Application Programming Interface (API) for each of the supported services. Each API is implemented as a DLL which are loaded dynamically (load-time loading) when an application references one of the API routines. Furthermore, the DLLs represent user mode drivers which are source code compatible across multiple hardware platforms, such as Intel, Mips, and Alpha based workstations.
The ACT Service includes a detached process that is responsible for processing requests from local or remote clients to the provided services. It further serves as the focal point of the ACT Services available on a given target (local) machine. The process is started when the operating system boots (Win95 or WinNT) and creates several threads which implement the specific aspects of the Service. To illustrate, the process creates two threads for processing messages from EADnet. One thread is responsible for servicing interrupts from the PCARC board, and the other is responsible for transmitting messages to a specific destination node residing on EADnet. Accessing the hardware is through the WinRT kernel mode driver (VxD) that was purchased from Blue Water Systems, Incorporated. The WinRT driver supports hardware access through a list processing mechanism. The Service establishes a list and submits it to the driver as a sequence of port IO and memory read and write operations. In addition, WinRT provides a collection of C/C++ MACROS to access the hardware for read and writes operations. The macros provide platform independence since some peculiarities exist in memory accesses with RISC processors (i.e. Digital Alpha). Furthermore, the WinRT driver is available for Intel, Alpha, and Mips platforms running either Win95 or WinNT. This complies with the recommendations outlined by the Epicure review committee by providing a multiple platform philosophy. The following sections discuss the implementation details relating to the ACT service.
The ACT Service is comprised of an API for each of the supported services and another for backward compatibility with the existing implementation, a container application for proper initialization and startup of the Service under both Win95 and WinNT, and a detached process which performs message passing of EADnet messages, CAMAC operations, and Tevatron event notification. The API responsible for backward compatibility supports the routines that are presently used in applications, such as OpenEADNET() and CloseEADNET(). It represents a user mode driver (DLL) that implemented a thunking mechanism which maps the Win16 API calls to Win32 API calls.
The APIs responsible for supporting the PCARC are implemented using DLLs, one for each of the services. DLLs provide a reasonable mechanism for source code portability across the various platforms where the ACT Service will be running. Microsoft prefers that developers implement user mode drivers (DLL) and defer the kernel mode drivers (VxD) to Microsoft. The benefit is that a developers product can be offered on many platforms, thus increasing market share. The calling sequence of the new API calls will use the existing implementation as a model, with slight variation.
The container is an application that is implemented specifically for the target operating system. Under Win95, it is responsible for creating a detached process and entering it into the Win95 registry [3]. Under WinNT, the container processes messages from the Service Control Manager (SCM) [5]. Through the control panel, clients determine whether services will start manually or at system startup. Messages sent from the control panel are collected and distributed by the SCM. The container receives the message and responds accordingly. In the case of a start message, the container creates a detached process and initializes the necessary data structures and mechanism in order for applications to communicate with it. The container responds to a stop message by sending a suspend message to the process. This allows the process time to cleanup any outstanding requests and notify clients of its state change. The process then places itself into suspend state, thus reducing further synchronization with the container application. When the SCM container receives another start message, the detached process is placed into a active state and is eligible for incoming requests.
The detached process created by the container application is responsible for processing requests for the various services on behalf of the client. After the process initializes, it creates threads which process the specific behaviors related to the supported services. The process represents the primary thread that is responsible for controlling the threads and synchronizing their activities which implement the particular behaviors of a service. In addition, it serves as a focal point for incoming requests from local and remote clients, and as a transmitter of responses from the services to the requestor.
As referred to earlier, an application attaches to the service API by referencing one of the API calls. The API is responsible for make the necessary connections to either the local or remote service. Several options are available for implementing the communication path between the API/DLL and the detached process. These include named pipes or Dynamic-Data-Exchange (DDE) mechanisms. Both can be used for interprocess communication either locally or over a network.
A DLL is a binary file that is viewed as a shared library for access from multiple applications. It consists of entry points which applications refer to in order to access the available services. A DDL can be loaded into an applications address spaced either implicitly or explicitly. Implicit link occurs when an application references one of the entry points, referred to as load-time linking. Explicit linking is achieved by calling the LoadLibrary API routine, and is referred to as run-time linking. The DLLs which represent interface to the ACT Service will be implemented using implicit linking. This provides for a transparent interface and does not require applications to explicitly reference the library. Below briefly describes the DLL which constitutes the API for the ACT Service.
The second release will be ported to either an Intel Win95 or WinNT platform. This may raise some issues regarding the treatment of the WinRT kernel mode driver. Although the driver provides a common hardware interface for Win32 applications, peculiarities might exist between how a list is processed. Experiments using the WinRT driver for an Alpha platform has shown that interrupt processing in slightly different than on Intel platforms. This peculiarity has been brought to the attention of the developer and should be rectified in the near future. In addition, an attempt will be made to port the source to Borland C++ under Win95 and WinNT. The development of the second release will also include the container specific to Win95 based workstations. Intel based WinNT workstation should be similar to the Alpha based workstations.
The final release will include both Win95 and WinNT implementations for Intel and Alpha platforms. The WinRT driver is available for Mips microprocessors, and possibly HP PA-RISC for the WinNT operating systems. Therefore, future releases may include Mips and HP PA-RISC platforms under WinNT as part of a general package of the ACT Service executing under many platforms.
Keywords: EPICURE, ARCNET, PCARC
Distribution:
Normal