OS/2 Warp! Warpstock

Bringing you OS/2 Warp News and Rumors since August 1997



ArcaOS 5 - the Blue Lion roars

  • Part One - July 16, 2017
       Fixing the lockup button
       Customizing XCenter widgets
       Using more than 4GB of RAM

  • Part Two - July 17, 2017
       yum update fail?
       Testing some video cards (updated July 22)
       DOS window blues

  • Part Three - TBD
  • 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! One thing you'll notice is 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!

    I only took a quick look at the version of SNAP Graphics bundled in ArcaOS. As far as I could tell, the only changes thus far from the last SciTech release are for branding purposes. It would be great to see future improvements, incorporating changes that were made to Panorama, ACPI support, and of course support for hardware acceleration for additional graphics chipsets, although the latter seems unlikely. I also 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 of 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

    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

    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

    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.

    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.

    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.

    This page is maintained by Steve Wendt.