Fact-checked by Grok 2 weeks ago

NeWS

NeWS, short for Network extensible Window System, is a developed by in the mid-1980s as an alternative to the , utilizing the page description language to enable extensible, networked graphical user interfaces for environments. It was designed to support interactive applications across heterogeneous hardware and software platforms, with its specifications released into the to encourage widespread adoption and porting. The system was primarily engineered by , who served as the lead developer during his time at starting in 1984, building on his prior work in interpretive programming environments. Detailed in the 1989 book The NeWS Book co-authored by Gosling, David S. H. Rosenthal, and Michelle J. Arden, NeWS emerged as a response to the limitations of early windowing systems, aiming to integrate high-quality imaging and extensibility directly into the display server. By the late , it had been ported to various UNIX-based systems and licensed broadly, reflecting Sun's strategy to foster an open ecosystem for graphics programming. At its core, NeWS featured an interpretive architecture where the server executed code, allowing developers to create dynamic, device-independent graphics and user interfaces without recompilation for different displays or printers. Key capabilities included support for distributed applications that could span multiple sites over networks, advanced imaging models for smooth rendering, and built-in extensibility through 's stack-based , which facilitated custom extensions for windows, events, and input handling. This design emphasized portability and integration, enabling seamless transitions between screen and print outputs. NeWS's legacy includes its hybridization with the in the X11/NeWS product, which combined X's client-server model with NeWS's engine, influencing future developments in UNIX distributions such as those from . Although it did not achieve the dominance of X, NeWS pioneered concepts in programmable display servers and networked graphics that informed subsequent technologies in extensible user interfaces.

History

Development

Development of the Network extensible Window System (NeWS) began in 1984 at as a research project initially named SunDEW (Sun Distributed Extensible Windows). This effort was led by , who served as the primary architect and later became renowned for creating , alongside co-designer David S. H. Rosenthal, who also contributed to the . By 1986, the project had evolved into NeWS and was publicly announced in October of that year. The primary motivation for NeWS stemmed from the limitations of ' earlier windowing system, SunView (also known as SunWindows), which relied on a kernel-based architecture that constrained extensibility and advanced graphics capabilities. Developers sought to create a more flexible alternative by integrating —a originally designed for printers—as the core imaging model to enable sophisticated, device-independent graphics and programmable user interfaces. This approach was inspired by the object-oriented paradigms of Smalltalk, pioneered by at PARC, emphasizing dynamic and extensible environments for networked computing. NeWS was built on SunOS, the Unix-based operating system powering Sun's workstations, with initial targeting toward models like the Sun-3 and later adaptations for the SPARC architecture. The project addressed the growing need for device-independent imaging in distributed systems, allowing high-quality graphical interfaces across varied hardware while supporting multi-user and concurrent application environments without the rigid constraints of prior systems.

Release and Initial Adoption

NeWS was officially announced and released by in October 1986 as a networked designed for UNIX workstations. It was introduced alongside 3.2, running as a user-level process on the operating system, and remained integrated with subsequent releases, including 4.1. This launch marked a significant advancement in windowing technology for Sun's platform, emphasizing extensibility through rendering. Initial adoption of was concentrated within Sun's own ecosystem, primarily on its workstation hardware such as the Sun-3 series, which featured processors and supported color displays for enhanced graphics capabilities. By the late , it extended to newer SPARC-based systems like the line introduced in , solidifying its role in professional and research environments. The system saw limited external distribution at first, with ports and licenses granted to select partners including and universities for experimental and developmental use. As the successor to SunView, NeWS provided a more flexible foundation for graphical interfaces, layered atop SunWindows components to enable object-oriented toolkits and networked operations. It became integral to Sun's OPEN LOOK graphical user interface standard, jointly developed with AT&T and first released as a toolkit in 1987, promoting consistent application design across UNIX systems. This integration supported Sun's hardware innovations, such as high-resolution color framebuffers, and facilitated early applications in academic computing and internal engineering tasks.

Design and Architecture

Core Principles

NeWS is fundamentally designed as an object-oriented , where the primary building blocks are views represented as inheritable objects implemented via dictionaries. These objects support encapsulation by bundling instance variables—such as /Transparent or /linesperside—and methods like /PaintClient within the dictionary structure, ensuring data and behavior are contained and accessed through defined interfaces. Polymorphism is achieved through dynamic , allowing subclasses like LinesWindow or LiteWindow to customize responses to events or rendering without altering the base class. Garbage collection is integrated as an extension to , employing to automatically reclaim memory when object references are removed, such as by setting /cv null def. This object model draws direct inspiration from Smalltalk, featuring class hierarchies, inheritance via subclassing (e.g., inheriting from Object), and a send operator for messaging that mirrors Smalltalk-80's object interactions. A key aspect of NeWS's is its support for , enabling multiple lightweight processes or threads per window to handle concurrent operations within a shared . These processes, created using the operator, execute code non-preemptively, switching context only when explicitly paused via the pause statement or when blocked on , which facilitates efficient management of tasks like background repainting without interrupting foreground activities. The system organizes user interfaces through a of nested , which serve as composable, overlapping drawing surfaces forming a rooted at the device . This allows complex UIs to be built by embedding child —such as a LinesCanvas within a ClientCanvas—enabling modular composition and spatial relationships among elements. Events are distributed synchronously within the server via a time-stamped , propagating up the hierarchy from the target and ensuring ordered processing by matching interests and halting at exclusive handlers. NeWS emphasizes programmability by providing a high-level that treats the display as a programmable surface, extending to support interactive graphical user interfaces beyond mere manipulation. Developers can leverage toolkits like Lite, which offers object classes for windows, menus, and controls, to script dynamic behaviors such as transformations, curves, and custom event responses directly on the side, promoting and performance through server-side execution.

PostScript Integration

NeWS incorporated a full interpreter running on the server to serve as its core imaging model, enabling device-independent , font rendering, and image display. This approach utilized a subset of the language, extended with NeWS-specific primitives, to handle all graphical output directly on the server side. Clients transmitted code snippets or programs over the network, which the interpreter executed within lightweight processes to generate screen content, abstracting away pixel-level details in favor of high-level path and transformation operations. In implementation, the stack-based nature of formed the foundation for drawing commands, with operand, execution, and dictionary stacks managing graphical state. These commands integrated seamlessly with NeWS objects, such as canvases represented as PostScript dictionaries, which encapsulated drawing surfaces and supported hierarchical structures for complex scenes. Operators like moveto, lineto, stroke, and fill operated within a stencil-paint model, while the current (CTM) allowed for dynamic coordinate manipulations; this object-oriented integration ensured that graphical state was maintained consistently across interactive updates. The primary advantages of this PostScript integration lay in its support for sophisticated, resolution-independent user interfaces, where graphics could scale seamlessly across devices without quality degradation, as the system operated in user-defined world coordinates rather than fixed pixels. Native capabilities included for smooth edges, arbitrary affine transformations such as and , and on-the-fly rasterization of fonts at any size or , fostering high-fidelity rendering that enhanced visual complexity in applications. This device independence also facilitated consistent output to printers or higher-resolution displays, with image quality improving automatically as hardware capabilities advanced. However, the interpretive execution of imposed significant computational overhead compared to native code, as each drawing operation required runtime evaluation, potentially slowing performance in resource-intensive scenarios. To mitigate this, NeWS relied on optimized , such as Sun-3 workstations with dedicated framebuffers and transformation accelerators, to achieve acceptable speeds; without such support, the system's demands on CPU and could limit its practicality for interactions.

Networking and Extensibility

NeWS employed TCP/IP as its underlying network protocol, utilizing and System V UNIX sockets to enable client-server communication across distributed environments. This design allowed clients to send programs or byte streams directly to the for remote execution, where the server interpreted and rendered the code for display and input handling. The protocol supported a flexible client-server split for applications, with logic partitioned arbitrarily between the client—often handling complex computations —and the —managing user interactions and rendering via —to optimize performance and resource use. Extensibility in was facilitated through dynamic loading of code modules over the network, enabling real-time customization and extension of server functionality without recompilation. For instance, developers could load new classes or scripts, such as the VideoWindow class, to add features like video handling, supporting the creation of tailored applications in collaborative settings. This mechanism complemented the arbitrary partitioning of applications, allowing portions of an app to execute remotely while maintaining seamless integration. The security model relied on basic host-based authentication, using a RemoteHostRegistry dictionary to permit connections only from authorized hosts, with defaults restricting access to the local machine. However, the power of PostScript's interpretive nature introduced vulnerabilities, as remote code execution could allow malicious programs to compromise the server if unauthorized access occurred. NeWS incorporated features for efficient distributed operation, including synchronous remote events through tagged requests and replies—such as ps_getvar for querying server state—and asynchronous events via unsolicited messages like ps_menuhit. On platforms like IRIS, shared memory mechanisms enhanced low-latency collaboration by accelerating input event queuing between processes.

Implementation and Porting

Original Implementation

The original implementation of NeWS was developed for ' workstations, primarily the and Sun-2 series, with subsequent support for Sun-3 and models. It was written predominantly in for the core server logic, incorporating an embedded interpreter as a thin layer for extensibility and rendering. The system ran on versions 3.2 and later, which were based on 4.2BSD UNIX, and was optimized for 680x0 processors in early models (such as the Sun-2 and Sun-3) before extending to architecture in the Sun-4 series. This platform-specific design ensured tight integration with Sun's hardware ecosystem, including monochrome and color displays. The NeWS server served as the central component, managing input from devices like keyboards and mice, rendering graphics via a stencil/paint model, and distributing events through a queue-based system using lightweight processes for concurrency. It supported bitmap operations for both monochrome (1-bit) and color (8-bit) framebuffers, such as those connected via devices like /dev/bwtwo0 for black-and-white displays and /dev/cgtwo0 for color, enabling high-quality text and graphics rendering with features like offscreen canvases and dynamic scan-conversion of outline fonts. Event handling was notification-based, serializing inputs with timestamps and routing them to appropriate windows or views, while the PostScript interpreter extended standard primitives for color objects, transformations, and conic splines to facilitate the view hierarchy core principle. File I/O interfaces allowed seamless integration with Sun's Network File System (NFS) for shared resources in networked environments. The source code remained proprietary to Sun Microsystems, distributed internally and located in directories like $NEWSHOME/lib/NeWS, with no public release of the full codebase. To address performance bottlenecks from interpretation, the implementation included optimizations such as , garbage collection, and compressed binary encoding, alongside prototypes for custom accelerators. These accelerators, exemplified by the Viper board, provided direct access for color rendering, clipping, and video canvases, mitigating slowdowns on 680x0 and early systems by offloading computations. Retained windows further aided efficient damage repair without full redraws, and the device-independent model allowed mapping to various Sun .

Ports and Adaptations

NeWS source code was made available to licensees from , facilitating ports and adaptations to platforms beyond the original Sun workstations. This included access for research purposes at universities such as and Carnegie-Mellon University, as well as licensees including the University of Maryland, and integration with Adobe's technology. Key ports were developed for (SGI) workstations, supporting advanced graphics in 8- and 24-bit RGB modes and integrating with the library through additions like the MEXWindow subclass. Architech Corporation adapted NeWS for on PC-compatible hardware, operating in monochrome mode with named pipes for , facing challenges such as 64KB segment limits and . Other adaptations targeted the and platforms, while Graphics, Inc. extended NeWS to their Viper graphics board (1280x1024 resolution, with video support), incorporating video canvases aligned to modulus 16 boundaries. Porting NeWS involved significant challenges, including differences in hardware architectures and operating systems (e.g., UNIX versus ), requirements for performance optimization, handling of long filenames, and resolving unportable code constructs specific to certain environments. These efforts often required custom tuning for non-Sun CPUs and careful management of the interpreter core, leading to incomplete or specialized implementations in some cases. Outcomes of these ports were mixed, with commercial adaptations achieving targeted success in graphics-intensive or applications but remaining niche outside Sun ecosystems; many remained experimental or academic in scope. A prominent adaptation was the merged X11/ server, which supported both protocols in a single implementation to enable coexistence of X and NeWS applications, resolving issues like colormap conflicts through integrated window management—detailed in the design overview presented at the 1988 Conference. However, this hybrid approach introduced compatibility complexities in practice, such as protocol interoperation overhead.

Applications and Toolkits

Notable Applications

One of the flagship applications for was Adobe's FrameMaker, a document editor originally developed by Frame Technology Corporation and released in March 1987 for Sun workstations using SunView. By the end of 1992, FrameMaker gained native support for through its Device Independent Maker (DIM) architecture, enabling seamless portability and leveraging NeWS's integration for advanced graphical layout, real-time numbering, cross-references, and hypertext features in a networked environment. This OPEN LOOK-compatible version positioned FrameMaker as a key productivity tool on Sun platforms, demonstrating 's capability for complex, high-fidelity document processing. HyperLook, an interactive hypermedia system developed by Arthur van Hoff at the Turing Institute in , served as a pioneering demonstration of 's extensibility for multimedia applications. Released commercially in 1992 for Sun's (which supported NeWS co-server mode), HyperLook allowed direct manipulation of user interfaces via property sheets and object-oriented scripting in , facilitating networked collaboration and editable runtime environments. It was deployed at over 300 sites worldwide for tasks ranging from presentations to geographic information systems, highlighting NeWS's support for dynamic, high-level application design without traditional recompilation. A notable port built with HyperLook was the 1989 adaptation of , the city-building simulation game, undertaken by developer Don Hopkins for Sun workstations running . This version, refined and demonstrated in 1992 at the Turing Institute, utilized NeWS's rendering for real-time dynamic visuals, pie menus for intuitive controls, and networked audio mixing, showcasing the system's potential for interactive simulations with across clients. Altsys , a commercial vector drawing tool, exploited NeWS's capabilities for precise graphics editing when ported to Sun's environment in the early 1990s. Originally developed for , the adaptation of Virtuoso 2.0 demonstrated cross-platform transportability, offering advanced features like Services and high-resolution output, which underscored NeWS's role in professional design workflows.

Development Toolkits

The Toolkit (), released by in 1989, served as a primary library for developing graphical user interfaces on the NeWS . It offered a suite of widgets including buttons, menus, and scrollbars, along with comprehensive event handling mechanisms to manage user interactions such as mouse clicks and keyboard inputs. integrated wrappers that enabled () for user interfaces, allowing developers to define and extend UI components through PostScript-based classes and methods. An earlier offering, the Lite Toolkit, provided a simplified for creating basic applications, emphasizing lightweight drawing primitives for efficient rendering of simple and text. Released prior to as part of the initial distribution, it focused on core functionality without the full overhead of advanced widget sets, making it suitable for prototyping minimalistic interfaces. Like , the Lite Toolkit leveraged for custom widget creation, facilitating device-independent that could be easily adapted across networked environments. Both toolkits supported in UI components, enabling developers to subclass base elements—such as windows or menus—to customize behavior and appearance while reusing established code structures. This approach, rooted in 's dictionary-based objects, promoted for scalable interfaces. Additionally, they included integrated debugging tools for remote sessions, such as the shell (psh) and breakpoint mechanisms, which allowed real-time inspection and repair of running processes across network connections. These toolkits facilitated of networked graphical user interfaces, streamlining the development of distributed applications that could operate seamlessly over networks. Within Sun's internal projects, they were employed to build tools like the VideoDisk , which combined C code with scripting for interactive media control panels. Their extensibility also found application in academic environments for experimenting with custom visualization and .

Competition and Comparison with X Window System

Technical Differences

NeWS and the differed fundamentally in their imaging models, with NeWS employing a vector-based, PostScript-driven approach that emphasized device-independent, high-level operations such as curves, , and transformations using a stencil-and-paint . This enabled programmable rendering that scaled across resolutions without pixel-level dependencies, leveraging for polygons and vectors where available. In contrast, the relied on a bitmap-oriented model with low-level primitives like points, lines, rectangles, arcs, and polygons, defined precisely in terms of affected pixels on a device-dependent grid. X's pixel-focused operations, managed through graphics contexts (GCs) with attributes such as line width and fill style, prioritized direct hardware mapping but lacked the abstract, vector scalability of NeWS. Event handling in NeWS supported both synchronous and asynchronous delivery, processed server-side via PostScript programs to minimize network latency and ensure ordered event propagation through queues with timestamps and serialization. Clients could register interest in events like mouse or keyboard input, with broadcasts distributing copies to multiple processes for coordinated responses. The , however, used primarily asynchronous event delivery, where the server notifies clients of inputs or window changes (e.g., expose or resize) without guaranteed order, requiring clients to select event types and manage themselves. This flexibility came at the cost of added complexity in coordination, as core events generally include timestamps for input events, though applications must still handle potential race conditions. In terms of programmability, integrated a full interpreter into the server, allowing remote code execution, dynamic downloading of PostScript snippets, and object-oriented features like classes, , and methods defined in dictionaries. This enabled extensible behaviors, such as subclassing window objects or integrating toolkits like Lite directly on the server. The , by design, employed low-level protocol requests via libraries like Xlib, with no native support for server-side code loading; extensions required recompilation or separate mechanisms, limiting remote programmability to basic state management through GCs and properties. X's approach favored simplicity and but demanded more client-side logic for complex interactions. Performance characteristics highlighted these trade-offs, as NeWS's PostScript interpretation introduced overhead from parsing and executing high-level code on the server, potentially slowing rendering compared to direct primitives despite reduced network traffic from localized processing. Benchmarks for X11 showed efficiency in message handling, with variable-length requests achieving lower latency (e.g., 240 µs for no-op operations on Digital VS2000 hardware) than earlier versions, avoiding the interpretive costs of NeWS. Hybrids such as X11/NeWS combined both by running X clients alongside PostScript processes in a shared scheduler, inheriting X's low-overhead protocol for simple tasks but exposing NeWS's interpretive delays for advanced graphics.

Market and Adoption Factors

NeWS, developed by , was a that required licensing fees for access to its , creating a significant barrier to widespread adoption. In contrast, the X Window System's X11 release in September 1987 was distributed under the permissive , which permitted free use, modification, and redistribution without royalties, fostering rapid dissemination across the industry. This open licensing model enabled vendors to integrate and port X without financial hurdles, unlike NeWS, where Sun charged for , reportedly $995 for the related OpenWindows distribution in 1991, deterring third-party implementations and ports. The ecosystem surrounding was tightly coupled to Sun's proprietary OPEN LOOK graphical user interface standard, co-developed with in the late 1980s, which restricted its neutrality and appeal beyond Sun's hardware and software stack. X, however, emerged as a vendor-agnostic standard, quickly adopted by major players including (DEC), (HP), and , who released commercial products based on X10 in 1986 and X11 by 1988. The formation of the X Consortium in January 1988, funded by these and other vendors, provided coordinated development and standardization, accelerating X's integration into Unix workstations from diverse manufacturers. Additional adoption barriers for included the steep learning curve associated with its PostScript-based programming model, which relied on a stack-oriented, object-like language that intimidated developers accustomed to C-based like those in X. Sun's charges further limited ports to non-Sun platforms, confining NeWS primarily to Sun's ecosystem. By 1990, X had established dominance in the Unix workstation market, while NeWS remained niche, peaking in usage within Sun systems before Sun shifted support toward X compatibility in products like .

Decline and Legacy

Reasons for Decline

NeWS's decline was precipitated by several technical limitations that became increasingly apparent as computing hardware evolved into the 1990s. The system's reliance on an interpreted language for rendering graphics and handling user interfaces imposed significant performance bottlenecks, particularly on mid-range workstations of the era, where the computational overhead of executing PostScript code in strained CPU resources compared to the more , bitmap-based approach of competitors like X11. Additionally, the executable nature of PostScript code introduced inherent security risks, as it allowed for dynamic program execution within the window server, creating a larger vulnerable to malicious scripts that could potentially compromise system integrity—issues that were mitigated in simpler systems but exacerbated NeWS's complexity. Market dynamics further eroded NeWS's viability, with its close association with the OPEN LOOK graphical user interface standard suffering when the (OSF) endorsed in 1990 as an alternative, limiting NeWS's ecosystem as developers gravitated toward the Motif/X11 combination for cross-platform compatibility. Compounding this, acquired Frame Technology—the developer of FrameMaker, which had a NeWS version—in 1995 for about $500 million, further diminishing NeWS's application ecosystem as focus shifted to cross-platform tools. Sun Microsystems itself accelerated NeWS's obsolescence through strategic pivots toward industry standardization. By 1991, OpenWindows 3.0 featured the Xnews server—a that integrated atop NeWS but suffered from degraded performance and incomplete feature parity, alienating users and developers. Sun fully abandoned NeWS by the mid-1990s, transitioning Solaris to the (CDE) built on and X11, as the company sought alignment with the emerging Unix standards to bolster enterprise adoption. Broader industry trends sealed NeWS's fate, as the rise of free and open-source software in the 1990s, exemplified by distributions bundled with X11, offered cost-free alternatives that fostered rapid innovation and community-driven portability—advantages NeWS lacked due to its proprietary licensing, which Sun never open-sourced despite internal advocacy. This open ecosystem displaced proprietary windowing solutions like NeWS, which remained confined to Sun hardware without the collaborative momentum that propelled X11's dominance.

Influence on Later Systems

NeWS pioneered the concept of programmable user interfaces through its use of as a full programming language for rendering and event handling on the display server, allowing dynamic UI modifications without recompiling client applications. This approach enabled remote execution of code across networked machines, where clients could send snippets to the server for immediate rendering, facilitating environments. These innovations influenced Adobe's (DPS), a commercial extension of PostScript for interactive displays, which was licensed and integrated into NeXTSTEP's , providing the foundation for high-fidelity graphics that later evolved into macOS's imaging model. Key innovations in NeWS, such as pie menus developed by Don Hopkins, offered radial selection interfaces that reduced selection times and errors compared to linear menus, as demonstrated in empirical studies. These were integrated into the HyperTIES hypermedia system, an early browser built on NeWS that supported linked documents and interactive navigation, serving as a precursor to web technologies by emphasizing hypermedia structures and gesture-based controls. Additionally, NeWS's extensions, using PostScript dictionaries for classes, , and subclassing (e.g., custom windows like VideoWindow), provided a model for extensible UI components that echoed in later toolkits, including Java Swing's hierarchical, lightweight component architecture created by the same designer, . In modern contexts, NeWS's emphasis on simplicity and direct rendering resonated in Gosling's 2002 essay, where he reflected on redesigning systems with minimal overhead and local rendering libraries, principles that align with Wayland's for efficient, protocol-light management. The system's client- separation, with remote execution handling UI logic on the while clients managed input, prefigured asynchronous updates in web applications, akin to AJAX's background exchanges that separate from -side processing. Documentation, sample PostScript scripts, and examples from NeWS, as preserved in the 1989 "The NeWS Book" and historical archives, have contributed to its study in UI history, highlighting lessons in extensibility, networked rendering, and toolkit design that inform contemporary research on programmable displays. The 1989 "The NeWS Book" documents these elements, including sample programs and the Lite toolkit, ensuring their availability for analysis of early object-oriented window systems.

References

  1. [1]
    The NeWS Book: An Introduction to the Network/Extensible Window ...
    Sep 28, 2011 · The NeWS Book leads the technical reader through the discovery of a revolutionary window system: the Network extensible Window System, ...
  2. [2]
    A Conversation with James Gosling - ACM Queue
    Aug 31, 2004 · Over the years he also wrote the original Unix Emacs, and was the lead engineer of NeWS (network-extensible window system). Today he is a ...
  3. [3]
    [PDF] t SPRINGER-VERLAG
    Gosling, James. The NeWS book: an introduction to the Networked Extensible Window. System 1 James Gosling, David S.H. Rosenthal, Michelle J. Arden. p. cm ...
  4. [4]
    [PDF] NeWS™ 1.1· Manual - Bitsavers.org
    Jan 15, 1988 · Sun View 1 windows appear to update the display simultaneously with NeWS can- vases. Sun View 1 windows are surrounded by a white margin to ...Missing: SPARC | Show results with:SPARC
  5. [5]
    SunOS - Computer History Wiki
    Nov 20, 2023 · Release date, Code base, Description. Sun UNIX 0.7, 1982, UniSoft UNIX v7 ... SunOS 3.2, Sep 1986, Same as 3.0, plus some 4.3BSD, First support ...
  6. [6]
    Section 2. Sun and standardization wars - ACM Digital Library
    The Open Look Tool kit was re- leased in 1987, and the battle between Open Look and Motif began. Open Look was limited to a single company, since. Sun had ...
  7. [7]
    [PDF] Object Oriented Programming in NeWS Owen M. Densmore Sun ...
    The NeWS† window system provides the primitives needed to create window managers and user-interface toolkits, but does not, itself, supply either.Missing: multitasking | Show results with:multitasking
  8. [8]
    [PDF] Frame Technology and FrameMaker - Walden Family
    The period between our founding in 1986 and our IPO saw an explosion of competing windowing systems for Unix workstations, such as SunView, OpenLook, XWindows,.
  9. [9]
    HyperLook (aka HyperNeWS (aka GoodNeWS)) - Art.Net
    HyperLook is an interactive application design system, that lets you develop advanced multimedia systems, via simple direct manipulation, property sheets, and ...
  10. [10]
    [PDF] HSB SPE L - NeXT Computers
    The port of Altsys Virtuoso to Sun's Open Windows demonstrates that it is possible to develop a program on NeXTSTEP and then transport it to another ...
  11. [11]
    OPEN LOOK GUI FAQ 01/04: General
    Apr 3, 2025 · The NeWS Toolkit (TNT) was an object ... The UIT also includes features that simplify event management and the use of PostScript and color.<|control11|><|separator|>
  12. [12]
    [PDF] The X Window System, Version 11 - Bitsavers.org
    Dec 10, 1990 · X is used on high performance workstation displays as well as terminals, and client programs run on everything from micro to super computers.Missing: programmability | Show results with:programmability
  13. [13]
    The mysterious history of the MIT License | Opensource.com
    Apr 26, 2019 · Version 1 of X came out in June 1984. The software reached version 11 in 1987 (hence "X11," as all subsequent releases have been called). Minor ...
  14. [14]
    Sun's NeWS was a mistake, as are all toolkit-in-server windowing ...
    Mar 1, 2020 · This article exhibits some common misconceptions about NeWS. NeWS had what amounted to uploadable toolkits, and therefore could and did have multiple toolkits.
  15. [15]
    X Window System User's Guide for X11 R3 and R4 of the X ... - O'Reilly
    X11 has been adopted as an industry-standard windowing system. X is supported by a consortium of industry leaders such as DEC, Hewlett-Packard. Sun, IBM.
  16. [16]
    None
    Summary of each segment:
  17. [17]
    XConsortium - X.Org
    Sep 15, 2013 · All rights to the X Window System were assigned by MIT to X Consortium, Inc. on January 1, 1994. X Consortium, Inc. closed its doors on ...Missing: 1987 | Show results with:1987
  18. [18]
    X Window System At 40 - DSHR's Blog
    Jul 2, 2024 · On 19th June the X Window System celebrated its 40th birthday. Wikipedia has a comprehensive history of the system including the e-mail Bob ...
  19. [19]
    History Of Window Systems
    ### Summary of NeWS Window System from https://blog.dshr.org/2021/03/history-of-window-systems.html
  20. [20]
    OSF/Motif Style Guide: Revision 1.0 - Google Books
    OSF/Motif Style Guide: Revision 1.0. Front Cover. Open Software Foundation. Prentice Hall, 1990 - Computers - 166 pages. Programmers are guided in the design of ...
  21. [21]
    History of Adobe Systems Inc. - FundingUniverse
    In the mid-1990s Adobe continued to grow through acquisitions and worked to strengthen its position in the volatile software industry. The acquisition of Frame ...
  22. [22]
    [PDF] Open Windows Version 3 Installation and Start-Up Guide
    This manual tells you how to install and start up your Open Windows ™ environment. Basic Open Windows Components. The OpenWindows environment is Sun's network- ...Missing: abandonment | Show results with:abandonment
  23. [23]
    How NeWS became yesterday's news in the window system wars
    Jul 10, 2024 · And yet it failed in the marketplace, whereas the X Window System has been an enduring success over the last three decades. NeWS was ...
  24. [24]
    NeWS - Network extensible Window System - Art on the Net
    NeWS is the Network extensible Window System, written by James Gosling and David Rosenthal, at Sun. ... Date: Sat 12 Dec 1987 17:01:36 EST From: David ...Missing: Microsystems | Show results with:Microsystems
  25. [25]
    Designing to Facilitate Browsing: A Look Back at the Hyperties ...
    Apr 21, 2018 · The more recent NeWS version of Hyperties on the SUN workstation uses two large windows that partition the screen vertically. Each window can ...
  26. [26]
    None
    ### Summary of NeWS Design, Technical Aspects, and Potential Issues