Decisions and Work

Purpose

On this page open decisions and work should be collected. Only the Problem, Solutions and Decision should be written here, all discussions should be done on the discussion Page.

ABIv0 / ABIv1 in AROS

Problem

With x86_64 the first ABIv1 is introduced to Freepascal, but it is not working currently because of the differences in the SDK. To change that is not a big problem, but if is done, it would be good to have a general approach for the ABIv0/ABIv1 switching. Freepascal already has a concept of ABI switching. Here a Default must be set (abi_default) and a new one. The first reaction would be to make ABIv0 as abi_default (because thats the only one working) and create another one abi_AROSv1 or something like this. But if we look to the future the i386 ABIv0 will be gone (far distant future after singularity or so) then there will be no abi_default or so, which is a little bit strange, isn't it?. The decision also must be synchronized with freepascal ideas about this ABI feature in Freepascal. (Charlie got the task to discuss this.)

Solutions

1. ABIv0 as abi_default, ABIv1 as abi_AROSv1
2. ABIv1 as abi_default, ABIv0 as abi_AROSv0

Decision

No decision

VarArgs Versions of Functions

Problem

How to create varargs Versions of functions. The current implementations in the three platforms are different.

• Amiga uses "array of const" together with broken readintags() and readinlong()
• AROS uses "array of const" together with own TTagsArray AddTags function
• MorphOS uses "array of DWord"

The Amiga implementation is for sure broken because readintags/readinlong are using one global array so if you call a Method which triggers an Event which want to do an other function with tags you get a crash because the second tag use overwrite the tags of the initial method. (the reason the approach was completely removed in AROS)
The AROS implementation has its problem on the string, especially shortstring side.

AddTags(TagList, [TAG_SOMETHING, shortstringvar]);
somefunction(GetTagPtr(TagList));

Might work or not. The contents of shortstringvar could be already overridden by something else. The contents is copied to a string and connected to a PChar, but this is freed after the AddTags call already, so this have to be considered also as broken. You can avoid this by putting the string as PChar into the varargs call. Besides this all "array of const" expect the value inside to be a LongInt Value (Note: It's Signed) The most Tags have are over MaxInt so they give a very bad Warning about range violation on every compile. Of course it possible to If "array of const" is even possible for 64 bit is untested currently, but I guess it is.
The MorhOS uses "array of DWord", which is the easiest and cleanest approach in my understanding. of course it should be "array of PtrUInt" to be on the save side for 64Bit.
Overall there should be one solution for all three platforms. To keep the casting to a minimum one could use the TAG_() idea, magorium used in his Trinity/Triforce approach [1].

function TAG_(TagItem: PtrUInt): PtrUInt; overload; inline;
function TAG_(TagItem: PtrInt): PtrUInt; overload; inline;
function TAG_(TagItem: Pointer): PtrUInt; overload; inline;
function TAG_(TagItem: boolean): PtrUInt; overload; inline;

The Third option would be to invent something new, like an advanced record/class whatever to make it possible and easy useable.

Solutions

1. Go for "array of PtrUInt" everywhere
2. Go for "array of const" everywhere
3. Invent something New

Decision

No decision

Systemvartags

Problem

In Amiga there is this funny "systemvartags" unit which contains all the varargs Versions of the other units. This means if you include this unit you get dependencies to all the units included.

Solutions

1. Remove "systemvartags" from Amiga and move the varargs versions to the original unit
2. Introduce "systemvartags" for AROS/MorphOS as well and move all varargs to there

Decision

No decision

AmigaLib

Problem

There is no AmigaLib currently for AROS and for Amiga and MorphOS its very different what should be inside this unit. Functions like DoMethodA, DoSuperMethodA and so on reside currently in intuition at AROS. If there a AmigaLib one should define whats in there. In principle it would be nice to have the SetHook();[2] Function in there to set a Hook structure in the right way, especially MorphOS is very different than the other.

Solutions

1. Introduce AmigaLib for AROS, move DoMethod and so on to there
2. Remove AmigaLib for Amiga/MorphOS move the functions to other units

Decision

No decision

DoMethod

Problem

At the moment there is a big difference between AROS on the one side and Amiga/MorphOS on the other side when calling DoMethod and such functions.

//Amiga/MorphOS
DoMethod(Obj, [MethodID, param1, param2, ....]);
//AROS
DoMethod(Obj, MethodID, [param1, param2, ....]);

Solutions

1. DoMethod(Obj, [MethodID, param1, param2, ....]);
2. DoMethod(Obj, MethodID, [param1, param2, ....]);

Decision

AROS changed to Version 1 [3]

OpenLibrary/CloseLibrary

Problem

AROS Opens the Library belonging to a unit in the initialization section and close it in the finalization section. Which is more or less consistent with Windows/Linux behavior for shared libs. When the Library could not be opened nothing special happens, besides the LibBase stays on nil. The Application writer has to care about to check the if the needed Libraries are opened.

Amiga opens the Library belonging to a unit in the Exec section (begin ... end. which correspond to initialization section) of the unit and Connect the ExitProc of the application to the CloseLibrary function. If the Library cannot be opened it shows a requester and close the program with Error 20.

MorphOS never opens Libraries automatically, every Library have to opened by the application writer it then connects the CloseLibrary to the ExitProc of application. If the library could not be opened the InitLibrary call to open the library returns with False.

The ExitProc approach for the CloseLibrary should be considered as broken, because the ExitProc happen before the finalization happen. For Example in LCL the destroy of the GUI is happend in the finalization of a unit -> Library already Closed. -> Hard to find bug.

The AROS approach was nice as long we used the GetLibAddress for calling because there was a check for nil Libbase, now with syscalls, no such check is done so it just crash if you use LibCalls with nil Libbase, an exception here would be nice.

The Automatic Open of Libraries is a little bit too much if you just included a Unit for it's Structures/constants but do not need the functions at all. (Does this really happen? (*) besides exec, intuition, graphics, amigados, which are open anyway)

(*) Molly (talk) 21:23, 23 December 2015 (CET) Besides those mentioned, yes: Utility (TAG_END) and workbench (WBArg) being the most encountered, while there are some other (not so common) situations -> more research required.

The automatic exit when Library can not be opened has it flaws. If you want to write a software which checks for Library existence for example: if cgfx available use its functions, if not use graphics.library functions

Solutions

1. Open/Close Libraries in Initalization/Finalization (AROS style), user has to check if Libraries really opened.
2. Libraries must be Opened by User with a InitXXLibrary function (MorphOS style) but closed in finalization of the unit.
3. Invent something new, inside the RTL to somehow register Library uses and automatically close on program end.

Decision

No decision