Next Meeting: TBD
Meeting Directions

Be a Member


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Mr. Know-It-All



Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats


Past Presentations



Contact SCOUG

Copyright SCOUG

warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

SCOUG was there!

Copyright 1998-2022, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Drivers Pay The Bills

Rick Curry sits at home and writes OS/2 device drivers

And he's done it for years

by Peter Skye

ENTURA --- How does an average Joe, a working man, a ham 'n' egger, a keyboard jockey like the rest of us, take his OS/2 knowledge and bootstrap it into a 9-to-5 that will pay Uncle Sam and the bills and still have a few bucks left over for a video and a beer?  How do you take the knowledge that snuck into your cranium while you thought you were having a good time playing with "that new operating system" and sell it on the open market to all comers?

           How do you do that?

           In the little town of Ventura, west of the San Fernando Valley and northwest of Los Angeles, resides the epitome of that very Joe the Working Man, that keyboard pounder of the OS/2 experience, that guy who made it work.

           Joe's name is Rick Curry.

Rip Tide

           Rick doesn't look like an OS/2 device driver expert.  He looks more like a surf bum.  His lanky frame and unshorn hair are just waiting to be respectively bronzed and bleached by the summer sun.  He belongs in the California waves, walking the nose of his Al Merrick board or scrounging the few dollars necessary to catch the next plane to Hawaii and the north coast of Oahu, considered very fine crest country indeed.

           "Checking any baggage on the flight, sir?"

           "Just the surf board, dude."

Update Those Old Drivers

           Rick writes OS/2 device drivers, and he specializes in SCSI.  "How many SCSI drivers have you written over the years?", I inquire.  "Six from scratch, plus a few upgrades to existing drivers," Rick responds.  "What kinds of upgrades do SCSI drivers require?" I ask.  Rick's eyes light up.

           "Changes which have occurred in device drivers since OS/2 2.x have not been especially interesting, and a great many manufacturers have continued using their old OS/2 2.x drivers with relative impunity.  Most of the changes are trivial and are made by placing different constants in the device driver header."

Scatter/Gather And DMA

           "SCSI drivers require scatter/gather memory block resolution due to DMA transfers.  Let's take a look at this."

           "Memory pages are 2K bytes long.  SCSI transfers are 64K bytes maximum.  The user's application program asks the OS/2 kernel for memory and receives one pointer, and then sends that pointer to the driver.  The driver will use this pointer for the data being read or written."

           "But the pointer refers to virtual memory, and that virtual memory may be broken up into several non-contiguous groups of 2K memory pages."  I'm trying to follow along, and can only recommend that if you're not confused yet you should look up Global Descriptor Tables and Local Descriptor Tables in your Intel microprocessor architectural manual.  Rick's not confused at all, though, and is still explaining.  "DMA, which stands for Direct Memory Access, requires contiguous memory.  So when the driver gets the pointer, it then asks the kernel for an array of structures (pointer and size) for the actual physical memory blocks that make up the memory that's virtually pointed to by that original pointer.  The driver needs these values so that the host adapter can conduct DMA data transfer, and a DMA transfer is then conducted for every entry in the array.  Thus, the physical memory which is 'scattered about' is 'gathered up' during the DMA transfer."

           "Actually, it's typical for a SCSI driver to allow chaining of DMA transfers at the user's request, and this is often done in the host adapter's firmware without any intermediate interrupts.  Non-SCSI drivers don't have such firmware and those drivers must reallocate a DMA channel for every entry in the array of memory structures before continuing."

           I ask if my brain could rest for a moment, and could we speak of something lighter?  Rick laughs and runs through some of his work experience.

Just A Game Of Chance

           The most interesting programming job that Rick ever procured had nothing to do with OS/2, and nothing to do with PCs.

           He was employed to program slot machines.

           The company was Interscience, and the machines had the usual spinning cylinders covered with bars and cherries and other nondescript symbols, but behind the front panel there wasn't a thing left to chance.  "There was an embedded computer system inside each slot machine that took care of everything," explains Rick.  "When a symbol stopped in front of you, it had nothing to do with the old method of spring timers and ratchets.  It stopped because the software sensed the spinner's position and fired a solenoid to catch it.  Much less maintenance.  We didn't use a pseudo random number generator as many people would do, and instead sampled a free-running counter to determine what the current symbols should be.  Had a heck of a time proving to the Nevada and New Jersey State Gaming Boards that it was truly a game of chance."

           "We also had to program the machines to circumvent cheaters.  'Stringing' is gluing a string onto a coin and then bouncing the coin in the slot so the machine thinks you've put in a lot of coins, and 'spooning' is holding up the jackpot coin counter's sensing microswitch so it doesn't count the coins as they're being ejected and you get more.  You can catch both with timing routines."

Pounding Of The Waves, Pounding On The Keyboard

           And can he comment on his beach boy surfer look?

           "I ran some track in high school," says Rick, "which helped when I was chasing RTD buses.  And I worked for a while as an aerobics instructor.  And I like camping."

           "But no," Rick concedes, "I've never gone surfing."

Warp Server and IOCTLs

           So back we go to the technical stuff.

           "Some of the changes in Warp Server care about the vintage of your device driver and you should update those drivers to get optimal performance and in some cases in order for them to work at all."  Rick is telling me how OS/2 drivers have evolved into their present form.  "For instance, there is an ability within Warp Server (and other older versions of LAN Server as well) to associate several serial ports together as a shared modem pool.  The modem pool feature is only available under Warp Server to device drivers which are of a recent enough vintage."

           "The most complicated change a manufacturer may want to add is to allow other drivers to directly send an IOCTL to their driver without leaving ring 0.  This is one way in which Warp Server improves network performance, since it allows network software to resolve requests within the drivers as much as possible."

           "So, the Warp Server kernel allows drivers to do IOCTL calls between each other and, in fact, the newer LAN Server portion requires this functionality.  Older LAN servers didn't have such a requirement; instead, you had to have your application program coordinate the calls, and you incurred a lot of extra overhead because your page tables would become invalidated when you did a ring level change."

           "It's a little bit more complicated, but the IOCTL will typically use the same code as your strategy routine and therefore even this change is fairly easy."  When I ask, Rick explains to me that a "strategy routine" is a specific section of your driver code.

What Makes A Curry

           Rick Curry was born in Burbank, California in 1956, moved to Terra Verde, Florida (it's near St. Petersburg) at age 8 for a year, and then back to the Los Angeles area where his family eventually settled in Chatsworth.  He started college at California State University Northridge in 1974 and eventually got a B.S. in Computer Science And Mathematics with an "option Computer Mathematics" in 1994.  Rick's comment:  "I always had plenty of work, so I just took a few classes when things were slow and after I got tired of hanging out in the bars."

           Computers are his hobby.  For fun, he's developed a strong interest in writing gaming software --- he's already adapted a Multi-User Dungeon (MUD) program to OS/2 and is working on another.  He's also posted an offline utility for Chin Huang's YARN newsreader which he named YTSG (Yarn To Soup Grep; SOUP is Simple Offline USENET Packet format).  He wrote it in VisualAge C, and it runs on a server as cgi-bin to create a viewable "DejaNews"-style database of the news you've downloaded.  And as we talk he shows me some code that allows you to switch full-screen sessions using an undocumented call.  Pretty neat, since the switching problem is the main reason I try to stay away from full-screen work.

And His Experience

           Rick began using computers in the early 1970s while still a teenager, and first worked on an IBM 360 clone by Interdata.  He then worked as a technician in both analog and digital electronics for various companies including Pertec and Anadex, and then returned to computing as a programmer.

           His first involvement with OS/2 was in the imaging industry WORM market at Janus Systems.  This was when Microsoft still had OS/2; Rick worked on OS/2 LADDR (Layered Application Device Driver) drivers which linked to each other and passed pointers back and forth, and much of the work was in assembler.  When Microsoft dropped OS/2, Janus got the 1.3 release and ported their optical jukebox driver library to OS/2 from VAX.  Rick spent five years at Janus, and survived the purchase of Janus by Atlantic Research Corporation and the subsequent sale to Computer Science Corporation.

           But in 1989 Janus was shut down, and Rick again became an independent firmware contractor, getting work through inquiries.  He kept in contact with some of the old Janus customers and did work for them and for JPL.

           JPL?  Jet Propulsion Laboratories?

           "Yes," says Rick, and he's still both proud of and intrigued with his JPL work.  He was involved with embedded systems there, especially synthesizers in the 20 MHz band that were used in ground-based space stations.  Rick wrote the synthesizer software code before the hardware was available for testing, and to check his work he wrote it all as OS/2-compatible and then simulated the hardware with additional OS/2 routines, for testing.  When the hardware finally was ready, so was his fully-tested code.

           For Foxboro, a process control company in Foxboro, Massachusetts with development offices in Valencia, California, he wrote an AMD 2901 floating point library.

           For EMP (Electromagnetic Processes), he rewrote the CLOCK01.SYS clock driver (CLOCK02.SYS, he points out, is for microchannel) that OS/2 loads automatically at boot time.  The client wanted to tie the clock module to a NIST wire for "better timing".

Train Drivers

           And for the Burlington Northern Railroad he wrote an OS/2 SCSI device driver subsystem for Kollsman controller software which was driving Kodak WORM (Write Once Read Many) drive jukeboxes.  The railroad kept all of its technical drawings (bridges, trackwork, buildings) on WORM, and during the project Rick worked with both of the competing Group 4 compression standards as he tried to shrink the files as much as possible.  The WORM devices had 1K sectors, typical for WORM drives, and Rick used three simultaneous threads to handle file location, translation, and writing.

           Three drivers were written for the subsystem --- an .ADD, a .DMD, and a .SYS --- to accomplish the translation from raw WORM bytes to application program data.  His .SYS driver communicated via IOCTLs down to the .DMD driver, and since the SCSI card was ASPI (Advanced SCSI Programming Interface) compatible he used that for .DMD to .ADD communication.  "All Adaptec controllers can work with ASPI, since Adaptec created the interface," says Rick.  "Under OS/2, the ASPI layer is an OS/2 driver and, as far as I know, supports all cards which have an OS/2 .ADD driver."

           Finally, Rick ended up with a long string of OS/2 projects from Kinko's, the large business services company with main offices in Ventura.  All Kinko's on-premise servers run OS/2.

Here's The Code

           Rick is a specialist with ASPI, the Advanced SCSI Programming Interface developed by Adaptec.  ASPI allows a programmer to break a device driver into two components, an ASPI module which controls a specific device but doesn't care about the SCSI adapter being used, and an ASPI manager which accepts ASPI commands and converts them to the specific commands that the currently installed SCSI adapter can understand.  The application program sends an ASPI command to the ASPI module, which converts it into the specific commands the device requires.  These device commands are then sent to the ASPI manager, which knows how to get them through the particular SCSI adapter being used so the device commands actually arrive at the device.

           To better understand what Rick does when writing an ASPI SCSI driver, I downloaded and read ASPI_OS2.TXT from the Adaptec site.  The file contains a fairly complete overview of ASPI plus lots of code showing how you write an OS/2 ASPI driver.  If you're a real techie, take a peek at the file (the url is at the end of this article) and see what's going on.

Look At All Those Funny Numbers

           Rick has a lot of experience with what he calls the "black screen of death," that funny display of cryptic internal names and hexadecimal values that shows up on your screen when OS/2 decides something has gone very, very wrong and it's just not going to run any longer.  Programmers who write device drivers are used to clobbering their system, and get a lot of these.

           "Look at the CSLIM value, which is the size of the code segment of the driver which caused the error," advises Rick.  "Then use the EXEINFO utility, available at Hobbes, to search all your driver headers for that size, and you'll know which driver told you about the problem.  Then use the CS:EIP value, which is the offset in the driver code where the error occurred."  Fascinated, I later download EXEINFO and unzip it.  It's a neat little utility; you tell it what you're searching for (like a CSLIM value from a Trap error screen) and it finds the offending module, be it driver, EXE, DLL or whatever.

Seen Any "Trap E Page Faults" Lately?

           If you're using an ASPI SCSI driver, you give the driver a list of the buffers you have locked down (done by the original call) and the ASPI firmware handles everything after this.  But you'll get a Trap E paging fault if your driver doesn't "scatter/gather" correctly.  The Trap E is "very occasional", according to Rick, and many SCSI drivers may still be prone to it.  "Why does the Trap E only happen occasionally?" I ask.  "Because OS/2 typically gives you contiguous memory, so there isn't any scatter/gather to be done," replies Rick.  "But if the memory pool is low and you get non-contiguous memory, you'll get that Trap E if your driver doesn't handle it properly."

           If you want to write for ASPI, the OS2ASPI.DMD driver is included with OS/2 (it's in \OS2\BOOT\) but remember that it's not put into CONFIG.SYS by default.  Instead, the installer puts OS2SCSI.DMD into your CONFIG.SYS if it finds a SCSI host adapter.  If you want OS2ASPI.DMD in your CONFIG.SYS, you have to put it in yourself.

Was That A Car Or A Microsoft Marketing Man?

           Rick drives a red Camaro and likes to accelerate.  This reporter recently took a ride with Mr. Curry and witnessed much accelerating and very little braking, indeed.  Our return ride to his home was climactic as he neatly cornered the nearby intersection with his shocks maxed, slid sideways across the road sand at the end of his cul-de-sac and came to a smoking stop in his driveway, missing his camper by mere inches.  "I've been practicing that move for years," Rick said with a wide smile.

           Upon regaining the power of speech, I suggested we take the camper next time.  "Ooh, that's fun!" said Rick.  "It's turbocharged."

Woolly Drivers

           Mr. Curry learned to write OS/2 drivers during the Microsoft OS/2 days.  "It was wild and woolly", he recalls, "there was some sample code but not much.  We purchased a Microsoft support package for about $1500 a year but found that if you called them up with a question you would basically be insulted.  We reverse engineered a lot to learn how things worked."

           Rick used the Microsoft compiler with OS/2 1.0.  It's still available for free from IBM Developer Connection, and he still uses it occasionally.  It's good for 16-bit drivers only.

And Woolly Compilers

           Rick uses VisualAge C/C++ the most, but it's 32-bit only.  "You use 16-bit drivers for the primitive functions, and invoke them from 32-bit drivers which do the heavy non-I/O processing.  A 16-bit driver can still use 32-bit instructions; it's just the kernel calls which must be 16-bit."  In fact, as Rick points out, "CLOCK01.SYS, whose code is in the DDK Driver Development Kit, sometimes just starts using 32-bit code and then reverts back to 16-bit."  So when you write your driver, remember that the low-level stuff is called with 16-bit calls.  "Use an assembler directive," says Rick, "to switch into 32-bit mode from 16-bit mode."

           Rick's enjoying the compiler discussion.  "VisualAge C/C++ can inline C code with the '_Inline' directive (which doesn't work with C++ code; use 'inline' instead), while other compilers just inline C++.  Or," he says, "you can use a macro to insert actual code rather than making a call."

           He also uses Watcom C/C++ (version 11.0.a is the most recent release; about $10 will get you an upgrade).  Rick points out to me that the Watcom linker puts an underscore ("_") after, not before, a name.

How To Write A Driver

           The Man Of Many Drivers uses a "state machine" driver model.  His current OS/2 driver toolkit is the IBM Developer Connection Device Driver Kit for OS/2, and he's very pleased to point out that the packages also have the relevant manuals in them.  Rick also notes that they include slightly more complete IOCTL info, including a TESTCFG driver which allows direct I/O to devices.

           "Yes, I use the debug kernel, and I've also used the text-based ASDT Debugger.  There's a lot of useful information that comes back from these tools."

           "And the Watcom bulletin board has a lot of good device driver information, and also check the old IBM Boca Raton OS/2 BBS, now on the Internet, for more driver info."

NT vs. Warp Server

           Rick is a family man.  He's got a wife, Penny, and a young son, Michael.  When I visit his home for this interview, Penny (also a device driver programmer) is hard at work at her keyboard, formulating a driver.  Not an OS/2 driver, though.


           "NT drivers are a nightmare," says Penny.  "There's so much you have to worry about.  OS/2 drivers are a breeze compared to NT."

           "NT has a huge amount of overhead," adds Rick.  "An NT box with four processors seems to be equivalent to an OS/2 box with one processor.  Warp Server with one processor beats NT with four processors."

           "To develop for NT, you must have all of the Microsoft tools.  Don't try to start an NT driver without them."

           "Plus, NT uses spinlocks for multiprocessing compatibility.  And my experience with WinNT drivers," he continues, "is that they lock up if the driver is required to do too much at once."  Rick, I must add, requires a lot from his OS/2 drivers.  Perhaps he's just trying to push NT too hard.

Learning That Driver Code

           I ask Rick what you need to have on hand to start writing OS/2 device drivers.  "The compiler, of course," he responds, "plus the IBM DDK Driver Development Kit.  And a second machine so you can test the driver without having to reboot your main machine every time the driver blows up.  And a few acquaintances who've already written drivers so you can ask them the really tough questions," he adds with a smile.  "Here's a tip, for example.  Put some debugging buffers inside your driver and add some IOCTL code so you can read the buffer values.  Then send your driver IOCTLs while you're testing it so you can monitor what's going on inside."

Gunning For SPAM

           "And what is CAUCE, the organization you mention at the bottom of your emails?" I ask.  Rick grins.  "That's the Coalition Against Unsolicited Commercial Email.  I'm a member.  I think it's a worthwhile organization and people should know it exists.  They're out to stop the spammers."  I quickly calculate what it really costs when the spam guys send out their messages:  a million spam messages, even at only five seconds each to look at the title and then press the delete key, is 1,400 man hours.

           "I personally go after spammers with a vengeance.  I'll check the email header and try to figure out what part of it is faked and what server the spammer is using.  Then I'll contact the webmaster there and alert him, so he can shut down the account and maybe spiff up his monitoring and security a little.  I use NSLOOKUP from the command line, plus TRACERTE, PING and WHOIS (available from Hobbes).  I use WHOIS version 1.1 which reverts to the local server, and you can specify '-h' on the command line to check that European agency (the hosts are,, and"

Besides Drivers

           A solid device driver background has opened a lot of doors for Rick, since it's a lot easier to understand all of OS/2 when the drivers don't seem to be some sort of magic.

           His workload has often been exclusively OS/2 drivers.  He's currently involved in both drivers and non-driver OS/2 projects, including networking with Ethernet on NetBIOS, Netware and TCP/IP (all for Kinko's), developing software, doing trouble-shooting, and a large project doing "mail slots" which he describes as an "extremely loosely-coupled connectionless named pipe" so phone lines can connect a Hewlett-Packard 3000 database server to DOS clients over a network.

           Rick's got the experience to write device drivers for many years to come.  Maybe he'll expand into IrDA drivers, or IEEE 1394 drivers, or maybe he'll teach an online class so others can gain some of his experience.

           So the next time you tap on your keyboard, be careful.  Show some respect for those little drivers that are hyperventilating to get your data to its destination.  One of them may have been written by Rick Curry.


Rick Curry, Richard Curry Consulting -- Firmware and System specialist,,


Adaptec Support,

Adaptec Support -- Drivers And Files,

ASPI, Advanced SCSI Programming Interface, go to the Adaptec site and search on ASPI

ASPI_DEV.TXT, Adaptec's ASPI for OS/2 Specification,

CAUCE, Coalition Against Unsolicited Commercial Email,

EXEINFO.ZIP, search Hobbes at


IBM Boca Raton OS/2 BBS (IBM PC Company BBS),

IBM Developer Connection,

IBM Developer Connection Device Driver Kit for OS/2,

IBM Developer Connection homepage,

IBM Developer Connection Online,

Watcom bulletin board, same as Watcom C/C++

Watcom C/C++, owned by Sybase, and look at all the available links

YARN, written by Chin Huang,,

Section List

Rip Tide
Update Those Old Drivers
Scatter/Gather And DMA
Just A Game Of Chance
Pounding Of The Waves, Pounding On The Keyboard
Warp Server and IOCTLs
What Makes A Curry
And His Experience
Train Drivers
Here's The Code
Look At All Those Funny Numbers
Seen Any "Trap E Page Faults" Lately?
Was That A Car Or A Microsoft Marketing Man?
Woolly Drivers
And Woolly Compilers
How To Write A Driver
NT vs. Warp Server
Learning That Driver Code
Gunning For SPAM
Besides Drivers

The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 1998 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG is a trademark of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation.
All other trademarks remain the property of their respective owners.