The A-Shell User Interface typically takes one of the following forms (generally organized from least to most graphical):
| • | Dumb monochrome ("green screen") terminals, supporting XY positioning, little or no other features. |
| • | Smarter monochrome terminals or emulators, supporting Wyse50 or AM6x with a range of visual features and attributes accessed through Tab(-1,x) interface, e.g. status lines, box operations, reverse, underline, dim/bright. |
| • | Color terminals and emulators; can select foreground/background colors from a small palette; often color is only used to map onto monochrome attributes) |
| • | Enhanced emulators (ZTERM, AlphaLAN, ATE) which add the ability to access limited Windows functionality via ESC sequences, while still being fundamentally confined to the fixed pitch display environment. (The InSight package extended that somewhat, by replacing certain higher-level display functions with Windows equivalents.) |
| • | ATE provides capabilities which overlap both those of the enhanced emulators and the full Windows environment. At the low end, it provides some tricks for improving the look of text mode applications while remaining a text-mode display device (e.g. beveling effects, mouse support, the ability to tie the colors to Windows colors, access to GDI printing, FTP, etc.) At the high end, it provides nearly all the capabilities of a local Windows GUI environment; the main limitation being that data has to travel between the server and the client display device, sometimes limiting the practicality of certain functions, or at least imposing some constraints on the server in order to achieve good performance. |
| • | Full Windows GUI environment, which comes in various levels of sophistication depending on the version of Windows. |
A-Shell has always worked in all of these environments, more or less the same way, by sticking with a limited set of fixed-pitch text mode capabilities. While very practical for portability, this lowest-common-denominator approach has limited the ability to upgrade legacy applications to provide a more Windows-like user interface when in that environment. To partially address this desire, we have historically added miscellaneous Windows functions in a piecemeal fashion so that ASB programmers committed to the Windows environment can access isolated GUI features (such as a message box, or image display) to what remained fundamentally text-mode applications.
The piecemeal approach has provided only limited satisfaction to programmers trying to compete against true Windows applications, so beginning with 4.9 and continuing through the 5.1 development cycles, we have extended and rounded out the GUI capabilities of ASB to the extent that you can create applications which have a true Windows look-and-feel, and can compete head-to-head with "native Windows" applications created in other languages. While there will always be features that some other language has that are not (yet?) in ASB, we are realistically at the point where no one should be able to use that as an excuse for not being able to write or sell a modern, competitive application.
The goal of the AUI Toolkit is to not just to provide modern Windows GUI capabilities, but to do so in a framework that maintains at least some degree of compatibility with the existing legacy text and procedural architecture of ASB. Ideally, all of the AUI functions would (or will?) work in a purely text environment as well, but that hasn’t been achieved. What has been achieved is a viable means to migrate in an incremental, evolutionary manner from the legacy text environment to the GUI environment, improving the modularity of your programs in the process.
