A long time ago I played around with x64 AROS already. Of course I would like to freepascal on it as well. Even on the first implementations of freepascal fr AROS i386 I already enabled and included basics for x64 AROS but I never got it to work, because my freepascal branch didn’t compile for x64 because it was at some broken state. Now at the trunk of course it will work again. In April 2015 I tried again and reached very fast the point to write the assembler startupcode. The same problem as before (with i386) no idea how it should look like. I looked a little bit around (also into the other startupcodes of other x64 fpc platforms, linux mostly) and took a shot. Sadly it didn’t work it always told me „bad load hunk“. So from time to time I looked into when I have only little time (not enough time to do anything useful at LCL) but I didn’t get any idea. Yesterday evening (already in bed just before sleep) I got an idea, and today evening I tried it very shortly and it gives not an error message but crash. YEAH! Never so happy about a crash. But why it crashs? ABIv1 problems? The Stacktrace tells me it crashes inside dos.library/Error with an _aros_not_implemented_ error :-O. This call gets the Error Output filehandle, seems still does not exists on x64 AROS. Easy solution comment out and use the Output stream as Error stream like Amiga and MorphOS do.
And finally it is working 😉
Of course its only a very bad hacked version currently and no ABIv1 things are done, so the compiler self does not really work (crashes on linker calling). But it shows that it will be possible to make an fpc for x64 AROS. Of course I have to talk to Charlie to check how to make a syscall for x64 (is even easier than i386) and how to make such ABI difference. but it is not really in hurry.
MorphOS use ELF for its binaries so the resources can be linked directly into the executeable. But Amiga uses Hunk format for executable and fpc is not prepared to link them into the executable so Charlie configurated them as external resources. I was curious if this is working. So I had to compile a new fpcres and bring lcl to compile for Amiga. After preparing some things for MorphOS this was not a big thing.
And on the first try it works already, but it looks wierd, the Window is full screen without any window decorations or button, even I limit the size. I deactivated the layout hook and it looks exactly the same. I have no idea whats wrong there. Same as MorphOS its crashing on Exit, I guess with the same reason.
Besides this its working nicely, even rather fast, at least faster than I expected.
As written yesterday the it seemed that the Hooks just do not work. This was right because I deactivated them. After reactivation the Button clicks and close windows works very nicely. But the Layout Hook still does not work. The routine for setting the min/max and layout is called. I added some debugoutput and noticed that the size of the window seemed to be negative. No wonder it won’t open it. But why its negative it should not be, the LCL window gets a valid size. In the end my very first idea was right… the structure is wrong which is used to get the Min/Max/Def sizes.. all Values there are set as ShortInt so -127…128 wich is rather unusual for Width/height of windows and really when look into AROS units this are Words so 0..65535 so no wonder MUI refuses to open the windows it just didn’t get the real size.
S I fixed the structure (locally) and voila its working. So I compiled some of my test programs from the fpc-tests repositiory to see where we are… because some are animated I made a little video out of it:
Link to the video
What we see:
Upper Line from the left:
- Button/Memo: To Test click events, and Enabled/Disable of Button, completly works
- Menu: Does not work at all, because at the moment it crash if I activate it again, maybe it cant stand emty menustrips, which would be bad because Menustrip only can be added on creation not later added.
- Progressbar/Busy bar: Works
- Timer: Works
Lower Line from the left
- ComboBox: a little bit strange, the upper comboBox is there, even react on clicks but is not drawn.
- Edits: the normal edits work as expected… just my SpinEdits (2 Button + Edit) are not shown at all
- Scrollbars: again they are there but not visible.
from this things I slowly get an idea what happen and this would be REALLY bad! All combined items does not work! Maybe because I added an LayoutHook??? But this would mean you can never put a combined Element like the Scrollbar into a Group wich has an own Layouthook. I would call this a bug.
In the Video is also easy to see that the size calculations are not right… especially at the Button test, the Memo is alBottom, but draws alreay over the windowborders. I took me very long to make this right on AROS… seems at MorphOS its again different.
Besides this all programs crash on exit at the moment. I try to debug it but its really hard because you have to dissassemble the program then use the offsets from the crash log to find the position where it gave the problem. It seems that the problem appears that the LCL access some property short BEFORE the item gets destroyed but this crash already. The item is not destroyed because its still visible on the screen. No idea whats wrong there maybe with debugtexts will be better.
Charlie did an awesome job to add some more festures to the MorphOS (and Amiga) Freepascal compiler so FINALLY i was able to compile the LCL for MorphOS. I had to deactivate a lot of stuff for now, but all not very important. Some are expected to be a problem like the cybergraphics things… other more surprising for me like diskfont library which does not exists (the freepascal wrapper unit for it only, I guess)
But also other stuff I have to think about, especially, GetAttr, SetAttr, CallHook, maybe I make some wrapper functions to make it easier to handle them at all three platforms. It kept crashing all the time… of course bcause I forget AGAIN that you need to to Open the libraries for the needed units, there is the most interesting point, when to init because some initializations will need it. Finally I found the best position for now.
So it does not crash anymore but also does not open a window… seems my Hooks for MorphOS does not work well because the Layouthook is never called, and the Window open attribute does nothing. After deactivating the LayoutHook it at least start it does not care about the size, thats the reason the Button is full window size. I have the Hooks working in an separate MUI testprogram so I guess I just did something wrong in the LCL. So because the Hooks does not work even the close button does nothing in MorphOS.
So much work, so little time.
When I try to compile some of my Sources for MorphOS or Amiga I always stumble over the problem that this two platforms does not have the VarArgs version of all the function I use (mostly happen for SetAttr or CallHook). Besides the array of const Version we use now in AROS has some problems, especially with Shortstrings which gets copied to a string then conversed to PChar, but after the call already destroyed, can have bad behaviour.
Especially at MUI I noticed the most functions expect the strings to stay after call, so I long time decided already to change the calling to an array of NativeUInt which should be much better, because you are forced to think about strings/PChar casting and it should be easier to transfer things to Amiga/MorphOS.
I wrote a little helper routine for tag and parameter handling and tried to get rid of the units tagarray and longarray which are basically just broken. I decided to use the Advanced Record approach and it looked really good, in some test programs I did with operator overloading its really easy to use.
But in LCL it did not work at all. Very strange and bad problems everywhere, crashes always at different points. For one test the crash point was easy to identify by the callstack in a very short routine, so I started to debug there. But strange everything was right, IT SHOULD WORK! But it doesn’t I took out some of the commands just let Tagsarray empty… and it still crashes, all Pointers are correct but if you try to investigate the Tagsarray it crashes, really strange. Just for fun I changed the type of my tagsarray from a advanced record to an old school pascal object (not class) and voila it is working :-O seems the advanced records are barely broken on extensive use. I hope the object are working better.
Some tiny improvements on the SimpleIPC Server for Amiga-style systems, ServerRunning was not implemented and UniqueInstance use the Message type to transfer the number of Parameter, so I had to implement this also.
Now its possible to use UniqueInstance functions in AROS also, without special ifdefs. (only a tiny change in the original unique instance code is needed an additional define ifdef Unix -> if defined(unix) or defined(HASAMIGA))
The code is available at GitHub
A discussion I currently read reminds me of some special things about WBStartup message in AmigaOS. If a program is started by Icon/Workbench the program recieves a WBStartup Message which must be replied at end of program (Most C compilers care about it already). There is a tiny additional thing. If workbench get the reply message it will unload the code from the memory, so every code executed after can fail if the memory is reused by other programs. By RKM its suggested to Forbid() task change, reply message and end program without Permit() task change again, but of course only when started by Workbench, if started by CLI it should not end with . I didn’t remember to see this in the fpc AROS implementation. So I implemented it for AROS and test it a while, then later also fix for Amiga/MorphOS?
Working on the fcl-process package, first started with the easier part, the SimpleIPC class which is rather straight forward possible with MsgPort and of course this is the same for all three platforms (Amiga, AROS, MorphOS). A little bit more difficult is the TProcess thing because its rather tightly bound to pipes which not really working well in AROS, sometimes even not available.
The easiest way to make such a pipe is of course just a file in T: a common way at Amiga style systems.
Its a very basic implementation only for the Output but its already enough for let Lazarus find the right compiler, and does not complain anymore that the compiler does not support i386-aros. 🙂
I started a bigger evolution task for the LCL implementation. The cleaning of the codebasis and maybe also a litte preparation for the other platforms. I started with some hint removal and an easier implementation of EventHook connecting. I hope that way I can rid of some very old code from the MUI-LCL implementation start in 2011. I think later I will implement an own Tag Handling system for LCL which then can work for all three Platforms together. So tagarray and longarray units can be removed from the uses sections.
And with it some more debugging of course. In Lazarus the dependency views now working as expected.
I got this strange problem in EdiSyn already, there are always Exception TList index out of bounds but I never had any idea where it came from. in SynEdit it happend on scrolling in Lazarus happend very often when a selection was done. I tried to find out where it fires by addign debug outputs and search for TList access but I even did not find the function where exception was fired. (now I know why :-P)
The root of this problem was that the exception bring back a Stack dump but only the address no function name or so (as the crash trace back does). So I looked to AROS source, how to create such a trace back with function names and found that this is easy available via debug.library (in newer AROS Versions).
So now I get a nice trace back with all the names for functions on a exception in LCL applications, very nice.
So if I need a stack dump I can call LCLProc.DumStack to get this directly (for example to know from where a Event is called)
But back to the problem, (as visible in the screen shot) the crash appears to be in Classes.TFPList as we know already from the exception text. The function before is in MUIBaseUnit :-O so it’s in my code 😉
So my initial guess was not so bad, it has something to do with the timers, the timers are checked before the MUI messageloop is polled.
for i:= 0 to FTimers.Count -1 do
begin
TMUITimer(FTimers.items[i]).CheckTimer;
end;
Which looks fine for the first moment, BUT if a Timer is removed (Deleted/Disabled inside a TimerEvent (another or the same)) the Count is not evaluated again in a for loop so this Index error can appear.
The for loop must be replaced by a loop which evaluates the FTimers.Count again, for example:
i := 0;
Num := FTimers.Count;
while i < FTimers.Count do
begin
TMUITimer(FTimers.items[i]).CheckTimer;
if Num = FTimers.Count then
Inc(i)
else
Num := FTimers.Count;
end;
Mostly the timer self is removed (disabled), so we increase "i" only if the count did not change. This should be bullet proof for list index problem. But of course it can be some timers get called not so often (lets guess, a timer is activated and an other one is deactivated), but it only means a timer is fired 25-50 ms later which should be ok.
