While we all know what a wonderful computer we have, and most of us don't even consider using anything else (I know I don't), it is not all that practical for writing large
applications. As a result, the release of new applications are rare. To try to remedy this problem, we have started developing a new set of programming libraries. However, as we did not want to loose the aspects which are rather typical for our OS, we have had to make a clean break from already existing libraries (like standard c libraries as part of c68). So ProWesS applications can still be reentrant and are quite small.
ProWesS is strictly event driven. The programmer has to describe what the window should look like. The control is then passed to ProWesS which will display the window and wait for events. The events can be handled by routines which are provided by the programmer. These routines can
change the behaviour of the window, add or remove something from the window or do something (like copy a file). When the event handler terminates, the window is updated. When the control is passed back to the calling application (because the window is exited (or broken down in ProWesS terminology)), the window is removed from the screen.
The OS has never given a lot of support for graphics. This has changed when PROforma was released. We therefore no longer support most of the graphics in syslib, but recommend the use of PROforma when graphics are necessary.
PROforma is short for 'PROGS Font & Raster Manager', and it does exactly what this
name suggest. It is a library of routines to manage and display vector graphics and fonts on (raster) devices like screens and printers.
The availability of a separate program to manage graphics and fonts has several advantages. It allows application developers to create output of equal quality (resolution permitting) on several devices, and they can share resources. In short this means that the
PROforma library only has to be loaded once, independent of the number of applications which use it. Also fonts only have to be loaded once, and can be shared between applications.
PROforma was originally developed as the graphics library for LINEdesign. That does not mean that this is the only kind of application for which PROforma is of use. PROforma is also perfectly suitable for desktop publishers,
word processors, business graphics and all applications which want high quality output (which must be just about every application except compilers and games). Actually, even at the time of writing there are things which are possible with PROforma but can't be accessed through LINEdesign.
More recently, PROforma has been redesigned to a great extent, to make it even more future-proof, easier to extend
(both internally, and by writing drivers). There have been some changes to make it easier to write a window manager (for ProWesS) and complete support of colour has been added.
As a library, PROforma has the form of dynamic link library (DLL).
syslib is a set of low level library routines, mainly to provide an interface with the operating system (although some user code is included as well). The library is specifically written to be incompatible with the standard C library so that they can be mixed if necessary (although a lot of it is quite similar to what is already available).
The standard C library is specifically written for unix® machines and presents a few problems when compared to syslib. In fact it is difficult to implement the standard libraries completely. This requires the support of signals, which is some kind of user interrupt of a program. However much more annoying is the limited error handling. Normally errors are reported by returning an out of the ordinary value to functions, and
storing what the problem was is _errno, a global variable.
Unfortunately, global variables make programs modify their own code, in which case the code is not reentrant. As the standard libraries always use these variables, most C programs are not reentrant. However, if no global variables are used then there are no problems. syslib specifically does not require the use of global variables. When library
functions need to read or modify global variables, proper DLL linking also becomes difficult to provide.
Consistency is also a strong point of syslib. There is a consistent naming scheme, only one memory model, only one type of strings etc.
syslib is also intended to make programming safe. No
unsafe constructs are supported by syslib, or when possible, a safe way of doing things is provided. For example, many aspects of QDOS are only accessible because of direct access to the system data structures. However, this can cause dangerous modifications and allows you to do some things which are not "clean". syslib specifically does not support such operations.
An example of an important
part of the library is the support for external modules. This allows code to be written as a separate part of the program, which can be loaded on demand. This can be useful because it allows pieces of a program to be replaced by others, or extra pieces to be loaded. This is for example very useful for printer drivers. Many drivers can be added when necessary (as indeed is the case in PROforma).
C programs are typically quite large (especially when compared to native assembler). There are two main reasons for this. The least important factor is the translation from c to assembler. This translation produces code which is less optimal than native assembler (from good programmers) and can therefore be slightly larger. However this does not make a significant speed
difference. Most of the time, a program is waiting for the user to tell it what to do anyway. For those pieces of code where speed does matter (typically less than 1% of a program) you could still use assembler anyway.
A much more important factor are the libraries which are included in the program. These libraries can make up a large part of the final program. As such, this is not a problem, but the
same routines are linked with many programs, thus wasting memory when multitasking. Thus we wrote the Dynamic Link Library Manager. When a program uses the DLL Manager, it can link to routines which are separately loaded. In fact, a dynamic link library is just a kind of thing. However, it is used in such a way that the calls to the thing code are a lot more efficient than when using the extension thing mechanism.
Note that the DLL Manager does not load extensions, it only links to them. The direct loading of extensions is in general not possible without assuming that there is a hard disk with the extensions. Therefore the extensions have to be loaded in advance, and an error will be reported if a dynamic link can not be resolved. (In fact, ProWesS applications normally use a loader program which will test whether the needed extensions
are available and if necessary load them - this is some kind of boot facility and only works in a controlled environment).
The DLL Manager also does prepares the system for using syslib (it makes sure that enough supervisor stack is available), and allows you to load all programs which use it as resident extensions. The programs will then be linked as executable things.
The DATAdesign engine is a rather powerful, multi-user, freeform database management system. It allows DATAdesign files to be shared (used at the same time) by several programs (with proper record locking). The fact that it is freeform means that the maximum length of a field doesn't have to be specified in advance, but can vary from record to record. This allows you to store an entire text in a record.
This is one of the most important extensions which exist. It allows a general (named) access mechanism to arbitrary pieces of memory. It is for example used by the DLL
Manager for finding the DLL's. This extension was written by Qjump.
This is one of the basic system extensions, which allows the use of a pointer, the arrow or shape which is used to indicate things. It also does other things like making sure that the window from one job is not
overwritten by another job, and taking care of (re)displaying a window when switching jobs. The pointer interface was developed by Qjump.
The Scrap extensions (which are produced and written by Jochen Merz software), is a buffer to pass data (usually text) between applications.
Hotkey System II
The Hotkey System II extension allows the user to define the definition of combinations of <ALT> with another keypress. Amongst the user defined combinations, it handles last line recall and the Stuffer Buffer (which is a one line scrap which is often used to pass filenames between applications). The hotkey system is developed by Qjump.
The button frame extension allows ProWesS to put buttons on screen. This extension was originally part of Qpac II and has kindly been donated by Tony Tebby for use in ProWesS. The button frame was developed by Qjump.
Global Variables are usually referred to in (DOS® and Unix®) literature as Environment Variables. It is a global mechanism to assign a string to a name, and make that globally available (in our case without a shell). This is very important to make automatic installation of software possible.
Variables are often used to indicate a directory, and can be used to start a directory name (possibly in a path). They are a part of ProWesS and written by PROGS.