I've built a lot of conceived, designed, and built a lot software over the years, frequently with the help of others. I have documented much of this work in on other, thematically organized pages, including agent software implementations, architectures and systems, new communication media, and hypermedia spaces. This section documents software that doesn't fit into any of those categories. Most of it is either desktop productivity or utility software. Unlike other sections, where content is listed chronologically, this section features the most important software first, starting with the software that, in its Windows Explorer (formerly Windows File Manager) variant, is probably my most successful effort, at least in terms of impact on the way everybody uses and manages their computers.
File Manager was, if not the first, certainly one of the first menu-driven file management programs (the only roughly contemporary competitor I'm aware of was the much less functional Lotus file manager that shipped, at about the same time, with Lotus 123 version 2). Developed specifically to solve a time consuming consulting problem. At the time of implementation, DOS 2.0 had just been released and many users did not understand that the new subdirectory feature had to be used if one was to make practical use of a fixed disk (the root wouldn't accept more than about 250 files). While the use of FILEMAN reduced the time required to reorganize a fixed disk from hours to minutes, the general purpose file management capabilities of FILEMAN made it an immediate hit with users for a whole variety of purposes. Indeed, we received so many requests for new function that we made FILEMAN end user configurable, allowing users to add their own functions. FILEMAN is still widely used, and a new versions continue to be released by volunteer programmers. FILEMAN (and its companion subdirectory management program, STP) is a part of the source code base of the IBM DOS Shell, the OS/2 File Manager (first released with OS/2 1.2), and (by way of the latter) the MicroSoft Windows File Manager (MicroSoft not only used the source code under its joint development agreement with IBM, but eventually hired away the OS/2 File Manager programming team in Hursley). My concept and design based, in part, on my earlier SUBDIR. Initially developed with Clark Maurer. Reimplemented (as FILEMAN2) with Richard Redpath. Has passed through several hands since, and is still maintained, developed, and widely used.
As FILEMAN gained in popularity it rapidly became apparent that its file management capabilities were inadequate to the requirements of large scale hard disk maintenance. Erasing, moving, and copying whole directories was not the kind of thing it was good at. SubTree Plus (STP) was designed specifically to solve these problems by depicting and allowing direct manipulation of the subdirectory structure of a hard disk. STP is, to my knowledge, the first program to implement a directly traversable subdirectory tree or to allow direct manipulation of subdirectories and subdirectory content. It has, like FILEMAN, enjoyed tremendous popularity and is still in use today (new version continue to be released by volunteer programmers). It is also part of the source code base of the IBM DOS Shell, OS/2 File Manager, and (by way of the latter) the MicroSoft Windows File Manager (which was recently renamed "Windows Explorer"). My concept and design based, in part, on my earlier SUBTREE. Initially developed with Dennis LaCroix. Later development (including the IBM BURT3363 product) done with Richard Redpath.
Presaged by my earlier PE macro set and the PEACCESS front end, the E editor family (currently incarnated as OS/2 enhanced Editor/EPM) was rooted in the legacy of Personal Editor, but sought to surpass it with a superior user interface, superior extensibility, and extreme speed. Initially a partnership effort with Clark Maurer, the initial E editor married my desire for a better user interface and Clark's passion for a really fast editor. E's speed, small footprint, and ease of use made it a runaway hit with users. It is still widely used despite the fact that no new version of the original non-configurable E editor has been released in over 10 years. Another non-configurable variant of E, TEDIT, retains my original user interface design and is shipped with IBM DOS and IBM OS/2.
Further extension of the capabilities of E started with the ME prototype. Conceived as an exploration of editor configurability and the use of editors as a platform for building applications, ME combined the configurable menu functionality of EASYMENU with the key and command configurability that would ultimately be released in E2. All of the essential design elements of ME's EI (E interpreter) configuration language used in E2, E3, EPM, and other E language variants (including MicroEdge's SlickEdit) were designed in ME. ME was used to develop a number of prototypes, including a expert system data collection tool, an spreadsheet-like user interface to IBM's host DB/2, a TCP/IP mail front end, an experimental reimplementation of FILEMAN, a never released new version of the Yorktown PC User's Workbench, and the DARWIN user interface prototype. ME was also used to develop several important E2 macro sets, including E2DRAW. The design lessons of ME were considerable, moreover, and many of the decisions associated with BBMODEL reflect lessons learned in the process of implementing and prototyping with ME.
ME was a joint design effort with Clark Maurer. We designed ME and the EI language together. We implemented the system together. Most of that work remained intact when Clark, working alone, released the E2 editor without the ME menuing capability. While my contributions to subsequent E family editor incarnations has been minimal, I have built a number of systems using E family editors, including E2SURVEY (the only E family editor implementation that shares no macro code with the E editor itself), E2XEDIT, E2TEXT, and BBMODEL.
When asked to quickly develop and specify the user interface for a new IBM SGML word processor, determined that the fastest way to design and test the system was to build a user interface prototyping toolkit, based on the E2 editor. This interpretive user interface prototype toolkit, called BBMODEL, specified user interface elements using a consistent tag-based markup in which the style of user interface elements was treated as an attribute of a standard tag set rather than as a specific tag. This separation of style and content allowed us to rapidly try out a range of user interface presentation options, with, for instance, menus rapidly cycled from action bar styles to pull down styles to pop-up styles. The inclusion of E2TEXT in the BBMODEL prototype allowed us, moreover, to test the prototype system as a functional word processor. BBMODEL development ended as the word processor design solidified and work on the product code started.
By that time, however, BBMODEL had been transferred to Stephen Bois, where it was used as a test bed for exploring the early concepts that resulted in the ITS user interface development system. While few people have heard of ITS, it has been used by millions of people who have stopped at IBM kiosks at World's Fairs and Olympics. While ITS is compiled to P-code rather than interpreted, it retains, and has expanded on, much of its BBMODEL legacy, including the use of tags and the separation of style from content. ITS has vastly expanded from BBMODEL, particularly in its expansion on the concept of separating style from content. While a number of base ITS tags are unchanged from BBMODEL, they are but a small fraction of the entire ITS tag inventory. Hence, while I sometimes feel vaguely grandfatherly about the system, I don't claim to have had any important role in its development. BBMODEL was my concept and design, and was developed in conjunction with Valerie Olague and Eric Hesse. The Word Processor it was built for was completed and nearly shipped (the project was canceled with the product in shrink wrap waiting for formal announcement) with a user interface that looks almost exactly like my design. BBMODEL was used throughout the development cycle of that word processor to demonstrate and test user its interface concepts.
Cowrote this specification for the OS/2 system editor with Jay Tunkel. Implemented editor with Clark Maurer and others. Wrote the editor documentation as shipped with OS/2 1.1. I am occasionally embarrassed to admit this, because OS/2 System Editor is a very low function editor (mostly it illustrates what should be a standing principle in the computer industry: "Requirements processes primarily exist to justify removing already implemented function from programs"). That said, the original OS/2 System Editor specification was considerably more powerful and E-like than the version that ultimately shipped. Indeed, the specification was purposely written to enable upwardly compatible move to an E family editor on subsequent OS/2 release. While this never happened, the most advanced version of E, OS/2 Enhanced Editor or EPM, was added to OS/2 at OS/2 2.1. Yet another E compatible editor, tedit, was added to OS/2 at OS/2 4.0.
One of the first user configurable menu driven front ends for DOS programs, EasyMenu provided the central user interface component of the Yorktown PC User's Workbench. My first serious excursion into computer language design (based in part on the user configurability of FILEMAN, EASYMENU provided the impetus for a series of later efforts, including ME, E2Menu, and BBModel. Provided a partial source code basis for the IBM DOS Shell. My concept and design. Developed with Clark Maurer.
Possibly the only complete E family editor macro set that completely replaces the default E macros. Provides everything needed to conduct an electronic survey, with support provided for a wide variety of question types, including multiple choice, multiple selection, open ended, and one line answers. Uniquely, implements a complete editor within the E2 editor. Also provides mechanisms remembering previous answers across sessions and for asking targeted follow up questions based on the answers given. To my amazement, still sometimes used to conduct electronic surveys in IBM.
An intelligent dynamic field resolution sort utility. Resolved sort columns, even where they are not physically justified, based on relative position and dynamically determined data type (text, integer, floating point, etc.). The key notion, in FSORT, was that pure left to right character based sorts were not nearly as useful as resolved data type based sorts. My concept and design. Implemented with Alain Benoix. Good idea that the world could still use.
Pioneered Presentation Manager interaction from REXX programs. Sought by IBM PSP as an OS/2 deliverable. Other systems have since matched and surpassed RXPM, but it remains the first interpretive system I am aware of to manage a iconic windowing environment. My concept and design. Implemented with Alain Benoix.
A prototype REXX extension that allowed any OS/2 dynamic link function to be called from REXX without conversion to the REXX API's. The only requirement for use of a DLL function from REXX was the specification of the function's typed calling parameters in a profile. REXXTRAN did all format conversions (string of length, integer or float of size and other characteristics, etc) between REXX and the called dynamic link library function. Sought by PSP as an OS/2 deliverable. Some of the concepts associated with REXXTRAN are now associated with SOM, but it remains, to the best of my knowledge, the only system of its kind to map interpretive languages to dynamic link libraries without any requirement of special coding and/or compile options (that could be applied, a priori, to any existing DLL). My concept and design. Implemented with Alain Benoix.
Building calculators on PC's was not a new idea when we started the development of MenuCalc. Formula solving, as illustrated by Spreadsheets and mathematical problem solving environments wasn't a new idea either. What was new, in MenuCalc, and its successor, MC2, was the idea of packaging substantial formula solving capabilities in a small pop-up calculator that didn't take over the entire screen. MenuCalc and MC2 were very widely used for a long time. My concept and design. Developed (as MenuCalc) with Ted Diament and (as MC2) Richard Redpath.
One of the first sets of UNIX-style filters available for DOS after the release of DOS 2.0. A suite of over a dozen tools for automatically reorganizing data files, including columnar data selection, reorganization, and modification capabilities. Also included sample filter source code that was widely used as a base for writing new filters. These filters have had substantial productivity in subsequent work, including the prototype "Mirror Backup" (see below). I have long had a design for a FILTER GUI that would allow users to show, in a template fashion, how they wanted a data file reformatted, and would then create a reusable filter chain to do the data reorganization, but have never had a chance to implement it. I have rewritten this suite several times. The initial implementation was in Intel 808x Assembler. Subsequent implementations have been done in REXX, PASCAL, C, C++, and Java.