I took a very old laptop and installed a new ubuntu (its really bad with only 1GB RAM) and tried to install freepascal with AROS crosscompiler and also crosscompile to AROS. Just to see which steps are needed. Then I also installed lazarus from source (my source from github) hmm seems I destroyed some things for other platforms and again chose a bad point for my branch. It can not create any lfm files, so no new projects/forms possible, I got this message at AROS but I thought its some problem there. So bad seems I have to update my lazarus branch again, always so much trouble. But besides this I got the lazarus GUI to crosscompile AROS lcl programs, and even run them inside AROS, should be much easier coding (for edisyn for example ;-))
Charlie implemented most of the x64 AROS support to freepascal trunk, most important the syscall. Hence I can use the library units I have already for i386. Of course at first try it just crashes. The reason seems to be that some library calls are not implemented, like Error() in dos.library or CreateRastPort() in intuition, strange I remember at ABIv0 it was written one should use CrateRastPort() instead of self get the memory and initialize… and now its not working anymore. Should be not a big task to alloc mem and call init in such a call? What is the reason of removing such call. Same for Error, it usually just give you the pr_CER of your process so why it can’t do that?
Nevertheless a little bit GUI is working (after dealing with the CreateRastPort/FreeRastPort stuff). The tiny Hello world window on the top right side is the MUITest example I ship with the fpc i386, same for Windowtest which uses intuition and gadtools to oppen window and show a button. the other two demos are fpgui examples.
Playing around with the LCL for MorphOS, seems to work nicely, but (as described last time already) it crashes on Exit. I tried to find the reason for it. It seems that that the MUI Objects are kind of destroyed already, even still visible on the screen. Due to the special way to work in LCL I do not like the automatic destroy function of MUI. If you build up a mui application with application, window, items in there you usually only need to destroy the application and every thing else will just be automatically destroyed. Of course thats not what we want to use for LCL (or it would be impossible to destroy single button/Windows and so on). Long time before at AROS I played around with it and the best solution is to just unlink the item from its parent and destroy it by hand (MUI_DisposeObject) because then it is always in my full control when an object gets destroyed or alive.
Seems thats exactly my problem now. When I begin to destroy my objects at some point it seems that the MUI Objects are already destroyed, so it crashes, but this object (window) is still visible on the screen. I removed all MUI_DisposeObject from my code and still the Window gets destroyed somehow :-O and the mui objects are invalid. Here happens something I do not understand. Really strange thing, maybe its some special „new MUI Version“-thing? I don’t know and not really an idea how to continue here. Maybe I need to write a simple non-LCL program where I do the same and try to find out this strange behaviour.
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?
