Almost 14 years after its first public release, Ghostscript is still a commercially thriving, actively evolving, nearly-Open Source PDL interpreter. It has successfully evolved from its original function as a PostScript Level 1 previewer running on MS-DOS on IBM-compatible PCs to cover new input PDLs (PDF, PCL5, and PCL XL), output formats (bitmaps, many printers, and low- and high-level PDLs, including PostScript-to-PDF "distilling"), development platforms (Unix, Linux, MS Windows, Macintosh, VMS, ...), deployment platforms (desktop, server, and embedded), and graphics capabilities (including CIE-based and CMYK color, RasterOp, anti-aliasing, and partial transparency), while maintaining or improving performance and output quality. This talk will examine, within the available time, the design choices (some more successful than others) relating specifically to this broad-spectrum coverage.Ghostscript repeatedly uses several design patterns to achieve functional and performance coverage. One example is "least common denominator plus specialized but functionally equivalent modules selected at build time". This handles differences in build environments, C language dialects, and operating system interfaces, as well as some user-selectable options. A second example is virtual functions, which handle output formats, color representations, and many other points of variability within Ghostscript. A third is "pipelineable interface", used in the memory manager and also for back ends. A fourth is "mixed-level interface", which places both high-level and low-level operations in a single interface with default implementation of the former in terms of the latter. The talk will give some specific examples of each of these, with an assessment of how well they have worked.Until mid-2000, nearly all the development of Ghostscript was done by a single developer with little input. This produced code with extremely high internal consistency, but spotty documentation and some idiosyncratic coding and design choices (such as extremely heavy use of C preprocessor macros). With the transition of development and maintenance to a mixed team of both commercial and public developers working in a much more open process, many processes formerly happening within a single person's head must be documented (e.g., necessary coding rules), automated (e.g., checking for conformity with those rules), modified (e.g., accepting a lower level of quality in intermediate releases), and/or augmented (e.g., public code review, allowing the existence of multiple code branches). The talk will assess some of these changes and their likely impact on future evolution of the code.

The Smalltalk-80* programming language includes dynamic storage allocation, full upward funargs, and universally polymorphic procedures; the Smalltalk-80 programming system features interactive execution with incremental compilation, and implementation portability. These features of modern programming systems are among the most difficult to implement efficiently, even individually. A new implementation of the Smalltalk-80 system, hosted on a small microprocessor-based computer, achieves high performance while retaining complete (object code) compatibility with existing implementations. This paper discusses the most significant optimization techniques developed over the course of the project, many of which are applicable to other languages. The key idea is to represent certain runtime state (both code and data) in more than one form, and to convert between forms when needed.