Archimedes Applications: Authors' Guidelines ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Name: 0310091 Version: 0.02 History: 0.01: Undated : started. 0.02: 15-Feb-89: updated for release on SID This document explains some of the issues involved in writing applications for the Archimedes machine. It describes some techniques for fully utilising the available resources. Readers are assumed to be familiar with the Archimedes Programmers Reference Manual. We welcome feedback through SID. The document includes: Guidelines about versions of the OS, version checking Guidelines about installation of applications Guidelines about use of some facilities of the OS, e.g. memory allocation, graphics and screen modes, the Wimp Current bug-list for the OS Whilst every effort has been made to ensure the accuracy of information in this guide, no liability for errors or omissions can be accepted by Acorn Computers Limited. OS VERSIONS The only officially supported version of the OS is currently 1.2. Any customer who bought a system with a previous version, and who returned their registration card, should already have received a free upgrade to 1.2, including new ROMs, manual and welcome disc. The official description of Arthur 1.2 is contained in the Programmer's Reference Manual, Issue 1. This is now available from Acorn, so order your copy if you are currently using a pre-release PRM. The version number of the OS (e.g. the kernel) always corresponds to the version number of the module called "UtilityModule". The version number of a module can be found in the help string of the module (e.g. that generated by going "*help modules" or via SWI Module) which is always of the format: xxxxxxxxxxxxxxxnn.nnxxxxxxxxxxxxxx.... e.g. character 18 will be a dot, and those of character places 16, 17, 19, 20 which are digits give an ordering to released versions of the module. (There may be tabs in the help string: these must be expanded before finding the character places). There is also an identity number for a version of the OS, which is readable via OSBYTE 0. These values, however, are not necessarily ordered. INSTALLATION AND PROGRAM RESOURCES Many programs consist of more than just a single file, but exist as a suite of programs, or have related data files. This makes the installation of the program on a hard disc or network quite tricky and error-prone. This section discusses various approaches to this problem, and some techniques that may help. There is a range of solutions depending on the severity of the problem. There are three important principles to bear in mind. (1) Allow the user to install the application on media other than the release one, e.g. Winchester, Econet. A Winchester is no longer a luxury item: many people have them. Make this installation operation as easy as possible. Conversely, do not assume that customers have hard discs. (2) Do not assume that yours is the only application that is used on this machine. Make the application easy to enter and exit, without requiring the user to hit break on entry and exit, and without requiring special configuration of the machine for your application. (This is not always possible: read on). (3) The "leave the machine tidy" principle: it's important to ensure that your application, as well as working, does not cause the mysterious failure of the next application to be run. e.g.: * do not change the current directory within the program * ensure that fonts are released on exit * ensure that your sprites are discarded on exit or better, do not use the system sprite area but define and use your own * do not leave open files (but do not use *close or *shut!) * do not leave event handlers installed An application will typically consist of a runnable piece of code (BASIC, compiled C' or assembler), a set of resources relating to this code and a set of directories containing data for the application. In order to make the transfer of all these files onto hard discs or network file servers, a directory structure as show below could be used for the release floppy disc: $ __________________________|_____________________________ | | | | | | | | !boot AppName Library Resources | | | ___________|_________ | | | | | | | !run app_dir1 app_dir2 AppName AppName | | | | | ___________|________ | | | App_code Sprites Templates There are three directories in the root: AppName, Library & Resources. AppName is "owned" by the application and contains all the data files that relate to the application in any directories that the application may require. For example, a word processor would store the user's documents within this directory. Library contains a very simple start-up program, written in BASIC, which sets up the system variables for the application and then calls the runnable code of the application. An example of this is shown below: 10 REM > Library.AppName 20 *set Application$Resources $.Resources.AppName 30 *set Application$Data &.AppName 40 *RUN $.Resources.AppName.App_code All references to the applications resources and data files should be made via system variables. The application should not change the current directory and should not refer to files via absolute pathnames. (See the Programmers Reference Manual for information on how to use system variables.) Similarly, this program should set the Font$Prefix, if it is not already set, load any modules that the main application requires, etc. The main application should always be written so that if it is run without its environment being set-up a suitable error message it produced. Resources contains all the resources needed by the application. These resources are stored in a sub-directory of resources with the name AppName. This is so that on hard discs and file servers, many applications can have their resources within one resources directory. If applications are required to work from a SHIFT-BREAK, then a !boot file will be required. An example of this is shown below: 10 REM > $.!boot 20 *key 0 QUIT|M AppName|M 30 *FX225,1 40 *FX138,0,128 The current desktop does not allow the user direct access to the library(ArthurLib). Therefore, to be able to start-up applications from the desktop on the network, there must be some form of start-up program, preferably within the AppName directory. This could be called !run. Note that the desktop also insists on setting the current filing system to ADFS in exit even if the program you choose to run is on the network. Therefore, the !run program must look to see what filing system was used to start it up, and if this was the net, issue a *NET command. An example of a !run program is shown below: 10 REM > &.app.!run 20 30 SYS "OS_GetEnv" TO fs$ 40 IF INSTR(FNcase(fs$),"net:") OR INSTR(FNcase(fs$),"-net-") THEN *NET 50 60 *key 0 QUIT|M AppName|M 70 *FX225,1 80 *FX138,0,128 90 END 100 110 DEF FNcase(A$) 120 LOCAL c%, s$ 130 FOR I=1 TO LEN(A$) 140 c% = ASC(MID$(A$, I, 1)) 150 IF c%>64 AND c%<91 THEN s$=s$ + CHR$(c% OR &60) ELSE s$=s$ + CHR$(c%) 160 NEXT 170 =s$ With the above disc structure and files, installation of applications onto hard discs can be reduced to: *COPY ADFS::0.$.AppName ADFS::4.$.AppName R~C *COPY ADFS::0.$.Library ADFS::4.$.Library R~C *COPY ADFS::0.$.Resources ADFS::4.$.Resources R~C For file servers, the library and resources files can be copied directly into $.ArthurLib and $.Resources. (Note that a network manager must perform these operations, creating these directories if they do not aready exist.) *COPY ADFS::0.$.Library.* NET:$.ArthurLib.* R~C *COPY ADFS::0.$.Resources.* NET:$.Resources.* R~C In a multi-user environment, each user may require a copy of the applications data directory. To make it easier for network managers to 'give' this structure to new users, a copy of the applications could be placed within the applications resources directory using the copy command below: *COPY ADFS::0.$.App NET:$.Resources.App.Structure R~C This would give a file server directory structure similar to the one shown below: $ ____________________|___________________ | | | | | | UserName Library Resources | AppName AppName | | | | | ___________|_________ | | | | | !run app_dir1 app_dir2 AppName | ___________________|__________ | | | | Structure App_code Sprites Templates | _______|___________ | | | !run app_dir1 app_dir2 To create an environment for a new user now simply requires the network manager to copy this structure to the user's root: *COPY $.Resources.AppName.Structure $.UserName.AppName R~C The operation of installing files onto hard discs or networks and providing new users with the appropriate environment can also be done using the copy facilities provided by the desktop. RECONFIGURING THE SYSTEM ENVIRONMENT Some programs may wish to reconfigure the computer on which they run, in order to get the most from the resources available. As much as possible, try to ensure that your program is not dependent on the precise configuration of the machine, so that a machine with less (or more) memory will still run successfully. If this is not possible (e.g. if your program absolutely requires more memory than a standard configuration of 310 makes available) then ensure that, on exit, your program leaves the machine as it found it. Such reconfiguration or reorganisation of the machine should be performed in a !Boot file that is separate from the main application, so that (for instance) a 440 owner is able to install the application itself onto another disc, without having to go through the reconfiguration sequence. If your program will not run realistically on a 305 then consider producing a low-end product with reduced functionality, rather than offering a full-spec product with hardly any workspace. Do not rely on the presence or contents of DeskFS: it may disappear (or its contents change) in future versions. GRAPHICS The Archimedes machine has an extremely wide variety of screen modes, allowing control of a variety of monitor types for applications. The traditional model of screen modes from the BBC Computer is that the screen is 1280*1024 "OS units" in size, and that the number of pixels is a divisor of these dimensions. It is likely that this proliferation of modes will continue, as more and more sophisticated display hardware becomes affordable. The MultiSync monitor standard, for example, is becoming more and more popular and provides dramatically better visual resolution than traditional colour monitors. For instance, the rendition of anti-aliased fonts in mode 20 (640*512) is outstanding compared to their appearance in mode 12 (640*256). Future developments may also include monitors that have more than 1280 pixels in both directions. Because of this, it is worth generalising the way that applications work so that they will work in a variety of screen modes. Rather than examining the mode and building the properties of each mode into your program, it is better to read the mode and VDU variables from the operating system and to parameterise the program based on these values. Note that systems with hi-res monochrome monitors (MonitorType = 2) will stay in mode 22 or 23 irrespective of the mode type selected by the application. Applications should read the VDU variables after mode changes to detect success and print a message stating that the application cannot support hi-res modes if this is the case. The OS unit should be thought of as an absolute measurement of length, rather than 1/1280 of the screen. The font manager already does this, and fixes an OS unit as around 1/90 of an inch. One of the problems that this leads to is differing aspect ratios of pixels: on traditional monitors pixels tend to be higher than they are wide by about 2:1, on mode 20 the pixels are almost exactly square. Reading the XEigFactor and YEigFactor mode variables gives the size of this aspect ratio. Sprite scaling facilities can be a considerable help in coping with these variations. In order to cope with future different monitor sizes, do not assume that the screen is 1280*1024. Instead, assume that OS units are about 90 to the inch, and that larger screens may have more OS units in total size. Using the Wimp is also useful for insulating a program against total screen size, although the icon bar must be painted with care. The total size of the screen can be read using two mode variables that are not mentioned in the Programmer's Reference Manual (but are implemented nevertheless). Variable 11 is called XWindLimit, and gives the number of pixels across the screen, minus one. Variable 12 is called YWindLimit, and gives the number of pixels up the screen, minus one. If you wish to perform direct screen writing, do it legally. By reading screen and mode variables, it is possible to get hold of the base address of screen memory, the number and width of display lines, etc. Write via this, rather than by putting magic constants in your program. Note that the mode variable LineLength, rather than the variable YShftFactor, should be used when hopping between display lines (YShftFactor is an anachronism, from the days when multiplication was slow). Screen writing can only be performed in SVC mode. FONTS AND SPRITES The Arthur font manager provides auto-scaling and anti-aliasing of fonts, providing automatic availablility of all sizes of a font, and dramatically better screen rendition than competing systems. This is particularly true on MultiSync monitors. On normal colour monitors some people do not like using the anti-aliased fonts for everyday editing. Thus, applications should provide users with the choice of using the system font rather than the anti-aliased ones. The anti-aliased fonts provide far more detail for print previewing. Providing the option of white-on-black viewing is also helpful to some people, depending on the properties of their particular monitor. The font cache is a shared resource on the machine. Programs should not attempt to set its size but should take whatever the user has set, assuming that if it is small then there is a good reason. Installation documentation should point out this issue if it is likely to be a problem. Also, a program can find out the size of the font cache, and produce a warning to the user if it seems unusably small. Programs should not set the Font$Prefix variable on startup, but should check for the availability of fonts and act appropriately if none are to be found. Check carefully that your program preserves font reference counts. Do not assume that your program is the only client of the font manager, there may be other clients (e.g. modules) in the system. Use your own user sprite area, rather than the "system" one. The system sprite pool is for experimentation and simple programs, rather than for use by "serious" applications. ON FUTURE ARCHIMEDES SYSTEMS THE STANDARD CONFIGURED SPRITE POOL SIZE MAY BE 0. LANGUAGES The best languages in which to write large applications for the Archimedes machine are C and BASIC V. The latter is slower (except in floating-point-intensive operations), but produces considerably more compact programs. Unlike most BASICS it provides long variable names, named procedures with parameters and local variables, libraries, error trapping, and structured control statements. C on the Archimedes machine is extremely fast, faster than on most 386 and 68020-based workstations for anything less than 5000 pounds. C is the subject of an ANSI international standardisation effort, and is the language of choice for programmers who wish to port their work between different operating systems. Acorn's C compiler and library are to full ANSI spec. Arthur-specific facilities can be accessed via the arthur.h library provided with the compiler. This header file is fairly simplistic; some authors have ended up using just the swi and swix procedures in it, and building their own facilities above this level. Future versions will be considerably extended, but will preserve compatibility with the existing arthur.h library. THE WIMP Use the built-in menu system rather than building your own. Some of the programs on the Welcome disc were produced using pre-production versions of the window system, which did not have the menu system, and they should not be taken as examples. Always check Wimp_CreateWindow's success. The current Wimp pre-allocates enough space for a fixed number of windows; this may change to a system of more dynamic allocation. If you have no use for the adjust key on the mouse, then make it do nothing, rather than mimicing the action of the select key. This gives more room for future extensions in functionality, and reinforces the idea that the naive user always presses select to perform the "obvious" function. A mouse-click in a scroll bar that is not on the central bubble or on an arrow, should be interpreted as "move by one window-width" in that direction. If building a suite of application programs, build standard facilities for such operations as: * entering a filename * entering a *-command * changing the palette to suit user taste * interaction using a dialogue box * producing an error message For instance, consider the palette-setting facilities in the desktop. The structure of the desktop program is worth studying in this area, as it demonstrates how a number of dissimilar windowed facilities can be bound together into a single program, with very little knowledge of each other. This sort of approach allows utilities, once developed, to be included in all programs. When performing a poll_wimp, ignore messages that are of types you do not understand (rather than complaining "illegal poll_wimp return", or predicting what the next poll_wimp return will be). Future extensions to the Wimp may produce new message types: these will be arranged so that if existing programs ignore them, all will be well. The recommended entry/exit sequences for Wimp programs is: set the mode and palette SWI Wimp_Init (fail -> wimp unplugged, so complain cleanly) *pointer .... the program SWI Wimp_Closedown VDU 4 (output text to text cursor) VDU 26 (default text/graphics windows) set text foreground to 0, background to 15 CLS (set screen to background 15) *desktop A user who does not wish to return to the desktop after Wimp applications can go: *set alias$desktop quit Do not assume that you are fully in control of all the windows on the screen; i.e. there may be other windows on the screen in addition to those constructed by your program. Future extensions to the Wimp may provide facilities for "desktop accessories", or for running more than one application concurrently. This should similarly constrain particularly clever tricks with the palette; e.g. the Music Editor uses different planes of the palette to make the undrawing of notes easier. The structure of the desktop program may change in future versions of the machine. Do not access the module by name, or assume the presence of its sprites. FILE TYPES There are various points to bear in mind when developing an application with a specific data file format, e.g. word processors and spreadsheets. Write a careful spec of your external data format, and treat it as a long-term commitment: expect future versions of your software to have to work with old files, so plan for change and expansion. Choose a file type for use with this data format (Acorn ISV Support controls allocation of these). If at all possible, use a data format already in existence in the outside world. This is especially true of office software, e.g word-processors and spreadsheets. Do not rely on the pre-defined run type for "Plain ASCII Text", file type FFF, within your program. A user may wish to set this to start up his/her favourite text editor. NETWORK AND OTHER PRINTERS Many users have access to network printers and therefore, applications should support these. To write to a network printer, applications need only select *FX5,4 and send data in the same way as to a local printer. NB: it is possible to re-direct the output from printer type 4 (or 5 and above) by setting the appropriate system variable. For example, to re-direct output to a file called OUTPUT the following instructions could be used: *SET PrinterType$5 ADFS::0.OUTPUT *FX5,5 All output to the printer will now OPENOUT the file OUTPUT and send all data to this file. This is a quick and simple way of providing what used to be SPOOLED output from programs. PAGE ZERO DO NOT peek or poke page zero or other operating system workspace. Interfaces not published in the PRM may change between versions of the operating system. Furthermore, on future versions of the operating system such memory may be protected from user mode access. If you intercept the hardware vectors, make sure that all accesses to those vectors are performed in SVC mode. FUTURE CHANGES Every effort will be made to ensure that future versions of Arthur are backwards compatible with 1.2. However, some small spec changes may be introduced if we consider them worthwhile. MOS Module *command decoding currently has a different set of terminators from alias *command decoding, so if you had set alias$dir, *dir^ is different to *dir ^. The termination of aliases will be changed in future versions, to be the same as the termination of commands. MOS ^H in ReadLine will act as DEL, so that the backspace key acts like the delete key. This is extremely convenient on the Archimedes keyboard. MOS In mode 23, 1 OS-unit is currently equal to 1 pixel. This only affects the setting of the mouse rectangle, as it is a text-only mode. In future versions graphics will be allowed in this mode, and the scaling will be changed so that 2 OS-units are equal to 1 pixel. Mode 22 will be unaffected. MOS OS_ReadModeVariable currently checks that the specified mode is one that you could move into, and (if it is not) then it transforms the mode number (as it would be transformed if you selected that mode) before producing the variable value. This is only important if the mode specified cannot be selected on this machine, because the monitor type is wrong. This is the wrong behaviour for finding out the properties of a sprite with the specified mode. In future versions, this behaviour will be changed so that the mode number is not transformed before the variable's value is read. Desktop The desktop program in future versions of Arthur will be completely different. The 1.2 desktop will run as an application program, but will not be present in the ROM. APPENDIX A: ARTHUR 1.2 KNOWN BUG LIST All bugs in this list will be fixed in future versions of the operating system. Where there is any doubt, the exact course is specified. BASIC Certain array operations fail the second time they are executed inside loops, e.g. A()=0. A()=+0, or anything but a trivial expression, works. BASIC $=A$ does not get trapped if A$="". BASIC BASIC doesn't allow you to set HIMEM to the end of application workspace, even though it starts off at this value. e.g. HIMEM=HIMEM fails. Debugger When MOV r0, r14 is executed out of line after being breakpointed in SVC mode, then r0 is set to some value pointing into the debugger. Debugger SWI "Debugger_Disassemble" does not allow you to specify where the instruction came from, in order to get branches correct. MOS Circular segment fills can go wrong, if the last two points are sufficiently far from the centre, e.g. MODE0: MOVE640,512: MOVE200,200: PLOT173,1000,1000. Do not use such plot operations. MOS Multiple redirection errors give misleading messages, e.g. *thing { > foo > nonexistentfs: } gives 'Channel on channel 24'. This message will be improved in future versions. MOS Default OS_BreakPt handler prints incorrect PC of breakpoint (stored value is correct). MOS *Eval overwrites kernel workspace. The longer the result is, the worse the effect. *Eval with an integer result means that you can't soft break any more, long string results can crash the machine. The SWI behind *Eval (OS_EvaluateExpression) is fine. MOS Flushing the printer buffer when user or net printer is selected, causes the printer handle to be zeroed without being closed. This usually causes the 'File open' error message the next time a byte is sent to the printer. (Acknowledging escape flushes the printer buffer, and so will cause this effect). MOS Certain keys (e.g. TAB,`,num pad keys) do not take a pending CTRL-SHIFT-ALT into account; the effect is postponed until the next 'normal' key. In future versions of the operating system, ALT will be a shifting key in line with the behaviour of the ALT key on IBM machines. This provides ALT-nnn (three digits) to enter an absolute keycode, and various country-dependent ALT-letter sequences that provide accented characters. CTRL-SHIFT-ALT will have no effect. MOS *Modules counter wraps every 256 modules. MOS After a line fill to the right only (plot codes 88-95, 120-127) the external version of the graphics cursor Y-coordinate gets corrupted (it should be set to the Y-coordinate of the new point). Thus if a relative plot follows, the wrong coordinate is used. MOS *SCREENLOAD (and the corresponding SpriteOp) generates a misleading error report if it could open the file but an error occurred when getting the data (as happens for example if the disc is not in the drive). MOS *SCREENLOAD (and the corresponding SpriteOp) generates a misleading error report if an error occurs in Wrch while changing mode or programming the palette. MOS *SCREENLOAD (and the corresponding SpriteOp) sets the supremacy bit to 0 on all colours, even if the sprite has palette information. MOS If *SCREENLOAD (and the corresponding SpriteOp) needs to change MODE to load the image, then the cursor gets reenabled and can corrupt the image. MOS *SCREENSAVE should save the palette in 256-colour modes, instead it saves 64 palette entries. This will not be changed, however: the current file format will be retained. MOS Supervisor readline and 'SWI xx not known' share the same buffer. This may affect error messages produced in IRQ mode. MOS SpriteOp 'Return nth name' (13) does not check properly for overflowing the user's buffer. MOS During module initialisation, CAO contains -1, leading to "Currently Active" errors when podule modules try to overwrite MOSROM versions. MOS Recursive calls to the Module SWI during module death/init may lead to the MOS attempting to operate on the 1st incarnation of a module with 0 incarnations. MOS HeapExtend reason code corrupts the return address for the SWI, and it never comes back. MOS If expansion of an alias gets bigger than 256, an abort occurs (e.g. *Set alias$fred echo %0 %0 %0 %0 followed by *fred aaaaaa(etc.) goes wrong). Future versions will truncate at 256 characters. MOS The checks in SWI Plot that the FX3 status, the VDU queue status and the spool handle are all zero do not work - they read from the wrong locations. The locations that are actually read are three locations in the soft key expansion buffer. Normally these are zero, so the code takes the fast route always, and graphics output does not get spooled or sent to other output streams, and always goes to the VDU ignoring any queued VDU codes. However, if a soft key is programmed which is longer than 110 characters and does not have zeros at the 111th, 130th and 148th characters, and that key is expanded through rdch, then the code will always take the slow route, and send the graphics codes through WrchV. (The slow route can always be forced by claiming WrchV) MOS SWI Module with reason code EnumerateROMModules gets confused with more than one podule; returns the wrong registers for enumeration of the second RM in the second podule. MOS "*RMRun fred one two three four" loses the argument "one" between initialising the module and entering it. In future versions this argument will not be lost. MOS SpriteOp ReadPixelColour in 256-colour modes returns the colour with bits 3 and 5 clear. Future versions will be read from the sprite as described in the documentation. MOS Heap manager operations that free a block which is at the end of the used area of the heap, and are preceded by a free block, update the free list incorrectly. MOS Registers dumped in ExceptionDumpArea when the exception occured in FIQ or IRQ are SVC ones. MOS ModHand with ExtendBlock reason code never returns V set, even though the error pointer is set up. MOS SWI OS_ValidateAddress gets the start of screen memory wrong; it thinks it starts at 32Mbyte - 3* screensize. Desktop Fails to look on ADFS for accessories on start up. (New bug - it worked on 0.3). Desktop On exit characters 128-159 have been redefined; some are the same as characters higher in the set, so the line editor copies as them. Desktop On exit the function keys are not in their default state. *fx 225,1 is needed to reset them. Desktop On exit the palette is not reset correctly. Desktop Colour 7 of the default palette is dark blue; it should be black. The default run action for palette files (to *print them) is not useful to 1.2 palette files. This action may be removed in future versions. ADFS Disc not present upcall can get stuck refusing to acknowledge that the disc is now present. This affects *copy with named discs. ADFS Renaming a directory into another directory messes up the parent pointer. *COMPACT will put it right. ADFS+ If !Boot on a disc is a transient, and you select a FileSwitch directory on this disc, remove the disc from the drive, and auto-boot three times, the machine hangs on the third time (after printing 'Disc not present' the first two times). FileSwitch Killing FileSwitch doesn't de-allocate temp strings and fschain from the system heap. FileSwitch Calls to FSFunc that pass names to the filing system don't check the null filename conditions. FileSwitch RESET in the middle of running a transient leaves a block on the RMA heap that is free but still pointed to by fileswitch, so the next *RUN of an absolute type file crashes. FileSwitch OS_Args (r0>8) doesn't give the correct error message for an unbuffered filing system. FileSwitch If a transient returns with V clear, but has obtained an error from FileSwitch, the error is always raised. FileSwitch transients get given a dud r13: subtract &30 from r13 before using it within a transient, or you may crash the machine. Subtracting &30 will have no adverse effect in future versions (because it is a falling stack). SoundChannels Refuses to die when SoundDMA not there. Podule Calls to ReadBytes and WriteBytes don't preserve R4 as they are supposed to. If either of these two routines gets an error back from the Loader then the stack is broken and a BranchThroughZero usually occurs. (The common error is AddressTooBig.) FileSwitch Special fields of the form net#fs-master: are (wrongly) faulted. FileSwitch If using copy with ~c~f options, and if you are copying on top of an existing structure and files in the source are bigger than your selected buffer (Q affects that), then some files get left open. Wimp Immoveable window disallows all drags for that window (e.g. dragging the scroll bars). Wimp Blinks wrong icon if menu arrow selected. Wimp Toggle icon not redrawn if window doesn't move. Wimp If window moves, toggled state is reset. Wimp Clicking in the scroll bar causes a window to change its position in the stack. Wimp Wimp_GetPointerInfo returns 1 word too many. Wimp Sprite icon with border goes wrong, since fg colour of icon is treated as EOR colour instead. Wimp *Pointer sets bounding box to 0,0,1280,1024. Future versions of the operating system will read the screen size. Fonts *Fontcat if isn't set, gives the error 'Bad file name'. In future versions it will say that there are no fonts. Fonts Background colour change within a Font_PaintString (using character 18) causes an address exception. Fonts 'No more font handles' causes an address exception. Below are a number of known bugs in the Econet and NetFS modules. Many of these have been fixed and replacement modules are available from the ISV Department on receipt of a blank formatted 800k 3.5" disc. NetFS *Pass works, but gives a junk error message. NetFS PutBuffer of >&7FF bytes uses the wrong port. NetFS OS_Args gets the file server number wrong. NetFS *Logon doesn't look for the library. NetFS *Logon doesn't send the file server *SDisc . NetFS *ShutDown without having logged on gives an address exception. NetFS On exit from GBPB with r0=5, the disc name is padded with spaces. NetFS Execution of a *-command while not logged on gives a misleading Bad Station error. NetFS *Create hangs. NetFS %, & and @ in net filenames are not supported, but will be in future versions. \ and ^ are also not supported, nor will they be in future versions. Econet SWI AbandonTransmit causes an address exception if given a bad handle. Econet SWI ConvertStatusToString fails completely. Econet Retries after failure of Final Ack are off by 1 byte. Econet 'No reply' etc. give the wrong (254) net number in error messages, viz '254.253 not listening'. C. Acorn Computers Limited