PrefaceCross-Platform Development in C++
Building Mac OS X, Linux, and Windows Applications
Syd Logan
Addison-Wesley
Preface
During the ten or so years of my career prior to joining Netscape in 1998, I had the good fortune to work on a wide variety of projects, on an equally diverse set of platforms. I worked on an embedded kernel of my own design for a somewhat obscure CPU (the TMS34020). I obtained experience in Windows kernel development, writing file systems drivers for the Windows NT and Windows 98 kernels, to support the development of a Network File System (NFS) client. In user space, I mostly specialized in user interface development, initially developing Motif (Z-Mail) and OpenWindows applications for UNIX, eventually getting exposure to Win32 and the Microsoft Foundation Classes (MFC) toolkit on the Windows platform. I even had the chance to write code for the Classic Mac OS to support a project that would be shipped by Apple, using the Mac Toolbox application programming interface (API). All of this code was written in the C language, and all of it was highly nonportable, written only with a concern for the job, and platform, at hand.
But then I joined Netscape, as a UNIX expert of sorts. Initially, I was assigned the task of working on bugs in the 4.x Netscape browser, specifically handling defects filed against a port of the browser to IBM's Advanced Interactive eXecutive (AIX) platform. Netscape had a contract with IBM to ensure that bugs filed against the AIX version of the Netscape browser, or bugs that IBM considered important, were fixed in a timely fashion, and this contract funded my hiring. Similar deals were cut with SGI, Hewlett-Packard, and Sun, and perhaps others, and these deals funded additional Netscape staff. Two or three of us were assigned to deal with AIX, specifically.
During this time, portability had not yet been perfected at Netscape. Although much of the codebase of Netscape was portable, the project did not have a unified build system, and the user interface code was completely platform specific. Many bugs had a decidedly platform-specific nature to them (hence the need to have separate teams to support individual platforms). Code that worked flawlessly on the Windows version of Netscape ran horribly on less well-supported platforms. Not all platforms had the same set of features, and features varied from platform to platform.
Within a year of joining Netscape and fixing AIX bugs, I somehow earned my way onto the Netscape Instant Messenger team, and work on the new codebase based on the open source Mozilla platform. This team, which consisted of three engineers, was tasked with porting the AOL Instant Messenger client to the Netscape browser. The Netscape IM team was hastily formed right after AOL acquired Netscape, to try to bring AOL-based functionality into the application. (The other major AOL property integrated into Netscape was support for AOL Mail).
The new Netscape client, in development at that time, was, as mentioned previously, based on the open source codebase named Mozilla. This codebase, at the time, was largely the product of Netscape engineers located in offices located in San Diego, and Mountain View, but contributions from the open source community were on the rise. (I refer to the project as Netscape/Mozilla in the remainder of this Preface).
Netscape was in fierce competition with Microsoft for the browser market at this time, which meant the browser of course had to work well, and ship on time on the Windows platform. Netscape also generated significant advertising revenue through the Netscape portal, and clicks there were highest when a new version of the browser was released, and tens of millions of users visited the portal to download a fresh copy of Netscape. Supporting Netscape not only on Windows but also on Mac OS and Linux helped keep the number of visits high and generate revenue. So, Linux and Mac OS were treated as equals with Windows within the Netscape culture, not only because it was the morally right thing to do (as many of us believed), but also because every visit to the Netscape portal was important to the bottom line of the company.
Netscape/Mozilla was a complete departure from anything that I had ever seen or worked on before. First of all, this new version of Netscape was not just a browser, it was a platform, capable of hosting applications. (The primary examples shipped with Netscape were AIM, the Mail/News client, a WYSIWYG HTML editor named Composer, the Chatzilla IRC client, and the browser itself. Extensions, such as those available for Firefox today, are closely related). Instead of building the graphical user interface (GUI) for these applications in C or C++, using APIs provided by a native platform GUI toolkit such as MFC or Gtk+, Netscape/Mozilla-developed technologies were used instead. Static Extensible Markup Language (XML) files were used to describe the layout of the user interface, much like HTML is used to describe the layout of a Web page. The XML dialect developed for this purpose was called XML User Interface Language (XUL). JavaScript code, linked to the XML elements via attributes much like JavaScript is linked to HTML elements in a Web page, was used to respond to menu item selections and button clicks. To build an application for Netscape/Mozilla, all one needed was this combination of XML and JavaScript; and because both JavaScript and XML are intrinsically portable, so were the user interfaces that were designed using these technologies. When JavaScript wasn't enough to do the job (as was the case for any real applications, like those shipped with Netscape and Mozilla), JavaScript code could call C++ functions that provided the guts of the application, housed in shared libraries. These shared libraries, or components, were directly supported in the Netscape/Mozilla architecture via two technologies: XPConnect and XPCOM. These technologies allowed component developers to define platform-agnostic interfaces using an Interface Description Language (IDL). Using XPCOM and XPConnect, JavaScript code could query for the existence of a component, and from there, query for a specific interface. If all was good, the JavaScript code was handed an object that it could call just like any other object, except the object was written in C++, and was capable of doing things that JavaScript programmers could only dream of. The interfaces, by their nature, were highly platform agnostic.
The impact of the work done to support portability in the Netscape/Mozilla architecture was not, quite frankly, immediately apparent to me. But, over time, I came to appreciate the power of such an approach. The positive effects of the decisions of those who came up with the architecture are indisputable; during its heyday, Netscape was shipping tens of millions of browsers to users, not just for Windows, Mac, and Linux, but for SunOS, AIX, HP-UX, SGI Irix, and a host of other UNIX-based platforms. The "tier-1" platforms (Mac OS, Linux, and Windows) literally shipped at the same time. Each of these ports had, for the most part, the same feature set, and mostly shared the same set of bugs and quirks. To achieve portability at such a grand scale required a very special architecture, and it is one of the goals of this book to give you a good understanding (if not an appreciation) for how the Netscape/Mozilla architecture directly impacted the portability of the codebase.
However, it was not just the architecture of Netscape/Mozilla that made the browser and related applications (AIM, Mail, Composer) portable. To pull this sort of thing off, one needs not only a solid architecture, but also a culture of policies and procedures that put cross-platform development high on their lists of priorities—as well as large doses of discipline to ensure these best practices were followed. Tools, such as Tinderbox and Bugzilla, both which are described in this book, were invested in heavily by Netscape and Mozilla, and the investment paid off in spades. Engineers were forced to consider other platforms, not just their own, and a regression found during daily testing on just one platform could halt development on all platforms, not just the one affected, because Netscape and Mozilla realized that the only true way to achieve portability was to deal with the issues in the here and now. A good chunk of this book steps away from the code, and describes these best practices, because no matter how good your architecture is in supporting cross-platform, you have to work all the platforms you plan to support with the level of care and devotion to detail if they are going to make it to the finish line with the same levels of quality.
Similar to the way that the programs we write are made up of data structures and algorithms, portability, in my opinion, consists largely of architecture and process, and this conviction is at the foundation of the book that you now hold in your hands.
How This Book Is Organized
This book is organized as a series of themed chapters. Most of these chapters consist of a set of items, with each item covering a specific topic supporting the chapter's overall theme. Early in the book, you will find sections that contain items presenting best practices that must be communicated to the entire development organization, including management, development, and testing. Later chapters cover software-engineering topics that management should be aware of, but these chapters have been written primarily for readers who will be implementing the code. In all, there are 23 items presented in these initial chapters.
The implementation of a user interface is a major concern in the development of cross-platform desktop applications. Item 23 serves to introduce the topic. The final two chapters of the book are therefore devoted to cross-platform GUI-related topics. The first of these chapters provides a comprehensive introduction and tutorial to the wxWidgets cross-platform GUI toolkit. After reading my intr...
![[Start the discussion]](http://g-ecx.images-amazon.com/images/G/01/x-locale/communities/discussion_boards/start-new-discussion-sec._V192250339_.gif){kind=small}
