ArcaOS 5 - the Blue Lion roars

On May 15, 2017, OS/2 users were at last greeted by a new release of our favorite operating system. ArcaOS 5.0 marked the first full update since eComStation 2.1 in May 2011 (or since eCS 2.2 beta 2 in December 2013, if you count beta releases). It all started with the announcement at Warpstock 2015 that Arca Noae had a license from IBM to create a new OS/2 distribution code-named "Blue Lion", with a tentative release scheduled for Q3 2016, approximately 10 years after IBM officially axed OS/2 development (having met their "10 more years of OS/2" promise they had made in 1996).

As is standard fare in the software development world, there were a number of release delays, but we were tantalized with details of the features to come along the way. The original goal was to create an installer which does not require optical media, with support for installation from USB and possibly network installs. While this did not make the cut for version 5.0 (perhaps it will be ready for 5.1?), I believe all of the other features previously mentioned made it into the release. In addition to ArcaOS 5.1 being in the planning stages, there will be "point release" updates for 5.0; the first of them, version 5.0.1, was released on July 9, 2017, which included a handful of fixes, primarily for the installation process.

Soon after the release of ArcaOS 5.0, the Memorial Day sales started. I ran across a great hardware deal: a Dell Precision T3500, with a six core / twelve thread Xeon W3690, with 12GB of RAM, for only $339 and free shipping. You can still find similar systems on NewEgg and Amazon, although not at such a great price. I figured that would make a great system for trying out ArcaOS, with lots of CPU cores to utilize the ACPI SMP support, and an excess of RAM over 4GB, to try out the PAE RAM disk feature. So, I purchased the hardware and the software, downloaded the ArcaOS ISO, and waited for the hardware to arrive.

Testing the boot CD

Before running the ArcaOS install on my new box, I booted the CD on a couple of my other machines. On my old Pentium 4 which still runs Warp 4, I found a few problems. The first issue I found was that although the driver detection had correctly selected the E100B NIC driver, the ancient version included was too old to work with my hardware. I reported this as a bug, and am glad to say that Alex Taylor corrected it for the ArcaOS 5.0.1 release. The second issue I ran into is that when the (default) Panorama video driver is used, the boot hangs when PMShell should start. Using the pre-boot configuration menus, this could be resolved by using IBM's generic VESA driver, GENGRADD. Because that box has a card well supported by SNAP Graphics (ATI Radeon X800), I have never used Panorama on it, so I have no idea if it is a new or long-standing bug. Anyway, once the install CD booted properly, I could use the management console, which includes a couple handy tools, including a web browser (Arora), so you can test your network connectivity. The other machine I tested the boot CD on has an Ivy Bridge CPU, an Nvidia GTX 1060, and a Realtek NIC. The pre-boot driver detection did not select the appropriate NIC driver on this machine; another bug I reported, and fixed for 5.0.1 by Alex Taylor.

On my "new" Xeon system, the pre-boot driver detection had a similar problem to the Ivy Bridge; the appropriate driver for the NIC was not selected. In this case, it turns out the MultiMac Broadcom BCM57xx driver was a recent addition, and the pre-boot support for it had not been added yet; another fix included in 5.0.1, thanks to Alex Taylor. Initially, I was not sure what the included NIC hardware was (I just got it!), so I proceeded with the installation with the "NULLNDIS" dummy driver. It turns out that switching from that to the appropriate driver later is not terribly straightforward; although I got it working, I ended up blowing it away to test the 5.0.1 release, where it "just works" as intended. The other issue I have with this system is that UniAud does not seem to be loading properly for the audio hardware (neither 5.0 or 5.0.1). I haven't done sufficient troubleshooting yet to file a bug, and it may just be due to the very old version of ALSA audio drivers used. Alternatively, it may be getting confused by some HDMI audio support on the graphics card. I will have to investigate that further at some point.

Customizing the desktop

After the ArcaOS install finishes, you have a desktop that looks like this:

You'll notice that I used the excellent PMView to create the screenshots. I haven't dug up my license information again yet, hence the trial version! You can also see that the XCenter Pulse widget doesn't have the space for showing CPU load on lots of CPU cores, but that's easily cleared up by setting the text color to the same as the background color; drag and drop from the color palette is an awesome OS/2 feature! An issue that has tripped up some people, since it isn't at all obvious, is that the "lockup" icon does absolutely nothing after the initial install. ArcaOS has fairly good defaults for most things, but it seems they forgot to turn on the screensaver. The settings for that are not immediately obvious; it's not in any of the System Setup configuration objects, but rather in the desktop properties. You need to right click on the desktop background, select Properties, go to the "Screen Saver" tab, and turn it on. You also need to click the small "+" in the top right corner twice, to get to page 3, and choose a module to use (I'm partial to the Matrix):

Now, about that XCenter; it's extremely configurable! Many years ago, I started an XCenter widgets page for showcasing that very purpose; quite a while back I handed it over to os2usr.org, who graciously still maintain it. Included in the screenshot below are lSwitcher, HBMemMon, the standard Pulse with modified colors, HBTcpipGraphMon, and the standard Time with modified colors:

The other thing I mentioned about this new box earlier was that it has 12GB of RAM. A 32-bit operating system like OS/2 is limited to addressing the first 4GB of RAM, unless using Intel's PAE extensions. ArcaOS can make use of this extra RAM for one purpose, a RAM disk. I haven't had much opportunity to play with it much yet, but you can see that I have an 8GB drive M: available; I imagine this could be quite useful when compiling large projects like Mozilla - as long as you remember to save off any final output you care about prior to rebooting! At least on my system, the option to preserve contents on warm reboot does not work; I imagine this is dependent on the system BIOS (or anything else in the boot chain) not clearing the RAM.

Initially, I only took a quick look at the version of SNAP Graphics bundled in ArcaOS. The obvious changes from the last SciTech release are for branding purposes, as well as vastly improved SMP support. It would be great to see the automatic native panel support for VBE from Panorama, ACPI support, and of course support for hardware acceleration for additional graphics chipsets, which Arca Noae plans to work towards for newer Intel chipsets. I didn't spend much time trying out the integrated Samba networking support, but there are reports that it works quite well; the old IBM Peer client has been incompatible with other systems for several years.

Part Two

Package Management

One of the hotly contested changes in recent years has been the push towards using RPM packages, particularly for open source software that has been ported to OS/2. RPM is the package format used by Red Hat Linux, as well as SuSE, Mageia, and a few other Linux distributions. YUM is a front-end to RPM, which upstream has largely been replaced by DNF. Personally, I have been using RPM with Red Hat Linux distributions since long before YUM even existed, so I'm fairly comfortable with its capabilities and how it works. However, like many others, I bristled at the prospect of this entire new ecosystem thrust upon my carefully maintained environment. In fact, I have long maintained the "mozsupport" package on the Warpzilla Tips page precisely to help people avoid having to use the RPM environment in order to run Mozilla apps; I still maintain that until you can run "yum install firefox seamonkey thunderbird" and have all the dependencies installed for you, it simply does not work as intended.

Arca Noae recognized they could provide a lot of value in this area; they enlisted Alex Taylor to create a GUI front-end, which is freely available for everyone to use. In addition, the RPM environment is fully integrated into the ArcaOS install; although you cannot opt out, there is also no historical baggage to conflict with, since it is a fresh installation.

I do have to say, it was rather nice to run "yum install wget diffutils" to quickly install some very useful utilities! However, I did run into one snag pretty quickly - I ran "yum update" to update all of the packages that have been updated since the install ISO was bundled together, which seemed to run fine. However, subsequent runs of yum produced no output, and the GUI interface threw up some odd error messages. I was afraid that something had been horribly corrupted (so quickly!), but all was revealed when I noticed that some entries had been logged to the popuplog.os2 file:

       07-15-2017  23:44:25  SYS2070  PID 0100  TID 0001  Slot 0094
       C:\USR\BIN\PYTHON2.7.EXE
       RPMIO7->LIBCX0._fread
       127
     

The yum tool is really just a bunch of interpreted Python scripts; Python was talking to the RPM libraries, which were making calls into libcx for the fread() function. The SYS2070 error is a clear indication that you have mismatched DLLs. So this told me exactly what happened; yum updated the libcx package, found that it was in use, and unlocked it so that the files could be replaced. However, something else was running that kept the old libcx in memory, so when I tried to run yum, it crashed because it did not have the correct DLL. After a quick reboot, all started working again, but this shows that the OS/2 port of yum could use a feature to notify the user when files were in use and had to be unlocked to be replaced, and as such a reboot is recommended.

Of course, that is not the only problem with yum; run something like "yum info cups" and you'll see Python crash with some Unicode errors. Sooner rather than later, you will also see error messages about the RPM database. But overall, it mostly works, and Bitwise has started to consider switching over to DNF, which upstream is moving away from interpreted Python to compiled code.

Graphics cards and drivers

This Xeon system I am testing on came with an ATI RV620, which appears to be marketed as AMD Radeon HD3450. I assumed it wasn't very good, and replaced it with an Nvidia GTX 650Ti I had sitting around. However, assumptions are always worth testing, and make for some handy comparisons. The SysBench program has some benchmarks for Graphics operations, as well as DIVE, so I ran those on Panorama and GENGRADD on the GTX 650Ti first:

Panorama, GTX 650Ti

BitBlt S->S Copy	BitBlt M->S Copy	Filled Rect.	Pattern Fill	Vert. Lines	Horiz. Lines	Diag. Lines	Text Render	PM-marks	Video Bus Bandwidth	DIVE fun	M->S DD 1.00:1	Dive-marks
428.011	484.699	611.998	519.941	6.939	45.007	12.395	175.498	120.634	2332.891	7851.138	7831.152	2937.839

GENGRADD, GTX 650Ti

BitBlt S->S Copy	BitBlt M->S Copy	Filled Rect.	Pattern Fill	Vert. Lines	Horiz. Lines	Diag. Lines	Text Render	PM-marks	Video Bus Bandwidth	DIVE fun	M->S DD 1.00:1	Dive-marks
0.615	8.002	16.000	15.732	7.714	7.721	7.835	7.976	6.807	31.200	104.275	106.126	39.564

Switching from Panorama (VBE2GRAD) to GENGRADD is as simple as switching one line in Config.Sys:

       SET C1=VBE2GRAD
       SET C1=GENGRADD,SBFILTER
     

As you can see, despite not utilizing any GPU hardware acceleration, Panorama utilizes a lot more CPU hardware tricks to speed up graphics operations. GENGRADD was so slow at the BitBlt benchmarks, that the screensaver kicked in and trashed the initial results (the driver is very fast when it doesn't actually have to draw anything!). Panorama seems to be slower than it should be for vertical lines, but otherwise it handily beats out GENGRADD. Having satisfied that curiosity, I switched the graphics card to the ATI RV620, and inserted the ArcaOS boot CD. Unlike with the ATI X800 on my old Pentium4 box, the boot CD was able to load PMShell with Panorama without any problem. So I booted from the hard drive, and ran the graphics benchmarks:

Panorama, ATI RV620

BitBlt S->S Copy	BitBlt M->S Copy	Filled Rect.	Pattern Fill	Vert. Lines	Horiz. Lines	Diag. Lines	Text Render	PM-marks	Video Bus Bandwidth	DIVE fun	M->S DD 1.00:1	Dive-marks
423.174	477.471	592.724	518.907	6.839	44.837	12.367	226.404	123.280	2321.866	7825.582	7912.127	2952.199

As you can see, the results are similar to the GTX 650Ti, which is to be expected since the CPU, RAM, and so on are all identical on this software driver. I did not bother testing GENGRADD, as I expect the results to be similar to what was seen on the Nvidia card. Update: However, out of curiosity, I decided to also test the Arca Noae build of SNAP Graphics, and although it also runs in unaccelerated VBE mode, I found that it was faster than Panorama in most cases, other than Screen to Screen BitBlts. More on that in part 3 below...

SNAP Graphics, VBE 2.0, ATI RV620

BitBlt S->S Copy	BitBlt M->S Copy	Filled Rect.	Pattern Fill	Vert. Lines	Horiz. Lines	Diag. Lines	Text Render	PM-marks	Video Bus Bandwidth	DIVE fun	M->S DD 1.00:1	Dive-marks
5.187	528.477	1182.483	553.959	7.426	278.426	14.817	408.971	110.668	2362.672	7805.509	7958.855	2971.616

I found there are a few other benefits to sticking with the ATI card over the Nvidia card. First of all, the VESA BIOS exposes more video modes on this card; on a flat panel, Panorama attempts to automatically run at the native panel resolution, but when attached to a CRT, which dynamically handles a wide variety of video modes, it's very convenient to have a selection of options. In my particular case, for the CRT monitor I currently have attached, I was able to choose 1400x1050 rather than the 1280x1024 that all of the benchmarks were run at. Secondly, I found that UniAud is no longer detecting two audio devices (it appears I was right about HDMI audio on the Nvidia card), although ALSAHLP$ still reports errors for the AD1984A HDA codec. My attempts thus far to adjust mixer settings with unimix and PMUniMix have been fruitless.

The third benefit to the ATI card had to do with windowed DOS sessions. Many OS/2 users could care less about DOS (and WinOS2) support, but for those that do care, getting a functional windowed DOS session can be a hit and miss experience. Over the years, it has often been falsely attributed to the video driver not functioning correctly. There is in fact one driver that controls this, VSVGA.SYS, and despite it's name, it is actually not part of the video driver. The virtualized DOS environment is handled by various IBM drivers, and in the case of VSVGA.SYS, they have a table of video BIOS workarounds, which they apply or do not apply based on the PCI ID. Those PCI ID fixups stopped happening in the mid-2000s, when IBM ceased OS/2 development, and no longer had SciTech helping to test on a wide variety of graphics cards. However, if you know the switches to pass to VSVGA.SYS, with some experimentation, you can often find a combination that results in working DOS virtualization. You can find the list of supported switches within VSVGA.SYS itself; look near the end for "/int10".

Now, back to the point: on the Nvidia card, opening a windowed DOS session would seemingly work, but an odd beep would be emitted. If you tried to open a windowed WinOS2 session, you would be met with an ongoing beep from the speaker, along with a complete system lockup! Meanwhile, fullscreen DOS and WinOS2 sessions worked fine. I am in the "don't care that much about DOS and WinOS2 support" camp, so didn't spend much effort in trying to resolve the issue. However, having switched to the ATI card, I see that windowed DOS and WinOS2 sessions display an error message, but have no beeps or lockups! Adding "/int10textgrfxsafe" to VSVGA.SYS in Config.Sys eliminates the error message for windowed WinOS2 sessions, and with further testing, I may be able to get windowed DOS sessions fully functional as well, but it's low priority for me.

Part Three

More Graphics Driver Fun

Reading some posts on the OS2World forum, I was reminded of how the Panorama VESA driver uses a shadow buffer to speed up screen drawing, and how it's actually a bit of a hack that doesn't actually work properly with a lot of things. Anything that does a lot of quick drawing to the screen can cause problems (anyone using Panorama has no doubt seen at least occasional drawing issues, even with mundane WPS usage); one of the more frequent complaints is with multimedia players, such as SMplayer and VLC. When Rich Walsh was working on the DIVE acceleration code for Mozilla, he had to put in special case handling to disable it when Panorama's shadow buffer is enabled. Fortunately, because it is known to be buggy, there is an easy to use option to disable it. I did some quick benchmarks to see how that affected the SysBench results:

Panorama, ATI RV620, shadow buffer disabled

BitBlt S->S Copy	BitBlt M->S Copy	Filled Rect.	Pattern Fill	Vert. Lines	Horiz. Lines	Diag. Lines	Text Render	PM-marks	Video Bus Bandwidth	DIVE fun	M->S DD 1.00:1	Dive-marks
1.515	458.129	933.925	438.503	7.737	82.299	14.383	201.385	69.173	2320.656	7862.647	7950.562	2963.428

As you can see, the benchmark most impacted by the lack of the shadow buffer is the screen to screen BitBlt. Although still quite a bit faster than GENGRADD, it is much slower than SNAP Graphics (see benchmark numbers in part two to compare). Interestingly, filled rectangles and horizontal lines appear to be much faster with the shadow buffer off, but again, still significantly slower than SNAP Graphics. Whether the shadow buffer code can be fixed without sacrificing its speed, I do not know. It's by no means a substitute for proper hardware acceleration, but we currently don't have that option on newer graphics chipsets.

One nice feature that Panorama does have is that it detects the native resolution on digital panels, and dynamically adds a VESA mode in the video BIOS to handle it; this is especially useful on widescreen displays, as the VESA BIOS often only includes 4:3 resolutions. If you wish to use SNAP Graphics instead of Panorama and miss that handy feature, you can try the "widescreen activators" created by Robert Lalla. Disclaimer: I have not tested those personally. Hopefully, the widescreen VESA mode feature can be added to SNAP Graphics in the future.

Besides the faster drawing operations, another advantage to using SNAP Graphics is VESA DPMS support. The screen saver that comes with ArcaOS (Doodle's Screen Saver) is able to use DPMS to turn off the display, a feature that does not work correctly with Panorama. You can find the settings for this on page 2 of the Screen Saver tab in the Desktop properties.

Some people have noticed that the "Advanced" button on Screen page 1 does not appear to do anything after installing the bundled SNAP Graphics on ArcaOS. Previous users of SNAP Graphics know that usually brings up the GACtrl program, for testing different resolutions and other graphics driver features (even some sample OpenGL tests).

This is actually a problem in two parts; the Advanced button opens the WPS object for GACtrl, but the SNAP Graphics desktop objects are not created by default. In the \snap directory, there is a makewps.cmd script to create the desktop objects. After running it, you will have some desktop objects, including one for GACtrl, but the Advanced button still does not do anything! This is because the makewps script had some branding modifications, to change the object IDs from "SCITECH" to "ANSNAP". You can change all instances of "ANSNAP_" to "SCITECH_", or just "ANSNAP_GACTRL" to "SCITECH_GACTRL". Run the script again, and now the Advanced button will load GACtrl. However, I must warn you that when launching GACtrl this way, upon exiting from it, I sometimes got black screen "internal processing error" crashes in the OS/2 kernel. If you experience this problem as well, you may want to assign the "SCITECH_GACTRL" object ID to another WPS object. If anyone has great ideas for what alternative the Advanced button could launch, please share!

If you thought that was a cool hack, here's another one: do you want to disable that SNAP Graphics logo that displays right before PMShell loads? There isn't an option for it, but it only takes a few simple steps. We need to modify the graphics.bpd file (found in the \os2\drivers\snap directory), replacing instances of "splash.bpd" with another string of the same length, such as "xplash.bpd". A standard text editor won't work for this, but you can use a hex editor like hiew. After making this handy modification, I figured creating a patch suitable for the IBM OS/2 patch tool (as opposed to GNU patch, which is more suited for source code than binary patches) would be nice. I found a handy patch generator called MAKEPAT. For some reason, it was archived with the arcane ZOO format, but as usual, Hobbes has what is needed. For your patching pleasure, a patch suitable for the ArcaOS build of SNAP Graphics:

; Patch for graphics.bpd (8545901 bytes)
FILE graphics.bpd

VER 00021482 73
VER 0004351C 73

CHA 00021482 78
CHA 0004351C 78

Save that as \os2\drivers\snap\graphics.pat, then run "patch /a graphics.pat" and it should say "Patches applied to graphics.bpd". If it says "The verification failed for graphics.bpd", then you already applied the patch, or you have a different version, and can follow the steps above to manually modify it, and/or create your own patch. Then reboot, and the splash screen will no longer display!

---

I'll continue to add more thoughts to this article as I have time to write and document further, with quick links at the top of the page. Overall, Arca Noae has put out a very solid first release, and I look forward to seeing what else they have in store for us in future versions!

Short personal bio: My first experience with OS/2 was with version 3.0, OS/2 Warp. I had heard many positive things about OS/2 2.11, and in 1994 when I saw Warp on the shelf at the Fry's Electronics store, I purchased it immediately. I had no interest in Windows 95 when it came out the following year, although I quickly picked up Warp Connect, participated in the public beta for Warp 4, and purchased it upon release in 1996. There was a brief period where CompUSA carried a number of OS/2 software titles, such as Stardock's Object Desktop. It was disappointing to see IBM capitulate the desktop to Microsoft soon after, but my interest in OS/2 did not wane, as I created the "OS/2 Warp News and Rumors" page in 1997 (which continues to this day), and followed with great interest the web browser developments at IBM, particularly with Netscape in the late 1990's, and then with Mozilla in the 2000's. Between 2000 and 2006, I worked at SciTech Software, which licensed their cross-platform video driver technology, marketed as Display Doctor and SNAP Graphics, to IBM, for use with OS/2.

Want to comment on this article? You can contact me via the email address below, or feel free to start a discussion on the OS2World forum; I'll try to add links to anything interesting that comes up there, like this one.