Epicure Software Release Note 137.0<P> <b> The Analysis and Design for an ARCnet, CAMAC, and Tevatron Clock Service under Windows 95 and Windows NT</b>

Epicure Software Release Note 137.0

The Analysis and Design for an ARCnet, CAMAC, and Tevatron Clock Service under Windows 95 and Windows NT

David M. Kline

Abstract:

Some Epicure workstations are hosted by personnel computers based on Intel microprocessors running the MS-DOS operating system under the Windows 3.x environment. Within the workstation, residing on the ISA bus, is the PCARC and TEV Clock decoding board acting as a medium to provide services which communicate with EADnet, perform standalone CAMAC operations, and notify clients of a single Tevatron event. The current implementation includes a collection of Dynamic-Link-Libraries (DLL) which execute in the context of a single user Windows 3.x environment. Win16 applications reference the DLL routines by loading the library explicitly (load-time loading). However, since multiple users can log in under Windows 95 (Win95) and Windows NT (WinNT), the current implementation must exist as a Service executing in the context of the operating system as a detached process, and made available when the operating system boots. Therefore, the need exists to develop a Service that executes under both the Win95 and WinNT operating systems to provide an identical level of functionality as present under Windows 3.x. Furthermore, since the Service will be native to both Win95 and WinNT, the features of the Win32 API can be employed thus exploiting the processing power of the hosted microprocessor. This paper will focus on the analysis and design of the ARCnet, CAMAC, and Tevatron (ACT) Service that will be available to clients either residing on EADnet, DECnet, or TCP/IP based networks.

Overview

Epicure workstations hosted by Intel processors, running the Windows 3.x (Win3x) environment, contain the PCARC and TEV Clock decoding board to interface to EADnet, perform local CAMAC operations, and receive notification of a single Tevatron event [1]. Applications interface to the PCARC board through a collection of Dynamic-Link-Libraries (DLL) which are explicitly loaded to gain access to a particular service. The migration to Windows 95 (Win95) and Windows NT (WinNT) concluded that the current implementation does not behave identically as under Win3x. Therefore, a Win95 and WinNT Service will be developed in order to maintain backward compatibility with existing applications, and to extend its functionality to remote clients residing on EADnet, DECnet and TCP/IP based networks.

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.

Service

As referred to earlier, the ACT Service is the mechanism by which applications, either local or remote, access services supported by the PCARC board residing on the local machines ISA bus. Furthermore, ACT is a service provider which supports backward compatibility with the existing implementation and extends its abilities by providing network capabilities.

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.

Dynamic Link Libraries (DLL)

This section describes the Dynamic Link Libraries (DLL) which represent an applications interface to the ACT Service. Before describing the specifics related to the ACT Service, a brief discussion of DLLs is presented.

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.

DLL: EADnet

Access to ARCnet is implemented as port IO and memory operations. Port IO is used to access the control registers of the communications device and to control its configuration and the processing of interrupts. Memory operations provide read and write access to the communication device memory for ARCnet message passing. An incoming message from ARCnet signals a thread that monitors the occurrence of an interrupt. The thread reads the information from the ARCnet buffer and determines whether to process it locally, or dispatch it to the primary thread. Local processing typically includes recognizing specific NTI's relating to the retrieval of local node information [2]. However, if the message is destined for a client, the message is queued to the primary thread and is relayed to the destination residing either on the local or a remote machine.

DLL: CAMAC

CAMAC operations are performed by a series of write operations to specific port IO addresses which represent the crate, slot, function, address, and data of a particular CAMAC operation. Notification of a completed CAMAC operation is performed by reading the status of the Q and X from a specific port address. When the response it received, the information is passed to a local or remote client.

DLL: Tevatron

The notification of a single Tevatron event is performed by writing a number of the event to a port address. When the event occurs, an interrupt is generated and the application is notified.

Implementation Strategy

The implementation language of the ACT Service is C++. The initial release will be written in Visual C++ running under Windows NT on an Alpha platform. This serves as a reasonable starting point since some of the features available on Intel platforms are unavailable on Alpha platforms. For example, one can not provide inline assembly code, a feature of the C++ language, using Visual C++ for Alpha platforms. Other limitations and portability issues are discussed in ``Microsoft Visual C++, Programmer's Guide'', chapters 3 and 5. In addition, other limitations exist under Windows 95 which do not under Windows NT. For example, the Win32 API for Win95, does not support calls which provide services, such as OpenService() or CloseService().

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.

References

1
[Emmons] Donald Emmons. ``PCARC and TEV Clock Decoding Board''. Epicure Hardware Release #36, November, 1992.

2
[Kuplic] Mike Kuplic. ``EADnet NTIs and Data Types''. Epicure Hardware Release #42, April, 1995

3
[Q125714] ``How to Start an Application at Boot Time Under Windows 95''. Microsoft Article Q125714, 1995.

4
[Win95] Microsoft. ``Windows 95 Resource Kit''. Microsoft Press, 1995.

5
[Win32] Marshall Brain. ``Win32 System Services - The Heart of Windows NT''. Prentice Hall, 1994.

Keywords: EPICURE, ARCNET, PCARC

Distribution:

Normal

Security, Privacy, Legal

rwest@fsus04.fnal.gov