The Codesmith's Library
Written by Carsten Whimster
My Web page is continually growing, and has become quite large and popular. It has recently had over 1500 hits, forcing me to expand my counter to 5 digits. It should be ok there for a while [grin]. It includes, among other things, a short list of developer-oriented links. Check it out at http://www.undergrad.math.uwaterloo.ca/~bcrwhims/os2.html.
This summer has seen me incorporating a number of useful changes into my
POV-Panel/2, culminating in a 1.1 beta release available on my Web page.
It also saw me getting my first few registrations, so I must be finally
doing something right [grin]. I had a lot of learning to do during this,
however, both with respect to REXX, VX-REXX, OS/2, and supporting paying
customers. It seems that if you pass a commandline to REXX with a quoted
long filename in it, it isn't parsed correctly, but rather on a
word-by-word basis. In some ways this is not too strange, but it is rather
awkward, and has caused me to create a known-bugs section in my README file
for the program.
Designing High-Powered OS/2 Warp Applications is a unique type of book. It does not attempt to teach you how to program, but rather how to design programs, or how to think about programming. These are the chapter titles:
I will concentrate on the sections, rather than the chapters, since the divisions between the chapters are much fuzzier than in actual programming books.
If any of the above sounds familiar, that is because it is. I didn't realize until I started reading (and after getting a heavy dose of deja-vu all over again [grin]) that this book is an update of Reich's previous Designing OS/2 Applications. It has one new chapter, a few new sections, and some updated text here and there. For this reason (after much internal debating), I have decided to just concentrate on the new or changed sections, and a few problem areas in the older book (to see if they have been fixed), rather than copying the old review, or pretending that it never happened, and reviewing it as if it was totally or even mostly new. I will use some of the text from the previous review, and just brush quickly through a lot of the book, but really concentrate on the new stuff. For a complete review of the previous book, I refer the reader to Volume 3 Issue 1 of EDM/2, available at fine FTP sites near you. Here goes...
Section I explains the advantages of OS/2 over other platforms. This is explained both from an end-user's point of view, as well as from the programmer's point of view, and includes discussion of such issues as pre-emptive multitasking, multi-threading, virtual memory, and so on. There are new sub-sections on symmetric multiprocessing and portability to the PowerPC. The importance of the proper use of threads to benefit from SMP is stressed. The PowerPC sub- section has a small quote which re-raises an old point of discussion between followers of the PowerPC: "Object code compiled for Intel chips will not run on most PowerPC RISC chips." The key word here is, of course, "most". IBM has repeatedly denied (until I last heard) that there is a PowerPC chip being designed which has hardware emulation of the 80x86 instruction set to speed up running Intel-compiled programs, and to speed up the acceptance of the PowerPC chip. Considering Reich's insider position (he does not work for IBM any more, but was on the OS/2 development team, and has very strong ties in IBM), I would take this as further evidence that such a chip is actually being designed. Interesting.
Reich also has a small dig against Microsoft in the following sentence, which is quite amusing: "In contrast to others, with sets and subsets of APIs, this gives your user the consistency without you having to rewrite code to exploit the set or subset of function depending on which version of the operating system you may be on." Apart from the obvious value in advocacy USENET forums, this is quite interesting from a programmer's point of view too, in that we have it so much easier over here than they do over there with their ever-changing APIs. The basic message here is that only a recompile is necessary to move to the PowerPC, except for device-driver writers.
The next new sub-section is on "OS/2 Development: The Next Generation". Huh, Star Trek? Nope, just a brief paragraph extolling the virtues of objects, code and object reuse, and development environments. Curiously enough, IBM's latest CSet++ (Now Visual Age C++) is much more of an "environment" than it ever was, so Reich is obviously in tune with the developments at IBM [grin].
Section II is a large section, which outlines the overall application design theory and procedures. The importance of good, solid, up-front design are stressed over and over again, not quite ad nauseam. Again, there is a new sub- section on SMP, which discusses scheduling on SMP machines. It is obviously (but not obviously enough!) very important not to make assumptions based on the fact that on the vast majority of machines, only one thread can run at a time. This does happen, though, and it is a very subtle thing, so making sure that your design is correct up-front really pays off here. Timing-related bugs are a beast to debug, as I found out in CS342 (concurrent programming), but that is another story. He also emphasizes that just adding more threads to make a program SMP-able is not a good idea; rather, add threads where appropriate on non-SMP machines, and SMP will enhance the running of your program.
Chapter 7 is a completely new chapter on Warp for the PowerPC. As such, I will go into more detail here. The Workplace OS is explained, and the fact that OS/2 Warp for the PowerPC is merely the first implementation of this is stated. The personalities of Workplace OS are explained. Basically they are just an API layer between the program and the IBM Microkernel, which is a Mach-derivative. This API layer can be almost anything, including OS/2 PM, DOS (an INT13 etc. API layer? Yuck), AIX, and at some point in the not too distant past, Windows NT and System 7. Understandably, both Apple and Microsoft got cold feet about having their OSes run under an IBM OS, and canned the idea. Anyway, the main (and startling) difference between Workplace OS and Intel OS/2 is that the device drivers, OS/2 API, and other sub-personalities run as user programs, not as privileged programs! This makes no difference to most of us, with the glaring exception of device-driver writers. It does mean, though, that once the microkernel is stable and mature, this baby will be solid as a rock, and re-booting will become very rare. As a worst-case scenario, you will have to restart the interface. This we can already do now, but not in quite the same way. Device driver writers can look forward to much more portable drivers, since they are not, to any large extent, hardware dependent, but rather send messages to and from the microkernel. At least, this is the way it is explained, although it seems a little hard to believe; only a recompile should be necessary. I don't quite see where the new code goes every time a new sound card or video card is written; in the microkernel? A new microkernel every time a new "thing" is released? Inconceivable. To some extent then, these device drivers must be hardware dependent, but only dependent on the "thing", not the machine. Weird science. Same device driver works for all the personalities too. This is easier to see. Basically, each personality is comprised of a server, and a client-library (the API). The server has the major chunks of ideology specific to the O/S it emulates, and the client-library actually services the API calls from programs, sometimes without calling the server, other times by calling the server. All calls take the form of messages, which are more or less the same old thing for PM writers, except on a below- the-surface scale.
Section III discusses modularization in much greater detail. Reich presents his idea of design (which is tempered by years of writing for OS/2, so listen up), starting with the overall design accomplished by taking a black-box approach to your app. There is a new sub-section on Application Development Tools for OS/2 (actually this used to be a CASE tools section, but CASE tools are frequently way too expensive for individual developers, so I imagine that is why the section now has a more generic flavour) which discusses the various types of tools that are available to help design and write applications, including RAD environments, CASE tools, and so on. This is followed by a sub-section on Object Technologies. SOM, CORBA, and OpenDoc are discussed here, along with explanations of how it all hangs together. Finally, there is a new sub-section on Interprocess Objects and Agents, which discusses communication with WPS objects. DSOM is also briefly mentioned.
Making it Happen is the title of section IV. Practical decisions are the main focus here, such as the choice of development environment, tools, source code revision systems, and so on. The sub-section Handling Long Jobs has been restructured a little to make the flow more logical, and this has affected the layout of the next couple of sections. In the next chapter, there is a new sub-section named Guard Pages and Exceptions which discusses, well, I won't spoil the surprise [grin].
Note: the example on semaphores and deadlock is strictly speaking inaccurate. I quote: "You can see there are three threads. Threads 1 and 2 make use of semaphore A. Threads 2 and 3 make use of semaphore B, and threads 1 and 3 make use of semaphore C. No two threads make use of the same resources, but you can see that if thread 1 has semaphore A, thread 2 has semaphore B, and thread 3 has semaphore C, any semaphore request by any of the three will cause a deadlock." In fact, if, say, thread 1 requests semaphore C, it is still possible for the three threads to complete as follows: thread 1 requests semaphore C, and locks. Thread 2 requests semaphore A, and locks. Thread 3 finishes with semaphore C, releases it, requests semaphore B, and locks. Thread 1 can now get semaphore C, and run to completion, releasing semaphore A and C. Now thread 2 can get semaphore A, and run to completion, releasing semaphore A and B. Finally, thread 3 gets semaphore B, and runs to completion. In fact, any sequence of events will complete, which has one thread giving up a semaphore before requesting another. If all three threads needed two semaphores at the same time, and each acquired one, then any further requests causes deadlock. This is slightly different than the statement of the problem, but it is significant. I imagine this is what was meant. This section needed rewording in the first book too, so I guess Reich doesn't read my column. (Sigh)
There is a small new sub-section (which isolates material covered elsewhere in the previous book, I think) which discusses resources in DLLs.
Section V deals with performance tuning. Many little neat performance tricks are presented, such as minimizing fix-up costs, accessing DLLs intelligently, thread priorities, EXE packing, and DLL placement. User interface speed is also discussed in some detail. There is a new sub-section called Code Size versus Path, which should be called Code Size versus Path Length, I think. Basically, Reich advises that, since CPU power is getting cheaper much faster than RAM and hard drives, and since the CPU is faster than either, it is advisable to pack code and data as much as possible, and to unpack it using extra CPU cycles. There is a limitation to this, of course, but in general I would agree. One extreme example of the benefits of this is given by Stacker and similar programs: occasionally, having the data compressed on the hard-drive, and decompressing it on-the-fly actually yields an increase in speed, due to the reduced wait for the hard-drive to transfer the data! This is not in all cases, of course, but more often that you would think.
The penultimate section deals with testing and changing code. These two chapters are short, sweet, use common sense, and haven't changed, so I will leave them out here.
The final section is on installation programs, and this happens to be a pet peeve of mine. Frequently, you pick up some really neat program, but get frustrated trying to install it correctly. In my opinion, a decent installation procedure should include instructions on how to install manually, in case the installation program fails. This is obviously difficult to do in the case of something as complex as OS/2 itself. With the types of programs that most of us write, however, it should be a breeze. In addition, reinstalling and uninstalling are mentioned, but too briefly. Uninstallation programs really should be given more emphasis, especially in this day and age where programs like Uninstaller for Windows are perpetually at or near the top of the best-seller list, and Windows 95's logo program requires an uninstallation program.
There is a brief summary following this last section, which concludes the book.
Not surprisingly, this book is very much like its predecessor. In fact, so little has changed that it is more of an update than a new book. A few areas have been improved, and a few need improvement, but overall this book has retained the strengths of the previous book, and still should have a spot in most OS/2 programmers' libraries.
The book is now pretty up to date, which is a plus, but the semaphore example still needs rewording, and the book still drags slightly in the early chapters. The book still has a slight C bias, which I suppose is in order, despite going a little against the self-imposed language-neutrality of the text.
If you already have the previous book, then take a long hard look at the new sections, and see if you really need it. If you don't, get it; 'nuff said. It is a very good book for showing you what features OS/2 offers a programmer, and how to go about the up-front design of applications. For large projects, this kind of book is essential. It gets a solid A on the report card.
Designing High-Powered OS/2 Warp Applications, Reich
Our Bookstore has reviews and links to Amazon for all books we have reviewed in the past, as well as several books waiting to be reviewed, and others which we recommend.