About

linkedin_img
facebook
twitter
steve_looking_10082008_g

I’m a software developer, architect, and technologist with an extensive background in software development, systems design, enterprise architecture, and product innovation. I’ve written software for everything from coin changers to enterprise systems, with an emphasis on real time operating systems, device drivers, memory management, and instrumentation. I’ve served as team leader, chief programmer, architect, director, and VP of engineering. I’ve managed people, projects, budgets, and customer expectations across a wide range of systems and services including mobile devices and applications, tablets, desktops and desktop applications, public and private clouds, speech to text and text to speech systems, large-scale analytics, RPAs, A.I., security, and big data.

I began repairing minicomputers, disk drives, and magnetic tape drives while studying electrical engineering. worked for several companies as a software engineer, eventually forming my own consulting company where I provided hardware and software development services to companies such as IBM, Microsoft, Boeing, Hamilton Standard, Grumman, Ford, General Motors, and Kodak. I joined Gerber Technology as a software engineer, eventually moving up the ranks to manager, director and VP of Engineering.

In 1989 I joined the IBM OS/2 development team in Boca Raton, Florida where I worked on OS/2, OS/2 Warp, and OS/2 device drivers. I worked with OEMs to get device support into OS/2. My device driver programming book became the authoritative text for anyone developing an OS/2 device driver.

When IBM abandoned OS/2 and closed down the Boca Raton site, I was invited to Austin, Texas but declined the offer.  I instead joined IBM Research in Yorktown Heights, NY where I worked on a variety of projects including mobile enterprise applications, private and public clouds, virtual desktop services, analytics, healthcare applications, mobile communications, security, business process transformation, and municipal traffic and energy systems. I led cross-divisional teams, and was a member of the future technology and intellectual property development teams.

After leaving IBM in 2013, I joined Cigna as IT Senior Principal and Director responsible for the development, architecture, and deployment of mobile and web applications, web servers, cloud systems, client-facing applications, physical and biometric security, privacy, compliance, and new product innovation.

In my copious spare time I install and maintain networks and software for physicians including patient management, EHR/EMR, and clinical decision systems including Allscripts Pro, Lytec, Lytec MD, AdvantX, Epic, and others.

I enjoy listening to and playing music from the first half of the 20th century. Some of the most memorable and enduring songs were written during that time period. I began taking piano and guitar lessons in an attempt to learn how to play a few songs. The lessons have not helped, but I’ve learned to enjoy listening to myself nonetheless.

Links to Publications (more articles, papers, and written material, including patents, can be found at Google Scholar.

by Steve Mastrianni ♦ Van Nostrand Reinhold, $39.95

Book Review:

Device drivers, the programs in your CONFIG.SYS file that control your computer’s peripheral hardware, hold a mystical aspect for many programmers, as if they re
something that mere mortals must not behold. Commonly believed to be difficult to write, most programmers shy away from them. This need not be the case. With good documentation, an understanding of how the system works and how it interacts with
the device driver, writing a device driver is no more difficult than any other code. It’s the fear of the unknown, you see.

Writing OS/22.0 Device Drivers in C paves the way toward enlightenment and under¬
standing. In spite of a somewhat unwieldy (although accurate) title, and a bit of
unnecessary novice programmers material in the beginning, it is chock full of the information you need to understand how device drivers work, and what is involved in writing them. There is a vast amount of new knowledge to pickup when working with device drivers, and Mastrianni guides you into it. He starts with an interesting review of the beginnings of the PC industry, and provides an introduction as to how and why device drivers have evolved.

He also presents an overview of the PC architecture, lightly touching on Micro Channel Architecture and Enhanced Industry Standard Architecture (EISA). Actually, there’s a bit too much introductory material, including a description of such basic concepts as binary and hexidecimal numbering systems! Anyone who’s attempting to work with device drivers should already have such basic computer knowledge. The thought of someone who isn’t familiar with binary attempting to write a device driver… well, there are better ways to get a headache!

Still, it’s better to have too much information than not enough. Although much of this material will be familiar to anyone who’s written device drivers for OS/2 or other systems, it provides a nice review, and a foundation for those new to device drivers. The review section finishes with an overview of the OS/2 operating system. Then comes the meat, with a breakdown of what goes into an OS/2 device driver. While technical, its still readable and understandable.

Mastrianni begins the development sections by outlining a skeletal device driver with numerous code examples and explanations. Following this is a sample Physical Device Driver, (PDD). The sample PDD controls a conveyor belt: turning the motor on
and off, and sensing switches. In constructing the complete PDD, Mastrianni builds upon the concepts presented earlier.

Device drivers usually need to know the bus architecture. ISA machines use switches or jumpers to configure hardware settings: interrupt levels, DMA channels or port addresses, for example. Micro Channel is more flexible, using a setup program to configure the system, saving the settings in nonvolatile RAM on the boards themselves. The device driver must know how to determine these settings. Mastrianni discusses issues related to the Micro Channel bus. Further code examples demonstrate a combined ISA/Micro Channel initialization routine. Unfortunately, an equivalent section covering EISA issues is not included.

Virtual Device Drivers (VDDs), which are new for OS/2 2.0, are covered with descriptions on VDD architecture, Virtual DOS Machines, VDD-to-PDD communications and virtual DevHlp (device helper) services. VDDs are the magic that make DOS boxes work so well. DOS programs normally interact directly with hardware; the screen, serial ports and so forth. Naturally, if two programs attempt to use the same device simultaneously, chaos can result. Imagine two children trying to watch different shows on one television. OS/2 protects against this uncivilized behavior by intercepting the I/O requests and letting a VDD for that device determine what to do. It may permit the action (possibly assigning ownership of that device to that program), deny the I/O (if another program owns that device) or queue all the requests so that all programs can use that device. A brief description of each of the various standard virtual devices helps to explain the role that they play in a working system. To complete the coverage, Mastrianni presents a sample VDD which works with the sample PDD.

Mastrianni does not ignore the many other important areas related to device driver development: memory-mapped adapters, IOPL (Input/Output Privilege Level), DMA (Direct Memory Access), EDDI (Extended Device Driver Interface) and interrupt
handlers. Although Mastrianni does not cover Presentation Manager drivers in detail, he does include an introduction to PM drivers.

The book includes a substantial amount of reference material. These chapters cover areas such as the request packets which OS/2 issues to the device driver, and the DevHlp services which are available to the device driver. Mastrianni includes numerous charts of useful information within this section.

If you’ve ever had trouble debugging a program, just wait until you try debugging a device driver! The device driver’s close ties to the operating system are often problematical; if the driver doesn’t work, the system may not come up. As
Mastrianni explains, special tools such as the kernel debugger (KDB) are required. He briefly explains the use of these tools and includes a handy command reference to
the KDB.

Pictures are said to be worth a thousand words. In the case of a device driver, program listings are the pictures. Appendix C includes 71 pages of listings. Although several of these listings repeat earlier examples, Mastrianni does provide several additional listings. These include the standard device driver include file, and parallel and serial port drivers.

If you don’t like entering codes from a book, a companion diskette is available. The diskette includes the source, makefiles and documentation for all the examples. Or, you may order another set of utilities: the C callable DevHlp Library and Toolkit (which includes the companion diskette). Neither of these diskettes is required to use this book as an educational tool, nor as reference source. However, if you plan on writing device drivers using C instead of Assembly Language, the Library and Toolkit will be necessary. While you could create the C-to-assembler interfaces for the DevHlp routines yourself, it would be quite time consuming. An example of one of the interface routines is included in the book—while it is short, there are a lot of DevHlp functions. Recreating the complete library would require a lot of typing!

Overall, this is a very helpful book. Mastrianni covers a wide range of material, and presents it in a more readable fashion than the IBM Device Driver Kit. The book is not as detailed as the DDK, which is a mixed blessing. While the DDK is thorough, it is frequently overwhelming. Writing OS/2 2.0 Device Drivers in C is useful as an introduction to writing device drivers, and provides a firm foundation for further digging into the DDK. It also provides great assistance to those who would rather write in C than in assembler. There are several issues, such as C startup code, and segment ordering, which need to be addressed when doing so; and Mastrianni provides good coverage of these topics. For anyone contemplating writing an OS/2 device driver, modifying an existing driver or simply desiring a greater understanding of how OS/2 interacts with device drivers and hardware devices, this book is well worth owning.

Alan Weiner is a consulting engineer at Communica, Inc., located in Bourne , Massachusetts. He has been twiddling bits since the late 1960’s , and writing system-level software since the days of the 8080.

Fun Stuff

I love being outdoors, exercising, and playing sports. I spend over an hour every day on the treadmill and working out in my home gym. I enjoy rock climbing, zip-lining, biking, and running. In 2010, I took up snowboarding. There’s nothing like getting out in the cold, brisk, New England air and falling down a lot.

%d bloggers like this: