Hubbry Logo
GEM (desktop environment)GEM (desktop environment)Main
Open search
GEM (desktop environment)
Community hub
GEM (desktop environment)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
GEM (desktop environment)
GEM (desktop environment)
GEM (desktop environment)
View on Wikipedia
from Wikipedia

GEM
DevelopersDigital Research
Lee Jay Lorenzen
Initial release28 February 1985; 40 years ago (1985-02-28)[1]
Stable release
GEM/3 3.11 / 3 November 1988; 36 years ago (1988-11-03)
Operating systemMS-DOS, Concurrent DOS, FlexOS, CP/M-68K, GEMDOS, TOS
PlatformIntel 8088, Motorola 68000
TypeWindowing system
LicenseGPL-2.0-only
Websitewww.deltasoft.com

GEM (for Graphics Environment Manager[2]) is a discontinued operating environment released by Digital Research in 1985. GEM is known primarily as the native graphical user interface of the Atari ST series of computers, providing a WIMP desktop. It was also available for IBM PC compatibles[3][4] and shipped with some models from Amstrad. It was available on the BBC Master computer with an Intel 80186 co-processor. GEM is used as the core for some commercial MS-DOS programs, the most notable being Ventura Publisher. It was ported to other computers that previously lacked graphical interfaces, but never gained traction. The final retail version of GEM was released in 1988.

Digital Research later[when?] produced X/GEM for their FlexOS[3][5] real-time operating system with adaptations for OS/2 Presentation Manager[6][3] and the X Window System under preparation as well.[3]

History

[edit]

GSX

[edit]
GSX and CBASIC workflow diagram
GSX advertisement in 1982

In late 1984, GEM started life at DRI as an outgrowth of a more general-purpose graphics library known as GSX (Graphics System Extension),[7] written by a team led by Don Heiskell since about 1982.[8] Lee Jay Lorenzen (at Graphic Software Systems) who had recently left Xerox (the birthplace of the modern GUI) wrote much of the code. GSX was essentially a DRI-specific implementation of the GKS graphics standard proposed in the late 1970s. GSX was intended to allow DRI to write graphics programs (charting, etc.) for any of the 8-bit and 16-bit platforms CP/M-80, Concurrent CP/M, CP/M-86 and MS-DOS (NEC APC-III) would run on,[9] a task that otherwise would have required considerable effort to port due to the large differences in graphics hardware (and concepts) between the various systems of that era.[7]

GSX consisted of two parts: a selection of routines for common drawing operations, and the device drivers that are responsible for handling the actual output. The former was known as GDOS (Graphics Device Operating System) and the latter as GIOS (Graphics Input/Output System),[10] a play on the division of CP/M into the machine-independent BDOS (Basic Disk Operating System) and the machine-specific BIOS (Basic Input/Output System).[7] GDOS was a selection of routines that handled the GKS drawing, while GIOS actually used the underlying hardware to produce the output.[7]

Known 8-bit device drivers

[edit]

Known 16-bit device drivers

[edit]

The DOS version of GSX supports loading drivers in the CP/M-86 CMD format. Consequently, the same driver binary may operate under both CP/M-86 and DOS.[14]

GEM

[edit]

Intel versions

[edit]

The 16-bit version of GSX 1.3[7][9] evolved into one part of what would later be known as GEM, which was an effort to build a full GUI system using the earlier GSX work as its basis. Originally known as Crystal as a play on an IBM project called Glass, the name was later changed to GEM.

Under GEM, GSX became GEM VDI (Virtual Device Interface), responsible for basic graphics and drawing.[10] VDI also added the ability to work with multiple fonts and added a selection of raster drawing commands to the formerly vector-only GKS-based drawing commands. VDI also added multiple viewports, a key addition for use with windows.[15]

A new module, GEM AES (Application Environment Services), provided the window management and UI elements, and GEM Desktop used both libraries in combination to provide a GUI.[16] The 8086 version of the entire system was first officially demoed at COMDEX in November 1984,[4][3] following a demonstration on the 80286-based Acorn Business Computer in September 1984 where the software had been attributed to Acorn,[17] and the system was shipped as GEM/1 on 28 February 1985.[1]

GEM/1
[edit]
GEM 1.1 Desktop running in 640×350 EGA resolution

GEM Desktop 1.0 was released on 28 February 1985.[1] GEM Desktop 1.1 was released on 10 April 1985 with support for CGA and EGA displays.[18][19] A version for the Apricot Computers F-Series, supporting 640×200 in up to 8 colors, was also available as GEM Desktop 1.2.[20]

Digital Research also positioned Concurrent DOS 4.1 with GEM as alternative for IBM's TopView.[21]

DRI originally designed GEM for DOS so that it would check for and only run on IBM computers, and not PC compatibles like those from Compaq, as the company hoped to receive license fees from compatible makers. Developers reacted with what BYTE described as "a small explosion"; it reported that at a DRI-hosted seminar in February 1985, more than half of the attendees agreed that GEM's incompatibility with Compaq was a serious limitation. Later that month the company removed the restriction.[22] Applications that supported GEM included Lifetree Software's GEM Write.[23]

At this point, Apple Computer sued DRI[24][unreliable source?] in what would turn into a long dispute over the "look and feel" of the GEM/1 system, which was an almost direct copy of Macintosh (with some elements bearing a closer resemblance to those in the earlier Lisa, available since January 1983). This eventually led to DRI being forced to change several basic features of the system.[25][26][27][28][24] (See also: Apple v. Digital Research.) Apple would later go on to sue other companies for similar issues, including their copyright lawsuit against Microsoft and HP.

In addition to printers the system also contained drivers for some more unusual devices such as the Polaroid Palette.[13]

GEM/2
[edit]
GEM 2.0 displaying its Desktop Info dialog. This version of GEM supports 640×480 16-color VGA.

DRI responded with the "lawsuit-friendly" GEM Desktop 2.0, released on 24 March 1986, which eventually added support for VGA, sometime after its release in 1987.[29] It allowed the display of only two fixed windows on the "desktop" (though other programs could do what they wished), changed the trash can icon, and removed the animations for things like opening and closing windows. It was otherwise similar to GEM/1, but also included a number of bug fixes and cosmetic improvements.

In 1988 Stewart Alsop II said that GEM was among several GUIs that "have already been knocked out" of the market by Apple, IBM/Microsoft, and others.[30]

GEM XM
[edit]

GEM XM with "GEM Desktop 3.0" was an updated version of GEM/2 in 1986/1987 for DOS (including DOS Plus) which allowed task-switching and the ability to run up to ten GEM and DOS programs at once, swapping out to expanded memory (XM) through EMS/EEMS or to disk (including RAM disks, thereby also allowing the use of extended memory).[31][32][33][34] Data could be copied and pasted between applications through a clipboard with filter function (a feature later also found in TaskMAX under DR DOS 6.0).[32] Digital Research planned to offer GEM XM as an option to GEM Draw Plus users and through OEM channels.[31]

The GEM XM source code is now freely available under the terms of GNU General Public License.

See also: Concurrent DOS XM
GEM/3
[edit]
GEM 3.11 displaying its Desktop Info dialog

The last retail release was GEM/3 Desktop, released on 3 November 1988,[35] which had speed improvements and shipped with a number of basic applications. Commercial sales of GEM ended with GEM/3; the source code was subsequently made available to a number of DRI's leading customers.

While GEM/2 for the PC still provided a GSX API in addition to the GEM API; GEM/3 no longer did.[10]

GEM/4 for CCP Artline
[edit]

GEM/4, released in 1990, included the ability to work with Bézier curves, a feature still not commonly found outside the PostScript world.[citation needed] This version was produced specifically for Artline 2, a drawing program from the German company CCP Development GmbH.[36][37][38][39][40][41][42]

The system also included changes to the font management system, which made it incompatible with the likes of Timeworks Publisher.

Artline 1 still ran on GEM 3.1.[39]

GEM/5 for GST Timeworks Publisher
[edit]

Another version of GEM called GEM/5[43] was produced by GST Software Products for Timeworks' Publisher 2.1. It contained an updated look with 3D buttons, along with features such as on-the-fly font scaling. It came complete with all the standard GEM 3.1 tools. This version was produced from GEM 3.13 with only the Bézier handling taken from GEM/4.

ViewMAX for DR DOS
[edit]
Main article: ViewMAX
Screenshot of ViewMAX file manager with user-defined colors

GEM Desktop itself was spun off in 1990 as a product known as ViewMAX which was used solely as a file management shell under DR DOS. In this form the system could not run other GEM programs. This led to a situation where a number of applications (including ViewMAX) could exist all with their own statically linked copy of the GEM system. This scenario was actually rare, as few native GEM programs were published. In 1991, ViewMAX 2 was released.

In these forms, GEM survived until DRI was purchased by Novell in June 1991[44][45] and all GEM development was cancelled.

X/GEM
[edit]

Throughout this time DRI had also been working on making the GEM system capable of multitasking. This started with X/GEM based on GEM/1, but this required use of one of the multitasking CP/M-based operating systems.[clarification needed] DRI also produced X/GEM for their FlexOS[3][5] real-time operating system with adaptations for OS/2 Presentation Manager[6][3] and the X Window System under preparation as well.[3]

Ventura Publisher
[edit]

Lee Lorenzen left soon after the release of GEM/1, when it became clear that DRI had no strong interest in application development. He then joined with two other former DRI employees, Don Heiskell and John Meyer, to start Ventura Software. They developed Ventura Publisher (which was later marketed by Xerox and eventually by Corel), which would go on to be a very popular desktop publishing program for some time.

Atari versions

[edit]
TOS 4.92 (Atari Falcon) running HomePage Penguin and Desktop
Main article: Atari TOS

Development of the production 68000 version of GEM began in September 1984, when Atari sent a team called "The Monterey Group" to Digital Research to begin work on porting GEM. Originally, the plan was to run GEM on top of CP/M-68K, both ostensibly ported to Motorola 68000 by DRI prior to the ST design being created. In fact, these ports were unusable and would require considerable development. Digital Research also offered GEMDOS (originally written as GEM DOS, it was also called "Project Jason"), a DOS-like operating system aimed to port GEM to different hardware platforms. It was available for 8086 and 68000 processors and had been adapted to the Apple Lisa 2/5 and the Motorola VME/10[46] development system.[47] Atari decided in January 1985[48] to give up on the existing CP/M-68K code and instead port DRI GEMDOS to the Atari ST platform, referring to it as TOS.[49]

As Atari had provided most of the development of the 68000 version, they were given full rights to continued developments without needing to reverse-license it back to DRI. As a result, the Apple-DRI lawsuit did not apply to the Atari versions of GEM, and they were allowed to keep a more Mac-like UI.

Over the next seven years, from 1985 to 1992, new versions of TOS were released with each new generation of the ST line. Updates included support for more colors and higher resolutions in the raster-side of the system, but remained generally similar to the original in terms of GKS support. In 1992, Atari released TOS 4, or MultiTOS, along with their final computer system, the Falcon030. In combination with MiNT, TOS 4 allowed full multitasking support in GEM.

Continued development

[edit]
Screenshot of OpenGEM 5

When Caldera bought the remaining Digital Research assets from Novell on 23 July 1996,[50] initial plans were to revive GEM and ViewMAX technologies for a low-footprint user interface for OpenDOS in mobile applications[51][52] as Caldera View, but these plans were abandoned by Caldera UK in favour of DR-WebSpyder and GROW. Caldera Thin Clients (later known as Lineo) released the source to GEM and GEM XM under the terms of GNU GPL-2.0-only in April 1999.[52] The development of GEM for PC continues as FreeGEM and OpenGEM.

On the Atari ST platform, the original DRI sources were ported again to be used in the free and open source TOS clone EmuTOS. New implementations of the AES portions of GEM have been implemented from scratch in the form of XaAES, and MyAES,[53] both of which are fully re-entrant and support multitasking on top of the FreeMiNT multitasking extensions to TOS.

Description

[edit]

The "full" GEM system consisted of three main parts:

  1. GEM VDI (Virtual Device Interface)
  2. GEM AES (Application Environment Services)
  3. GEM Desktop (an application providing drag-and-drop file management)

GEM VDI was the core graphics system of the overall GEM engine. It was responsible for "low level" drawing in the form of "draw line from here to here". VDI included a resolution and coordinate independent set of vector drawing instructions which were called from applications through a fairly simple interface. VDI also included environment information (state, or context), current color, line thickness, output device, etc.

These commands were then examined by GDOS, whose task it was to send the commands to the proper driver for actual rendering. For instance, if a particular GEM VDI environment was connected to the screen, the VDI instructions were then routed to the screen driver for drawing. Simply changing the environment to point to the printer was all that was needed (in theory) to print, dramatically reducing the developer workload (they formerly had to do printing "by hand" in all applications). GDOS was also responsible for loading up the drivers and any requested fonts when GEM was first loaded.

One major advantage VDI provided over the Macintosh was the way multiple devices and contexts were handled. In the Mac such information was stored in memory inside the application. This resulted in serious problems when attempting to make the Mac handle pre-emptive multitasking, as the drawing layer (QuickDraw) needed to have direct memory access into all programs. In GEM VDI however, such information was stored in the device itself, with GDOS creating "virtual devices" for every context – each window for instance.

GEM AES provided the window system, window manager, UI style and other GUI elements (widgets). For performance reasons, many of the GUI widgets were actually drawn using character graphics. Compared to the Macintosh, AES provided a rather spartan look and the system shipped with a single monospaced font.

AES performs its operations by calling the VDI, but in a more general sense the two parts of GEM were often completely separated in applications. Applications typically called AES commands to set up a new window, with the rest of the application using VDI calls to actually draw into that window.

GEM Desktop was an application program that used AES to provide a file manager and launcher, the traditional "desktop" environment that users had come to expect from the Macintosh. Unlike the Macintosh, the GEM Desktop ran on top of DOS (MS-DOS, DOS Plus or DR DOS on the PC, GEMDOS/TOS on the Atari), and as a result the actual display was cluttered with computer-like items, including path names and wildcards. In general, GEM was much more "geeky" than the Mac, but simply running a usable shell on DOS was a huge achievement on its own. Otherwise, GEM has its own advantages over Mac OS such as proportional sliders.

Native PC GEM applications use the file extension .APP for executables, whereas GEM desktop accessories use the file extension .ACC instead.[54][55] All desktop accessories (and also a few simple applications) can be run under ViewMAX without modification.[54][55]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

GEM (desktop environment)

View on Grokipedia
from Grokipedia
GEM (Graphical Environment Manager) is a pioneering (GUI) and developed by , Inc. (DRI), first released on February 28, 1985, for personal computers running , , and other operating systems, featuring overlapping windows, pull-down menus, icons, and a desktop file manager to provide an intuitive (windows, icons, menus, pointer) interaction model. It was designed to bring graphical computing to PC compatibles and was licensed to OEMs, most notably for their ST line of computers, where it powered the TOS operating system until the early 1990s. Evolving from DRI's earlier GSX graphics subsystem released in 1983, GEM was spearheaded by project lead Don Heiskell and primary developer Lee Jay Lorenzen, a former PARC engineer, with its architecture divided into the Virtual Device Interface (VDI) for handling, Application Environment Services (AES) for user interface elements, and the Desktop accessory for file management. The system supported a range of hardware, including EGA and VGA cards, resolutions up to 1600x1200, and programming in languages like and C, while early versions required about 127 KB of memory alongside . GEM's debut at in November 1984 showcased its similarities to the Apple Macintosh interface, which led to a 1986 lawsuit from Apple; the settlement prompted design modifications in GEM 2.0 (released March 1986), such as removing the trash can icon, though it retained core functionalities like raster drawing, fonts, and viewports. GEM 2 (1986) added initial VGA support, while multitasking was provided by the separate GEM/XM extension (1987); GEM 3 (1988) included further enhancements like bundled applications. Subsequent versions expanded capabilities: GEM/4 (1990) introduced Bézier curves and 24-bit color, while a custom GEM/5 (1990) for specific applications like Timeworks Publisher featured a 3D interface; meanwhile, ViewMAX (1990), a GEM-based shell bundled with , provided graphical file management before DRI's acquisition by in 1991 diminished its prominence. Despite competing directly with (also 1985) and influencing applications like Ventura Publisher, GEM's market share waned due to limited application support, marketing challenges, and the rise of in 1990, though its source code has since been open-sourced and it remains emulatable for historical study.

History

Origins in GSX

GSX, or Graphics System Extension, was developed by as a device-independent graphics library to enable portable graphical applications across diverse hardware platforms. Initially released for the 8-bit CP/M-80 operating system in November 1982 through a collaboration with Graphic Software Systems, Inc., it laid the groundwork for standardized output on early microcomputers. The 16-bit version, GSX-86, followed in July 1983 specifically for , targeting /8088-based systems like the PC, and was bundled as an extension to provide enhanced capabilities without hardware-specific coding. At its core, GSX featured the Virtual Device Interface (VDI), a standardized set of function calls that abstracted operations such as line drawing, text rendering, and area filling, allowing applications to issue device-agnostic commands. The VDI supported vector-based drawing for scalable output and included utilities like the Graphics Device Operating System (GDOS) for high-level interface management and the Graphics Input/Output System (GIOS) for loading device-specific drivers dynamically. While GSX primarily focused on , it integrated with CP/M's file handling mechanisms, later evolving into GEMDOS for more robust disk and I/O operations in subsequent systems. This separation of graphics logic from hardware dependencies was pivotal, enabling developers to create portable software that functioned consistently on printers, plotters, and displays without recompilation. GSX's portability was achieved through installable device drivers, which translated VDI calls into hardware-specific instructions. For 8-bit CP/M-80 systems, drivers targeted printers and plotters, supporting features like multiple line styles, marker sizes, text rotation in 90-degree increments, and hatch patterns. Known 8-bit drivers included:
Device TypeExample DriverSupported Resolution (dpi or coordinates)Key Features
PrinterEpson MX-80960 x 2160 pixels6 character sizes, 5 line styles, polylines, fill areas
PlotterHP 72201016 x 787 coordinatesContinuous scaling, 7 line styles, 8 pens, markers, text
PlotterHP 7470A1219 x 787 coordinatesUnlimited pens, polylines, text
PlotterHouston DMP-3/41016 x 787 coordinates5 character sizes, 9 line styles, 6 pens
TerminalVT100 w/ Retrographics1023 x 779 pixels4 character sizes, 5 line styles, monochrome, fill areas
For 16-bit systems, drivers expanded to include graphics adapters and supported both modes for raster displays and vector modes for precise plotting. These handled higher resolutions and color capabilities, with features like extended marker sizes (up to 190 pixels) and multi-device output. Representative 16-bit drivers encompassed:
Device TypeExample DriverSupported ResolutionKey Features
MonitorIBM PC Color/Graphics Adapter320 x 200, 4 colors mode, text, polylines, fill areas
MonitorIBM PC Monochrome640 x 200, 2 colors mode, high-resolution text
Monitor720 x 348 monochromeHigh-resolution , vector support
Printer High Res120 x 144 dpi12 character sizes, hatch patterns, rotation
PlotterHP 7470AVector scalable182 marker sizes, 6 line styles
By abstracting hardware variations, GSX significantly influenced the development of graphical software ecosystems, serving as the foundational graphics layer upon which the GEM desktop environment was later constructed to provide a unified user interface.

Initial GEM Development

Digital Research announced GEM (Graphical Environment Manager) in September 1984, with a public demonstration at the COMDEX trade show in November of that year. The initial version, GEM 1.0, was released on February 28, 1985, as a graphical desktop environment compatible with both CP/M-86 and MS-DOS operating systems on Intel 8086-based personal computers. Under the oversight of founder , the project was led by key developers including Lee Jay Lorenzen, who had prototyped an early graphical interface called "" in 1983 after joining the company from . Lorenzen's work integrated the Virtual Device Interface (VDI) from Digital Research's prior GSX graphics subsystem, enabling device-independent rendering and portability across hardware. Additional contributions came from team members such as Don Heiskell and , focusing on the core architecture for the 8086 processor family. GEM 1.0 introduced a menu-driven interface with drop-down menus accessible via a top , allowing users to navigate commands without command-line input. It supported windowing for overlapping or tiled application windows, enabling basic multitasking-like behavior, and featured icon-based file management on a , where files and folders were represented by pictorial icons for intuitive drag-and-drop operations. These elements provided a (what you see is what you get) experience with control, high-resolution graphics, and color support where hardware permitted. The licensing model emphasized OEM bundling, with offering runtime licenses to hardware manufacturers for $500 per developer toolkit or $1,000 annually per product, facilitating widespread integration. GEM was bundled with systems such as the Atari ST series, Amstrad PC 1512, Apricot PCs, and Tandy computers, contributing to its rapid adoption as one of the first commercial GUIs for personal . Early challenges included hardware constraints on 8086 and 8088 processors, where the environment required about 128 KB of alongside .

Platform-Specific Evolutions

Following the initial release of GEM 1.0 in 1985, which established the foundational event-driven model for graphical interfaces, subsequent versions introduced iterative enhancements to address hardware limitations and user feedback while navigating legal constraints. GEM 2.0, released in March 1986, incorporated bug fixes for stability issues, including improvements to functionality and driver compatibility for emerging display adapters. These updates were partly driven by a 1986 settlement with Apple Computer, which required modifications to certain interface elements to avoid similarities with the Macintosh, resulting in a more restrained but reliable evolution of the . GEM 2.0 added support for dialog boxes to handle user interactions and warnings more effectively, alongside a simulated multitasking capability through desk accessories that allowed limited concurrent operations, such as background , provided sufficient RAM (at least 320 KB). The version also enabled desktop icons in compatible configurations for representing files, folders, and drives, enhancing intuitive despite the legal restrictions that limited overlapping windows and animations in some implementations. Minor updates followed, such as GEM 2.1 later in 1986, which refined the with a new system font and further driver optimizations for better compatibility with PC hardware variations. These changes prioritized robustness over expansive features, reflecting Digital Research's focus on broadening adoption amid evolving DOS ecosystems. By 3.0, released on November 3, 1988, for systems, the environment evolved to leverage VGA graphics capabilities, supporting resolutions up to 640x480 and color palettes expandable to 256 colors through enhanced Virtual Device Interface (VDI) drivers. This version introduced font scaling options, allowing adjustable point sizes (from 8 to 72) in applications like GEM Write and GEM Draw, which improved text rendering across varying display and printer outputs. Additional minor releases, including 3.1 in 1989, addressed compatibility with soft fonts and bit-mapped printing drivers, ensuring smoother integration with high-resolution peripherals while fixing residual issues in graphics rendering. These advancements maintained GEM's portability but highlighted ongoing challenges in optimizing on resource-constrained systems. Cross-platform adaptations posed significant challenges, particularly in porting GEM's to diverse CPU architectures like the 68000 processor in ST systems. The VDI layer facilitated this by abstracting graphics and input handling, enabling GEM to run under TOS on hardware with minimal code changes, though optimizations were needed to handle the 68000's addressing modes and structures differently from x86-based PCs. This portability supported overlapping windows and menu-driven interactions across platforms but required custom drivers to mitigate timing discrepancies in event processing, ensuring consistent responsiveness. Official support for GEM declined by 1990, as competition from Microsoft's overshadowed its market position, leading Digital Research to shift focus toward integrated solutions like ViewMAX. Novell's acquisition of in 1991 effectively ended active development, though the technology influenced later clones and ports.

Core Features

Graphical User Interface Elements

GEM's is founded on the (Windows, Icons, Menus, Pointer) paradigm, which facilitates mouse-driven navigation and interaction through visual elements rather than command-line inputs. This model, inspired by earlier systems like the , emphasizes intuitive point-and-click operations enabled by a such as a . The menu bar employs a pull-down structure, where selecting a title reveals a list of options, supporting accelerator keys for keyboard shortcuts to enhance efficiency. It accommodates up to 10 menu titles, with each holding as many as 30 items, allowing applications to organize commands hierarchically while maintaining a compact top-level bar. The rightmost title typically serves as the desk accessory menu, providing quick access to utilities without disrupting primary workflows. Window management in GEM supports overlapping and resizable windows, each featuring a for identification and manipulation, vertical and horizontal scroll bars for content navigation, and a close button to terminate the view. The system handles a maximum of eight windows simultaneously, including the desktop as handle zero, with users able to move windows by dragging the title bar, resize via corner boxes, and toggle full or partial views through dedicated controls. These elements ensure flexible multitasking within the constraints of early personal computing hardware. The icon system utilizes 32x32 icons to represent files, folders, and applications on the desktop, promoting visual recognition over textual labels. Drag-and-drop functionality allows users to launch programs by dragging icons to the desktop or move files between windows by dragging them directly, streamlining common operations like file management. Dialog boxes in GEM come in modal varieties, which halt interaction until dismissed, and modeless types that permit continued work elsewhere, incorporating user input controls such as sliders for proportional adjustments, radio buttons for exclusive selections, and editable text fields for data entry. These boxes, sized up to the full desktop extent, use resource files to define layouts and behaviors, ensuring consistent and responsive feedback across applications.

Application Integration

The Application Environment Services (AES) formed the core API layer of GEM, enabling developers to create graphical applications that interacted seamlessly with the desktop environment through a standardized set of functions for managing windows, menus, dialogs, and user events. AES was structured as a collection of 12 subroutine libraries, including those for applications, events, menus, and resources, which handled the higher-level aspects of user interface programming without delving into low-level graphics rendering. This API allowed applications to integrate with GEM's graphical user interface elements, such as icons and windows, by providing consistent mechanisms for event handling and inter-process communication. Central to AES was its message passing system, which facilitated communication between the AES kernel, applications, and the desktop shell via a dedicated message pipe. Messages were fixed at 16 bytes in length, with the first three words specifying the message type, sender application ID, and length; predefined protocols included WM_REDRAW (message code 20), which notified an application to redraw a specific region following events like resizing or uncovering. The system maintained an event queue for processing inputs, including mouse movements (with X/Y coordinates), keyboard scan codes, button presses, and timer ticks in milliseconds; developers accessed these through functions like appl_read (opcode 11) to retrieve messages from the pipe and appl_write (opcode 12) to send them. For multi-event detection, the EVNT_MULTI function (opcode 25) allowed applications to wait on combinations of events, such as keyboard input (flag MU_KEYBD) or buttons (flag MU_BUTTON), ensuring responsive behavior in the single-tasking environment. Resource files in the binary .RSC format were integral to application integration, storing structured data for user interface elements like menus, dialogs, and icons in object trees that could be tailored for different resolutions (e.g., 640x200 or 640x400 pixels). Developers loaded these files using RSRC_LOAD (opcode 110), retrieved addresses for components via RSRC_GADDR (opcode 112), and freed them with RSRC_FREE (opcode 111); the files contained data structures such as OBJECT for layout and TEDINFO for text fields. The GEM Resource Construction Set (RCS), a dedicated editor tool, enabled the design and compilation of these resources, allowing programmers to visually assemble dialogs and menus before generating the binary .RSC files for runtime use in applications and desk accessories. Basic AES integration began with initializing an application via appl_init (opcode 10), which set up the parameter block, established communication with the AES kernel, and returned an application ID (ap_id) for subsequent calls; a typical startup sequence might follow with wind_create (opcode 100) to define a window and wind_open (opcode 101) to display it. Sample code in C, such as that from the GEM Programmer's Toolkit demos like HELLO.APP, illustrated this process:

c

#include <aes.h> int main() { int ap_id; ap_id = appl_init(); if (ap_id > 0) { // Create and open a window int handle = wind_create(0x0007, 0, 0, 200, 100); // NAME | MOVER | SIZER flags wind_open(handle, 50, 50, [300](/page/300), 150); // [Event loop](/page/Event_loop) appl_exit(); } [return 0](/page/Return_0); }

#include <aes.h> int main() { int ap_id; ap_id = appl_init(); if (ap_id > 0) { // Create and open a window int handle = wind_create(0x0007, 0, 0, 200, 100); // NAME | MOVER | SIZER flags wind_open(handle, 50, 50, [300](/page/300), 150); // [Event loop](/page/Event_loop) appl_exit(); } [return 0](/page/Return_0); }

This snippet demonstrates initialization, window creation, and basic event handling, with the application exiting via appl_exit (opcode 19) to cleanly terminate. Despite its strengths, AES operated in a fundamentally single-tasking framework, where only one foreground application could execute at a time, limiting true concurrency and requiring developers to manage state manually during event processing. Pseudo-multitasking was achieved through desk accessories—small, always-available utilities like a clock or —limited to six simultaneous instances and requiring at least 128 KB of free RAM; these ran in the background via the AES kernel's dispatcher but could not perform complex operations without suspending the main application. This design constrained resource-intensive integrations, such as background , which needed 320 KB RAM and a hard drive for reliability.

Device and Hardware Support

The Virtual Device Interface (VDI) in GEM serves as the core mechanism for device and hardware support, enabling device-independent interaction with peripherals through layered abstractions for input, output, and metafile handling. The input layer manages devices such as mice and keyboards via functions like locator requests for cursor positioning and key status queries, while also supporting valuator devices for analog inputs and string devices for text entry. Output layers handle raster operations for pixel-based rendering on screens and printers, as well as vector operations for line and shape drawing on plotters. Metafile devices facilitate the creation and storage of graphics in a portable, device-agnostic format, allowing output to be redirected or archived without hardware-specific dependencies. This architecture, building on Digital Research's earlier Graphics System Extension (GSX), ensures portability across supported platforms. GEM supports a variety of peripherals through VDI-compatible drivers, including impact printers like the FX-80 and FX/LQ series for dot-matrix output, plotters such as the 7470A for vector plotting, and digitizers including the Summagraphics MM Series tablets for precise input capture. These devices are interfaced via RS-232C serial ports (limited to COM1 and COM2) or parallel connections, with drivers translating high-level VDI calls into hardware commands for tasks like hardcopy printing or tablet coordinate sampling. Resolution and mode support in GEM adapt to the underlying hardware, ranging from basic modes at 320x200 to color-capable configurations like 640x200 with 16 colors or 640x350 with up to 16 colors on enhanced graphics adapters. Higher-end systems, such as those with EGA or cards, extend to 720x348 or 640x480 color modes. The VDI employs normalized device coordinates (spanning 0 to 32767 units per axis) for scalable rendering, with transformation modes allowing conversion to raster coordinates for direct addressing, though aspect ratio distortions may occur on non-square displays without compensation. GEM's is modular and runtime-loadable, relying on files with .DRV or extensions (e.g., printer) managed by the Graphics Device Operating System (GDOS) component within GEMVDI.EXE. These , typically 30-40 KB in size, include variants for 8-bit and 16-bit processors to support systems like the or 68000, and are configured via ASSIGN for device identification and loading into application space. Despite its flexibility, GEM exhibits known compatibility issues, such as screen flicker on interlaced displays—particularly observed in ST implementations where video output instability affects the GEM desktop—and limited joystick support, treated as valuator input devices but often lacking full integration with application event handling or precise control in gaming scenarios.

Implementations and Ports

Intel-Based Systems

GEM was initially implemented on Intel x86-based systems, targeting hardware such as the IBM PC and compatibles running or . Released in 1985 by , it provided a graphical shell environment atop these text-based operating systems, enabling point-and-click interaction with a mouse and icons on supported graphics adapters like the IBM Color Graphics Adapter or . The core GEM/1 version functioned as a lightweight , consuming approximately 127 KB of when combined with the underlying OS, allowing seamless integration with command-line applications like and while launching GEM-based graphical tools. Hardware requirements included at least 256 KB of RAM for 2.x systems, rising to 320 KB for 3.x, alongside compatibility with standard PC peripherals such as the . Subsequent versions enhanced performance and memory handling for evolving processors. GEM was optimized for the 8086 and 8088 CPUs prevalent in early PCs, leveraging the GSX subsystem for efficient rendering within the 1 MB limit of . Later iterations, including /3 released in , introduced support for expanded memory via the EMS specification, utilizing a Virtual Memory Manager (VMM) to access additional RAM beyond conventional limits, which was crucial for resource-intensive tasks on systems with LIM EMS 3.2 or 4.0 hardware. For 80286-based machines, GEM/XM (an extension of GEM/2 around 1986-1987) incorporated multitasking capabilities, enabling up to ten concurrent GEM and DOS programs through task-switching mechanisms that exploited the processor's for improved stability and , though still constrained by DOS's real-mode heritage. Notable applications built directly on GEM's APIs exemplified its role in professional software on x86 platforms. Ventura Publisher, developed in 1985 by Ventura Software and later acquired by , relied on GEM's graphical kernel (trimmed to 24 KB for efficiency) for its desktop publishing features, including style sheets and , making it a leading tool for long-document production under . Similarly, GEM Draw, part of Digital Research's own application suite, utilized the VDI (Virtual Device Interface) APIs for vector-based illustration and diagram creation, integrating seamlessly with other GEM tools like GEM Write for word processing. By 1986, GEM had gained significant traction among DOS users, with Digital Research projecting over a million installations amid competition from Microsoft's , though exact varied by OEM bundling and hardware adoption. Its peak popularity on systems highlighted GEM's accessibility for transitioning PC users to graphical workflows before the dominance of later Windows versions.

Atari ST Adaptation

The Atari ST adaptation of GEM formed the core of TOS (The Operating System), Atari's proprietary operating system released in 1985 alongside the debut of the 520ST computer. TOS integrated GEM as its desktop shell, building on the original Intel-based GEM developed by by porting it to the processor and tailoring it to Atari's hardware . This adaptation combined GEM's with GEMDOS for file handling and a /XBIOS layer for low-level hardware access, enabling a seamless GUI experience directly from ROM. GEM in TOS was specifically optimized for the Atari ST's diverse hardware configurations, providing native support for both color-capable models like the 520ST with its 320x200 resolution in 16 colors or 640x200 in 4 colors, and low-cost variants such as the 520STFM with a 640x400 display. The Virtual Device Interface (VDI) within GEM handled graphics rendering across these modes via Line A routines, ensuring consistent operation without requiring extensive application modifications. MIDI integration was a key hardware synergy, leveraging built-in MIDI ports connected to an MC6850 ACIA chip for real-time input/output, which XBIOS functions like Midiws() and Bconout() facilitated for applications. Later enhancements in TOS versions, such as 1.04 and beyond, capitalized on hardware upgrades like the dedicated chip introduced in the 1986 Mega ST and 1989 STE models, which accelerated bit-block transfers for faster screen redraws and graphics operations through optimized Line A calls. The GEMDOS component capabilities to support Atari's double-sided 3.5-inch floppy disks with FAT-based clustering (1024-byte sectors) and hard drives, using functions like Rwabs() for low-level sector access and Dsetdrv() for multi-drive management, enabling reliable data handling up to 16 drives. This adaptation made TOS and integral to Atari's creative software ecosystem, powering music production tools like Cubase via interfaces and desktop publishing applications that exploited the ST's modes. Third-party utilities, such as the NeoDesk from Gribnif Software, enhanced GEM's desktop functionality with advanced drag-and-drop features and improved file operations, becoming a staple for users in , CAD, and multimedia workflows.

Later Extensions and Clones

After official support for GEM ended in the early , several unofficial projects emerged to extend and recreate its functionality, leveraging releases and emulation technologies. These efforts preserved GEM's legacy on legacy hardware while adapting it to modern contexts, often focusing on open-source development and compatibility enhancements. The project, initiated in 1999, produced an open-source clone of GEM designed to run on and systems. Based on partial obtained from Thin Clients, Inc., it included a multitasking that supported running multiple GEM and DOS applications simultaneously, with features like integration and a DOS menu accessible via keyboard shortcuts. also incorporated compatibility layers allowing it to operate within environments, enabling legacy GEM applications to function in DOS emulation modes on later PCs. On the platform, clones like extended GEM's capabilities beyond its original single-tasking limitations. Developed by Gribnif Software, is a multitasking GEM AES (Application Environment Services) replacement that supports unlimited GEM applications and desk accessories, allowing up to 256 windows open at once with background manipulation and 3D interface elements. It employs , requiring less than 200 KB of memory, and is compatible with ST, TT, and hardware, including low-memory configurations starting at 1 MB; optionally, it integrates with the kernel for enhanced performance. Modern emulations have further sustained GEM through software recreations in the 2010s and beyond. Emulators such as PCem accurately simulate PC environments capable of running original GEM software on contemporary hardware, while provides cycle-accurate emulation of Atari ST systems, natively executing GEM-based applications and TOS (The Operating System). These tools, combined with ongoing source code distributions from projects like , have facilitated preservation and experimentation, with updates to the 1999 Caldera releases enabling compilation and modification for current platforms. Projects like OpenGEM continue to maintain and extend the codebase for modern DOS environments as of 2025. The legal framework enabling these extensions stemmed from the transfer of Digital Research's . Acquired by in for $80 million, the DRI assets—including —were sold to Systems in 1996. Caldera released the under the GNU General Public License in mid-April 1999, allowing open-sourcing that spurred community-driven clones and ports. This release included core GEM components and some Atari-specific files, paving the way for derivatives like .

Technical Architecture

Graphics and Input Handling

The GEM Virtual Device Interface (VDI) provided a comprehensive set of over 100 function calls, serving as primitives for rendering and input processing. These primitives encompassed a wide range of operations, including basic drawing elements such as lines, arcs, and ellipses, as well as more complex tasks like filling and text rendering. For instance, the v_gtext() function enabled the output of text strings at specified coordinates, supporting various fonts and effects, while v_fillarea() allowed for the filling of s defined by an array of points using predefined patterns or solid colors. The VDI employed a dual to abstract hardware differences, distinguishing between logical coordinates in Normalized Device Coordinates (NDC) and physical coordinates in Raster Coordinates (RC). In NDC mode, the coordinate space ranged from (0,0) at the lower left to (32767,32767) at the upper right, providing a device-independent logical mapping that facilitated portability across resolutions. Physical RC used device-specific units with an upper-left origin, directly corresponding to screen or printer raster. Transformations between these systems, including scaling and , were handled via internal matrices set during initialization, allowing applications to perform affine transformations without direct hardware access. Input handling in the VDI focused on low-level event sampling to support interactive applications. Mouse tracking was achieved through functions like vq_mouse(), which queried the current button state and cursor position in real-time, enabling precise pointer management. For keyboard input, scancodes were retrieved using vq_key_s(), which sampled the keyboard state and returned key transition events, ensuring compatibility with diverse hardware layouts. These input primitives formed the foundation for higher-level event processing, with multi-event coordination often layered atop them in full GEM implementations. Clipping and raster operations further enhanced rendering efficiency and flexibility within the VDI. Clipping was controlled via vs_clip(), which defined a rectangular to confine all output primitives, preventing off-screen and optimizing on limited hardware. Raster operations, particularly BitBlt-style transfers, were implemented through vro_cpyfm() for opaque copies and vrt_cpyfm() for transparent ones, supporting logical modes such as replace, XOR for non-destructive overlays, and AND for masking effects. These operations allowed efficient screen updates and image manipulations, with the VDI routing calls to underlying device drivers as the final output endpoint.

Memory and Resource Management

GEM employed a real-mode memory model on x86 architectures, adhering to the segmentation scheme where each segment was limited to 64 KB, necessitating careful management of , , and stack areas to fit within these constraints. Dynamic memory allocation was handled through a heap mechanism, allowing applications to request and release blocks as needed during runtime. This approach was essential for GEM's operation on systems with limited RAM, typically requiring a minimum of 256 KB for basic functionality, though color modes demanded at least 384 KB total system . Resource handling in GEM centered on .RSC files, which encapsulated elements such as menus, dialogs, and icons in a binary format. These files were loaded into memory as hierarchical structures using the rsrc_load() function from the Application Environment Services (AES), which allocated a contiguous block, parsed the contents, and adjusted pointers for device-specific coordinates and offsets. Once loaded, resources formed an object that applications could query and manipulate via functions like rsrc_gaddr() to retrieve addresses of specific elements, ensuring efficient access without repeated disk I/O. To manage memory usage, developers were required to invoke rsrc_free() after use, releasing the allocated block back to the heap. Memory management lacked automatic garbage collection, relying instead on manual deallocation to avert leaks, particularly in prolonged sessions where multiple applications and accessories ran concurrently. Functions such as appl_exit() facilitated cleanup upon application termination, but programmers had to explicitly free resources and objects to maintain system stability, as unclaimed heap blocks could fragment available memory and degrade performance over time. This manual process was critical in GEM's multitasking environment, where desk accessories shared resources with the desktop and active programs. Configuration was partially managed through GEM.INI, an initialization file used primarily for font and device settings, including paths to directories like FONTS and defaults for display modes such as 256-color VGA support in later implementations. This file allowed customization of system paths and operational parameters, ensuring compatibility across hardware variations without recompiling core components. For instance, it specified defaults for color palette handling in extended modes, adapting to available video adapters. In low-RAM configurations, GEM incorporated optimization techniques like disk swapping for oversized elements, such as large bitmaps exceeding available heap , temporarily offloading them to auxiliary storage to prevent crashes. This swapping mechanism, activated in "step-aside" mode for full-memory applications, allowed the desktop to yield resources dynamically, though it incurred penalties on slower drives. Such strategies were vital for viability on entry-level systems with 384 KB or less, balancing functionality against hardware limitations.

Compatibility Layers

GEM's compatibility layers were designed to facilitate across operating systems and hardware platforms, primarily by emulating legacy interfaces and providing bindings that bridged GEM's core components with underlying OS services. On systems, the Graphics System Extension (GSX) served as a key emulation layer, supporting calls through its Virtual Device Interface (VDI) while adapting to environments via device drivers that handled graphics requests and coordinate translations. This allowed GSX to load drivers in CMD format directly on , enabling consistent graphical output without requiring full OS replacement. Additionally, early GEM implementations on Intel-based PCs leveraged hardware like the V20 microprocessor to intercept and emulate calls, including those routed through interrupt 21h (int 21h), which provided a pathway for legacy DOS and software to interact with GEM's graphical services. For the Atari ST platform, GEM integrated with The Operating System (TOS) through GEMDOS, a disk operating system layer that mapped GEM's file handling routines to TOS's underlying filesystem. GEMDOS employed a FAT12/FAT16 structure akin to , using drive letters (A: through P:) and backslash-separated pathnames to ensure seamless access to Atari's hierarchical filesystem, with filenames limited to 8 characters plus a 3-character extension. This binding allowed GEM applications to perform file I/O, directory operations, and device interactions via TOS traps (e.g., TRAP #1), preserving compatibility for multi-OS development while abstracting hardware-specific details like floppy and hard disk access. To enhance portability beyond the core Application Environment Services (AES), Digital Research provided the GEM Programmer's Toolkit, which included bindings for languages such as C and Pascal. These bindings facilitated the development of GEM-compatible applications across platforms, supporting utilities like the Lattice C compiler and components such as VDI and Resource Construction Set (RCS), with a minimum RAM requirement of 512 KB for toolkit operations. Despite these adaptations, GEM's compatibility layers had notable limitations, lacking native networking support and relying instead on external terminate-and-stay-resident (TSR) programs for modem and serial communications via the two available RS-232C ports (COM1 and COM2). This dependence on TSRs, such as those for packet drivers or dial-up access, introduced potential conflicts with GEM's memory management and multitasking absence, restricting networked operations to DOS-level workarounds.

Legacy and Impact

Post-Development Maintenance

Following Digital Research's acquisition by in 1991, official maintenance of shifted to limited updates before ceasing, with the final major release being 3.11 in 1988, which included enhancements for better DOS integration but marked the end of active development under DRI. maintained bundles with but focused on enterprise applications, leading to a decline in consumer-facing support. In 1996, acquired the DRI assets from and revived interest by releasing updated versions of (renamed OpenDOS) bundled with , incorporating bug fixes and compatibility improvements. ultimately open-sourced the codebase in 1999 to foster community involvement rather than continuing proprietary maintenance. On the Atari ST platform, where GEM formed the core of the TOS operating system, official support extended until 1993 with patches specifically for the Falcon030 hardware, enabling 24-bit color depth and improved graphics rendering to leverage the machine's DSP capabilities. These updates, including TOS 4.04, addressed compatibility gaps for the Falcon's advanced video hardware, allowing GEM-based applications to utilize true-color modes without requiring full OS overhauls. After Corporation's decline, no further patches were issued, transitioning maintenance to third-party efforts. Community projects like EmuTOS continue to maintain and extend functionality for emulation and vintage hardware as of 2025. In the , community-driven initiatives filled the void left by official support. Preservation efforts also included scanning and sharing original GEM manuals online, such as the 1985 GEM Desktop guide and 1987 Operating System Handbook, which were digitized by retrocomputing archives to aid hobbyists in legacy systems. By the late , these activities signaled the end of the GEM era, as users and developers shifted toward internet-enabled tools like early web browsers, leaving GEM as a preserved artifact rather than an evolving platform.

Influence on Modern Environments

GEM's adoption of the WIMP (windows, icons, menus, pointer) paradigm in 1985 helped standardize graphical user interfaces, influencing subsequent systems that prioritized intuitive, mouse-driven interactions over command-line operations. As a direct precursor to , also released in 1985, GEM shared core elements such as tiled windows, drop-down menus, and icon-based file management, contributing to the competitive "GUI wars" alongside rivals like and TopView. While positioned GEM as an accessible DOS overlay, its design ideas pressured to accelerate Windows development, though the two remained distinct competitors without formal collaboration. Within the Atari ecosystem, 's native integration on the ST series extended its reach, with indirect ports and adaptations reinforcing cross-platform GUI evolution in the mid-1980s. In open-source communities, 's APIs live on through projects like Open, an implementation compatible with that revives the environment for legacy and low-resource computing, enabling modern hobbyists to develop and run applications on emulated or real DOS hardware. Similar echoes appear in experimental desktop prototypes, preserving 's lightweight for compatibility with older software stacks. The era's legal disputes underscored GEM's impact, as Apple Computer filed a against in 1985, alleging that GEM's visual elements too closely resembled the Macintosh interface, including overlapping windows and menu bars. The settlement forced modifications to GEM's PC version—removing features like resizable windows and desktop icons—while allowing the Atari ST variant to persist, but it highlighted growing concerns over GUI that affected broader industry standardization.

Cultural and Historical Significance

GEM played a pivotal role in democratizing graphical user interfaces during the mid-1980s by providing an affordable alternative to Apple's Macintosh, running on low-cost hardware such as the ST series, which launched at $800 for the 520ST model in 1985. This accessibility extended graphical computing to hobbyists, small businesses, and educational institutions beyond the high-end systems that inspired it, particularly in Europe where compatible machines like the PC 1512 gained popularity. By integrating with existing and environments, GEM bridged command-line and visual paradigms, enabling broader adoption of WIMP (windows, icons, menus, pointer) interfaces without requiring proprietary hardware. In popular media, GEM received prominent coverage in 1980s technology outlets, including a demonstration on the television program The Computer Chronicles in February 1985, which highlighted its user-friendly features to a growing audience of home and professional computer enthusiasts. Publications like Byte magazine referenced GEM in issues from 1985, discussing its integration with operating systems and its potential for desktop applications, contributing to its visibility amid the GUI wars with emerging competitors like Microsoft Windows. These portrayals positioned GEM as a symbol of innovative, approachable computing in an era dominated by text-based systems. GEM's educational impact was significant in the 1980s, serving as a practical tool in curricula for teaching operating system design and interface principles on budget-friendly platforms like the Atari ST. Its intuitive design facilitated hands-on learning in university labs and schools, where students explored GUI concepts without the expense of Macintosh systems, fostering early exposure to visual computing in regions with limited resources. Today, holds collectible value among retro computing enthusiasts, with complete Atari ST software suites and peripherals often auctioned for $50 to over $100 on platforms like , reflecting demand for preserved 1980s artifacts. Archival efforts have ensured its longevity, with the hosting emulatable collections of Atari ST software and documentation since at least 2013, including runnable environments via browser-based emulation to maintain accessibility for researchers and nostalgics.

References

  1. https://www.abortretry.fail/p/the-gem-of-digital-research
  2. https://www.digibarn.com/collections/software/gem/index.html
  3. https://landley.net/history/mirror/cpm/gem.html
  4. http://bitsavers.org/pdf/digitalResearch/gsx/GSX-80_Graphics_Extension_Programmers_Guide_Nov82.pdf
  5. http://www.bitsavers.org/pdf/digitalResearch/gsx/GSX-86_Graphics_Extension_Users_Guide_for_the_IBM_PC_Jul83.pdf
  6. http://toastytech.com/guis/gsx.html
  7. https://bitsavers.org/pdf/digitalResearch/gem/Prochnow_The_GEM_Operating_System_Handbook_1987.pdf
  8. https://nemanjatrifunovic.substack.com/p/history-of-the-gem-desktop-environment
  9. https://ctrl-alt-rees.com/2023-05-13-how-apple-ruined-gem-and-nearly-windows-too.html
  10. https://bitsavers.computerhistory.org/pdf/digitalResearch/gem/GEM3/GEM3_Release_Note_Release_3.1_Oct89.pdf
  11. http://bitsavers.informatik.uni-stuttgart.de/pdf/digitalResearch/gem/Programmers_Toolkit/5074-2243-001_Introduction_to_GEM_Programming_Jun86.pdf
  12. http://www.bitsavers.org/pdf/digitalResearch/gem/Prochnow_The_GEM_Operating_System_Handbook_1987.pdf
  13. http://bitsavers.informatik.uni-stuttgart.de/pdf/digitalResearch/gem/Programmers_Toolkit/8039-2024_GEM_Version_2.0_Vol_1_Application_Environment_Services_Reference_Jun86.pdf
  14. https://bitsavers.org/pdf/digitalResearch/gem/GEM_Desktop_Ver1.0_1985.pdf
  15. https://archive.computerhistory.org/resources/access/text/2019/01/102738494-05-01-acc.pdf
  16. https://www.atarimagazines.com/compute/issue60/175_1_GEM_A_New_Look_For_IBM_And_Atari.php
  17. https://freemint.github.io/tos.hyp/en/gem_about.html
  18. https://ia903106.us.archive.org/31/items/COMPUTEs_Technical_Reference_Guide_Atari_ST_Volume_3_TOS_1988/COMPUTEs_Technical_Reference_Guide_Atari_ST_Volume_3_TOS_1988.pdf
  19. https://decafbad.net/files/penguicon2021/history_of_atari_st.pdf
  20. https://www.production-expert.com/production-expert-1/in-1985-the-best-music-production-computer-wasnt-a-mac-or-pc
  21. https://www.ricomputermuseum.org/collections-gallery/small-systems-at-ricm/atari-1040stfm
  22. https://www.goto10retro.com/p/neodesk
  23. https://github.com/niutech/FreeGEM-XM
  24. https://gribnif.github.io/downloads/geneva/
  25. https://github.com/hatari/hatari
  26. https://www.hatari-emu.org/
  27. http://www.deltasoft.com/news.htm
  28. https://www.retrotechnology.com/dri/dri_16bit.html
  29. https://www.nytimes.com/1991/07/17/business/pc-software-maker-novell-to-buy-digital-research.html
  30. https://bitsavers.org/pdf/digitalResearch/gem/GEM3/GEM_3_Desktop_Installation_Nov87.pdf
  31. https://winworldpc.com/product/gem/3x
  32. https://www.operating-system.org/betriebssystem/_english/fa-dr.htm
  33. https://www.zx.net.nz/netware/drdos/caldera.shtml
  34. https://www.theregister.com/1999/04/27/gem_the_gui_that_beat/
  35. https://www.atariuptodate.de/en/system/os
  36. https://www.atari-wiki.com/index.php?title=TOS
  37. https://emutos.sourceforge.io/
  38. https://bitsavers.org/pdf/digitalResearch/gem/
  39. https://liam-on-linux.dreamwidth.org/96552.html
  40. https://www.osnews.com/story/1187/digital-research-and-the-gem-os-the-other-windows/
  41. https://arstechnica.com/features/2005/05/gui/
  42. https://sourceforge.net/projects/opengem/
  43. https://www.osnews.com/story/26322/apple-vs-dri-the-iotheri-look-and-feel-lawsuit/
  44. https://www.osnews.com/story/143393/history-of-the-gem-desktop-environment/
  45. https://vintageapple.org/byte/pdf/198509_Byte_Magazine_Vol_10-09_10th_Anniversary_Issue.pdf
  46. https://www.ebay.com/itm/297178644074
  47. https://archive.org/details/Atari_ST_TOSEC_2012_04_23
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.