This year freepascal got a big advance on many levels, in general with the freepascal 3.0 and for the Amiga-style systems also. Even more advances on the LCL/Lazarus topic on Amiga, AROS and MorphOS.
It began in 2014 already, when I restarted the MUI LCL implementation for AROS. Begin of 2015 I cared more about some applications to test the implementation especially the owner drawn things. So I wrote ColorIt and FPCMines for AROS and tried to write or port some little apps and some more.
A milestone reached in march 2015 when I got the SynEdit component to work. The little test program I used to play around with the needed changes in LCL grew on requests from the AROS community to a full usable Editor, which got the name Edisyn. By improving the editor many additional features are included into LCL, like key events, advanced mouse events, tabs, scrollbars, colors and much more.
With all this improvements I felt ready to give the lazarus ide another try and finally at least it starts. So we are on a good way to bring lazarus natively to work on AROS.
But how about the other platforms (AmigaOS and MorphOS)? I did already some changes in the code with the other platforms in mind. When the resource support was enabled in freepascal I took the opportunity to try to port the LCL for MorphOS and m68k AmigaOS. Which somewhat worked but not in the same way as in AROS especially the layout did not work and the program always crashed on the end. But it gave me much insight how MUI is working also for AROS Zune which is a little bit more error tolerant than the original MUI.
Also on the freepascal front some new things appeared, the support for x86_64 AROS was included, but sadly because of the ABI difference the port is still not finish and unusable. I’m waiting for the ABI switching feature in freepascal. The implementation is done just I need the decision to do it in the proposed way.
In October I did something unusual for me, I did C coding for AROS, trying to code a dynamic Amiga-style Library (in this case sql) to use it in freepascal AROS. But later I found out this wrapper library is not needed and I can directly use the C linklibs as they are.
At the end of the year I took more work again on the MorphOS and m68k Amiga LCL and finally got it to work. So the first LCL programs can be compiled for MorphOS and m68k Amiga.
What 2016 will bring
I hope I can join the two LCL implementations (AROS on the one side and MorphOS and Amiga on the other) together again. Bring the MorphOS port to the same level as AROS, that maybe Edisyn will work. The next logical step would be to continue on lazarus ide and try to make it somewhat usable.
Finally I found the reason for the strange crashes on Amiga and MorphOS on destroy of LCL apps. And now I also understand why it was so difficult to find it. It was … drum roll … not in my code :-O. It’s in the library units of MorphOS and Amiga. Little bit about the basics. On AROS I open the Library (belongs to a unit) inside the initialization section and close it again in the finalization section. I’m used to this behavior from windows DLLs. At Amiga and MorphOS a different way is used. The OpenLibrary is done in the initialization section (for Amiga) or must be done manually (MorphOS). On this OpenLibrary call the ExitProc of the unit is connected to a CloseLibrary routine. So far sounds good, but it seems the problem is that the ExitProc is called BEFORE the finalization of the unit, long time before as it seems, hence the muimaster.library is already closed when I try to destroy my MUI Objects which horrible crashed.
I placed some Debug output in the InitMuiMasterLibrary and CloseMuiMasterLibrary and can clearly see that the CloseMuiMasterLibrary happen before my LCL destroy things are called. I will play around a little bit with it. But in the end I have to talk with Charlie (Maintainer of FPC-MorphOS) about this, how to solve this problem.
This explain also other crashes I experienced before (like the crash of CloseFont for example)
As you might notice the freepascal 3.0 stable release is out. This is the first stable release includes AROS as a „fully supported target„. I created a binary release of this 3.0.1 stable freepascal for i386-aros. It only includes the compiler, FP-IDE and freepascal packages: RTL, FCL and AROS library units. (So no FPGUI, LCL and so on) It’s mainly needed to compile the trunk version as starting compiler. For real life coding the trunk version is a much better choice, because it has some more bufixes and new functions inside. The binary archive can be downloaded at the FPC-AROS Page.
Binary stable releases for Amiga and MorphOS will be created by ChainQ I guess.
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.
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.
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?
The integration of AROS into FPC trunk works very nicely already, I decided to make the first binary release of freepascal for AROS. I changed the installation a bit, introduced the package system to freepascal, so you only need to copy the folder to the harddisk and make sure the Envarc:sys/packages/freepascal points to this directory. (Which can be done by executing install script in the freepascal folder.) The package-Startup will then create all assigns ans pathes needed to operate fpc.
Until now the trunk fpc, the latest fpgui (1.2) are included, lcl/lazarus I didnt try with the new trunk version, I think later I will try also to update to the latest lazarus release and try to compile, which will need again much work I guess. As long as there are still things missing, I will supply both versions for download.
For the trunk integration I always need to check if this things also work at Amiga/MorphOS. I’m very happy that Amiga is working again. Its not so easy to cross compile it, until now I only got it to work on a i386-linux, but not at my x64 machine, the binutils does not want to compile currently.
Thats the reason I also prepared a freepascal m68k-amiga version. This should also work on a m68k-aros machine. At the moment I can not try, as long AROS vision and the nightly AROS iso seems not to work at e-uae at linux. Because its an amiga release (and not AROS) it only contains the Amiga functionality, so no FPGUI (there I need AROS special functions) but the FP-IDE is included.
There is a dedicated page for fpc-amiga:
FPC Amiga/AROS m68k
The AROS (i386) can still be found at:
FPC AROS
The two words in the headline seems to have no connection… hmm yes its right, I’m just to lazy to write two seperate messages 😛
So the first: Syscall… or better SYSCALL 😉
I backported the SYSCALLs for AROS from the freepascal trunk to my branch. Karoly was so kind to implement (see here) but the rtl there is far from usable. And with the backported we can already begin to transfer the systemlibraries to the new schema, then later not so much work 😛
The porting was more difficult as i guessed, the changes in the code are not so many as you see in the commit, BUT some of this codeparts even does not exists in my branch… introduced in between. Seems also in this part much things happend. But after try to understand the code and compare with PowerPC-MorphOS I found the way to do it.
I tested it with some simple functions from exec.library and it works nicely.
for example:
function RawDoFmtLocal(const formatString: PChar;
const dataStream: Pointer; PutChProc: Pointer;
PutChData: Pointer): Pointer; syscall AOS_ExecBase 87;
I backed a release out of it, just to have it released, my primary target stays the torrent client.
The second point… UDP
I released the ArTorr yesterday and already some bug reports arrived at my desk. On of them was rather simple to understand … in the torrent file was no HTTP tracker, only UDP trackers. I didn’t know such things exist, my files always had at least one HTTP tracker included. The problem is, I have no idea how UDP or the Bittorrent Tracker UDP work. Very helpful is the official text: UDP Tracker Protocol for BitTorrent. But stays the problem how to do a UDP connection. I searched a lot for example codes but the most working with synapse or lNet, both I have not available. But i found this page: Programming with UDP sockets which explains, in C, how UDP connections are working. Its rather easy I would say, even simpler than a TCP connection, and much better for non blocking calls.
So I tried to implement the protocol, its rather straight forward. so tomorrow I will see how it will fit into ArTorr, if this is working I will see how to write myself the HTTP Protocol for the tracker and then make the whole thing non-blocking. 😉 Seems thats my major topic… make things non blocking.
I really like this number 28463 😉
