Virtual OS/2 International Consumer Education

March 1998


Previous Page | Index | Next Page
VOICE Home Page:

Interview with an OS/2 User

This is the first of an ongoing series of interviews with people who use OS/2 in their daily lives. If you would like to be interviewed, or can suggest someone you think would be an interesting story, please send email to

OS/2's use has never been restricted only to business use. Many of us use it at home or for internet servers. However OS/2's use in the nuclear power industry is another branch of its existence which provides unparalleled evidence of its versatility.

For their prototype maintenance vehicle for the International Thermonuclear Experimental Reactor (ITER), Spar Aerospace programmer Perry Newhook chose to put OS/2 Warp 4.0 to use as both the brains of the on-board computer and the interface to the human operator remotely controlling it. The L7 Divertor Duct Maintenance vehicle and robot works under the more dangerous conditions within the fusion reactor where rapid response time is crucial to the success of any operation.

L7 Divertor Duct Maintenance vehicle

For more information on the ITER project please see the ITER Canada Homepage at and the ITER homepage at The page describing the L7 Duct Vehicle is at

Perry Newhook, P.Eng can be reached via email at

VOICE contacted Mr. Newhook to ask about his decision to implement OS/2 for this project.

VOICE> Can you please describe your current use of OS/2 in your workplace? What kind of hardware and software are you using for this project?

Perry> Currently all of my development is in OS/2 Warp 4. However the decision on which operating system to use is on a project by project basis, as no one OS will suit every need. That said, I've used OS/2 on every project I've been on here at Spar in the past three years.

For the ITER project, we used OS/2 Warp 4 trimmed down to bare bones with a shareware utility called BootOS2. This ensures that the only things running are my application and the required operating system files. To the trimmed down OS/2 we added networking TCP/UDP capability and in the case of the GUI machine, OpenGL.

For hardware, the PC's are just ruggedized Pentium 166's with 32MB ECC memory. Nothing special. There are two PC's in total; one runs the user interface GUI, that sports a 3D virtual display of the vehicle and robot, and the second has no screen or keyboard and is used to control the vehicle and robot. It also runs some of the safety systems.

VOICE > How was OS/2 chosen for this aspect of the project? What features were considered important for this project?

Perry> We looked at a variety of operating systems and development environments. We ended up picking OS/2 because of my familiarity with it, and the successes we have had with it in previous projects. Before we settled on OS/2 however I had to write a few performance measuring applications to see if it could match our performance requirements. Our end pick had to run on a standard PC, meet our real-time requirements, and have an intuitive and easy to use development/debugging environment.

For the GUI side we wanted something easy to be able to do screen designs, and since we wanted some kind of visual feedback to the operator, support for a standard 3D API such as OpenGL.

VOICE > What previous experience was there with OS/2 and other operating systems?

Perry> I have been using OS/2 since the 1.21 days; about eight years now I think. I learned OS/2 working on banking systems at NCR. Before that I was a Windows programmer so I'm familiar with both sides of the fence. Along the way I've also picked up in various projects, QNX, OS-9, SGI IRIX, and VxWorks. We have also used OS/2 in other parts of the space program, such as running QA tests on the space shuttles' Canadarm, so we knew first hand how reliable an operating system it is. Lab work here at Spar has also given us experience in a variety of real-time and non real-time operating systems.

VOICE > What other operating systems if any were under consideration for this >project?

Perry> I believe the serious contenders were QNX, VxWorks, NT and of course OS/2. VXWorks is a great product on the Motorola side and we have used it in the past, although noone had experience with the Intel version.. It was rejected for this product because we wanted to use an off-the-shelf Intel PC and some periphials we wanted to talk to didn't come with Intel VxWorks drivers. NT was discarded because I could show that it's memory management and multitasking were poor compared to the other choices. Also we needed to be able to disable the virtual memory and remove the GUI for the embedded PC, as these are two of the major causes of non-deterministic behaviour. With NT this was not possible, so we could not guarantee response times. Resource requirements were also very large for NT although this was not a major concern. To make development easier and cut developement costs we wanted the GUI PC and the embedded PC to use the same OS. Since we had decided that OS/2 would be used as the GUI, because of previous GUI work on other projects, we chose OS/2 as the embedded as well. Obviously before this decision was final we had to run tests to make sure it really was deterministic and that responses were well within our requirements. If OS/2 failed those tests we would have probably chosen QNX as it is an extremely good real-time OS. As it turned out OS/2 performed more than acceptably.

When we announced that we had chosen OS/2 as our embedded and GUI operating system, there was a bit of an uproar from the NT zealots on-site. Because we wanted to talk to a DeltaTau motion controller card and DeltaTau does not have a device driver for OS/2, it meant we would have to write one in house. The people pushing NT cited this as a reason to not use OS/2 as in their words "it would take six to eight months to write a driver", and DeltaTau already supplies a driver for NT. As I've written a Windows driver before, the six to eight month figure for a device driver for Windows was about right. Looking into OS/2 device drivers I found that the OS/2 device driver model was far easier than the Windows one. In the end it took a mere two weeks to complete a full featured device driver with libraries for the DeltaTau card.

VOICE > Do you foresee continued/increasing use of OS/2 in this fashion?

Perry> I hope so. OS/2 was a bit of an experiment for this project. Historically we had chosen VxWorks on a VME platform for any serious real-time projects. This time because of limited resources and budget, we wanted to try out a mainstream PC operating system. As it turned out we were able to complete the project without any having any OS related issues or problems. Incidentally this project had about the same complexity and better a safety implementation than a project we had finished a year earlier on VxWorks. The software on this project was completed in about half the time and at about one third of the budget of that previous one. Those familiar with the project agree that OS/2 was a major contributor to the cost and time savings.

The embedded / real-time market seems to be an area where OS/2 is ignored. While QNX and VxWorks are great as hard real-time operating systems, in many applications choosing those would be overkill. Many people and companies are doing backflips trying to get NT to work in real-time applications, an activity that just boggles my mind. NT's multitasking, memory management and huge footprint mean that NT is generally not suited for this task, yet people are still trying, including writing addons to the operating system in an attempt to make it real-time. For many of these applications, OS/2 is more than well suited and does not need any modification other than removing the parts that you don't need.

VOICE > Are there any changes that you would like to see to OS/2 that would facilitate your continued use or expanded use of OS/2?

Perry> The only problem that we had in OS/2 that we had to design around was the SIQ (single input queue) problem. We used a lot of threads in this system, over 40 across two PC's, both message queue and non-message queue capable, and we had to be very careful with the treads that processed messages in that they not be able to tie up the queue by taking too long in processing something. Because of this problem, if one message thread stops reading from the queue, no other message threads can read anything else from the queue until the first message is cleared. This caused some creative application designing to ensure that this cannot happen. If the SIQ problem was not there then we could have simplified things a bit. As it turned out it was not much of a problem, we just had to follow a few simple rules during the coding phase.

In certain programs at Spar, we have use for a soft real-time OS, that can generate a virtual reality type 3D display. We have used OS/2 and it's implementation of OpenGL to some extent for this purpose, including the ITER program, but to do any significant detail, it quickly becomes apparent that you need 3D hardware acceleration. OS/2 does not yet support 3D acceleration, and as a result this is one area that NT is currently more capable.

VOICE> If and when IBM makes Hardware supported OpenGL available, will that help in this area? Have you contacted IBM about 3D support?

Perry> IBM has already completed some necessary steps in creating hardware accelerated OpenGL, the most noticable being the release of the GRADD drivers. This GRADD model is necessary as IBM will provide the core acceleration via the GRADD drivers, and the card manufacturers simply add their part that links the hardware specifics to the driver. Since the time to create accelerated drivers is vastly reduced, it makes it much more likely that card manufacturers will commit the time to make the drivers.

It was also announced that the OpenGL AIX team has released their toolkit to the OS/2 division to be ported. This has to be done as it is this toolkit that help video card makers create the drivers. Letting IBM know that this functionality is what we need, is the best way of ensuring that this project goes to completion. You can tell IBM that you want hardware accelerated OpenGL drivers at the OS/2 Requirements Submission site:

Another event that has to happen is for video card manufacturers to ask IBM for the toolkit to create the accelerated drivers. The only way this will happen is if we the users, POLITELY ask the card manufacturers for 3D OpenGL accelerated drivers. Without a percieved demand, these drivers will never exist. Without these drivers, OS/2 penetration into any 3D market, and this market is continuing to grow significantly, will be limited.

IBM's software implementation of OpenGL is demonstratably faster than the software-only version of Microsoft's OpenGL. I see no reason why IBM can't make a hardware accelerated version and make it faster than Microsoft's, just like they did with the software version.

VOICE > Do you know of any other sites using OS/2 in the Nuclear industry?

Perry> No, not really, but I have had interested people from both inside and outside the nuclear industry contact me. Spar was one of the first companies to finish it's deliverable for the ITER program, so it will be interesting to see what OS's other companies chose and to see how well they hold up in the upcoming years of use. I've also had some intersting mumblings from within IBM itself.


Previous Page | Index | Next Page