Public Library
I published the first part of the Libraries creation at github. For now only the basic test library with some description how to use. The next will be the sqlite3 start I did.
C Linklibs to Libraries
Currently we are only able to use the shared AROS .libraries, so every C link lib is not available in freepascal for AROS. For example sqlite3, SDL, GLUT, SSL and and and much things only available as c linklibs.
I tried once long time before to use the c link libs directly but failed because of the „auto library init“ needed by them.
But of course the other way round, maybe would be possible to specially create a library in C which can be used in freepascal later. I’m not very good in C neither in Makefile magic but hey worth a try. First the official documentation is just crap, not existing (many 404 there, seems someone deleted/moved the documentation) or very old (already written in there that it will change in 2006 and the docu gets not updated) and what I found is just a documentation about how to create a library inside the AROS core build process. I don’t want to compile the complete AROS just to get my Library compiled. Shit, luckily I found an other library which had the same problem and which also come with the source (which is rather seldom on Amiga-style systems, but on AROS more common, but there not so many 3rd party libraries available, one I found)
With this it was rather easy to create a own custom build library with a simple function inside.
The next step was to include sqlite3 to the library. I decided for sqlite3 because its the easiest to check for success and even with some functions its already useful. The task sounded easy but exactly there the problems started, as always.
Again the „compiler magic“ autoinit killed me many times. Finally I found out that I can invoke this autoinit from my initialization by hand. And finally it worked.
This is now a single instance library, a pertask library would make more sense but I didn’t find out how to change that behavior (just to change a flag in the libinit structure was maybe too easy for the designer of this system). But for sqlite3 its not a big problem, it mostly work on a db which have to be opened and closed before using and then always must be supplied to the library. There are some calls which are not threadsafe like sqlite3_config or so but they could be protected via a mutex later. So for now not a big problem, maybe later I find a way to switch to pertask behavior.
The library includes now: sqlite3_open(), sqlite3_close(), sqlite3_free(), sqlite3_exec(). Which is enough to create a database, create a table, add some data and make some selections + output which I tested with a tiny pascal program.
The make process is not complete done and understood by me, there I have some more work to do and then one could begin to include all the sqlite3 functions to the library and make some more tests and of course write a pascal wrapper unit 😉
The long term idea would be also again to check how one could use the link libs directly in freepascal, when creating the c library I got much more knowledge how this autoinit things are working, maybe one could copy this to freepascal.
Pipes in Pascal
Played around a little bit with graphics and game mechanics. Result is (until now) a Pipe-like game just for fun.
Lazarus crosscompile
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 ;-))
AROS x64 is working, also with GUI
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.
… or maybe not
For sure 64-bit is the future but the current AROS 64bit is just crap. Most programs or even prefs just crash, networking is not working (same settings as in the i386 version), no sound (just stays quiet, even there is a soundcard detected), not possible to change the Workbench and Drawer background (the prefs program crash), even some of the demo apps does not work as expected or just crash. And so it goes on … if really someone wants to make a x64 AROS distribution, this will be a lot of work. I guess the most difficult part will be to convince the AROS-devs to fix this bugs, because this bugs are not new… the last nightly I tried was in April (and an other one in January) 2015 and all had the same problems, no improvement at all.
64 Bit is the future
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.
Amiga LCL
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.
New Tag Params
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.
We are unique
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
