December 94 - NetWare Development on PowerPC
NetWare Development on PowerPC
JAMIE OSBORNE
Apple and Novell recently announced a PowerPC version of NetWare. Under NetWare,
network services such as file servers, print spoolers, and electronic mail dispatchers
are written as NetWare loadable modules, or NLMs. By providing a software layer
between the NLMs and the hardware they run on, NetWare makes more efficient use of
the available hardware, improves portability, and allows programs to run on mixed
networks tying together different platforms. This article shows you how to get started
with NLM development.
Novell's NetWare has been around for years, and is considered by many to be the
networking standard in the DOS/Windows world. NetWare servers have always been
able to handle AppleTalk clients, too, but they have not been as prevalent in
predominantly Macintosh environments. As a result, most Macintosh developers have
never had the need or inclination to learn how to write software for NetWare servers.
With Apple's NetWare for PowerPCTM, you can now port your existing network
products, or create new ones, to run on Apple Workgroup Servers under NetWare.
In this article, we'll take a brief tour of the NetWare environment and what it takes to
write software for it. The article is intended primarily for developers of networking
software, particularly running on networks using Apple Workgroup Servers or
multiple platforms -- but you should also find it of interest if you're just curious
about NetWare or want to know about the available options for writing networking
software.
NetWare is anetwork operating system, a framework for providing network services.
Instead of running application programs, NetWare runsNetWare loadable modules, or
NLMs, which typically implement network-based services such as file storage,
printing, and electronic mail. An NLM can be loaded either on demand or automatically,
and uses the NetWare Operating System (NOS) to allocate memory, communicate with
clients, and interact with the underlying hardware. Once loaded, an NLM becomes an
integral part of the operating system, with no architectural "middlemen" to slow it
down. Figure 1 shows an overview of the NetWare architecture.
The information in this article is based on Apple's NetWare for PowerPC, an
implementation of Novell's NetWare 4.1. Earlier versions of NetWare are still in wide
use, but NetWare 4.0 added some new features such as directory services and
improved security. NetWare 4.1 is a more robust version of 4.0 and improves still
further on these new features. Though earlier versions of NetWare client software can
connect to NetWare 4.1 networks, they may not be able to use all the features of the
available NLMs. If you want your NLMs to support all versions of NetWare clients, the
NOS provides the necessary support libraries.*
Figure 1. The NetWare architecture
WHY NETWARE?
If you're a Macintosh developer, why should you make the leap to NetWare
development? To make your product available to the greatest number of users.
NetWare is used on more than 60% of all servers in the DOS-compatible world. Here
are some of the reasons NetWare is so popular.
EFFICIENT RESOURCE ALLOCATION
In a typical Macintosh network installation, a single server machine provides file
storage, printing service, a mail server, and maybe even a scheduling server or other
network services. Any one of these services might deliver acceptable performance on
its own; but when you try to put them all on the same "box," they must contend for
limited resources such as processor time, memory, and disk access. The result is that
they all suffer performance degradation: even on a blindingly fast machine, such
resource contention can slow all of your network services to a crawl.
NetWare helps alleviate this problem in three ways:
• OS-level resource access. Unlike other operating systems (such as
UNIX®), NetWare has no protection scheme to prevent a process from
accessing memory outside its domain. Once loaded, NLMs become part of the
operating system itself, with unrestricted access to memory and other
hardware resources. NLMs run faster without the overhead associated with
memory protection. The cost, of course, is that an unprotected NLM can bring
the entire system down if it crashes.
• "Lightweight" threads. The NOS is multithreaded, with threads from
NLMs existing alongside those belonging to the system itself. Because they
operate at the system level, NLM threads carry very little overhead and can be
spawned, executed, and switched very quickly.
• Nonpreemptive multitasking. NetWare is a nonpreemptive multitasking
system: the burden of deciding when to switch threads is placed on the
individual NLMs, rather than on the operating system itself. So long as all
NLMs are "good citizens," they can work cooperatively to produce a more
efficient system.
CENTRALIZED DIRECTORY SERVICES
One of the biggest headaches for many network administrators is maintaining user and
group lists for multiple servers and services. A single user may have an account on
two or three file servers, a mail server, and who-knows-what else. Keeping the
different accounts for that one person up to date can be a significant chore.
NetWare helps ease this burden by making centralized directory services available to
all NLMs. NetWare users log directly into the network itself, not into a particular
server. Using interfaces that NetWare provides, NLMs can access the directory
services and use them for authentication. Thus a mail server and a file server, for
example, can share the same user list instead of each maintaining its own. This
centralized approach to directory services benefits everyone. NLM developers don't
have to write the code to store, edit, and maintain their own user lists; network
administrators only need to maintain a single centralized directory; and users don't
have to remember half a dozen different passwords and authenticate themselves every
time they move from one network service to another.
PORTABILITY
Networks are growing larger everywhere, as users discover that computers linked
together, sharing services over a network, are far more useful than isolated
workstations. While this growth presents many opportunities for developers of
network services, it also presents the problem of diversity. The days are gone when a
company's computers all ran the same operating system. Today, Macintosh computers,
DOS-based PCs, and UNIX workstations must all coexist on the same network.
Porting a network service such as a mail server from one hardware platform to
another can take a great deal of time and effort. Building your server as an NLM,
however, gives it instant portability to any platform for which NetWare is
implemented. NetWare's uniform API "virtualizes the hardware," so that NLMs don't
have to interact directly with the platform they're running on. Since the interface to
NetWare is the same from one platform to another, porting your NLM is a simple
matter of recompiling.
THE RIGHT TOOLS FOR THE JOB
By now you should be convinced that NetWare has a lot of advantages to offer. The rest
of this article details what it takes to build an NLM that will run on NetWare for
PowerPC. Included on this issue's CD is sample code for a simple multithreaded NLM.
CHOOSING A DEVELOPMENT ENVIRONMENT
If you're already developing software for Power Macintosh computers, you probably
have most of the tools you need to develop software for NetWare for PowerPC. In the
next section, we'll see how to use these tools to do NetWare development in a Macintosh
environment; but there are non- Macintosh options as well:
• If you have an IBM RS/6000 computer, you can use thecset compiler to
develop your NetWare NLMs. (You'll need version 2.1.1 or later of the
compiler, which can generate PowerPC code.) This is the method Apple used to
port many of the NLMs that are part of NetWare itself.
• If you have a DOS-compatible machine, you may be able to use Novell's
UnixWare in conjunction with the Cygnus C/C++ Compiler for PowerPC (a
PowerPC version ofgcc). You should have at least an 80386 processor for
this option, but an 80486 or Pentium is recommended.
If you already have the hardware and software, either of these non-Macintosh options
can help you quickly begin producing high-quality code. But if you aren't already using
an RS/6000 or a DOS- compatible system, you'll probably do better to go the
Macintosh route. Purchasing an RS/6000 can be quite expensive, not to mention the
additional cost of setup and maintenance. You can get DOS- compatible machines for
much less, but not all of them are compatible with UnixWare. (Any certified
UnixWare reseller should be able to help you determine whether UnixWare will run
on your hardware.)
This article will focus exclusively on Macintosh development options. However,
general information about NetWare's interfaces applies to any development platform
you choose.
NETWARE DEVELOPMENT THE MACINTOSH WAY
MPW Pro (available from APDA) includes a PowerPC C/C++ compiler and linker that
run as tools under Macintosh Programmer's Workshop (MPW). The compiler, PPCC,
produces PowerPC object (.o) files, which you then pass to the PPCLink tool to
produce an XCOFF (eXtended Common Object File Format) file.
Ordinarily, the next step would be to pass the XCOFF file, in turn, to the MakePEF tool,
which turns it into a PEF (Preferred Executable Format) file ready to run as a
Macintosh application. To build an NLM, however, you don't use MakePEF. Instead, you
pass your object files to a special- purpose NLM linker that translates them into a
finished NLM, using information about imports and exports taken from adefinition file
you supply. (See the next section for more information on the structure and contents
of the definition file.) You invoke the NLM linker with an MPW script, NLMLink. As
shown in Figure 2, you pass it your definition file along with the usual PowerPC
runtime library, PPCRuntime.o, and another library, Prelude.o (provided with the
NetWare for PowerPC Software Development Kit), that allows NetWare to load your
NLM. The NLMLink script can also accept a list of .o files as arguments, in which case
it calls the standard PowerPC linker, PPCLink, for you.
To run and test your NLMs, you'll need the developer's version of NetWare for
PowerPC from Novell. You can install it on any Power Macintosh computer.
THE DEFINITION FILE
In addition to your NLM's object (.o) files, you must provide the NLMLink tool with a
definition (.def) file. This file, which is usually namedNLMName .def (whereNLMName
is the name of your NLM), contains information that NLMLink needs in order to turn
your linked object file into a finished NLM. Among other things, the definition file
includes a list of all routines imported to and exported from your NLM. Listing 1
shows an example definition file, taken from the sample NLM on this issue's CD.
The keywords description, copyright, and version give the information that
will be displayed on the NetWare console when the NLM is loaded.
Figure 2. Building an NLM with MPW
The keyword reentrant specifies that the NLM can be loaded multiple times on the
console, but only one copy of the NLM will reside in memory, with all threads sharing
that same copy of the code.
The keywords input and output tell the linker what file or files to read and what to
name the file it produces.
unloaded, respectively. The Prelude.o file that you pass to the NLMLink tool defines
default start and exit routines, named _Prelude and _Stop, to set up your NLM's
threads at load time and clean them up at unload. If your NLM is reentrant, you'll
probably supply a start routine of your own to handle reentrant loading; if not, you
define your own start routine, make sure it calls _Prelude the first time your NLM is
loaded.
The keyword import is followed by a list of the routines that your NLM needs to have
available at run time. These routines usually come from the NetWare C Interface, but
they could be exported by any other NLM running on the server. Any routine your code
calls that is not part of your NLM must be listed here, or the NLMLink tool will report
an error.
Finally, the keyword export is followed by a list of the routines that your NLM makes
available for other NLMs on the server to call. You need not export any routines at all;
however, if you want to give other NLMs access to any of your routines, you must list
them here. (Our sample NLM doesn't actually export any routines, but we've included a
fictitious one in the sample definition file, just for illustration.)
These are just some of the keywords you can use in a definition file. The NetWare for
PowerPC Software Development Kit documentation describes all of the possible
keywords and how to use them.
Listing 1. Example definition file
description "AppleTalk Demo NLM
copyright "Apple Computer, Inc.
version 1, 1, 1
reentrant
input ATDemo.out
output ATDEMO.NLM
start HandleMultipleLoad
exit _Stop
import
ATAtpClose
ATAtpGet
ATAtpOpen
ATAtpSendRsp
ATDdpNetinfo
ATNbpParseEntity
ATNbpRegister
ATNbpRemove
ATZipGetMyZone
exit
free
GetFileServerName
malloc
printf
strcat
strlen
strncat
_StartNLM
ImportSymbol
_TerminateNLM
_SetupArgv
atexit
__get_errno_ptr
BeginThread
ExitThread
strcpy
export
FooBar
A BRIEF TOUR OF THE NETWARE INTERFACE
The NetWare C Interface provides more than 1000 functions for interfacing with the
NOS. It's a load-time interface, meaning that function calls are resolved at the time an
NLM is loaded rather than at link time. Trying to document the entire NetWare
interface here would be like trying to summarize all ofInside Macintosh. We can,
however, look at some highlights. The NLMs that make up the NetWare C Interface
Interface). Together, these NLMs offer interfaces to the following NetWare services:
• high- and low-level I/O
• directory services
• file manipulation
• memory management
• threads
• communications protocols
• math functions
• human interface utilities
These services (which are described in more detail below) are actually only a few of
thoseavailable through the NetWare C Interface. Currently, more than 40 different
services(analogous to Macintosh Toolbox managers) are available to developers of
NLMs. The NetWare for PowerPC Software Development Kit contains documentation on
all of these services, as well as the latest development utilities and sample code.
INPUT/OUTPUT