Contents | < Browse | Browse >
AN OPEN LETTER TO ESCOM FROM THE ITALIAN AMIGA COMMUNITY ON FIDONET
From: email@example.com (Gruppo di lavoro corso Sistemi Operativi)
The following document is the result of one month of hard work and
discussion inside the Italian-speaking Fidonet Amiga users community. More
than 50 people, including software developers, professional DTV users and
normal users joined their efforts to make this document possible.
In the name of the Italian-speaking Amiga users community we wish you the
best of lucks in making the Amiga once again a successful platform.
According to the various opinions we have come across, the most important
aspect in a future operating system is the ability to configure and
customize all of its features.
Of course a standard configuration must be provided, and this configuration
should show all of the power of the system. The configuration provided
with the current operating system hides the real power and flexibility of
the Amiga Workbench and operating system.
The Amiga's unique Screen handling allows all of its programs to open an
appropriate screen to fit their own needs. This is the reason why in our
opinion the Workbench should not follow other operating systems where the
main desktop has 256 or more colors. We think that a 32 or even 16 color
Workbench is the right way between speed, memory usage and a sufficiently
colorful environment. There are utilities in the public domain such as
MagicWB and many others that accomplish this job with as low as 8 colors
through some impressive dithering.
We have gathered many and very different opinions about how to improve the
operating system for a new release, but we would like to emphasize that all
of the different personal tastes can be satisfied with an operating system
that is totally configurable as we mentioned before.
In the following list you will find many references to existing software
that is usually either under the Public Domain or Shareware concept. For
further details on how this software operates, we have included a reference
guide at the end of the document, complete with the addresses of the
authors in case you might want to contact them. Here follow the most
important opinions, some bug-reports and complains.
xx. Installation and help facilities
The first and most important thing is that the system is not user
friendly enough to a new user.
First thing off we need a tutorial that shows all of the basics to start to
get around your brand new Amiga. There used to be something similar a few
years ago; it was better than now that we have nothing like it but it had
too many static images. The user did not have the chance to interact
enough with the operating system environment. If a CD-ROM is to be fitted
as standard in future machines as we hope, the tutorial could be made as a
multimedia presentation with a speaker and all of the features this media
It is strongly recommended to have a "Help" menu in the Workbench that
activates an interactive Amiga Guide help such as the Balloon Help in the
Apple Macintosh or like the one in Directory Opus, but more user- friendly.
What we mean by this is that while the help is active you can click
everywhere and get information about the function or gadget you chose in
the Workbench. This help should be supported through the usage of shared
libraries so that also all other programs can use a system standard on-line
help. Usage of such on-line help should be mandatory in the developer kit
The second but not less important thing is the following. We have a good
hypertext viewer such as MultiView and a nice system standard hypertext
format such as the AmigaGuide format.
Why is it that there is no on-line help for any command whatsoever!?
Even the power users often need these!
Every single program of the OS should have an on-line help made with
AmigaGuide. It would be useful to finally use the "Help" key that for
YEARS nobody has EVER used. This is essential.
The same goes for the AmigaDOS commands. Too often the template given with
"<command> ?" is not enough even for the most experienced programmer. We
should keep the "<command> ?" -> template but add a help command. It
should work something like:
We should have a new system assignment called "HELP:" where all of the help
text files are kept, and all we would have to do would be to call More - it
would be useful if also the system default text viewer was configurable...
- We can't just pick up the Workbench or AmigaDOS manuals every time; in
fact, there shoould be a copy of these manuals in ASCII format included
with the operating system.
Also the ARexx manual should be given in a file in either AmigaGuide
(better) format or just plain text.
xx. Workbench operation
There are a few things that could be improved to make the Workbench an even
more powerful environment.
- There is a horrible bug (we believe it is something with the AGA chipset
though) in the Screen opening routines. This shows up clearly on the
Workbench if the external border is set to black with one of the many
borderblanker PD programs around. There is a verical line in the left side
of the screen, whose color register is 0. The width of this color-0 line
is independent of the resolution of the screen (that is why we suppose it
is a problem with the AGA chipset, but we might be wrong). Correct this
immediately, as it makes look backdrops with black as the background color
- The Workbench should allow asynchronous operation. The operating system
allows other program to multitask with each other but the Workbench does
not multitask with itself. Specifically some actions may take very long,
like opening drawers with large amounts of files or copying/moving files.
The Workbench should allow to work while a directory is being read. It is
crucial that the copy/move function opens a progress requester that allows
to abort the copying/moving and that allows the user to do other things in
the meantime on the Workbench itself. In fact, any action that could take
the Workbench busy should open its own progress requester and should work
- There should be a way to open the window of a drawer inside a disk
without having to open all of its parents before. Now if we need to enter
the drawer "DH0:Prefs/Env-Archive/Sys" we must open first the DH0: drawer
by double clicking on it, then the Prefs icon, then the Env-Archive icon,
and finally the Sys icon.
These are 4 actions that open windows that are totally useless for our
purposes if all we want to do is just see the contents of the "Sys"
This means that the new operating system should allow you to open a drawer
skipping all of the parent drawers. This can be accomplished by showing
the tree of the device and letting the user browse through it until he/she
finds the needed drawer and only then see its contents as icons, like in
OS/2. To accomplish this something as simple as a file requester can be
used. The AmigaDOS command "RequestFile" with the DRAWERSONLY option would
already allow this if the Workbench supported it.
- On the other hand, there is an option in the Workbench "Window" menu that
is called "Open parent" that would cause problems with the former directory
tree choosing option and currently causes memory problems even on 2MB
machines. Part of what this function does should be removed. In fact this
function keeps track (and takes huge amounts of memory to do it) of all of
the icons, its images and positions. The point is that even with 2MB
memory after a few sub-directories the user runs out of memory. It would
be enough just to preserve the complete path name of the parent drawer.
All it would take then would be to rescan the directory. It would be
slower, but much more memory effective.
- We recommend the usage of a 3-button mouse. We feel that all 3 of the
mouse buttons would be extensively used, for example in the choosing of the
directory in a tree (see above) you could double click the central button
while on top of a drawer icon to get an hypothetical 'tree window'.
All button actions should be configurable, and mouse buttons functions
should be switchable (also for left handed people).
- The keyboard shortcuts of the menu items in the Workbench screen are not
all assigned. This caused many complains. In particular, the widely used
"Show all files", "Show only icons", "View by name", and "View by icon"
don't have keyboard shortcuts. ALL items should have a shortcut, including
items in the Tools menu.
- The multiselection in the Workbench is not well supported. The current
way of deselecting a mistakenly chosen file is very uncomfortable. It
should be changed to simple clicking again on the icon with the left mouse
- The trashcan handling is not appropriate. We need a global trashcan, and
right now we have to put up with one trashcan for every partition.
- The Workbench must have an ARexx port.
- The "Execute Command" requester is not pointer sensitive and always opens
with the Topaz 8 font, independently of the system font the user chooses.
This is unacceptable for hires screens.
- All of the functions that ToolManager by Stefan Becker has should be
directly supported by the operating system. These include:
- Ability to add menu items in the 'Tools' menu. This feature is
specifically indicated in the Workbench manual but none of the programs
that come with the operating systems use it.
- Ability to add Images and Icons associated with actions to the Workbench
- Ability to add AppIcons to the Workbench.
- The handling of the scroll bars in the drawers is not smart. When one of
these sliders is moved, the contents do not follow it in real time, so that
we are only able to see the contents of the drawer in the initial and in
the final slider positions. This should be changed or such sliders lose
much of their utility.
- An interesting idea would be the possibility to have more desktops. What
we mean by that is the ability to open multiple Workbench screens at once.
Of course all of their data would have to be shared to save memory. The
programs that are run from one desktop (or call it 'view' if it seems more
appropriate) of course should open only on that view. This would also make
public screens useless for most things...
xx. Workbench configuration programs
The Workbench does not have any standard configuration provided with it,
but it should. There should be a number of default configurations,
possibly divided according to the screen resolution they're best for.
These should be ready-to-use configurations, including palette, font,
patterns, sounds, icons, and so on.
Another very important option that is required in all of the preferences
programs is, together with 'Save', 'Use', and 'Cancel', a 'Test' gadget.
Furthermore there should be keyboard shortcuts for all of these programs,
in fact the whole system should be entirely keyboard controllable.
For example currently there are no default patterns given with the OS. The
ones in the WBPattern are built-in the program and therefore are quite
useless, because they are not flexible enough. Instead, what we would need
is a directory with some nice backdrop patterns such as the ones that
MagicWB by Martin Huttenloher, a directory with some sounds, and so on.
The current configuration programs often have bugs; below a list with all
of our suggestions follows.
The standard screen mode MUST be a 31Khz mode. However, 15Khz video output
support must be kept for graphic users. Developers and normal users
currently have to buy expansive multiscan monitors to be able to use all of
the programs. Default 31Khz modes would allow Amiga users to buy better
and bigger VGA only monitors, as we noticed that very small minority uses
15Khz standard tv output. Unfortunately since games, the Bootmenu and the
system Alerts are in 15Khz mode (refer to the appropriate sections for
details) low end users now cannot use all of the Amiga screen modes because
multiscan monitors are too expansive. Note that this point is crucial.
This program only supports tiled patterns and does not allow absolute
positioning of a picture as backdrop pattern. In particular, we feel
necessary to have a 'center' option. This program is also incredibly slow
due to the fact that the palette is remapped each time the backdrop is
loaded (for example in the boot operations). There should be an option
that disables the backdrop remapping and simply uses the desktop colors,
changing only the ones that are not locked by the system. This way we
could have the system calculate the remapping just once, and speed up the
operatons quite impressively.
The current palette program is totally inadequate even for the low end
user. On Workbench 3.0+ even if the Workbench can be opened to up to 256
colors the user can only change the palette of the first four and of the
last four colors, and cannot lock nor edit any of the other 248 colors.
This problem is connected to some severe limitations of the icons structure
and of the icons editors provided with the Workbench that are discussed in
the Icon section.
The new palette program should be able to:
- Edit all of the colors in the desktop (up to 256)
- Lock any of them if asked
- Assign custom colors to ALL of the graphical elements in the OS. This
includes: gadget colors, window colors, text, background text, window
titles, menus, etc
- Have many ready-to-use complete color setups to choose from as already
- datatype support
- configurable sounds for every system event such as:
- window opening/closing
- screen opening/closing
- system requests
- and so on...
- The handling of just one type of beep (with flashing) is not enough.
Different classes of DisplayBeep()'s should be added and every one should
have a different sound associated with it. In particular there should be
different classes and priority for example for beeps that indicate finished
activity and ones that warn of a failure of some program function.
The IControl program now supports screen dragging with a key. It would be
very useful to have window dragging with another key.
Furthermore, now it is very unclear how to snapshot the Workbench window in
backdrop mode or not. Currently you have to choose from the menu item
"Backdrop" and then select "Snapshot window", but this approach it is not
intuitive at all. We recommend that this preference is included in the
IControl program. However both ways of configuring the Workbench window
should be available.
As explained in the GUI section, many users like popup menus like the ones
in MagicMenu by Martin Korndorfer, but many others don't. The solution is
adding a menu config option that allows to toggle popup menus on and off.
The font preview window is too small and is not resizeable. This means
that fonts higher than 24 pixels cannot be fully seen, even if they
perfectly work in the Workbench environment. Furthermore, if the Workbench
is open with many colors (for example 256) the window that the Font program
opens is not big enough as to fit all of the color gadgets and many are cut
outside the visible area. This is a real bug in the Font program requester
that should open a window that is big enough as to fit all of the necessary
Also, the system (shell) font should not be restricted only to FIXEDWIDTH
The fonts provided are not appropriate for high resolution screens. The
users need some that are specifically studied for the single monitor types.
The font engine should support other font types, such as the Adobe Type 1-3
and True Type, if the royalties allow it.
The Pointer preference program should have a variety of default pointers.
Also, support for alternate busy pointers and animated pointers would be
useful. The Pointer program is bugged. It will only open in PAL mode and
there is no way to promote it to any VGA-type screen.
The printer support is so important that it deserves a dedicated section.
Refer to that section for more information.
The date format should be FULLY localized.
xx. MultiView and datatypes
The datatypes are one of the strongest points that make the difference
between the Amiga operating system and others.
The concept behind them should be left behind for no reason whatsoever.
Using the datatypes we have a completely modular operating system. We
suggest including many more datatypes especially for usage with MultiView.
The most important are picture and animation datatypes to leave finally out
all of the non standard picture and anim viewers around. We have the
chance to use one program to see every single file in our computer, so
let's use it. Many of these datatypes are already in the public domain and
could be included.
Datatypes should be included for:
IFF24 ( which surprisingly is not supported yet )
SUN rasterfile images
HTML for Mosaic
Icon files (.info)
the most used audio formats such as .WAV .VOC .AIFF .AU .HCOM .SF
true support for ANIM5, ANIM6 and ANIM7 and CDXL
postScript files (screen output)
In fact there should be datatypes for as many filetypes as possible, but
the most critical are the picture datatypes.
The MultiView program should also allow the possibility to open more than
one file within the same screen. Right now if you want to view more files
at the same time it is necessary to load a copy of MultiView for each file.
One user also suggested that for the color reduction algorithms the
Floyd-Steinberg or other dithering algorithms should be supported. Also,
there is no support for 24bit images in the IFF datatype, and must be
included. MultiView has a bug if both BACKDROP and SCREEN flags are set
with an AmigaGuide document.
Datatypes should also have saving routines for picture formats other than
The AmigaGuide format should be improved too. MultiView does not support
full keyboard control. In fact, there are no keyboard shortcuts for the
"Contents", "Index", and all of the other gadgets that allow browsing
through the guides, and should be added to increase the ease of use.
Furthermore there is no color control. An AmigaGuide document that is
opened with the SCREEN option should allow customizable palette. A
"Search" gadget is necessary.
Pictures and any other datatype defined object should be supported within
the AmigaGuide document. Some users suggested that pictures should be
rescaled to small gadgets that show the picture when the gadget is
Finally, the AmigaGuide document handling in MultiView is quite slow.
See also the section about the Clipboard and about the Workbench desktop
improvements for other suggestions about the usage of datatypes for other
A more powerful clipboard system that supports a data conversion system
through datatypes would be appreciated. This way we would be able to cut a
piece of screen from a paint program and paste it in a word processor.
The clipboard functions should also apply to string gadgets that now do not
support cutting and pasting. There are many utilities in the public
domain, including one by Carolyn Scheppner, former Amiga developer.
PowerSnap by Nico Francois is one of the most used utilities by all users
and should be included in the operating system. This program allows to cut
a portion of bitmap from anywhere in a window and attempts to interpret it
as a string which is then pasted to the system clipboard. Note that this
tool allows cutting from programs that do not support the system clipboard.
Font support is included. PowerSnap is a 'must be there' in a future OS
according to ALL of the users' opinions.
Currently the icons are de facto limited to 8 colors. If the icons attempt
to use any other than the first 4 or the last 4 colors, since the icon
structure does not include the palette definitions the icons will show with
the wrong (unlocked) colors.
We need the new .info format for icons to save up to 256 colors (more
colors, though, would be a waste and would be useless) and to save the
palette together with the images.
The icon editor should of course be rewritten accordingly, and should save
only the used bitplanes to avoid wasting memory.
We need some icon collections like in other operating systems because we
have our HDs full of thousands of identical icons (the def_* ones).
We need to be able to get information with the Workbench menu "Info" from
AppIcons too. Adding a new tag for this is very easy and solves the
annoying 'Info failed' message on the Workbench. It would be useful if
AppIcons would also support custom menus with an appropriate tag.
We need more default icons like in Directory Opus. The user should be able
to set match parameters (ex. match name or extension with wildcard
support) so that when the Workbench finds a file that matches the
customizable file type the proper icon is assigned to it. Datatypes could
also be used to get a similar result. It does not make sense to use a
graphic interface that uses icons with images if all of the icons are
hammers as in the def_tool.info, because this way we have to go and read
the name. It is against the concept of "Intuition".
Defaults types should include:
- executable files
- ASCII texts
- AmigaGuide documents
- pictures (more formats)
and all of the other system files and more. Again, new file types should
be fully customizable. Directory Opus shows a good way of doing this in
the configure program under the item "Filetypes".
xx. Graphics User Interface
The GadTools Library has been heavily criticized. In the opinion of most
of us it has to be totally rewritten. The layout engine is not flexible
enough for the user and it is too complicated to handle for the programmers
that often spend much more time developing a graphic user interface rather
than the algorithm of the programs with obvious consequences.
Many users are now using the Magic User Interface by Stefan Stunz, and many
of the ideas were taken from this graphic engine. Its flexibility makes it
a unique product that yet does nothing but use Intuition and the BOOPSI
classes to their full potential. Still, the new graphic engine should be
faster than MUI.
RTG in future GUIs is mandatory.
A very important feature is the ability to have replaceable default gadget
images. This would lead to a totally upgradable GUI system. With proper
image upgrades, the look of such an operating system would very hardly look
Also this would avoid problems such as the ones caused by the fact that
many of the 2.0+ gadgets were designed for non interlaced usage (such as
the window resizing gadgets), which caused many complains.
This system could allow the usage of libraries of gadgets whose sizes are
specifically designed for certain resolutions, therefore solving many
Still, a scale engine such as the one in the Magic User Interface should be
supported. This engine should allow real window resizing as in the MUI.
This means that when a window is resized, all of its graphic parts should
be resized accordingly, provided that the aspect-ratio is kept constant.
So, we will have bigger buttons with bigger fonts and so on.
The windows handling routines should be updated too. We suggest that an
'iconify' (zoom) gadget for every window should be put as standard. Also,
there should be other ways to resize windows aside the current ones. The
gadget on the bottom right of the window is not sufficient. We suggest
that all four sides of the windows should be draggable sizing gadgets like
in X windows. The new libraries should also support dragging windows
partially outside of the visible screen area.
Dragging the entire window and its contents instead of just the border
should also be supported. This function should be configurable in one of
three possible ways:
- Always move only the border (like now)
- Move the border for size greater some user selectable value and for
smaller windows move the whole window
- Always move the entire window
The cycle gadgets should be popup gadgets as in the MUI. This means that
if a cycle gadget is clicked in the 'real' cycle image, to the left of the
gadget, as it is now it should browse through the possible options one by
one, while if it is clicked in the item part, it should open a popup window
showing all of the possible options. This is what CycleToMenu by Federico
Giannici and many other public domain utilities do.
Also the screen depth gadgets should be popup gadgets. There already is a
utility in the public domain called ScrMenu by Martin Blom that does this.
Popup menus should also be supported by the GUI libraries. These are menus
that open a window with the menu items anywhere on screen (and not just in
the top part like now) when the right mouse button is clicked. Since many
people like popup menus but as many don't, we do not mean in any way that
the current menu handling should be replaced by popup menus. Instead, both
ways should be supported. Also for some applications detachable menus are
useful and should be supported.
It is also important for menus to be fully keyboard controllable not only
with the Amiga+key keyboard shortcuts. Opening the menus with the alt key
and browsing through them with the arrow keys should also be supported
together with the classic right mouse button Amiga approach.
Support for screens in any number of colors greater than 256 is crucial.
It would be useful to have the ability to open a screen in any number of
colors, such as 512, 1024, and 2^n, with n up to 24 and 32, unlike other
platforms that usually only support 256, 32k, 64k or 24 bit palettes. This
feature alone could really make the difference.
xx. ASL and other requesters
The ASL library is outdated, uncomfortable to use and not configurable.
Most of the users replaced it with the reqtools.library by Nico Francois
and we feel that all of the featureos of this library should be straight-
forward included in the next release of the ASL.library.
The new requester library should allow:
- Configurable default size and position of the requesters
- Pointer relative requesters, meaning that all requesters should open
where the mouse pointer is.
- A standard palette requester that ASL does not have.
The file requesters should have the following features:
- The file requesters should show the available devices upon pressing the
(middle?) mouse button as in the Reqtools.library requesters.
- The file requesters should support multiselection by dragging the mouse.
- It would be very useful to have 'MakeDir' and 'Rename' gadgets in file
- Bring the screen they appear on to the front.
- Should always appear in the visible portion of the screen (support of
virtual screens). This means that if the requester opens outside the
visible area, they should automatically move the screen so as to be
- Should be completely keyboard controllable like reqtools' file
Most of the features listed were plainly taken from the ReqTools library
documentation but there are so many more that cannot be listed here.
The ARexx language is very powerful and widely used, but it can be
improved. It is recommended that the ARexx integration into the operating
system becomes even deeper. For example, for even more ease of use, it
would be better if all menu items were automatically available to the ARexx
port of a program. Also, it would be very useful to have GUI libraries
usable from within ARexx.
The Workbench should have an ARexx port too, so that all of its commands
are available to outside programs. This single option would make the
operating system much more powerful, with programs able to automatically
open drawers and select files.
xx. AmigaDOS and the Shell environment
a. AmigaDOS does not include a true MOVE command. The Rename command does
not support moving files across different devices. A simple macro called
'Move' can solve the problem. All it should do is check whether the source
and destination are in the same device or not and call 'Rename' or 'Copy'
and 'Delete' respectively.
b. It would be useful to have command to split big files.
c. AmigaDOS does not currently support multiple redirectioning. In
particular the ability to redirect the output to both a file and the stdout
is essential for some applications. In the public domain 'EchoHandler' by
Henrik Nordstr does exacly this, or a command like 'tee' in UNIX could be
d. The 'Dir' command sorts only the file names and not the directories.
e. Some commands have not been localized properly, like 'List', 'Avail',
f. The Format command has some bugs and does not have allow a high density
disk to be formatted in double density mode (880k) with an HD drive. Since
only a minority of existing Amigas have built-in high density drives this
is very annoying.
g. The Search command algorithm should be optimized because now it is just
too slow. See the utility list below for a better command already present
in the public domain. Also, 'Search' should support multiple keyword
h. The 'Initial-CLI' process does not use the new console handlers, does
not have a close gadget, and does not have clipboard support. In fact,
this Shell window has always had less features than the normal ones, and we
can't figure out why. This is annoying when selecting 'Boot with no
startup sequence' in the bootmenu.
i. The support of multiple assigns is not "real". 'ADD'ed assigns are not
sufficient. If one types "Dir ASSIGNEDPATH:", he/she should get a list of
all files in all directories associated with that name, including the
j. The 'Please insert volume xxxx in any drive' requester should not only
have the Retry and Cancel gadgets but should also have a 'Deny' gadget but
most important it should have an 'Assign' and a 'Mount' gadget like in
AssignWedge by Olaf Barthel.
k. The 'List' would be even more useful if it displayed the total bytes
used and not only the total blocks.
l. The console handler is good but outdated. There are many substitutes
in the public domain like 'KingCON' by David Larsson and 'GMC' by Goetz
Mueller. Here are the main features that a new console handler should
- File name completion with 'tab' key .
- Output history buffer as in 'KingCON' with configurable memory usage.
- Scrollbars in text Shells
- Customizable F1 through F10 function keys (also with Shift, Ctrl, and
- Ability to save the history buffer to a file with or without ANSI
- Possibility to have the current path in the title bar instead than in
the prompt as in GMC.
- Configurable actions such as shift-up/down ctrl- up/down, shift- return
as in GMC.
- Ability to store a line in the history without executing it.
- Ability to enable the 'Pg Up', 'Pg Dn' and 'PrtSc' keys. The latter
should allow to print either only the visible area or the entire buffer
(in text mode).
- Jump scrolling (selectable)
m. The v39 serial.device is SLOW, and has serious speed problems with the
new v.fast and v.34 28.800 bps modems.
n. In addition to RAM: and RAD: there should be also (in fact the majority
of the users use one) a dynamic recoverable ram disk. An example of this
is STAT-RAM, in the Shareware market. This device is a mixture of both RAM
and RAD. It dynamically allocates memory like RAM-DISK: but is also
recoverable and reset-proof like RAD.
xx. Disk and hard drive handling and maintenance
The Amiga operating system has not either a defragmentation utility nor a
recovery tool for both deleted files and corrupt media. We feel that these
programs are essential in an operating system. The defragmentation program
should have appropriate warnings about the possible damage that it can
cause, for example in case of a black-out. Also, an 'Undelete' command
should be included within the system. This program, however, should allow
to undelete files only in a given directory, unlike current public domain
and commercial programs that scan the entire device. There is not a data
recovery utility such as DiskSalv by Dave Haynie either. Such a program is
mandatory. This software should also allow partial recovery capabilities
(for data files). Also, for data protection a small anti virus program
should be included. Since an anti virus program cannot be kept up-to-date
as necessary if it was included, what the system anti virus program should
do is just checking the system vectors. On the other hand, it would be
useful if a system brain file editor would be included, with the updates
being left to the PD programmers. The system should also automatically
mark the bad blocks of all devices, and any access to these blocks should
be forbidden to avoid dreadful requesters like "Volume xxx has a read/write
error on block yyyy".
19. Memory and task management.
The memory and task management is not adequate for a real multitasking
environment such as the Amiga operating system. All the people who
contributed to the making of this document agree that the control that the
operating system has over its tasks and the memory they allocate is not
sufficient. There are many faulty programs out there and when they crash
the system cannot recover in any way the memory they allocated. Memory
fragmentation is also one of the single most important problems to be
solved. Furthermore, the operating system should be able to quit a program
and restore all of its resources. Note that this is very different from
quitting from within the program. This could be done by making the usage
of the commodities.library mandatory for all programs.
Still, some form of memory protection should be implemented anyway. Most
of us agree that such a feature is crucial for the new operating system,
but we do realize that such features cause a huge waste of resources and
processing time. This would make impossible to have low end and consumer
computers, so something in the middle has to be found.
We also feel that a flexible virtual memory support is required.
xx. Software failures
The software failures alerts are not appropriate for many reasons.
a. They open only at 15khz. People that use VGA ONLY monitors can't see
what's going wrong. We do realize that it is not easy, but all ALERTS
should check for the monitor type, or the VGAONLY option is crippled.
b. The messages of the software failures are too complicated for the low
end user that always gets scared the first times these happen. We DO know
this is much better than just freezing the computer, though. We recommend
a much more friendly explanation of the error that occurred with the task
name, not only the error number and task address. There are various
utilities that add a short explanation to the error messages. One of these
is the now outdated NewAlert by Martin Mares. The user should be given as
much (verbose) information as possible about what happened.
The Bootmenu routines should be rewritten.
One of the most incredible oversights in the operating system is the
handling of the bootmenu only at 15khz. Users with VGA ONLY monitors have
no access to the bootmenu options. This makes VGA ONLY monitors useless on
The user should be able to SAVE its custom boot configuration in a small
nonvolatile RAM like in the Amiga CD32. We even have a support library 95%
already done with the nonvolatile.library and with the battmem.resource
found on the Amiga CD32. On the other hand, there should also be a "Reset
to defaults" button, like in all preferences programs.
Quite a few options would make the Bootmenu better:
1. Monitor type selection between PAL, NTSC, VGA, and MULTISCAN.
2. Better control over the processor options. All features should be
present, like selectable Burst Mode, ExternalCache, Datacache, CopyBack,
etc. and all should have a separate toggle button.
3. ROM password protection, also with a enable/disable button.
4. Ability not only to view the autoconfig cards present, but also to
disable them at your need.
5. Ability to set the drive clicking on and off.
6. Ability to save all of the options. This should include also
autoconfig cards, automount drives, processor mode, monitor type, etc. In
particular, it should be possible to set a certain device not to automount
and save it with this configuration.
The printer support on Amigas has always been underdeveloped and below
average standard quality. Here are some of our ideas:
- There should be a printer spooler worthy of the Amiga multitasking
- More, newer and up-to-date printer drivers.
- Every printer driver should have its own configuration program
- A printer driver editor should be included either in the operating system
or in the Developer Kit.
xx. Miscellaneous tools and goodies
This is a list of all the utilities we think would complete the operating
system. Many are just too massive to be included, but again if the system
will be distributed on CD-ROMs then some public domain versions of these
pieces of software should be included within the CD.
- An external font viewer program should be included. This utility should
allow to view the complete character set of any font.
- A real-time compression commodity with different compression algorithms
support. This would make up for utilities like 'Stacker' on PC-IBMs.
- A small terminal program.
- The support for the narrator.device and translator.library should be
restarted and these libraries should be localized.
- LAN and Internet support programs like E-Mail, Telnet, Mosaic, FTP...
Since of course not every useful program around can be included within the
operating system, there should be a guide of which programs are considered
to be the most useful, with a short description of their functions and
where to find them.
xx. Compatibility with obsolete machines.
All functions that retain compatibility with 1.0 and 1.1 should be removed
from the Kickstart. These include OldOpenLibrary(), FattenLayerInfo() and
others. Also, all functions that have been substituted starting from
release 2.0 of the operating system should be considered obsolete and all
support should be dropped for os < 2.0 Specifically, compatibility with
Kickstart 1.3 should be abandoned in the preferences handling. IPrefs
should be automatically executed together with LoadWB, and the
DEVS:system-configuration file support should be dropped.
List of mentioned utilities and authors
1. Name : ToolManager
Function : Improve the desktop configurabilty trough customizable menus,
docks, images, icons, appicons and hotkeys.
Author : Stefan Becker
E-Mail : firstname.lastname@example.org
2. Name : KingCON
Function : Improved console handler
Author : David Larsson
Address : Gibraltarg. 82:150
S-412 79 GOTEBORG
E-Mail : Internet : email@example.com
3. Name : Reqtools.library and connected utilities
Function : Better looking, easy-to-use, configurable requester library.
Author : Nico Francois
Address : Corbielaan 13
E-Mail : Fidonet : 2:292/603.10 (Nico Francois)
Internet : Internet: firstname.lastname@example.org
4. Name : MUI (Magic User Interface)
Function : Totally new, customizable, stunning GUI
Author : Stefan Stuntz
Address : Eduard-Spranger-Strabe 7
E-Mail : InterNet : email@example.com
5. Name : CycleToMenu
Function : Transforms Cycle gadgets to popup menu gadgets
Author : Federico Giannici
Address : Viale Francia 4
E-Mail : firstname.lastname@example.org
6. Name : GMC console handler
Function : Flexible console handler
Author : Goetz Mueller
Address : Beim Wasserturm 3
7. Name : EchoHandler
Function : Allows mulitple redirection from the Shell
Author : Henrik Nordstrom
Address : Angsvagen 1
756 45 Uppsala
Phone : +46-(0)18-303763 or +46-(0)18-300104
E-Mail : FidoNet: Henrik Nordstrom 2:206/108 (The Crystal)
8. Name : MagicWB 2.0
Function : How the operating system icons should look.
Author : Martin Huttenloher of SASG
Address : Am Hochstraess 4
E-Mail : Z-Netz : XEN@NATHAN.ZER
Phone : ++49-(0)8362-81104
9. Name : ZGIF Datatype - Public Domain - could be included directly
Function : A GIF datatype
Author : ?
E-Mail : email@example.com or 100014,674 on CIS
10. Name : ScrMenu
Function : Opens a menu window with a list of open screens when the
screen depth gadget is clicked with the right mouse button
Author : Martin Blom
Address : Alsattersgatan 15A.24
E-Mail : firstname.lastname@example.org or email@example.com
11. Name : ArcHandler
Function : Allows archived files to be viewed like directories, and
all files inside can be read and/or executed transparently
to the operating system.
Author : Rafael D'Halleweyn
Address : Perckhoevelaan 17
E-Mail : Rafael.DHalleweyn@rug.ac.be
12. Name : MagicMenu
Function : Allows popup menus.
Author : Martin Korndorfer (con la dieresi sulla seconda o)
Address : Pommernstr. 15
D-W8912 Kaufering, Germany
E-Mail : Internet: firstname.lastname@example.org
Z-Netz: M.Korndoerfer@NATHAN.ZER or SYSOP@NATHAN.ZER
(NATHAN BBS: +49 8191 65542/66085)
Phone : (+49) 08191 / 6383
14. Name : NewAlert
Function : Displays useful info about software failures
Author : Martin Mares
E-Mail : email@example.com
15. Name : DiskSalv
Function : Data restore utility
Author : Dave Haynie
Address : 284 Memorial Avenue, Gibbstown, NJ 08027 USA
E-Mail : firstname.lastname@example.org
16. Name : AssignWedge
Function : Adds 'Assign', 'Mount' and 'Deny' gadgets in volume requesters
Author : Olaf Barthel
Address : Brabeckstrasse 35
Federal Republic of Germany
E-Mail : email@example.com
Concept and making by Federico Chiesa
Ideas, contribution, support and help by (in alphabetical order):
Paolo Agazzone Vincenzo Fodera` Mikael Osterhed
Danilo Aghemo Rolando Francini Antonello Pardi
Enrico Altavilla Mark Gallina Roberto Patriarca
Claudio Alviggi Edoardo Galvagno Jan Pasotto
Luca Baumer Gabriele Giambonini Denis Pavan
Massimiliano Belletti Eugenio Gori Giuliano Pochini
Giovanni Beltrame Bernardo Innocenti Luca Pompei
Giovanni Calderone Vincenzo Iodice Marco Roma
Norman Casagrande Raffaele Irlanda Francesco Ronchi
Gino Casavecchia Marco Losurdo Michele Santucci
Rocco Coluccelli Mauro Maltoni Demetrio Siragusa
Marco Della Vecchia Maurizio Mugelli Flavio Stanchina
Cesare Di Mauro Marco Musso Massimo Tantignone
Luca Di Meo Luca Nonato Alessandro Zummo
Fabio Filippi Massimiliano Origgi