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.

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.

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.

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

Ever wondered how the mixed Icaros + Linux user experience may be? This short video can be the answer. Enjoy!

In the video, Icaros Desktop 2.2.8 is running hosted on Linux Mint 19 + Xfce, probably the best fitting combination for HostBridge.

Some days ago, Aros-Exec user Salvatore reported that Sploiner, a CLI utility designed to split, join and recover big files, had been released along with source code. These sources built fine under Icaros' development environment so I could add the program to the distribution. Salvatore, however, also hinted that this program, once available on AROS, would have been fine for a new Magellan option, and so I did. It took a little while, because - as usual - I had to transform a "pro user CLI mentality driven" tool into a "casual user two click and go" one, and the best way to do that is by shell scripting.

First of all, however, let's talk a little about Sploiner. Sploiner is a one-command utility wich basically performs three different functions: splitting large files into little ones, rebuilding files from their parts and even recover the original file if a part is missing. I'll leave for now the recovering part, focusing on the other two. Sploiner can split a large file with a command like this:

Sploiner SPLIT filename -n <-s size> <-o outputname>

the -n option does not produce shadow files, sploiner's CRC control files it can use to rebuild a part of a file, if missing. The -s and -o options are more interesting because they actually produce part files, with filename and size chosen by user. For instance, let we split the video file from Josh Woodward coming in MyWorkspace/Videos in double-high-density floppy format (2,88 MB):



On the contrary, a syntax like this:

Sploiner JOIN basename AS namefile

would do the exact opposite. The basename in the former example would be jv_video, while the namefile should be JoshWoodward_InvisibleLight.mpg. Quite cosy, don't you agree? Yes, it is. But now let's transpose all this into a point'n'click GUI like Magellan one. We have a file to click on, and we wish to split it. How should we handle this?

First of all, I thought that asking the user for a parts namefile would have been a waste of time. The original large file already has a name, so why shouldn't we use it as well? Maybe because some of AROS filesystems still expect a 32-character lenght name, and simply adding the _PART.xxx suffix might exceed the quota. So I thought that the best solution would have been taking the first 22 characters of the original name and to append the _PART.xxx postfix to it. In our example, JoshWoodward_InvisibleLight.mpg would be splitted into several JoshWoodward_Invisible_PART.xxx name. But how many parts? That's a question only users can answer to. My solution to this problem has been using a RequestString instance, suggesting the size of a common high-density PC floppy disk (about 1,44 MB), with some bytes left. User can change this value to fit the size of a double-high-density one, or the size of a CD-R (700000000) if the original file is particularily large. At this point, we've all that we need to perform the action:


My script also creates a little text file called <basename>_PART.name which contains the name of the original file. Why? Because if you don't know it already, you may have some problems rebuilding it. Let's think about this scenario: a friend of yours gives you all the part of a video, but you don't know how the video was named in the first instance. Without further information, you wouldn't be able to name it correctly. The _PART.name file resolves this issue and tells Icaros how to name it after rebuilding. Operation that is performed like this:


In this case, only a question is proposed to users: should we keep the part files or not, after the join operation? If we choose to delete them, only the rebuilt file will be kept.