Some services are available to the programmer because of the design of the OS. The following topics discuss the OS features that are significant for NLM developers.
The NetWare operating system was originally designed without time slicing (preemption). All NLMs had to relinquish control of the CPU by blocking or by explicitly yielding control. Beginning with NetWare 5, the scheduler performs preemption, but only for NLMs that are linked with XDC data. NLMs not linked for preemption are required to relinquish control to the operating system.
For NetWare 5 and later, you can design your application to run with or without preemption. If you select nonpreemption, your threads will run until they knowingly call a function that blocks (relinquishes control to the operating system). Because the operating system waits for threads to block, nonpreemptive NLMs are expected to govern their use of the CPU time so as not to take control of the CPU for indefinite periods of time.
NLM applications must either quickly complete the request, do things to regularly relinquish control (such as I/O requests), or explicitly relinquish control by calling a function such as ThreadSwitch. In general, the NLM should run for about .1 millisecond on a 1.6 GHZ processor and then relinquish control.
If you select preemption, you must still design your application so that it relinquishes control. You cannot completely rely on XDC data and the preemption process to prevent your application from taking control of the CPU for too long of an interval and thus precipitating a CPU hog abend.
In the NLM environment, each thread group has its own current working directory (CWD), as well as a current working volume and a current server ID. However, there is no notion of "drive" in this environment when you are referring to the NetWare file system.
CWDs for NLMs can be used by almost all NetWare API functions that take a pathname as an input parameter. Any time a server and volume are specified in a pathname, the pathname is absolute. On the other hand, if the pathname does not contain a server or volume, the path is considered relative to the CWD.
Connection and task numbers are important NLM programming considerations. For information see Connection Numbers and Task Numbers in Connection Number and Task Management Concepts (NDK: Connection, Message, and NCP Extensions).
The main screen for the server is the console screen. This screen allows the operator to issue commands directly to the OS. This is also the screen where NLMs are loaded.
NLMs can have zero, one, or multiple screens. These screens display on the same monitor as the console screen. The OS switches between screens when the following happens:
This displays a menu of the names of the currently open screens. The operator then enters the number of the screen to switch to.
This switches the current screen to the next screen in the list of open screens. This allows the operator to cycle quickly between screens.
This is done when a thread calls DisplayScreen.
When an NLM terminates, its screens are destroyed and the console screen becomes the current screen.
NOTE:Keystrokes are accepted only for the currently displayed screen. An NLM that is waiting for input does not receive it until the operator switches to its screen and enters the needed keystrokes.
For an example of creating and using multiple screens, see Multithreaded Programming (NDK: NLM Threads Management).
NetWare 5.x and 6.x servers have the following types of screens:
Server console commands are entered at the command line of the System Console Screen. This screen is always present. On NetWare 5.x servers, NLMs can write to this screen and receive input from its keyboard. On NetWare 6.x servers, NLMs cannot write to this screen or receive input for it. They can write only to the System Logger Screen or to their application-owned screen.
This screen is only present on NetWare 6.x servers. This screen logs all system messages as well as the output from NLMs that write to the system console. NLMs cannot get characters from this screen's keyboard because the screen accepts only a few commands related to scrolling and other such activities.
The Debug Screen is accessed from within an assembly or C program or through a special key sequence. This screen is hidden unless the server is at a breakpoint.
This screen displays whenever the TRACK ON console command is executed.
An NLM can have zero or more application screens which are regular or popup. Popup screens, used to present instructional or error messages, are overlaid on regular screens. In some cases, an NLM might not require a screen (a library NLM, for example). An NLM might also write to the System Console Screen (NetWare 5.x), System Logger Screen (NetWare 6.x), or to the screen of another NLM (if the other NLM cooperates).
On NetWare 6.x servers, NLMs can receive input only from an application-owned screen. On NetWare 5.x servers, NLMs can receive input from the System Console Screen or from an application-owned screen.