Thursday, August 8, 2019

Summer works on Icaros Desktop

by on Thursday, August 08, 2019
Works on Icaros Desktop continue. I have decided to pause 64bit developments for some days, while I'm on vacation, and to work again on the usual 32bit version of the distribution. I have, for now, added some programs released or updated in july, and backported Icaros' improved launch script. The best addition so far, IMHO, is the Leu spreadsheet program from ALB42, a very promising application which may dramatically improve AROS useability for classic home duties. Leu can read and edit documents from Microsoft Excel (.xlsx), LibreOffice Calc (.ods), and some other formats. I don't know exacly how much compatibile it is, but I've opened without issues almost all the sheets I used for work, and I could even edit and save them into a different format.


Obviously, a filetype for spreadsheets has been added to Magellan as well, in order to open them with a double click. I've also added a filetype for LUA scripts, which can now be executed from Magellan.

Thursday, July 25, 2019

How I compiled deark for 64bit AROS

by on Thursday, July 25, 2019
Mantainer's diary. Some days ago I got a short interesting message from Bob Wilson: «Hello Paolone, I recently came across a command line program called deark. It's not a program that I would normally port, but you might find a good use for it. It should be easy to compile, if you want to try, add "CC= gcc" as the first line of the makefile». He was right: deark is one of those little big swiss army knives that most of us - dealing with PCs and the information technology every day - learn to love. It parses and extracts resources from an amazing variety of file formats, many of them almost gone forgotten these days. If you have a old file and nothing to process it, try deark: it might do something useful with it. Problem was, of course, porting it to AROS and, best of all, making it available for the 64bit version as well. Exactly like Bob said, compiling it for 32bit AROS had been straightforward: just adding the proper CC variable in the makefile and casting a 'make' did it. Another completely different story was, unluckily, the 64bit version.

There are two premises to be done: first of all, currently 64bit gcc for AROS doesn't work as expected, so - in order to compile sources for 64bit AROS - you should use either a crosscompiler or the AROS build system, which provides the crosscompiler by itself. Second, I am not a coder at all, which is limiting all my coding skills to shell and LUA scripts, and to the 'make' command: if you ask me to change a ./configure script, or a .c source file directly, I stop understanding almost at once. But, since I said I would have made a 64bit AROS distribution, I am now trying to compile everything I already need for it, or at least I suspect it may be useful in the future. And deark falls exactly in the latter family. So, I'll now explain what I did, in the hope it may be useful for others, too.

First of all, I set up a 64bit Ubuntu virtual machine and cloned the AROS git repository, installed all needed packages to compile AROS and made a initial build of the operating system. This operation is mandatory to download and install also all needed Linux tools and libraries, which are not included in the AROS sources, and all missing parts that were left outside for space reasons. Then I created a 'icaros' subdirectory in my local repo, entered it, and made also a new subfolder for every program I tried porting. I placed sources in these subfolder and, for every given program, created a mmakefile.src "recipe" that would tell the crosscompiler what to do. Please remember my disclaimer above: I am no coder at all, so I just have a vague idea of what these files do and how they work. If you can code in C or in other high level language, you should be far better than me in this. This is why I am not explaining how these .src files work: because I don't know this by myself. The magic is that... well, they work! And we should all be grateful to AROS coders for this!

A mmakefile.src file can be like this, for a very simple .c program. This is the one for poorx:

include $(SRCDIR)/config/aros.cfg
#MM local-icaros-poorx : includes linklibs
FILES := poorx
EXEDIR := $(AROS_CONTRIB)/$(AROS_DIR_DEVELOPER)/Build
NOWARN_FLAGS := $(NOWARN_FORMAT)
USER_CFLAGS := $(NOWARN_FLAGS)
%build_prog mmake=local-icaros-poorx \
    progname=poorx targetdir=$(EXEDIR) \
    files=$(FILES)
%common

the FILES variable lists all the .c files needed for building, while the progname one tells the name of the resulting binary file. EXEDIR variable is the path where the resulting program will be placed (according to AROS' filesystem) while NOWARN_FLAGS and USER_CFLAGS should be the place for all those nice options that coders know how to use, while I don't. Then there is the name for the recipe, which in our case is local-icaros-poorx. Once this has been written, and I have all needed files in-place, I can move to the root directory of my repo (in my case, ~/sources) and cast a command like:
make local-icaros-poorx
which will hopefully produce the poorx binary. Things get very complicated (for me, not for you expert coders!) when several .c files are needed for building, like in the case of deark. I had a very hard time creating a working one: I don't know yet how to manage prior building of dependencies, nor I know the right way to handle subdirectories, fact is that deark sources have the following structure:

With main sources included in the /src subfolder, all needed modules in the /modules directory and other needed components in the /foreign one. So I decided the 'best' way to start would be creating the mmakefile.src in the /src subfolder instead. This drawer looks like this:

a quite huge list of .c files, isn't this? well, so my initial FILES variable looked like:

FILES := deark-bitmap deark-char deark-data deark-dbuf deark-ucstring \
         deark-fmtutil deark-font deark-liblzw deark-miniz \
         deark-modules deark-tar deark-unix deark-user deark-util \
         deark-win deark-cmd

I just took the precaution of placing the main program (deark-cmd.c) at the end. Remember, in the FILES list, names don't have the .c extension in the end. First compile trial showed me that I needed to build all .c files included in /modules as well. But when, exactly? Build error suggested me that they should have gone between deark-ucstring and deark-fmtutil. The /modules subdirectory includes 125 .c files, how could I include them?

The right "chicken tomorrow" answer would be: "bug someone on slack or on the AROS mailing list and find someone so patient to care about you, learn how to properly handle this and do it well" but,  since I am a "egg today" kind-of guy, that would have been simply too wise. So I decided to include all .c modules here with the ../modules/name format. I'm sure bash has its own syntax to get the same result, but since I am more comfortable with Amiga shell, I used the List command instead (BTW: having hosted AROS running on Linux allows handling of Linux files with AROS shell. Cozy!):
LIST LFORMAT "../modules/%M \" >temp.txt
and copied/pasted/adapted the result in the FILES section:

FILES := deark-bitmap deark-char deark-data deark-dbuf deark-ucstring \
 ../modules/sunras \
 ../modules/cab \
 ../modules/binhex \
 ../modules/bsave \
 .......................
 .......................
 ../modules/alphabmp \
 deark-fmtutil deark-font deark-liblzw deark-miniz \
 deark-modules deark-tar deark-unix deark-user deark-util \
 deark-win deark-cmd

Another problem I had, was the fact that all .c files from the /modules subdirectory included lines like these:

#include <deark-config.h>
#include <deark-private.h>
#include <deark-fmtutil.h>

that I had to turn into these:

#include </home/paolone/sources/icaros/deark/src/deark-config.h>
#include </home/paolone/sources/icaros/deark/src/deark-private.h>
#include </home/paolone/sources/icaros/deark/src/deark-fmtutil.h>

because, otherwise, they couldn't find header files and building stopped every time with a new "file not found" error. Once again, the right solution would have been different, but a faster hack woud have given a 64bit deark executable more quickly. So I ask you to forgive my rudeness, and warmly suggest to learn the right solution instead. If you're in a hurry, however, you can do like me.

How to modify the same three lines in 125 .c files? Linux surely had its own commands, and I even considered using sed, however I noticed that examples on line used a syntax like:
sed -i 's/old-string/new-string/g' filename
and, since my strings included slash characters as well, I simply didn't want to look for the smarter solution. Why bothering, when I still have both AROS' List command and AROS gsar port? Three commands like

LIST LFORMAT "gsar -o %N -s<deark-config.h> -r</home/paolone/sources/icaros/deark/src/deark-config.h>" >subst.s
LIST LFORMAT "gsar -o %N -s<deark-private.h> -r</home/paolone/sources/icaros/deark/src/deark-private.h>" >>subst.s
LIST LFORMAT "gsar -o %N -s<deark-fmtutil.h> -r</home/paolone/sources/icaros/deark/src/deark-fmtutil.h>" >>subst.s

would create a very nice subst.s script I could EXECUTE within AROS. There would be even a smarter "create the gsar based script with a single command" solution, but since I'd had to understand how to handle strings which include spaces AND double commas, I went as usual for the faster+ugly one. In the end, I ended up having all modules .c sources modified in a way I can't share them anymore with anyone, but that at least compile on my machine. In fact, when I finally gave the command
make local-icaros-deark-src
for the last time, it compiled without much issues. And we now have deark for 64bit AROS as well!


 You can find it in the Archives. Have a look in the Uploads section if it's not already listed.

Wednesday, July 17, 2019

Icaros Desktop 2.2.8 now available for download

by on Wednesday, July 17, 2019
New version 2.2.8 of Icaros Desktop has been released, and it's now available for free download. There are goodies for everyone! You can play new accelerated games with your native installation, if your video card is supported, but you can also enjoy all the improvements we made to hosted modes. We got now VidentiumPicta, an image viewer heavily inspired from the pupular Windows program IrfanView, the Atari 800 emulator, the new 1.1 version of Polybios. But they aren't the only additions to the distribution: if you run the list below, you can see many new names like DisplayInfo, Sploiner and Bars'n'Pipes, the glorious music editor for Amiga, ported to AROS and re-released as freeware. But it's also time for gaming: we can now play Zaz, Shmupacabra, KrystalDrop, Powermanga, Africa and rRootage. Last but not least, Icaros Desktop 2.2.8 includes enhancements to the Magellan GUI and hosted mode, such as a better memory management and the chance to run AROS in full screen(*). We've also added a new hb command to HostBridge, to let people integrate host applications from the command line.

Gimp opening an image included with Icaros Desktop, after being called from the AROS command line.

New from Icaros Desktop 2.2.7


rRootage at the center of the screen
- added new hi-res CC-licensed images in Extras/Wallpapers
- fixed "browse for images" appearing not only for LH archives
- fixed traceroute in C
- updated x86 and M68K MCC_TextEditor to latest release
- added Atari800 to Extras/Emu
- updated InstallerLG to latest build
- updated ViewLHA to version 0.7
- added run_Lodepaint script by Salvatore Abbate to Extras/OpenGL/Utilities
- updated VIM to latest release
- deleted duplicated AmiTimeKeeper from Extras/Networking
- modified icaros hosted installation scripts for Linux and Windows
- modified icaros hosted launch scripts for Linux and Windows
- modified hosted prefs to attempt fullscreen (Linux only)
+ hosted preference program now acts differently on Linux and Windows
- modified hbadd and hbiconselect to fix some minor issues
- added the hb command to integrate host apps with the command line
- new variables defined in Envarc: for hosted fullscreen and memory prefs
- modified hosted prefs to manage reserved memory
- fixed: hosted installations won't ask about VMware driver anymore
- added Zaz to Extras/OpenGL/Games
- added Shmupacabra to Extras/OpenGL/Games
- added Bars'n'Pipes to Extras/MediaEditors
- added DisplayInfo to Extras/Misc
- added VindentiumPicta (image viewer) to Extras/Multimedia
- updated Koules to latest version
- added KrystalDrop to Extras/Games
- added Powermanga to Extras/Games
- updated ZuneBrot to latest version
- built Sploiner for AROS and added to C
- added a guide for gsar (enabled 'help gsar')
- added split and rebuild options to Magellan
- fixed a mistake in ZuneARC configuration file for LHA archives
- added rRootage to Extras/OpenGL/Games
- updated AmiCast Player to latest release
- added Africa (strategy game) to Extras/Games
- updated Polybios (HWP library for PDF files) to latest release
- updated SQLMan to latest release
- added documentation to Protrekkr
- updated manual: new chapter about hosted mode and HostBridge



Best of both worlds, when running Icaros Desktop 2.2.8 in hosted mode!


(*) AROS can run full screen on selected Linux distributions only. The right combination of architecture, drivers and window manager is mandatory. Icaros Desktop warmly recommends 32-bit Linux Mint 19 + Xfce, where the full screen mode works very well. Other distributions and window managers may give unpredictable results.

Friday, July 12, 2019

Some progress and some rework

by on Friday, July 12, 2019
I made some progress on Icaros 64. First of all, I contacted Antonio "Journeyman", author of Icaros' package selector used for installation of Extras. At the time (circa 2013) he sent me the binary but I completely forgot to ask him for sources but, luckily, he kept them safe and now thay have been safely placed on github. Luckily for me, I could compile them with no hassle, and this means that Icaros 64 will use the same installation procedure you're already accustomed to. I have also successfully compiled AmiTimeKeeper but, unfortunately, the program crashes AROS badly when launched twice. I suspect something is wrong when opening the GUI, but I simply miss the skills to investigate furtherly. Later on, I will look for help to fix it. It shouldn't be a networking issue, since network works fine and I could test it with AiRcOS (historic IRC client for AROS found in Contrib).


I have also made some substantial additions to the ./icaros script which runs hosted Icaros on Linux. I almost transformed it into a command, allowing the use of several switches and parameters to fine-tune the AROS environment, before starting it. It also allows handling of Icaros system variables, the ones normally controlled by our Prefs LUA scripts (Icaros Settings and Hosted). The new ./icaros script also handles killing of dead AROS instances, totally replacing the other ./quitaros script normally bundled with the distribution. This is for Linux only, at the moment, and I have no plans to backport it to Windows: sorry for this, it's not a priority but never say never, I'm quite difficult to foresight. I will make it available on 32bit Icaros Desktop too, tough. Funnily, this work on ./icaros wasn't even intended: I was learning how to use parameters with bash scripts, and I stumbled upon an example for the 'shift' command, which I decided to test with my script. A few hours later, I had completely overhauled ./icaros and added a lot of functions, which can be accessed without a fixed order. I will explain how to use it in the future.

Wednesday, July 10, 2019

HostBridge works on Icaros 64

by on Wednesday, July 10, 2019
First step towards a 64bit release of Icaros Desktop has been done: HostBridge is working for Linux-hosted AROS x86-64: I can run Linux applications from Icaros Desktop, open projects with the command line and even Icaros 2.2.8's hb command has been rebuilt for the 64bit environment. HostBridge, however, need also some 3rd party CLI programs which are not part of AROS: gsar and processicon, which I could compile with AROS build system thanks to the patient explanations from Kalamatee and the physical help of O1i, who fixed processicon to let it work correctly with the new system. The only current limitation for 64bit HostBridge is the icon selection: I still miss the great PictureReq utility, but I hope to get this done as well. In the meanwhile, I will use a standard file requester, altough an image selector would be preferable.


You might wonder why I decided to start with HostBridge. Well, in my opinion, it makes sense. AROS 64 is still lacking most of its 32 bit counterparts: there is no browser, no media player, no spreadsheet, no picture viewer... and while we're waiting for all of them, I guess it would be good to have a quick temporary replacement, using host apps instead. Moreover, in the beginning, Icaros 64 will be likely used in hosted environments, to become progressively more viable as a native alternative when more programs will be available, and ABI finally stabilized.

Monday, July 8, 2019

Let's talk, frankly, about 64 bits

by on Monday, July 08, 2019
As you may know, Icaros Desktop is - like other AmigaOS variants and inspired OS - a 32bit only operating system, which is quite limiting for nowadays standards. We can address a maximum of 4 GB of RAM, for instance, and we also inherited many AmigaOS limitations, since most of our programs were originally written for Amiga computers from Commodore. The system is also single-core and can't access all those sleeping transistors of your Intel or AMD CPU. Moreover, we're based on 'version 0' of AROS' application binary interface (ABI), which is 'stable' but also rather old, superseded by the current 'version 1' AROS coders are using for development. What does all that mean? In a nutshell, that we're running on a blind alley: we can use only a subset of modern PC specs, ABI v0 AROS isn't receiving any consistent update or backport for years, and Icaros itself is still relying on 3-years old code, which is cozy for people writing apps, but can be a problem for users that don't get proper updates and bug fixes.

So far, Icaros Desktop already achieved its main goal: providing a PC based Amiga-like operationg system which would make your PC look and act as an Amiga computer, giving great processor grunt to your Amiga programs. We can be proud of what we did. Install Icaros on a 5-15 years old PC, and you'll be still amazed: Icaros Desktop provides a modern environment, with modern file handling, modern GUI features, modern networking on the roots of a classic operating system. We might continue collecting new applications from 3rd party developers, but progress on AROS continues on ABI v1, which is not compatible anymore.

Unluckily, we can't simply overwrite older system files with newer ones, because current AROS x86 software wouldn't run anymore. Icaros Desktop includes hundreds of executables, and many of them were released as binary only, so we couldn't retain their sources for later use. We're talking about iconic components of the system, like the familiar AmiStart dock in the lower side of the screen, but also specific ones like AROS drivers for the Catweasel cards. In a nutshell, upgrading ABI would mean loosing most of the Icaros environment, what actually lets Icaros be... Icaros!

But progress never stops and we must make a step forward.

As I have already repeated and stressed on forums and social networks, there will never be a 32-bit ABI v1 version of this distribution. I don't think you need so much explanations about this: ABI v0 AROS took 20 years to get where it is now, and nobody still produces 32bit only PC processors. All CPUs sold in the last 15 years can run 64bit operating systems and almost nobody owns less than 4 GB of RAM. Moreover, hard drives are terabytes big and there is really NO motivation to binding to 32bit limitations today.

It's now time to leverage the Amiga(like) platform to modern standards. I simply can't ask you to loose your habits without giving you tangible advantages. For this reason, I am now working also on the x86-64, ABIv1 flavour of AROS, to start a brand new adventure. It will be based on the great experience I got from 32-bit Icaros, but it will bring real advantages like big size memory handling, better filesystems, updated system software and, hopefully in a near future, also multiprocessing support, to speed up multithreaded operations. ABIv1 64bit AROS can't run ABIv0 32bit software, so all applications must be properly adapted, corrected, recompiled and boundled. This is a huge task I absolutely cannot do by myself: I need help form developers. Much help. The greatest help I ever asked for.

It will take much time, before the 64bit version will be available. In the meanwhile, 32bit Icaros Desktop will still get updates and new point releases. This topic can be discussed here.

Theme Manager and themes included on Icaros Desktop are already working on 64bit AROS. 

gsar compiled for x86-64 ABIv1 AROS, using the AROS build system







Translate