AROSAmiga Research OS

Previous Next Top of Manual blank.gif

AROS - The Amiga Research OS


NEWS
    Old News
    Status
    Credits
Documentation
    Background
    FAQ
    CVS
    MetaMake
    Coding Style
    AROS XML
    Filesystems
    HIDD Intro
    HIDD Model
    Contents
    AutoDocs
    Random Ideas
Screenshots
Downloads
Snapshots
Links
1. Random Ideas
1.1 All lists and public structures must be protected by semaphores
1.2 Recursive lddaemon
1.3 Extend on the datatypes concept
1.4 HIDD Installation
1.5 Source code converter
1.6 select() for AmigaOS file handles
1.7 Cache memory
1.8 Double Buffer windows
1.9 Child/sub windows
1.10 EnqueueTail
1.11 Refresh only once
1.12 Clever OpenLibrary
1.13 Special write protection for libraries
1.14 Memory protection
1.15 Installer as a library
1.16 Installing AROS in PC BIOS
1.17 Separate implementation and interface
1.18 Configuration Database
1.19 Better debug support
1.20 Tool to show the number of missing/unimplemented functions
1.21 LibBase should become first argument of all functions
1.22 Use pipes instead of files to compile
1.23 Native compiler for AROS
1.24 Build Shared Thingy
1.25 Virtual Desktops



1. Random Ideas

This part of the documentation for AROS contains random and unsorted and possibly impossible improvements, ideas and other things which might go into AROS V2.x, when compatibility with AmigaOS is still important but where new things can be done.

1.1 All lists and public structures must be protected by semaphores

By Nils Henrik Lorentzen

A system like the hierarchical semaphores in pOS would be best.

1.2 Recursive lddaemon

By Claus Herrmann and Iain Templeton

lddaemon should be able to load more than one library at a time thus allowing to open a library which has to be loaded from disk which opens a library in libOpen() which has also to be loaded from disk.

The daemon could also search actively for a library allowing the user to specify one if it can't be found. Paths like PROGDIR: should be searched automatically.

If the lib can't be found, DOS_OpenLibrary() must create a message port and a message, put the port in the reply-to field of the message as well as the name and min-version of the lib and then send the message to the lddaemon and wait for the reply.

Open questions: Will this interfere with the way Exec handles libraries now (eg. single threaded libInit()) ? Can this introduce deadlocks in the locking of the exec library list ? What happens if libClose() calls libExpunge() ?

1.3 Extend on the datatypes concept

By Nils Henrik Lorentzen

Some datatypes-alike system where dataprocessing methods can be added to datatype classes. (Eg. for pictures one could add methods like Rotate(), Flip() and other typical image processing operators. Similarly one can add sound fx methods for sound data). For this to be usefull one should probably be able to add methods to a class one by one (so BOOPSI can probably not be used for this).

The objects should contain the data in a raw format so that the methods can easily operate on it. One should be able to stream data in and out of the objects. One could have separate "converter objects" that can convert from a data format (eg. GIF->internal raw image format and back eg. raw->GIF.) So when you want to put a GIF file into an image object the system will automatically search for installed gif->internal raw converters and convert the GIF into a stream of raw image data passed to the image object.

These data objects should of course have methods like Show() and Edit(). Edit() could invoke your favourite texteditor/paintprogram/drawprogram/etc depending on the object type. (text/image/structured drawing).

Now, should these objects be able to show themselves, like the old datatypes ? Well, IMO they should not be bound to a single operating system/GUI system, but they could maybe show themselves through some RTG system (?). But the viewer could also stream out the data from the object to show. When the object's data has changed, the viewer could be notified and where in the stream the "damaged" data is. (If a text viewer GUI views the first 100 lines of a 100000 line text data object, and the last 100 lines are changed, it wouldn't need to rerender).

As mentioned earlier one should be able to use this system on different OSes, and it should maybe also be possible to invoke methods on them over a network or even move the objects in a network (using CORBA ?). This way a heavy operation on the data object can be done on a faster machine while you are controlling it from a slower machine.

By keeping functionality into small components, 3rd party programmers can easily write freeware additional functionality. (One can add methods operating on the data one at a time.) It will provide very much reuse of code. (Just look around on Aminet: There are whole bunch of different image processing programs that implement the same functionality. This should really only have to be written once). If the system can work on other platforms too, we get even more developers that can support it.

I believe that if some system should have any chance at all of taking some market share from M$ it a) has to be free. b) must be available on as many platforms as possible. c) must consist of tiny components that can be added at run-time.=>This way it'll be easier for developers to support it.

1.4 HIDD Installation

By Aaron Digulla

When a new HIDD is installed, it should appear in the list of available HIDDs automatically (eg. by file notification on the directory).

1.5 Source code converter

By Aaron Digulla

We need an automatic converter for the incompatible features of AROS to convert the old AmigaOS code to AROS (which can then be compiled on AmigaOS by our compatibility lib).

Comment by Henning Kiel

The original Amiga Includes used to have an intuition/iobsolete.h AROS wants to get rid of obsolete stuff, and therefore we are not going to include iobsolete.h in our distribution. However, we are intersted in getting software for AROS and this may be old, but useful. So we need a way to support old sources, but in such a way, that the old code will be converted. (Maybe in multiple passes) This conversion-tool should do: (open, unordered list)

  • convert old defines to new ones
  • convert old storage types (e.g. SHORT to WORD)

1.6 select() for AmigaOS file handles

By Bernhard Fastenrath

I wanted to have a select() for AmigaOS filedescriptors some time ago, that's why I wrote the AbortPkt() patch which sends an ACTION_ABORT.

A select/asyncio handler (AsyncIO.hidd ?) which handles allocation of buffers and IO on multiple handlers could allocate buffers, do multiple reads on behalf of a process and signal the process when input is available. The same would happen for write operations (writing would block when the select handler has queued a maximum of bytes or buffers for a single process).

A process that wants to exit could just close the select handler and leave it to the handler to deallocate the buffers when they are returned one day ... Under AROS the handler would be able to use AbortPkt() and under AmigaOS it would be able to use it if the patch is installed and the underlying handler accepts the packet type ACTION_ABORT.

The idea reminds me a bit of Unix STREAMS or NT device drivers: both pass packets through several layers of device abstractions. UnixIO could be one layer below the select handler and would translate it to a real select() because the buffer mechanism of the select handler is part of the Unix kernel anyway; so a write would block when the kernel buffers are full, as usual.

1.7 Cache memory

By Aaron Digulla

I'm thinking about something called "cache memory". It should use all free memory to store "nice to have" data like for read ahead or write through caches for disks and harddisk or a printer spooler.

This memory is allocated by special functions. It doesn't appear in the "memory used" list but is added to the amount of free memory. Besides allocation and freeing there are two special cases. The simple one is that some other application needs the RAM, so parts of the cache have to be purged. The other one is to avoid memory fragmentation. It's not possible or useful to use all the free memory for caching. So the cache should always be one large block divided up in several smaller chunks. If an application needs memory, parts of the cache have to be freed *or* they have to be copied in unused chunks (eg. it's still faster to copy 512 bytes than to read them back from HD or a printer spooler should not throw the spooled data away).

1.8 Double Buffer windows

By Paulo F. Zemek

The Amiga has the Smart refreshed windows that uses an own bitmap and the Simple, that need to be refreshed because it uses the screen bitmap. I want a Double Buffered one. A simple refresh window where you allocate a bitmap and a rastport for it, and this will be send to window on Refresh (or in window's BackFill Hook) and when the Draw of All Buttons are finished, so you don't get "flickering" (I don't know the correct word) on the graphic, and uses almost the same memory of a Smart one.

1.9 Child/sub windows

By Paulo F. Zemek

The amiga needs a function for opening windows into other windows like on windows. The "Requester" does this, but stops the functionality of the window, and doesn't have all Attributes of a real window. This or something like this is needed for buttons which are over others, so the graphic of the "bottom" one will not pass over the front one. And can be created new functions for opening Windows/Screens, so you can convert a window into a screen, create Public Windows and open other windows on it...

Comment by Aaron Digulla

This is dangerous; it uses a lot of memory, adds many IDCMP event loops and the same effect can be achieved when using clip regions; all we have to do is to make the gadgets public, which render a window, plus maybe a BOOPSI subwindow class which installs a clip region in another window.

Comment by Bernardo Innocenti

I would like to extend Layers and Intuition to support child layers.

Basically, since V37 and upto V40 Intuition has undergone a major philosophical rearrangement. The old structure-centric way of doing things has been replaced by an object-centric fashon round the concept of boopsi classes. Gadgets and images have been hit first by this new technology. Windows, menus and screens would have had to, but for some reason it did not happen (lack of time or compatibility issues).

If windows were boopsi classes, you could override their default behaviour simply by subclassing them.

Some months ago I had a very interesting technical discussion around this topic with Massimo Tantignone, author of VisualPrefs. We talked about a possible design to implement child layers in a semi-compatible fashon, which would allow nested windows as well. The current Intuition already has some features (implemented in a non-OOP fashon) which simulate nested layers. These are GimmeZeroZero windows and requesters. Screens could be considered containers for windows, thus adding another level, but hierarchy stops here. There are ugly design asymmetries that prevent you from drawing in a Requester the same way you draw in a window and other similar problems.

I must admit that in this field Windows has a cleaner design (please don't kill me). A window is just a rectangular clip region and everything from menus to buttons is represented by a window. Dialogs and frame windows are just two special kinds of windows that are attached to standard window borders and system gadgets.

X11 has a very flexible concept for window borders. Insead of belonging to the application, the borders are drawn and refreshed by the window manager, which can even replaced at run-time.

Comment by Georg Steger

Child windows could be done similiar to MUI's virtual groups = with InstallClipRegion. Unfortunately InstallClipRegion in AmigaOS can be very slow and in case of SMART REFRESH windows also eat terrible lots of memory (hidden areas in the worst case might be backuped three times!!) because it is optimized for:

one installclipregion --> many render functions --> one installclipregion

instead of:

many installclipregion with few render functions inbetween.

It's also bad that there is no additional rastport-based clipping. Actually the gfx-functions don't know anything about a clip-region (or beginupdate state), they just clip to the cliprect list in layer->ClipRect. For AmigaOS maybe it would be easier to not add real child layers, but only child windows, which layers.library does not know about. I would also limit the child windows to SIMPLE REFRESH (and maybe SUPERREFRESH) type, as SMART REFRESH child windows would probably be too slow, and SMART REFRESH layers are the most complicated ones anyway.

One would need special funcs for GetMsg/ReplyMsg on win->UserPort similiar to GT_GetIMsg and GT_ReplyIMsg from gadtools.library. This funcs would filter certain messages, for example divert IDCMP_MOUSEBUTTON to the correct child window or "add" additional IDCMP_REFRESHWINDOW messages for example because of damage resulted from a MoveChildWindow which would first add this message to a private ChildWindow port. A ??_GetMsg(realwindow->UserPort) would therefore also return messages from private ChildWindow ports.

For rendering into a child-window (assuming non-SMART child windows only) I would use something like this:


ObtainChildWindowRastPort(childwindow)
{
  LockLayer(realwindow->Layer);
  save realwindow->Layer->ClipRect somewhere
  create a realwindow->Layer->ClipRect list based on:
  
     childwindow->visibleRegion AND    visibleregion must be calculated here *
     childwindow->clipRegion           from a InstallChildWindowClipRegion() *
}
ReleaseChildWindowRastPort(childwindow)
{
  restore realwindow->Layer->ClipRect
  UnLockLayer(realwindow->Layer);
}
BeginChildWindowRefresh(childwindow)
{
  LockLayer(realwindow->Layer);
  save realwindow->Layer->ClipRect somewhere
  create a realwindow->Layer->ClipRect list based on:
  
     childwindow->visibleRegion AND  visibleregion must be calculated here *
     childwindow->clipRegion AND
     childwindow->damageRegion
}
EndChildWindowRefresh(childwindow, done)
{
  if (done) childwindow->damageRegion = EMPTY
  restore realwindow->Layer->ClipRect
  UnLockLayer(realwindow->Layer);
}

Creating Layer->ClipRect lists for non-SMART REFRESH child windows is easy as you never have to backup hidden areas, so it is basically an AllocMem and setting some coordinates.

But if you want child layers for the actual AmigaOS, then you can only replace layers.library completely, but not Intuition for which you need special functions for MoveChildWindow, SizeChildWindow, ... which know about the child layers. It is not a good idea to patch the normal MoveWindow, SizeWindow, ... because child layers really need special functions like HideChildWindow, MakeChildWindowVisible.

Comment by Bernardo Innocenti

This would make child layers very different from normal layers. You woudn't be able to render inside them using exactly the same code, which is bad because authors of boopsi gadgets would have to take special precautions to support child layers. The same is true for requesters: have you ever tried to add boopsi classes to requesters? Well, you would find out that most of them won't work because of bugs in both Intuition, the gadgetclass and the subclasses.

I meant REALLY implemeninting child layers and child windows, not just faking them with some clever patch. Each child window would just get its own Layer structure and layers.library would have to be improved to take children into account when depth arranging or moving their parents.

I was thinking about something like this:


struct Layer
{
    struct Layer front, *back;
    [...]
    struct Layer parent, *children;
};

Where "parent" points to the parent (NULL if it's a top-level layer), and "children" points to the frontmost child layer (NULL if there are none). Children are chained together with front/back pointers in the same fashon of normal layers.

This way you wouldn't need to install any additional clip regions before rendering. That's exactly like window requesters: they are just a limited special case of child layers. The main weak points of the requesters design is that you can't nest a requester into another requester, and you must use a different set of functions to manage them. Furthermore, you can't move or depth-arrange requesters. If these limitations could be removed by implementing child-layers in a simmetrical OOP fashon, you would just use Open/Close/Move/SizeWindow() on them.

Another important improvement that could be done quite easily is turning Layer and Window structures into white-box instances of boopsi objects, like it has been done for Gadget and Image structures. Then the old-style functions (Open/Close/Move/Size/Window()) would just build the appropriate boopsi message and invoke the dispatcher. The same technique has been used to add boopsi support in pre-V36 functions such as ActivateGadget() and DrawImage().

Of course these ideas would require mayor reworking in both layers and Intuition, but I bet it could be done without breaking the current API and OS structures, so that unaware applications would continue to work as usual.

We wanted to submit our draft proposal to the AmigaOS developers for comment. If we could convince them of taking this way for the next Kickstart release, we would have no reason for patching or replacing layers.library at all.

Comment by Georg Steger

Requesters aren't child windows/layers in any way. For layers.library there is no difference between a requester layer and a window layer. It's just Intuition, which when moving or depth-arranging a window, additionally to the window layer also moves/depth arranges the requester layers of a window. If you tried to directly call MoveLayer (I know, it's not allowed) on a requester Layer you would see that you can easily move it out of the (not so) parent Window's layer or depth arrange it behind the parent Window's layer.

The only thing layers.library would have to do in such a case is add/remove damage to the child windows (whose coords are relative to parent window) that are non-hidden, right? Or do you think child layer cliprects should be re- "calculated" immediately as well, like what is happening with the normal layers. With the ObtainChildRastPort, ReleaseChildRastPort I was talking about this would not be done (= faster moving of top level layers) but instead ObtainChild- RastPort would take care about it = you have precalculated cliprects (= fast gfx functions) until you call ReleaseChildRastPort.

It is not a good idea to patch the normal MoveWindow, SizeWindow, ... because child layers really need special functions like HideChildWindow, MakeChildWindowVisible.

Comment by Bernardo Innocenti

We don't really need any special code for child layers: top-level layers would just be a special case of child layers whose parent is the screen layer_info. This asymmetry is bad, but you can't do anything about it because layer_info must be ratained for backwards compatibility.

Instead of adding adding a new set of functions to layers.library, we would have rather implemented it through boopsi classes. Layers could be turned into white-box boopsi objects (i.e: have a pointer to the class at a negative offset from the Layers structure and optionally additional instance data after the old-style structure). Then most of the current layers.library code would be moved inside the dispatcher of this new "layerclass", and the old functions would become stubs for call the respective methods. I think that would be a clean and extensible design for OOP layers.

Optionally they would have to clip the children to appear "inside" the parent when they are partially outside the edges of their parent. Look at Microsoft's MDI interface: if you open Word and move a document window outside Word's main window, it gets clipped inside it.

Perhaps we could get the same effect of child layers without touching the layers.library at all and doing OOP magic on Intuition windows instead. What if the Window structure had a pointer to its parent window and a linked list of children? Again, Intuition's Move/Size/OpenWindow() would have to be extended to support child windows in a OOP fashon.

Comment by Aaron Digulla

Moving this into Intuition looks most clean to me. Basically, what will happen is that you get a window which moves with it's parent and where the code which calculates the size of the window (or the cliprect for it) takes the size and position of the parent window into account. That should work best and looks simple enough to me to work.

Comment by Bernardo Innocenti

On a second thought, there would be some hard-to-solve efficiency and aestetic problems when child windows are implemented without the help of the layers.library.

I think it can be explained better by showing a piece of pseudo-code:


MoveWindow(struct Window *w, int x, int y)
{
    [...clip coordinates inside screen...]
     move window layer (relative to parent) *
    MoveLayer(w->WLayer, x + w->WParent->LeftEdge, y + w->WParent->TopEdge);
#ifdef INTUITION_CHILD_WINDOWS
    struct Window *child = w->WFirstChild;
    while(child)
    {
        MoveWindow(child, child->LeftEdge , child->TopEdge);
        child = child->NextWindow;
    }
#endif /* INTUITION_CHILD_WINDOWS */
    [...check for damage in ANY layer on the screen and send refresh
    notifications...]
}

Here we recursively call MoveWindow() on each children to adjust their relative position. Since MoveLayer() knows nothing about child windows, the effect you will see on the screen is:

  • the parent slides under its children, eventually damaging other windows on the screen.
  • the children (which are layers in front of the parent) inflict damage to their parent. These damage rectangles get immediately filled by the layer backfilling hook.
  • each of the children moves to "follow" its parent, eventually damaging each other (no matter which order you choose to move them). Again, the damage in the children windows is backfilled.
  • If the children had their own children (nephews? ;-), you would see them moving as described above.

This scenario is awful and must be absolutely avoided. A clever workaround could be adding a very complex function in layers.library such as MoveMultipleLayers(), which takes a linked list of layers as an argument. I can't imagine what kind of efforts this function should do to move all the layers at once in a way that minimizes damage. For sure, it would be rather complex to write.

1.10 EnqueueTail

By Paulo F. Zemek

exec.library can have an EnqueueTail, and this is easy to do, so the Enqueue already exists.

1.11 Refresh only once

By Paulo F. Zemek

Intuition should not send more than one REFRESH message to a window (ie. if there is already one in the queue, then it should be removed first).

1.12 Clever OpenLibrary

By Denis Bucher

OpenLibrary(), etc. should check for libraries in various places. It should be possible to add paths for these and similar functions and there should be a tool which checks and tells which library, etc. would be opened (eg. the path is libs,PROGDIR:libs,libs: and there is a x.library in libs and libs:. The tool should tell which one is opened and why (ie. loading libs:x.library over libs/x.library because: libs:x.library has version 41.0 and libs/x.library has 39.20).

1.13 Special write protection for libraries

By Aaron Digulla

It should be possible to protect some files (like libraries) so that you need to call a specific OS/FS function to replace them. This would allow to fix all problems with tools replacing libraries with old versions. Maybe even a patch to Open() would be enough which checks if someone tries to write in a specific directory and calls a tool which checks if the write is ok. This is of course a bit dangerous.

1.14 Memory protection

By Dave Haynie

Stuff we spoke about over lunch, dating back to our days consulting for Amiga Technologies. Andy mentioned the model they use for the 3DO operating system (the original one, not the M2 version, which is supposedly more like the BeOS).

In this system, each process has its own memory map, but the actual mapping is still global (eg, there's just one memory space). Your process can see the rest of the world as read-only. Functions like AllocMem() transparently work from local memory pools attached to your process, so things stay nicely page-aligned. This has the secondary effect of making AllocMem() faster than it is today, since you only have to involve Exec proper (locking the system up to keep things atomic) every so often, not at every AllocMem().

I would make the extension to this that memory contexts become first-class Exec objects. The System context would be the "root", with read/write access as we have today. Device drivers that need the direct access to hardware, or the performance of using references rather than copies, could be started on this context. You could build alternate contexts, such as the read-only underlay, as mentioned, or even fully private memory spaces, as in UNIX. Obviously this is for new code, and Exec would need to add/enhance functions for sending messages, copying, etc. between memory spaces. But since you're not expecting any old code to run in a fully separate space, some of today's bad habits wouldn't really be an issue.

1.15 Installer as a library

By Sebastian Rittau

Maybe we could rewrite Installer as library, which provides functions that are currently contained in Installers language. This would allow programmers to easily write Installer scripts in their prefered programming language, instead of learning Installer's own language.

While doing this, we could also add methods to uninstall an installed package.

1.16 Installing AROS in PC BIOS

By Aaron Digulla

There should be a tool to create a kernel which can be put into a Flash ROM or EEPROM or a boot file. The tool should be able to fix all absolute addresses in the kernel, it should be able to create the resident tags or a simple file system which allows the boot loader to find, load and init all parts it needs.

The main reasons for this are: When you add a new driver (eg. a harddisk controller), you don't want to have to install a C compiler just to be able to boot from it. The ordinary user just wants to call a "install driver" tool which does all the work without him worrying. Also to reduce similar code, the boot loader will probably use the same code to load drivers as will the OS. So the "file system" which is visible to the boot loader must be similar to what the OS sees. This becomes more important if some driver in the ROM is not loaded/inited during booting. Then the OS will use its normal ways to search for the driver and at this time, the driver must be visible by some file system-like means or the searching for it will fail.

1.17 Separate implementation and interface

By Aaron Digulla

An idea just stuck me which *might* safe us a lot of trouble.

We should separate the code from the interface. Code is here: The code for the ROM libraries and interface is here the Exec shared library interface.

As you might remember, I dream about AROS as native emulation (ie. compile Amiga apps which run as native apps without arosshell).

Most of the problems we have right now (eg. in the mmakefiles) come from the fact that we can't use the systems' own way to work with shared objects but that we try to emulate Exec's way.

IMHO, it would be much better if we did this:

exec becomes a plain exec.lib which contains normal functions. Then we create an interface for these normal functions and this interface can be accessed as exec.library. All we have to do now is to link the interface with the standard library. If we don't need the interface (eg. because we have a cool autoinit feature like the dynamic loader from Unix), we can omit it.

This way, we could separate the amiga-specific parts of AROS much better from the portable parts. Also, it would be possible to create different interfaces much better. And the interface wouldn't be intermixed with the portable code as it is now.

1.18 Configuration Database

By Aaron Digulla

Ok, since the topic has been brought up: Here is something which I'm missing in the current config DBs/registries:

There should be a way to keep histories of configurations plus "commit logs". Basically, the whole config should work with CVS. That would make debugging much more simple (just throw anything out and when it works again, do a diff to see what has changed). It would also answer the question "why did I disable that" ?

And with tags, you can name stable states of the config and switch between them.

1.19 Better debug support

By Bernardo Innocenti

Debugging in AROS is becoming harder as we add new functionality and the system becomes more complex. So we need more debug support in AROS. Here are some misc ideas:

DEBUGGING MEMORY
I'm thinking of adding some tortures into AllocMem(), FreeMem() and possibly other system calls to encourage buggy code to crash. Mungwalls around allocated blocks would be another great thing.
ASSERTING EVERYWHERE
To reach rock stability we must put all kinds of validity checks everywhere in the code. Please everybody start using those ASSERT_#? macros and create new ones for checking structures which may need further checks. I'm planning a ASSERT_VALID_LIST() macro for checking Exec lists against dangling pointers, infinite loops and succ <-> pred inconsistencies.
IMPLEMENTING COMPLEX CHECKS
Some of those macros might become too big to put them always inline. We may need to add some support code into exec.library or perhaps arossupport.library. Some I already feel the need for are _kassert() and _kbadpointer().
DIAGNOSTIC DUMPS
The need may arise to dump some system structures in a human-readable format to help debugging. I've done some DUMP_#?() macros (such as DUMP_LAYER(l) to track bugs in my own programs in the past, but I would like to turn them into functions because they are usually too big for inlining.
TRACING SUPPORT
Assertions in functions such as AddNode() would be pretty useless without some facility to trace back the call stack down to the caller. A single level might not be sufficient and gdb can't be used to debug programs loaded by LoadSeg(). Unfortunately, this is a very CPU-dependent feature and I have no clue of how it should be done.
TRAPPING EXCEPTIONS
We might benefit by implementing an handler to trap seg faults and other exceptions. This could dump the CPU registers and trace into the stack. Hits could be tracked down to the module responsable for them by adding SegTracker-like functionality into LoadSeg().
STACK TRACEBACK
We need to provide a CPU-dependent support function to unroll the stack to help tracking the origin of a bug. Seeing that AddNode() got an illegal node pointer is no big help if you don't know where AddNode() has been called from.

1.20 Tool to show the number of missing/unimplemented functions

By Georg Steger

The idea is to have a software which scans a software for AmigaOS functions and reports those which are not yet implemented.

1.21 LibBase should become first argument of all functions

By Michael Schulz

I would like to put LibBase as first argument for every function in every library (like in real classes). Then with __attribute__((regparm(1))) we could force compiler to pass first argument (would be LibBase) through register instead of stack.

1.22 Use pipes instead of files to compile

By Georg Steger

Could we have some of this autogenerated files like "functable.c" and "endtag.c" be generated and compiled on the fly by using pipes: ~generate this files to stdout and make gcc compile from stdin? -> no more functable.c and endtag.c files on disk -> speedup!?

Comment by Fabio Alemagna

gcc cant accept source files from stdin. It can do that only if the switch -E is given too, that means only preprocesig is being done. In order to do that you should call cc1 manually and handle all the rest (preprocessing, switches to pass to cc1...) manually too...

1.23 Native compiler for AROS

By Henrik Berglund

Maybe lcc would be the easies compiler to port to aros? You can find lcc at http://www.cs.princeton.edu/software/lcc/.

1.24 Build Shared Thingy

By Henning Kiel

AIM: The 'Build Shared Thingy' is intended to be a tool to generate all sorts of shared binaries in a common way. It should be only given a directory and produce the shared bin out of it -- or at least generate C-code which then only needs to be compiled. It might read in some *global* config file which contains info on the system (OS/Hardware).

Mainly the tool is intended to make generation of libraries easier, but it should be also possible to create HIDDs, etc. with this tool.

'How does shared library creation work?'

THINGS IT MUST DO: We must have an archive with all the functions code and the specification of the interface (ie. return-value and parameters like *.arch), so the tool can create the library-functions itself. There must be a way to substitute system/machine-dependant functions like a dir-tree in AROS/machine/linux-i386/rom/dos for linux-i386 specific functions which will replace std or will be added to AROS/rom/dos.

We must provide a short description of the library (ie. Name, LibBase, LibBaseType, Version, options like lib.conf).

The tool must provide standard init, open, close, expunge and null functions, which can be overridden or better: you provide an abstract description of what is to do (ie. library dependencies, initializing code, etc. -- the tool then will create the code on its own).

Archtools functionality (inherited from the gawk scripts) must be given: generate includes, merging archives, etc.

AutoDocs should be integrated, too, since they are closely connected to the sources.

Comment by Iain Templeton

This is the text of the file tools/buildshared/README, which I have removed and put the content in this file. It turns out that some of this functionality is implemented in the tools/genskeleton directory, and some in the new Python based archtools that Aaron Digulla has been workin on.

1.25 Virtual Desktops

By Stefan Berger et al.

Enhance Intuition to support virtual desktops. This should be easily possible with the (hyper)layers.library and the ability to make layers and windows invisible. Windows by default are opened on the currently active virtual desktop, which is identified by a 32 bit identifier in the screen structure. If windows are to be opened on a different desktop this can be specified with the WA_Desktop tag when the window is opened. WA_Sticky allows to make the window sticky and it will appear on all desktops. Desktops could be identified by a bit, thus making 32 virtual desktops available on a screen with the previously mentioned 32 bit identifier. The sticky flag would therefore select the desktop identifier 0xffffffff. The window and screen structures would have to be extended with a ULONG field. Enhance Intuition with function DisplayDesktop(screen, desktopnum). The technology is out in the public with the X window system, although there is a patent on this afaik.


Previous Next Top of Manual blank.gif
minilogo.gif

Amiga® is a trademark of Amiga Inc. All other trademarks belong to their respective owners.

Copyright © AROS - The Amiga Research OS
All Rights Reserved
Comments to webmaster: digulla@aros.org
Generated: Wed Oct 17, 2001