Section 1 Behind the Scenes Section 2 Behind the Scenes, continued In This Section: Behind the Scenes The Application Kit The Storage Kit As described elsewhere in this book, BeOS is an object-oriented operating system, from its lowest levels to its highest. Wherever possible, code is reused and recycled, rather than re-created from scratch. Each of the system servers described in Chapter 5 dips into its own pool of shared code and doles it out to applications as needed. These pools are divided into broad categories of functions called "Kits," and provide fundamental services (like networking, audio, data translation, and file management) to the system in the cleanest, most efficient way possible. BeOS includes a total of ten Kits; their functions are explored in this chapter. Behind the Scenes While the collection of BeOS "Kits" is of interest mainly to programmers, many technically oriented end-users may enjoy and benefit from this "glimpse behind the scenes." This chapter is optional reading for users interested in reaching a deeper understanding of the way BeOS operates, and as a primer for users interested in learning to program BeOS applications. It summarizes information available in The Be Book (on your system in HTML format at /boot/beos/documentation/BeBook/) and in these more extensive reference manuals: The Be Developer's Guide. The Be Development Team 1997, O'Reilly and Associates. ISBN 1-56592-287-5. Be Advanced Topics. The Be Development Team 1998, O'Reilly and Associates. ISBN 1-56592-396-0. If you've got two applications open at once and both of them include scrollbars, pulldown menus, resizable borders, and title bars, there's no need for both of them to include all of the code necessary to construct those objects, is there? Of course not. The codebase that describes the rudiments of a basic application is stored at a central location in the operating system. In this way, BeOS achieves maximum efficiency and minimum redundancy, while application developers enjoy the luxury of not having to worry about writing all that stuff themselves. This object-oriented arrangement also ensures a consistency of behavior and appearance throughout the system so that all of your applications look, feel, and behave basically the same way. Figure 1 The BeOS system servers have no user interface and are not user-configurable--they lurk in the background awaiting requests from the rest of the system. When a request is received, they spring into action. Some of the servers pictured here, such as the app_server and the registrar, are very active and are involved in almost everything you do. Others, such as the syslog_daemon and print_server, are seldom called upon. The system servers function sort of like liaisons, intermediating between the system Kits and your running programs. Managing this interplay of services and the code that enables the services are two interrelated constructs: the system servers and the system Kits. You never see the servers or Kits, as they don't have an interface and there's nothing user-configurable about them. The servers (introduced in Chapter 5, Files and the Tracker) are active programs (or "daemons") that lurk in the background, always running, waiting for requests from other programs before springing into action. The servers are compiled, running programs--you can see their icons by opening up your /boot/beos/system/servers folder in the Tracker. The Kits, on the other hand, are not programs at all, and they don't "run" in the background. Rather, they're collections of objects classified by the jobs they do. The concept of "objects" here is a little abstract. In reality, the Kits are defined in shared code libraries that are called upon by all programs, including the servers. There are ten Kits in all, and they collectively define the application programming interface (API) that programmers use to make their generic C++ code talk to and work with the specific aspects of BeOS. They are: • The Application Kit • The Network Kit • The Storage Kit • The Game Kit • The Interface Kit • The Support Kit • The Kernel Kit • The Translation Kit • The Media Kit • The Mail Kit You'll notice a certain amount of overlap between the list of Kits and the list of servers (for example, there's an Application Kit and an app_server, a Mail Kit and a mail_daemon). But there are also a number of Kits not associated with a server, and vice versa. The relationship is not one-to-one because some of the Kits serve umbrella functions for all of the servers. For instance, the Storage Kit handles the nitty-gritty of reading from and writing to your disks--a job that most of the servers need done in one way or another. Likewise, a Game Kit is necessary for reasons we'll get into later, but games don't require their own server to function. In other words, some Kits are important to all applications, while others come into play only in certain instances. All GUI applications need windows, borders, scrollbars, and menus, so all GUI apps draw on the Application and Interface Kits; but only applications that deal with audio/visual data need to draw on the Media Kit. Finally, all of the servers "sit on top of" the system kernel, interfacing with it directly. Figure 2 The servers sit between the kernel and your applications, functioning as an adjunct to or extension of both. Meanwhile, the servers look to the Kits as a codebase--a set of rules to follow in any given situation. For example, when you click on a link in NetPositive, the browser sends a message to the net_server requesting network services so it can do its job and bring back the requested page. The net_server operates according to rules set forth in the Network Kit, which defines the structure and programming interface of all network operations. The heavily threaded servers are capable of handling any number of applications simultaneously, which is the essence of the client-server model introduced in Chapter 1. So how are all of these things related? It sort of depends on your point of view. As an end-user, it may make the most sense to think of the servers as sitting between the kernel and your applications. Servers don't serve you--they serve your applications and your applications serve you. Digging through the Headers Unlike the Windows or MacOS worlds, where end-users may work for years without ever seeing a scrap of actual code, many BeOS programs are distributed with full source code, and the operating system installs with a full collection of headers and libraries, in addition to a free and unlimited application development environment. As in the Unix world, there is less distinction made between the end-user and the programmer, and anyone who wants to start cranking out code has all the tools they need at their disposal. Even if you're not a programmer, feel free to peruse the Kits as they appear to developers by using the Tracker to navigate the /boot/develop/headers/be hierarchy. Within that directory tree, you'll find a separate subdirectory for each of the Kits described in this chapter. All header files end with a .h extension. Open one of these files and it will be launched into the Metrowerks development environment, where BeOS programmers spend most of their late nights and early mornings crunching code to make your BeOS experience rock. See if you can determine the raison d'etre of a few random header files by studying the code they contain (of course, the filename is often a dead giveaway). Since the Kits are constantly being updated and improved by the Be engineering team, it's possible--even probable--that the Kits outlined here may be different than the ones you find on your hard drive. From a programmer's point of view, however, it's a little different, as developers don't access the servers directly. They access the Kits from within their code; the Kits in turn know how to talk to the servers. A programmer doesn't say, "Hey network--wake up!", but something more like, "I need a function that can establish a connection to another machine on the network." Since the function called is part of the Network Kit, it automatically establishes communication with the Network Server. Each Kit consists of a collection of "header" files--raw C or C++ code written by Be engineers. When a programmer needs a system service, she invokes a Kit by creating an appropriate object or "including" the appropriate header file and invoking the appropriate function. If you'd like to study more technical documentation on BeOS's system Kits, it's right there on your hard drive, at /boot/beos/documentation/BeBook/. There you'll find a collection of folders, each named for a separate Kit. Each folder contains a series of HTML documents describing that Kit in detail (though not always in plain English). The Application Kit The Application Kit is the most foundational of all the Kits--without it, you simply don't have a GUI application. The invocation of the Application Kit is the moment of conception for a BeOS application. By invoking the Application Kit, an application basically blinks into existence--it gains an identity and becomes known to the system. It gets registered in the Deskbar and can be referred to and communicated with by its application signature. The Application Kit consists of four major parts. Deeper than This If this description of the BeOS system of Kits and servers makes the whole arrangement seem delightfully clean and simple, that's because it is ... in concept. Compared to other operating systems, the BeOS API is a marvel of simplicity and elegance, and requires programmers to jump through far fewer hoops to get the system to do what they want it to do. It's so clean, in fact, that many BeOS developers have described programming for BeOS as "a joy." At the same time, though, the youth of the system means that there aren't as many prefab API calls in BeOS as there are in other operating systems--BeOS programmers sometimes have to install some of their own plumbing. That fact notwithstanding, an operating system--even a brand spanking new one--is incredibly complex by definition. Each of the Kits described here is a small universe unto itself, and includes dozens or hundreds of objects, options, flags, arguments, and possibilities. The Kits are the thread and cloth from which every part of the operating system is woven, as well as the genetic map from which of all of your applications are built. Just how complex are the Kits? Consider: If this book can be considered the bible for BeOS users, then the bible for BeOS programmers is The Be Developer's Guide, a book that covers the Kits and nothing but the Kits, in mind-numbing depth. The first edition of The Be Developer's Guide is more than 900 pages long. This chapter is much indebted to that book. Note on terminology: A "class," in object-oriented programming terminology, is an object--a chunk of code that performs a specific task and that can be reused as often as necessary. Some classes are "public," and pertain to the entire operating system, while other classes are "private" and concern only the current application. The terms "class" and "object" are pretty much interchangeable. Messaging The Application Kit allows programs to spawn threads (see Glossary and/or Chapter 2, Meet the System), and those threads to become the bearers of BMessages (Chapter 1), enabling them to communicate with one another and with the threads of other running applications. It also handles "event messages," keeping track of mouse clicks, keypresses, and infrared signals from your garage door opener. The BApplication Class By creating (or, more correctly, "instantiating") a BApplication class, the Application Kit makes its connection with the application server, which takes over common tasks like monitoring system resources, drawing images in windows, resizing borders, and lording over the cursor. Every BeOS application must include a single instance of this class. The BRoster Class BeOS maintains at all times an internal roster of all running applications. Programmers can query this roster to learn which applications are currently available for communication. By registering themselves in the system roster, applications provide the data other programs need to establish communications. The BClipboard Class This class handles the transfer of data to and from the system clipboard any time you cut, copy, or paste text, images, spreadsheet rows, or anything else. The Storage Kit We took a hard look at BFS (the Be Filesystem) in Chapter 5, Files and the Tracker, and discussed its many unique properties: journaling, attributes, node monitors, symbolic links, virtual filesystems, queries, and more. BFS is fine-tuned to handle high-bandwidth multimedia files with maximum throughput while at the same time offering the average user database-like functionality not available on any other system. The Storage Kit is the mechanism through which programmers instruct their applications to take advantage of these features. Of course, it's also responsible for the more mundane act of simply reading files from and to disk volumes. Needless to say, the Storage Kit works closely with the storage server to create and recognize files, directories, links, and attributes. Like the Application Kit, the Storage Kit is divided into four major functions. Maintaining the Filesystem and Navigating Hierarchies While you can mount any number of disk drives on your system, each of these drives can contain multiple partitions, and these partitions can in turn support various filesystems, the totality of all mounted partitions appears as a single logical hierarchy when viewed by the Tracker, or when referred to from within programs. As you add or subtract partitions, the hierarchy maintains its integrity. The collection of all mounted partitions on your machine is referred to as "the filesystem." Note, however, that this term is a little confusing, since the term "filesystem" also applies to the low-level layout and formatted structure of a disk platter. One term, two meanings. Maintaining and communicating with the collective filesystem is the chief job of the Storage Kit. Because BeOS uses a plug-in architecture that allows it to recognize filesystems from other operating systems, it must make at least one fundamental assumption about how those filesystems will be organized: BFS requires that any recognized filesystem will be hierarchical in nature, using a tree-like structure that fans out from a single root into a system of boughs, branches, and leaves (folders and files). Since virtually all filesystems out there are structured in this way, BeOS's potential support of alien filesystems is practically universal. Under this umbrella fall dozens of related responsibilities. Reading and Writing Files and Directories The function of the Storage Kit that is perhaps most visible to the user is the task of creating, deleting, naming, renaming, copying, moving, and otherwise managing the collection of mounted files and folders. This job is accomplished by way of two fundamental filesystem concepts: "nodes" and "entries." A node is an actual file--the data in your address book, for example. But it's not enough to simply scatter a disk with file data; something must keep track of what lives where so the filesystem can be constructed visually in the Tracker and reported accurately in the Terminal. Entries represent the locations of nodes. However, the relationship between nodes and entries is not necessarily one-to-one. While every node must have an entry, it is possible to have entries without nodes. For instance, an application might create an entry in the filesystem as a placeholder, before the file has actually been created. As you might expect, the onus of maintaining MIME types and attributes (Chapter 5, Files and the Tracker) also falls on the shoulders of the Storage Kit. From the perspective of the BFS, attributes are essentially normal files, and have their own nodes and entries. But from the perspective of the Tracker and the Terminal, attributes are not displayed in file listings (by default, though you can of course customize any Tracker view to display an array of related attributes--see Chapter 2, Meet the System), nor are their sizes reported to the user, so a distinction must be made between them. Since the Storage Kit is responsible for all reading and writing of attributes and MIME types, the system FileTypes database (page 272 in Chapter 5) also falls under its rubric. Monitoring Changes (Node Monitor) There are many instances in which it's useful for an application to be able to keep a watchful eye on a file or folder to see when it's been updated so it can take some kind of action. The mechanism that accomplishes this act of voyeurism is called the "node monitor." A simple example of the node monitor in action is the Trash icon on your desktop. As described in Chapter 5, the Trash is a special folder in a number of ways. One of its distinguishing characteristics is its ability to wear a different icon depending on whether it's empty or full. Because a node monitor is permanently trained on the Trash, dragging a file into the empty Trash bin will kick its node monitor into action, and the Trash icon will immediately change. The Tracker uses node monitors in all folder views--this is why making a change to the contents of a folder from the Terminal will cause the folder view in the GUI to be updated instantaneously. Application developers can employ node monitors in all kinds of creative ways. Node monitors are related to files and folders at the lowest level, so they're handled by the Storage Kit. Asking for Files (Requests and Queries) Files don't do anyone any good if they can't be retrieved by applications. Even if it seems like the most trivial task, requesting a file from a disk volume is one of the Storage Kit's most important jobs. There's more to this category than meets the eye, however. Requesting files from disk involves communicating with high-level system objects such as the familiar File panel and the Tracker list view, as well as more abstract functions, such as finding the current directory's parent, obtaining the full path of a file, or hoovering a file's custom icon out of its attributes. The act of querying the system for files that meet certain criteria is another Storage Kit task falling under this umbrella. As intuitive as it may seem to our human brains, scanning the system for all files that begin with a capital "M" requires a substantial amount of work from BeOS. In addition, the Storage Kit needs to maintain queries in a "live" state so that the results window updates itself when files suddenly meet (or stop meeting) your criteria. Real-time updating of virtually everything is "the BeOS way" and is accomplished at the filesystem level by the labors of the Storage Kit. The Storage Kit is also responsible for the job of creating and maintaining virtual filesystems such as /dev and /pipe (these directories are available to the system and can be seen from the Terminal, but do not represent actual storage locations on disk). ^ top ^ next >>