Arawak OS/2 Shareware/PAKLED.ISO/docs/edm/edmi3-1.inf

OS/2 Help File | 1995-01-05 | 180.2 KB | 1,791 lines

ΓòÉΓòÉΓòÉ 1. Jan 1995 Title Page ΓòÉΓòÉΓòÉ

                                      EDM/2
                  The Electronic Developer's Magazine for OS/2
                   Portions copyright (c) by Larry Salomon Jr.
                                Volume 3, issue 1

New Directions

Merry Christmas, Happy New Year, etc. to each of you out there in net-land.
This issue marks the beginning of a new year, and with a new year comes new
directions.  From the magazine's perspective, many new directions will be
explored, beginning with this issue - what I have written, including what you
are reading now, I have written using a word processor. It has been decided
that one of the directives for 1995 is to make it easier for potential authors
to disseminate the information that they have learned and wish to share.  Since
writing in .IPF is quite daunting, this has often dissuaded people from
submitting an article, and this hurts the OS/2 community.  Additionally, it
never was easy to spell-check an .IPF file.  <grin>  Since many word processors
now support the rich-text format (or RTF), this will now become the requested
file format for new submissions.  Please see the new Article Submission
Guidelines, which has been rewritten and uploaded to hobbes.nmsu.edu, for more
information.

Another directive for the magazine is to change the file format of the
magazine.  It only makes sense that, in order to increase the size of our
audience, the quickest way is to change the format to that which can be read
with viewers that are available on multiple platforms.  Since there are many
"arm-chair" programmers who do not develop OS/2 applications as part of their
daily routine, it would be nice if they could read the magazine on the machine
they use the most, whether that may be running DOS, Windows, or UNIX.  We will
keep you posted on this issue as we receive more information.

You'd Be Surprised...

at how many people thought the Title Page had nothing but legal drivel on it.
This came to light when I complained that only one person had voted for the
Reader's Choice Awards during the first three weeks following the release of
last issue; many people responded with "when was this mentioned?"  To prevent
this from happening in the future, we have moved the legal portions of the
magazine to the end of this page so that more people will read this section of
the magazine.  After all, we wouldn't want you to miss all of the humor.
<grin>

And Speaking of Voting...

I am pleasantly surprised at the response my complaint generated.  Since that
time, I have received many more than the fourteen I received last year. It
still isn't a flood, but I'll take what I can get.  Still, you have until
January 15 to send in your three votes for the best articles of the year 1994.
See last issue's Title Page for a complete list of the articles eligible for
this award.

It's really funny what some of the votes were for.  I'm not trying to pick on
anyone, but receiving votes for software and books that weren't even mentioned
in the magazine, much less part of the magazine (for which your votes should
be) gave me quite a chuckle.  I will be including those in the results so that
you, too, can have a grin or two.

Welcoming Another Network

We would like to officially announce the arrival of EDM/2 on America On-line
(AOL).  Our network distributor for AOL approached us with the desire to do
this for us and we are glad to have Jason B. Tiller ([e-mail]) on the
EDM/2 team!  Also, a Scooby Snack goes to David Pedigo who pointed out that, on
the site generalhq.pc.cc.cmu.edu, the directory name should be
/pub/NewsLetters/EDM2 and not /pub/newsletters/edm2 as was stated in previous
issues.

Reader Feedback

One reader, Tarjei T. Jensen, wrote in regarding the Coding for Dollars - Copy
Protection and Prevention article that appeared in last issue.  He suggested
that, for simultaneous access of an application, another scheme called NetBIOS
Name Defense can be used for tracking the number of licenses.  While his
explanation was detailed, I am a bungling idiot when it comes to anything
dealing with communications.  I invite Tarjei to write a "followup" article to
mine explaining this and the other methods that he mentioned in his letter.

Michael Shillingford also wrote in and brought up a very good point that, if
you're bored with the gray on black coloring of your command prompt, you can
use ANSI escape sequences in your prompt string to liven things up.
Unfortunately, these must go in a .CMD file, which you can execute during the
opening of the command window using the /K parameter of CMD.EXE. The escape
sequence is $e[nm, where n is a color from the following list:

 Value               Color
 30                  Dark gray
 31                  Red
 32                  Green
 33                  Yellow
 34                  Blue
 35                  Pink
 36                  Cyan
 37                  White

 The background color may be changed also by using the following numbers:

 Value               Color
 40                  Black
 41                  Red
 42                  Green
 43                  Brown
 44                  Blue
 45                  Purple
 46                  Dark cyan
 47                  Pale gray

 Finally, using the number 0 indicates that foreground colors are to be from
 the low-intensity set, while using the number 1 specifies the high-intensity
 set.

 If you don't want to set the prompt command twice, you may separate the
 numbers by a semicolon; the entire command ends with a lower-case m, e.g.
 prompt $e[37;40m[$p] sets the prompt to white on black with the directory name
 in brackets.

 Is IBM Opening Up?

 It would seem so.  After a discussion on comp.os.os2.programmer.misc about the
 undocumented APIs used in OS/2, I received from a friend who received from a
 friend (etc.  ad nauseum) the function prologues for the Session Manager APIs.
 It really doesn't help much more than any of the Programmer Reference guides
 that have been in the toolkits over the years, but it is better than what is
 readily available to most of the public.

 Finally

 Speaking of the Programmer's Toolkit, I received my copy of the DevCon 5,
 Special Edition CD-ROM during the last week of December, which I used to
 install the Warp toolkit.  Noted changes are the inclusion of the
 bi-directional interface and the MMPM/2 toolkit in the "base" toolkit. Also,
 while perusing through the folder, I was quite pleased to find the on-line
 documentation completely redone.  Granted, I was only browsing things and
 wasn't actually trying to use them, but it seems that they are actually usable
 now for more than just a reference guide.  Additionally, IBM has included new
 on-line documents such as Multimedia Application Programming Guide, Multimedia
 Subsystem Programming Guide, OS/2 Bi-directional Language Support Development
 Guide, and Workplace Shell Programming Guide.  Many, many thanks to IBM for
 this much-needed improvement of the toolkit.

 Copyright Notice and Other Stuff

 The Editor-in-Chief of this electronic magazine is Larry Salomon, Jr.

 Portions of EDM/2 are copyrighted by the editors.  This publication may be
 freely distributed in electronic form provided that all parts are present in
 their original unmodified form.  A reasonable fee may be charged for the
 physical act of distribution; no fee may be charged for the publication
 itself.

 All articles are copyrighted by their authors. No part of any article may be
 reproduced without permission from the original author.

 Neither this publication nor the editors are affiliated with International
 Business Machines Corporation.

 OS/2 is a registered trademark of International Business Machines Corporation.
 Other trademarks are property of their respective owners.  Any mention of a
 product in this publication does not constitute an endorsement or affiliation
 unless specifically stated in the text.

 Title Page - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 2. The Design and Implementation of VIOWIN:  Part 5 ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 2.1. Introduction ΓòÉΓòÉΓòÉ

The Design and Implementation of VIOWIN:  Part 5

Written by Larry Salomon, Jr.

Introduction

For my job, I once had to write an application that ran only when OS/2 booted
from the floppy diskettes.  Because I had no access to the functionality PM
provides, I resorted to a line-oriented interface, where messages were
displayed on the screen and scrolled up when necessary.  It was a good
interface, I thought; it was fully NLS enabled and had intelligent defaults so
the user basically only had to type in the name of the application.
Unfortunately, the Quality Assurance team didn't concur with my opinion.  "We
want a nice interface!"  one exclaimed.  "Yeah, one with different windows and
such!"  another shouted.

I was backed into a corner that I could only get out of one way.

This series describes the design and implementation of VIOWIN, a library that
implements a subset of the Win APIs provided by PM for fullscreen sessions.
The reasoning behind writing this series is that it provided me and will
hopefully provide you with some unique insights into how a windowing system is
developed; and since it is based on PM, your familiarity with the already
defined interface will increase your capability to fully understand what is
being described.

Obviously, this series assumes you have PM application development experience,
but it isn't required.

This Month

This month we will wrap up our discussion of the base library so that we may
begin looking at the window classes next month.

The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3,
Issue 1


ΓòÉΓòÉΓòÉ 2.2. Timers ΓòÉΓòÉΓòÉ

Timers

Timers were probably the most exciting to develop for me, because never before
had I given thought to how they were implemented.  Seeing them work for the
first time was quite enjoyable.  Before we look at the VIOWIN/PM timer, we
should look at the timer-like services provided by the kernel -
DosStartTimer(), DosAsyncTimer(), and DosStopTimer().  The first one starts a
recurring timer with a specified timeout; the second starts a timer that ends
after the first timeout; and the third stops a timer started with either
function.  Timers signify their timeout by posting a shared ("public") event
semaphore which can be checked using the DosWaitEventSem() function.

A first pass at guessing how to implement VIOWIN timers would lead you to use
the DosStartTimer() function.  Consider the situation when the user calls
vwStartTimer() on an already started timer with the desire to change the
timeout value.  Using DosStartTimer() makes implementing this ability more
difficult than is necessary.  Therefore, we instead use DosAsyncTimer() to
restart the kernel's timer each time, referencing the current timeout value.
Thus, to change the timeout, we simply change the appropriate variable, which
is used the next time DosAsyncTimer() is called.

It should also be obvious that, since timers continue in the background, a
separate thread must be provided for the timers.  It is conceivable that a
single, auxilliary thread could be used for all timers in the system, but it is
easier to implement if we create a new thread for each timer created.

Take a look at the vwStartTimer(), vwStopTimer(), and timerThread() functions
in the source provided; they should not be difficult to understand, especially
with the comments scattered throughout the source.

The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3,
Issue 1


ΓòÉΓòÉΓòÉ 2.3. Resources ΓòÉΓòÉΓòÉ

Resources

The title is actually misleading, because VIOWIN only supports STRINGTABLE
resources.  The problem is supporting resources is not getting the resources,
but decyphering the data that comes back from the kernel.  For this, I used
Microsoft's Quickhelp utility and Martin Lafaix's article Resources and
Decompiling Them from EDM/2 volume 2, issue 6.

STRINGTABLEs are a curious beast because they are the only resource for which
one does not specify a resource identifier for the table itself.  Instead, the
resource compiler breaks the table into 16-string subtables whose strings have
contiguous identifiers.  So, if you have a table whose strings have identifiers
of 1, 17, 33, and 49, the resource compiler will create 4 subtables containing
strings from 0-15, 16-31, 32-47, and 48-63, though each of these subtables
contains only one string.  You can obviously see why you would benefit from
using contiguous identifiers for your strings in the STRINGTABLE.

The kernel provides the DosGetResource() and DosFreeResource() functions for
loading the resource into memory and freeing the memory used by the resource
(the former returns a PVOID which is why the latter function is necessary).
Unfortunately, the online references do not tell you the format of the data,
which I had to figure out with the help of my two other references.

STRINGTABLEs (actually, the subtables) have the following form:

Size of the table (2 bytes)
Length of string 0 (1 byte)
String 0 (n bytes)
Null-terminator (1 byte)
Length of string 1 (1 byte)
String 1 (n bytes)
Null-terminator (1 byte)
  :
Length of string 15 (1 byte)
String 15 (n bytes)
Null-terminator (1 byte)

The null-terminator is not included in the length.  The identifier of the
subtable is calculated given the identifier of any string within it by dividing
the string identifier by 16 using integer division.  The position (0- 15) of
the string is calculate by taking the remainder of the previous division.  So,
string 120 is in the subtable with the id 120/16=7 and is in position 120%16=8
(meaning 7 when counting at base 0).

The code for vwLoadString() should be easy to digest given the above
discussion.  Take a look and send me any questions.

The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3,
Issue 1


ΓòÉΓòÉΓòÉ 2.4. Drawing ΓòÉΓòÉΓòÉ

Drawing

Since PM clips the output of any window to the rectangle defining the window, I
couldn't use printf() for output, since it knows nothing of these rules imposed
by the UI.  However, one must be able to output something, and since graphics
are not allowed in text mode, I decided to limit myself to two functions:
vwDrawText() and vwFillRect().  These two deviate from their counterparts in
that they do not accept an HPS as the first parameter, and they use the window
rectangle as the maximum clipping region, which can be reduced using the
appropriate parameter.  Because these functions do not perform any black-magic,
per se, they will not be discussed, but you are encouraged to look at the
source for them to be sure you understand what they are doing.  It should be
noted that these functions are one of the very few that actually write anything
to the screen; these use the VIO subsystem, as documented in the 1.3
Programmer's Reference.

The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3,
Issue 1


ΓòÉΓòÉΓòÉ 2.5. Cursors ΓòÉΓòÉΓòÉ

Cursors

Cursors in PM are something that not many people use unless they are writing
their own general-purpose window classes, yet they are an integral part of PM.
Since our drawing in VIOWIN is limited to textual information, we cannot
support the wide-range of options in the WinCreateCursor() function, but we can
provide enough functionality to allow the creation and manipulation of a
blinking underline cursor.  This could probably be expanded to block cursors as
well, but I was lazy.

It is important to note that a cursor is clipped and can be visible or not.
These two states are completely independent of each other, so you should resist
the urge to wrap them both up in a single flag.  I initially did this and then
found to my chagrin that the following sequence of events will produce a result
inconsistent with what should happen:

   1. Move the cursor outside of the window so that it is clipped
   2. Hide the cursor
   3. Move the cursor inside of the window again

 Having a single flag for both clipping and visibility results in the cursor
 being shown after step 3 although it is clearly obvious that it shouldn't be.

 VIOWIN provides four functions for cursor support: vwCreateCursor(),
 vwDestroyCursor(), vwShowCursor(), and vwQueryCursorInfo().  These all behave
 much like their counterparts.

 The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume
 3, Issue 1


ΓòÉΓòÉΓòÉ 2.6. Source Code ΓòÉΓòÉΓòÉ

Source Code

The complete source for the base library is provided in viowin.zip.  Of course,
the library is useless without the classes, but it is helpful to have
nonetheless.  The archive contains the following source files:

 File                Contents
 VIOWIN.C            Miscellaneous functions.
 VWCLASS.C           Class functions.
 VWCURS.C            Cursor functions.
 VWDRAW.C            Drawing functions.
 VWMSG.C             Message functions.
 VWRECT.C            Rectangle functions.
 VWRES.C             Resource functions.
 VWTIMER.C           Timer functions.
 VWUTIL.C            Utility functions used internally by the library.
 VWWND.C             Window functions.

 The provided makefile can be used to compile the library.  IBM's C-Set++
 compiler was used; you may have to make modifications to the makefile in order
 to use another compiler.

 The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume
 3, Issue 1


ΓòÉΓòÉΓòÉ 2.7. Next Month ΓòÉΓòÉΓòÉ

Next Month

That's it for the base library!  Next month, we will begin by looking at our
first window class - the button class - and how it is implemented.  Any
comments or suggestions will be quite welcome.

The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3,
Issue 1


ΓòÉΓòÉΓòÉ 3. RMX-OS2:  An In-Depth View (Part 1) ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 3.1. Introduction ΓòÉΓòÉΓòÉ

RMX-OS2:  An In-Depth View (Part 1)

Written by Johan Wikman

Introduction

This is the first in a series of articles where I am going to describe ReMote
eXecution for OS/2 - RMX-OS2, or simply RMX.  In this first article I am only
going to give an overview of RMX, but in the articles to follow - which I will
do my best to provide at a pace of one per month - I will dig into details and
present some stuff you'll find interesting (I hope :-).

RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 3.2. Remote Execution ΓòÉΓòÉΓòÉ

Remote Execution

I've been using and programming for OS/2 ever since version 1.1.  At the same
time I have also used various flavors of Unix and hence also the X Windowing
System.

X and PM are essentially pretty much alike:  they provide an API with which
graphical applications can be written.  In one respect, however, X differs
radically from PM (and most other windowing systems for that matter) as it
allows applications to run remotely.  That is, the application can run on one
computer but the user can use it on another computer.  The two computers can
reside anywhere on a network, if necessary in different buildings or even in
different countries.

This is something that OS/2 and PM does not support:  an application must run
on the same computer where it is used.  Yes, applications can, of course, be
explicitly split into client and a server parts where the two parts can run on
different computers (e.g. database applications), but you cannot take an
arbitrary PM application and run it on one computer and use it on another.

Running PM applications remotely is what RMX is all about.

Why would you want to do that then?  Well:

   1. Remote execution allows you to run an application on the most appropriate
      (powerful) computer on the network, yet interact with the application
      where it is most convenient.
   2. Instead of being forced to have n powerful computers for n people, you
      can have 1 powerful computer, where resource hungry applications are run,
      and n - 1 less powerful (and much cheaper) computers that are used as
      display servers for remote applications and for running ordinary
      applications.
   3. Once OS/2 for PowerPC is available you can run applications on a PowerPC,
      yet use them on a cheap Intel.
   4. It offers a convenient way for monitoring other computers.
   5. It is simply a neat feature :-).

 To be honest, the list above is slightly vapour as RMX currently is on beta
 level and couldn't be used in a production environment.  Nevertheless, the
 functionality for providing the services in the list (except item 3 of course)
 is there.

 RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 3.3. RMX in Practice ΓòÉΓòÉΓòÉ

RMX in Practice

Ok, so what does remote execution mean in practice?  A PM application's
structure can schematically be pictured as:

Figure 1) Schematic picture of a PM application.

The application consists of application code that more or less frequently call
operating system and PM functions.  All user interaction is handled through
calls to PM.  If we for each call to PM instead...

   1. make a packet out of the function arguments,
   2. send the packet to another computer,
   3. on the other computer extract the arguments from the packet,
   4. execute the actual function,
   5. make a packet out of the returned value,
   6. send the packet back to the other computer,
   7. extract the returned value from the packet, and
   8. return the result back to the application

 ...the visual appearance and interaction of the application can be moved to
 another computer.

 Figure 2) Schematic picture of a RMX application.

 In practice, each PM call (i.e., a call to a Win or Gpi function) is replaced
 with the following pseudo code.  We ignore for the moment exactly how that
 replacing is done.

  ReturnType WinFunction(arguments)
  {
    Copy all arguments to a transfer buffer
    Send buffer to server
    Read buffer from server (this call blocks until there is something to read)
    Extract result
    Return result to caller
  }

 The arguments of the function is simply copied into a buffer and sent over a
 communications link to the server.  On the server the arguments are extracted
 and the actual function is executed.

  void winFunction()
  {
    Read buffer from client
    Extract arguments from buffer
    Call actual PM function
    Copy return value into buffer
    Send buffer to client
  }

 The server reads the raw data, converts it into arguments of proper type and
 calls the actual PM function.  Essentially it is a question of transparently
 turning local procedure calls (LPCs) into equivalent remote procedure calls
 (RPCs).  Seems rather trivial doesn't it?  In practice, however, there some
 rather interesting problems to be solved:

     How can the functions be replaced without a need for a recompilation or
      relink?
     It is not only the application that calls PM functions, PM calls window
      procedures of the application.
     PM often reads resources from the executable.  How should this be handled
      when the actual executable is in another computer?
     Arguments passed by value are trivial to handle, but what about pointers?

 I'll return to these questions in a later article.

 RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 3.4. Design Requirements ΓòÉΓòÉΓòÉ

Design Requirements

When I started designing RMX - which actually is a part of my Master's Thesis -
I made a list of requirements that would have to be fulfilled if RMX was ever
to become an product people would use.

No recompilations - if somebody would suggest to me, "Hey, if you write your
application according to these fancy guidelines, then you'll get this neat
remote execution feature," I wouldn't even look at the stuff.  Even a relink is
too much as it effectively means that only developers could use the product.
Hence, an absolute design requirement was that it should be possible to run any
executable remotely without a recompile or relink.  (An observant reader
notices that I don't rule out patching :-).

Localized cost - of course there is a performance cost involved when
applications are run remotely and LPCs are replaced with RPCs.  (However, this
applies only to threads that call PM; non-PM threads run at the full speed of
the CPU-server.  The remote execution and the speed of the display-server do
not influence them at all.)  That cost is acceptable as long as the added value
of remote execution in itself is bigger. However, it would be unacceptable if
you would have to pay for the remote execution mechanism also when you run the
application locally, i.e., when you run and use it on the same computer.

Any communications media - remote execution is ultimately a question of moving
data between a client and a server.  The entire remote execution mechanism can
be built so that it does not depend on the media or actual low-level data
transfer mechanism used.  Hence, RMX had to be designed so that the data
transfer mechanism can be replaced without a need for changes in RMX.

Optional security - remote execution opens a loophole in the security as it
allows remote applications to connect to a computer and start monitoring
keystrokes.  In many environments a lack of security is not an issue; in others
it would prevent RMX from being used.  The conclusion is that security is
needed, but it must be provided in such a way that different levels of security
can easily be supported.

Visual appearance - it should not be possible to detect any difference between
an application running remotely and an application running locally.

Simultaneous Use - it must be possible to run remote and local application
side-by-side.

So, those were some of the requirements I specified before I started designing
RMX.

RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 3.5. Example ΓòÉΓòÉΓòÉ

Example

In the following I'll show you a concrete example of how RMX is used.  The
basic requirement is two computers that are connected somehow.  This example
assumes that we are using a network that supports named pipes.

Although RMX essentially does not care what mechanism is used for transferring
data between the client and server computers, it has to be told what mechanism
to use.  That is done by specifying an environment variable:

set RMXCOMMS=RMXPIPE

The value of the variable should be the name of a DLL that provides certain
functionality (I'll tell exactly what in the next article).  That variable
usually needs to be set only once - in CONFIG.SYS - but it is quite possible to
specify on a case by case basis what communications DLL to use.

An application must be marked (patched) before it can be run remotely. This has
to be done only once, and it does not influence the application's normal use
(apart from the requirement that certain DLLs of RMX must be present), and if
need be the application can be unpatched.

rmxpatch -p -d app.exe

I'll explain the flags and describe exactly what RMXPATCH does in a later
article.

Then we have the question of how to start a remote application.  After all, it
will be running on a computer that may physically reside quite far from the
computer where we will use it.  For that purpose there is RMXSTRTR.EXE and
RMXSTART.EXE. RMXSTRTR.EXE is a daemon application whose only responsibility is
to start remote applications upon requests from RMXSTART.EXE.  Being a daemon
it is usually started when the CPU-server is booted.

detach rmxstrtr.exe

Before we can start a remote application that will appear on the display-server
we must start a server application that provides services to the remote
application.  This is also something that normally is done when the computer is
booted.

start pmserver.exe

Now everything is set and we can start the remote application.  Assume that
\\ODIN is the network name of the CPU-server and that \\LOKE is the name of the
display-server.

rmxstart \\LOKE \\ODIN app.exe

This command will start app.exe on the computer \\ODIN but the application will
appear on \\LOKE.  Note, in the normal case this last step is the only thing
that is needed in order to start a remote application.

RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 3.6. Conclusion ΓòÉΓòÉΓòÉ

Conclusion

Ok, so that was a brief introduction to RMX.  In the articles that follow I
will go a lot deeper and provide a lot more details.  As I haven't written
those articles yet, I don't know exactly what they will contain, but the
following list shows roughly what I will cover.

Low level transfer - as mentioned, the low-level transfer mechanism of data
between the remote application and the display server is completely outside
RMX.  In this article I will thoroughly describe the mechanism along with a
detailed description of the current implementation that relies on named pipes.
Based on this article it should be possible to write an implementation for
TCP/IP, for example.

Marking applications for remote execution - basically any 32-bit PM application
can be marked for remote execution.  In this article I will describe how it is
done.

Starting remote applications - RMXSTRTR.EXE and RMXSTART.EXE provide the means
for starting an application on a remote computer.  In this article I'll
describe exactly what they do and how they do it.

Protocol - when data is transferred between two processes a protocol is needed.
That is also the case in RMX.

Turning LPCs into RPCs. - basically remote execution is a question of turning
certain LPCs into equivalent RPCs.  In this article I will describe how that is
done for the OS/2 PM API.

Threads - quite a few PM program use threads and obviously they must be
supported as well.  How are tightly coupled threads in in two separate
processes managed?

Performance - replacing LPCs with RPCs means in the context of RMX that the
performance of the display updating will suffer.  Fortunately, there are
measures with which the perfomance penalty can be reduced.

Security - RMX offers a possibility for adding a certain level of security.  In
this article I will describe how a security DLL can be written.

The only thing I guarantee about this list is that the next article will be
about the low-level transfer.  Apart from that, the items on the list and their
order may change.

As I mentioned, I developed RMX as part of my Master's Thesis.  If you can't
wait for the articles, drop me a note and I'll mail the thesis to you. Being a
thesis it is more general than this article series will be, but on the other
hand it also contains material that I won't include in the articles.

If you want to give RMX a try, keep an eye on hobbes.nmsu.edu. I'll will upload
the first proper beta-release real-soon-now :-).  Drop me a note if you want me
to notify you when that happens.

RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4. /dev/EDM/BookReview ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 4.1. Introduction ΓòÉΓòÉΓòÉ

/dev/EDM2/BookReview

Written by Carsten Whimster

Introduction

/dev/EDM2/BookReview is a monthly column which focuses on development oriented
books and materials.  The column is from a beginning PM programmer, but
intermediate REXX programmer's eyes.  Pick up whichever book strikes your
fancy, and join the growing group of people following our PM programming
columns.  I will review books aimed at beginners for a while, and then move on
from there.

Please send me your comments and thoughts so that I can make this column as
good as possible.  All mail gets read and responded to.

Designing OS/2 Applications is not a normal programming book. In fact, it talks
very little about programming, and a lot about designing programs, as might be
expected from its title.  If that sounds a little cryptic, read on...

/dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.2. Errata ΓòÉΓòÉΓòÉ

Errata

This month is a month of corrections.  I obviously try to be accurate and fair,
but recently I made a couple of minor blunders:

In last month's review I criticized Charles Petzold's new book for using
"Windows graphics" in some of the figures.  Of course it wasn't Windows
graphics, but rather OS/2 1.x graphics which happen to look identical. This is
a hangover from the first version of the book.  One reader told me that the new
version is very similar to the old version, and that there is hardly any new
material, just some updates.  If you can live with this (which means little, if
any, 2.1+ material), then I still recommend this book for its thoroughness.

Even further back, I managed to miss the WPS coverage in Anthony Rudd's
Application Development Using OS/2 REXX.  When I looked closer, it actually
covered almost as much as the REXX Reference Summary Handbook, so I have
changed its rating in WPS from "No Coverage" to "Introductory Coverage", which
is now the same for both.  The handbook covers a little more, but it is less
tutorial, so they end up about the same.

Well, with that off my chest...

I have rearranged the Content Index in a more logical order, and created a new
table called SYSTEM AND DESIGN BOOKS to suit books like this one, and other
non-programming books for programmers.  At the moment, the first two tables are
near identical in layout, but that will change over time. In any case,
comparing programming books with design books doesn't make any sense, and the
separate tables reinforce that.

/dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.3. Designing OS/2 Applications ΓòÉΓòÉΓòÉ

Designing OS/2 Applications

Designing OS/2 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:

   1. OS/2 as an End-User Platform
   2. Why Program for OS/2?
   3. OS/2 as a Development Platform
   4. Good Programs Have Good Up-Front Design
   5. OS/2 Kernel Architecture
   6. Presentation Manager, Graphics, and the User Interface
   7. Features for Your Application
   8. Application Structure
   9. Block Design and Architecture
  10. Designing the User Interface
  11. Where's the Beef?
  12. The Development Environment
  13. Prototyping the User Interface
  14. Building the Core Functions
  15. Using Advanced Functions
  16. Non-English-Language Support
  17. Base Tuning
  18. Visual Tuning
  19. Testing Methodology
  20. Code Change
  21. Designing the Installation Program
  22. Appendix A: Summary and Conclusions
  23. Appendix B: Bibliography

 In addition to this layout, the chapters are divided into sections as follows:

   1. Why OS/2? - chapters 1 through 3
   2. Overall Application Design - chapters 4 through 8
   3. Use Building Blocks or Your App Will Crumble - chapters 9 through 11
   4. Making It Happen - chapters 12 through 16
   5. Performance - chapters 17 and 18
   6. Testing and Code Changes - chapters 19 and 20
   7. Installation Programs - chapter 21

 I will concentrate on the sections, rather than the chapters, since the
 divisions between the chapters are much fuzzier than in actual programming
 books.

 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.  We all know the advantages of pre-emptive
 multi-tasking, multi-threading, a flat 32-bit address space, device
 independence, the object-oriented interface (WPS), DDE, virtual memory,
 paging, swapping, drag-and-drop, and a consistent user interface (CUA).  These
 are all elaborated on.  In addition, the API is touted as an advantage, both
 with respect to power, and also with respect to the (theoretical) portability
 of it.  Third, the advantages of OS/2 as a development platform are outlined,
 and include crash protection (tm), multi-tasking, and debugging support.

 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.  Examples of poor design practices are listed,
 and their faults explained.  Proper design techniques are carefully explained.
 One funny quote which is a favorite of the author's is "There's never enough
 time to do it right the first time, but there's always time to do it over".
 This is so true!  It doesn't take long thinking about the various products on
 the market to come up with concrete examples of this.  Even large
 multi-platform companies with huge resources seem to think that if they
 release a suite of programs quickly, and then fix it later, it will gain a
 large, devoted user base.  Wrong!  Doing it wrong the first time loses a
 developer a lot of potential respect, which is replaced by suspicion and
 mistrust.  Finally, the 60% design/30% code/10% test rule is introduced, and
 the logic behind it is explained.

 Starting in chapter 5, an overview of the inner workings of OS/2 is given,
 beginning with the kernel, and proceeding through to the Presentation Manager,
 The GPI, and the WPS.  This section is important in that it gives those of us
 who don't yet own a copy of The Design of OS/2 an insight into what goes on
 behind the scenes.  Following that, there is a section which explains what
 features are available to programmers, on a purely conceptual level.  Again,
 this is very helpful, since it is hard to know what is available when you
 haven't done much OS/2 programming.  Then again, even if you had, there are
 enough additions from version to version that keeping up with all the new
 features would be difficult.  Each feature available is explained in terms of
 advantages and disadvantages, and intended use.

 Application structure is the next stop on the journey, with device
 independence featured prominently up front, closely followed by modular design
 and using threads.  Multi-process applications are also discussed, along with
 some reasons that you probably shouldn't use them, unless you can't do it any
 other way.  DLLs, code sharing, resource sharing, and synchronization are all
 stops along our merry way, and the chapter finishes with a mini lecture on
 upgradability, portability, and serviceability concerns.

 The next section 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.  The user interface is the next stop along the
 design path, and CUA, data presentation, and window controls are all lightly
 visited.  Dialogs are paid a slightly longer visit, application defaults and
 CASE tools are discussed.  The Workplace Shell is treated particularly well,
 as is fitting.  The various levels of integration with the WPS are discussed,
 and the ways of accomplishing them (in theoretical detail) are presented.  I
 particularly liked this chapter, and learned a lot about things that I only
 had a vague idea about before.  Core functions are discussed next, and
 modularization, memory management, device drivers, application layout, file
 system support, EXEs versus DLLs, INI files and multiprocess applications are
 all revisited in greater detail than last time.

 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.  Writing the code for the user interface is next,
 and the pros and cons of using separate threads to do things like painting
 your window are presented.  Prototyping the interface is also a good way to
 check the validity of your design, since only a little code needs to be
 written to allow "walking through" your application.  Self-verification steps
 are common in this book, and allow you to get a better feel for whether you
 are on the right track with your application design or not.  Multi-threading
 the interface is discussed in great depth at this point, and ways of keeping
 the user interface responsive are presented, while keeping the code
 manageable.

 The next chapter deals with setting up the core function of your program
 properly.  Again, multi-threading is discussed, and semaphores are
 re-introduced as one way of sharing resources safely.

 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.

 Critical sections are introduced next, as a still safer way to share
 resources.  The large expense of critical sections is explained, however,
 emphasizing that if other designs are possible, they should be pursued.

 The next topic is IPC.  Various mechanisms, such as queues, pipes, and shared
 memory are explored.  Data formats, file formats, and file system dependency
 is discussed, including LANs.  Advanced functions come next in the ASCII
 stream of the book.  Getting the basic user interface and functionality into
 code has been the priority so far, but now is the time to add the advanced
 features that you want your application to have.  It is good to do this long
 before adding the advanced functions, partly because of the reluctance to
 change something major after you have added lots of code.  As Reich points
 out, if you add the simple stuff first, changes are easier to make because
 they don't make for much longer development cycles. DDE, printing, fonts, and
 the help facility come under this heading. Non-English language support is
 another, frequently overlooked item on the long list of things to look for.
 It is very easy to do, when done right, and extremely tedious when done wrong.
 How you can do it right the first time is carefully explained.

 The next section 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.

 The penultimate section deals with testing and changing code.  These two
 chapters are short, sweet, and use common sense, 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.

 There is a brief summary following this, which concludes the book.

 /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.4. Summary ΓòÉΓòÉΓòÉ

Summary

Designing OS/2 Applications is a different kind of book than anything else I
have reviewed so far.  It is theoretical in nature, and avoids actual code as
much as possible.  Instead, it concentrates on teaching the proper design
principles needed to create a new OS/2 application.  As such, in many ways it
is much more valuable and important than a "mere" programming book, but it
sacrifices programming detail to do this.  If you have ever wanted to know how
to go about designing and creating an OS/2 application, get this book.  Once
you need to know about the nuts and bolts of programming, you'll have to look
elsewhere, however.

I like this book very much, yet there are a number of small areas that could be
addressed.

The few examples that are in the book are in C.  Much of the material is
inherently bound to C programming, as well.  For example, talking about the
message implementation in OS/2 doesn't make much sense in VX-REXX or PM-Cobol.
Because this inherent bias is there, I would like to see it be more explicit
and upfront.  The alternative would be to abstract the material away from C
even more than it is, but I think it would be more workable to simply state
that 99% of all OS/2 programming is done in C, and that therefore there will be
a C bias in the examples.  Even C++ programming is quite different, and many of
the topics covered in the book become irrelevant when programming in C++.

Some parts of the book have a vague feel to them, perhaps due to the fact that
the author tried to avoid a language bias.  Specifically, the earlier parts
read slowly, and there is a fair amount of repetition.  I do not mean that the
book is difficult or tedious to read, merely that it is sometimes slow going.
Tightening up the earlier parts might help a bit.

Of course, the semaphore and deadlock example should be reworded.

There are some OS/2 2.1+ features that warrant mentioning.  This book has been
around for a bit, but a newer book is currently being written, and hopefully
this information will be included there.

/dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.5. Books Reviewed ΓòÉΓòÉΓòÉ

Books Reviewed

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéBOOK                              ΓöéAUDIENCE    ΓöéMARKΓöéCOMMENTS                               Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéReal-World Programming for OS/2   ΓöéIntermediateΓöéB+  ΓöéLots of good code examples, but        Γöé
Γöé2.1, Blain, Delimon, and English, Γöéto Advanced Γöé    Γöésometimes it is too complex for        Γöé
ΓöéSAMS Publishing.  ISBN            ΓöéPM C        Γöé    Γöénovices. Accurate.  Well organized.    Γöé
Γöé0-672-30300-0.  US$40, CAN$50.    Γöéprogrammers Γöé    ΓöéThe index needs a little beefing up.   Γöé
Γöé                                  Γöé            Γöé    ΓöéGood, but not entirely complete how-to Γöé
Γöé                                  Γöé            Γöé    Γöéreference.  Good purchase.             Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéLearning to Program OS/2 2.0      ΓöéBeginning PMΓöéB-  ΓöéThis book can be both frustrating and  Γöé
ΓöéPresentation Manager by Example,  ΓöéC           Γöé    Γöévery rewarding.  It is not very large, Γöé
ΓöéKnight, Van Nostrand Reinhold.    ΓöéProgrammers Γöé    Γöéand a bit pricey, but has some         Γöé
ΓöéISBN 0-442-01292-6.  US$40,       Γöé            Γöé    Γöéexcellent chapters on certain beginningΓöé
ΓöéCAN$50.                           Γöé            Γöé    Γöétopics, such as messages, resources,   Γöé
Γöé                                  Γöé            Γöé    ΓöéIPF, and dialog boxes.  Strictly for   Γöé
Γöé                                  Γöé            Γöé    Γöébeginners.  This book has only one     Γöé
Γöé                                  Γöé            Γöé    Γöé(large) sample program!                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéWriting OS/2 2.1 Device Drivers inΓöéAdvanced C  ΓöéA-  ΓöéThe only thing a device driver         Γöé
ΓöéC, 2nd Edition, Mastrianni, Van   ΓöéProgrammers,Γöé    Γöéprogrammer would not find in here is   Γöé
ΓöéNostrand Reinhold.  ISBN          Γöéfamiliar    Γöé    Γöéhow to write SCSI, ADD, and IFS        Γöé
Γöé0-442-01729-4.  US$35, CAN$45.    Γöéwith        Γöé    Γöédrivers.  Most everything else is in   Γöé
Γöé                                  Γöéhardware    Γöé    Γöéhere, along with skeleton examples.  AnΓöé
Γöé                                  Γöéprogramming Γöé    Γöéoptional DevHlp library of C-callable  Γöé
Γöé                                  Γöé            Γöé    Γöéfunctions can be purchased by those whoΓöé
Γöé                                  Γöé            Γöé    Γöédon't have time to write their own.    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéOS/2 Presentation Manager GPI,    ΓöéIntermediateΓöéC+  ΓöéThis book needs updating for OS/2 2.x. Γöé
ΓöéWinn, Van Nostrand Reinhold. ISBN Γöéto advanced Γöé    ΓöéIt is a well-written in-depth coverage Γöé
Γöé0-442-00739-6.  US$35, CAN$45.    ΓöéPM C        Γöé    Γöéof the OS/2 way of programming for     Γöé
Γöé                                  Γöéprogrammers Γöé    Γöégraphics.  It is not an introductory PMΓöé
Γöé                                  Γöé            Γöé    Γöéor graphics programming book.  You     Γöé
Γöé                                  Γöé            Γöé    Γöéshould know the basics of PM           Γöé
Γöé                                  Γöé            Γöé    Γöéprogramming already.                   Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéThe Art of OS/2 2.1 C Programming,ΓöéBeginning   ΓöéB+  ΓöéThis is a great introductory PM        Γöé
ΓöéPanov, Salomon, and Panov,        ΓöéOS/2 and PM Γöé    Γöéprogramming book.  It covers basic OS/2Γöé
ΓöéWiley-QED.  ISBN 0-471-58802-4.   Γöéprogrammers Γöé    Γöéissues like threads before it jumps    Γöé
ΓöéUS$40, CAN$50.                    Γöé            Γöé    Γöéinto PM programming.  The coverage is  Γöé
Γöé                                  Γöé            Γöé    Γöéquite thourough, with just enough      Γöé
Γöé                                  Γöé            Γöé    Γöéreference material to make it useful   Γöé
Γöé                                  Γöé            Γöé    Γöéafter you read it through the first    Γöé
Γöé                                  Γöé            Γöé    Γöétime.  The upcoming revised edition    Γöé
Γöé                                  Γöé            Γöé    Γöéshould be a killer.                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéMastering OS/2 REXX, Gargiulo,    ΓöéIntermediateΓöéB   ΓöéThis book is very easy to understand.  Γöé
ΓöéWiley-QED.  ISBN 0-471-51901-4.   ΓöéOS/2 users  Γöé    ΓöéIf you program with any regularity,    Γöé
ΓöéUS$40, CAN$50.                    Γöéand         Γöé    Γöélook elsewhere, but if you need an     Γöé
Γöé                                  Γöébeginning   Γöé    Γöéeasily read, well-explained beginner's Γöé
Γöé                                  Γöéprogrammers Γöé    Γöébook, look no further.  Some more      Γöé
Γöé                                  Γöé            Γöé    Γöédetailed, and complex real-world       Γöé
Γöé                                  Γöé            Γöé    Γöéexamples might be useful as you learn  Γöé
Γöé                                  Γöé            Γöé    Γöéthe material.  Good coverage of REXX's Γöé
Γöé                                  Γöé            Γöé    Γöécapabilities.                          Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéREXX Reference Summary Handbook,  ΓöéBeginning toΓöéA   ΓöéThis little handbook is packed full of Γöé
ΓöéGoran, C F S Nevada.  ISBN        Γöéadvanced    Γöé    Γöéuseful information.  Includes chapters Γöé
Γöé0-9639854-1-8.  US$20, CAN$25     ΓöéREXX        Γöé    Γöéon both built-in and some popular      Γöé
Γöé                                  Γöéprogrammers Γöé    Γöécommercial libraries.  Well-written andΓöé
Γöé                                  Γöé            Γöé    Γöécomprehensively indexed.  A must for   Γöé
Γöé                                  Γöé            Γöé    ΓöéREXX programmers.                      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéApplication Development Using OS/2ΓöéIntermediateΓöéA-  ΓöéExcellent coverage of everything REXX, Γöé
ΓöéREXX, Rudd, Wiley-QED.  ISBN      Γöéto advanced Γöé    Γöéwith the occasional sparse section. It Γöé
Γöé0-471-60691-X.  US$40, CAN$50     ΓöéREXX        Γöé    Γöéis a decent reference book, and has    Γöé
Γöé                                  Γöéprogrammers Γöé    Γöéenough unusual material that it will   Γöé
Γöé                                  Γöé            Γöé    Γöéprobably find its way into many REXX   Γöé
Γöé                                  Γöé            Γöé    Γöéprogrammers' libraries.                Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéOS/2 Presentation Manager         ΓöéBeginning PMΓöéA-  ΓöéThis book has the most thorough        Γöé
ΓöéProgramming, Petzold, Ziff-Davis  ΓöéC           Γöé    Γöéintroduction to PM basics in any book IΓöé
ΓöéPress.  ISBN 1-56276-123-4.       Γöéprogrammers Γöé    Γöéhave read so far.  It leaves the field Γöé
ΓöéUS$30, CAN$42                     Γöé            Γöé    Γöéwide open for a more thorough advanced Γöé
Γöé                                  Γöé            Γöé    ΓöéPM book later.  Very well written, veryΓöé
Γöé                                  Γöé            Γöé    Γöéthorough, and very understandable. OnlyΓöé
Γöé                                  Γöé            Γöé    Γöéa lack of in-depth treatment of controlΓöé
Γöé                                  Γöé            Γöé    Γöéwindows and common dialog boxes keep itΓöé
Γöé                                  Γöé            Γöé    Γöéfrom being perfect.                    Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDesigning OS/2 Applications,      ΓöéAll         ΓöéA   ΓöéThis book is about design, and making  Γöé
ΓöéReich, John Wiley &  Sons. ISBN   Γöéprogrammers Γöé    Γöéintelligent decisions in this process. Γöé
Γöé0-471-58889-X.  US$35, CAN$45     Γöé            Γöé    ΓöéIt describes the OS/2 programming      Γöé
Γöé                                  Γöé            Γöé    Γöéenvironment well, and thus helps you   Γöé
Γöé                                  Γöé            Γöé    Γöémake the proper choices in designing   Γöé
Γöé                                  Γöé            Γöé    Γöéapplications.  Highly recommended to   Γöé
Γöé                                  Γöé            Γöé    Γöéanyone creating more than just         Γöé
Γöé                                  Γöé            Γöé    Γöécommand-line tools and very small      Γöé
Γöé                                  Γöé            Γöé    Γöéprograms.                              Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

This table contains all books I have reviewed, so that you can find what you
are looking for at a glance.  I will be careful to rate books fairly.  If I
feel a need to adjust ratings, I will adjust all of them at the same time, and
write a note explaining why I felt this necessary.  Please note that books
aimed at different audiences should only be compared with great care, if at
all.  I intend to concentrate on the strong points of the books I review, but I
will point out any weaknesses in a constructive manner.

LEGEND:

BOOK:  The name of the book, author(s), publishing company, ISBN, and
approximate price.

AUDIENCE:  This is a description of the audience I think the book targets best.
This is not intended as gospel, just a guideline for people not familiar with
the book.

MARK:  My opinion of the success of the book's presentation, and how well it
targets its audience.  Technical content, accuracy, organization, readability,
and quality of index all weigh heavily here, but the single most important item
is how well the book covers what it says it covers.  Many books try to cover
too much, and get a lower mark as a result.

ΓöîΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéA+ ΓöéGround-breaking, all-around outstanding book                               Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéA  ΓöéExcellent book.  This is what I want to see happen a lot                   Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéA- ΓöéExcellent book with minor flaws                                            Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB+ ΓöéVery good book with minor flaws or omissions                               Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB  ΓöéGood book with some flaws and omissions                                    Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéB- ΓöéGood book, but in need of improvement                                      Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC+ ΓöéMediocre book with some potential, but in need of some updating            Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC  ΓöéMediocre book with some good sections, but badly in need of fixing         Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéC- ΓöéMediocre book, little good material, desperately in need of an overhaul    Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéD  ΓöéDon't buy this book unless you need it, and nothing else exists            Γöé
Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéF  ΓöéDon't buy this book.  Period                                               Γöé
ΓööΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

COMMENTS:  This is a very brief summary of the review proper.

/dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.6. Content Index ΓòÉΓòÉΓòÉ

Content Index

This Content Index is designed to let you find the book that covers the topics
you need to learn about.  It will eventually have a lot of categories, with
each book being rated along each row.  These tables will be quite large, and
will continually grow, so please give me your feedback regarding what
categories you would like to see, and which you don't.  It may take me a while
to flesh them out, so have a little patience.

Note:  books which cover the same material can look similar in this table, but
be different in real life.  The style of a book, for example, can not be seen
from a quick table, so make sure that you follow up by reading the reviews of
the books you find here.  Finally, be sure that the books you are comparing are
aimed at the same audiences.

PM BOOKS:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéBOOK ΓöéMARK ΓöéKernel ΓöéDevice ΓöéVIO andΓöéPM     ΓöéGPI    ΓöéFonts  ΓöéPrint  Γöé
Γöé     Γöé     ΓöéBasics ΓöéDriver ΓöéAVIO   ΓöéIntro  Γöé       Γöé       Γöé       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéRWP  ΓöéB+   Γöé2      Γöé0      Γöé0      Γöé4      Γöé4      Γöé4      Γöé3      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPME  ΓöéB-   Γöé1      Γöé0      Γöé0      Γöé2      Γöé2      Γöé2      Γöé0      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéODD  ΓöéA    Γöé0      Γöé5      Γöé0      Γöé0      Γöé1      Γöé0      Γöé1      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéGPI  ΓöéC+   Γöé0      Γöé0      Γöé0      Γöé0      Γöé5      Γöé2      Γöé3      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéTAO  ΓöéB+   Γöé3      Γöé2      Γöé1      Γöé4      Γöé1      Γöé2      Γöé0      Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéPMP  ΓöéA-   Γöé1      Γöé0      Γöé1      Γöé5      Γöé3      Γöé4      Γöé2      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

SYSTEM AND DESIGN BOOKS:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéBOOK ΓöéMARK ΓöéKernel ΓöéDevice ΓöéVIO andΓöéPM     ΓöéThreadsΓöéGPI    ΓöéFonts  ΓöéPrint  Γöé
Γöé     Γöé     Γöé       ΓöéDriver ΓöéAVIO   Γöé       Γöé       Γöé       Γöé       Γöé       Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDOA  ΓöéA    Γöé4      Γöé4      Γöé2      Γöé4      Γöé5      Γöé3      Γöé2      Γöé3      Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

REXX BOOKS:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéBOOK ΓöéMARK ΓöéREXX     ΓöéWPS      ΓöéReferenceΓöé
Γöé     Γöé     ΓöéIntro    Γöé         Γöé         Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéMOR  ΓöéB    Γöé4        Γöé0        Γöé2        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéRSH  ΓöéA    Γöé1        Γöé2        Γöé5        Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéADO  ΓöéA-   Γöé3        Γöé2        Γöé4        Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

BOOK LEGEND:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
ΓöéReal-World Programming for OS/2 2.1                                ΓöéRWP  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéLearning to Program OS/2 2.0 Presentation Manager by Example       ΓöéPME  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéWriting OS/2 2.1 Device Drivers in C, 2nd Edition                  ΓöéODD  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéOS/2 Presentation Manager GPI                                      ΓöéGPI  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéThe Art of OS/2 2.1 C Programming                                  ΓöéTAO  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéMastering OS/2 REXX                                                ΓöéMOR  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéREXX Reference Summary Handbook                                    ΓöéRSH  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéApplication Development Using OS/2 REXX                            ΓöéADO  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéOS/2 Presentation Manager Programming                              ΓöéPMP  Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
ΓöéDesigning OS/2 Applications                                        ΓöéDOA  Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

RATINGS LEGEND:

ΓöîΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé0ΓöéNo coverage           Γöé
Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé1ΓöéVery light coverage   Γöé
Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé2ΓöéIntroductory coverage Γöé
Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé3ΓöéGood Coverage         Γöé
Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé4ΓöéIn-depth coverage     Γöé
Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé5ΓöéAuthoritative         Γöé
ΓööΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

/dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 4.7. Coming Up ΓòÉΓòÉΓòÉ

Coming Up

I am running a little low on books at the moment, but there is relief in sight.
Next month I may be looking at OS/2 Presentation Manager GPI, 2nd edition,
Winn.  The following are the books I intend to review, in no particular order.

     OS/2 Presentation Manager GPI, 2nd edition, Winn
     OS/2 Unleashed, Moskowitz and Kerr
     The Design of OS/2, 2nd Edititon, Kogan and Deitel
     Designing High Powered OS/2 Applications, Reich (tentative title)

 I am considering reviewing the IBM OS/2 Redbooks, since they are readily and
 cheaply available, and look like good reference.

 If anyone has a book they want to see reviewed, I will be happy to oblige.
 Just mail me and tell me.  Publishers can send me books at the address on my
 personal page at the end of the magazine, and I will review all OS/2
 development-related and advanced user books I receive.

 /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 5. C++ Corner ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 5.1. Introduction ΓòÉΓòÉΓòÉ

C++ Corner

Written by Gordon Zeglinski

Introduction

Having a large collection of C++ objects, I was motivated to see if and how I
could use these objects within a SOM object.  To keep things nice and familiar,
let's use the profile (INI) file manipulation objects as our test case.

C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 5.2. Using C++ Objects in SOM ΓòÉΓòÉΓòÉ

Using C++ Objects in SOM

In the second SOM article, we compared SOM and C++ versions of objects designed
to manipulate profile files.  In each of these objects we went to the OS/2 API
to access the profile file.  This time, the SOM object will use the C++ object
to manipulate the profile file.

The hardest part of this task is determining how to define things in a manner
that SOM will accept.  Utilizing structures from other languages in SOM seems
somewhat cumbersome to me.  Pointer types are not supported by CORBA, which
makes sense given the cross platform nature of CORBA.  Ideally, we want some
way of storing a pointer to the instance of the C++ object within our SOM
object.  Recall that in the IDL file, when you declare an instance of a SOM
object within another object, that instance is accessed through a pointer in
the C/C++ bindings.  Also in SOM, you can declare an object "type"  without
defining it's body.  What if we declared an object type and then later included
C++ headers that defined a C++ object as the formentioned "object type"?

Using this idea, we create the following IDL file.

interface ProfileFile;

interface SOM_CPPini : SOMObject
{
   typedef unsigned long ULONG;
   typedef sequence<char> buffType;

   void OpenFile(in string FileName);
   ULONG GetError();

   unsigned long GetHandle();
   void SetHandle(in unsigned long H);

   void  WriteString(in string App,in string Key, in string String);
         // write a string

   void  WriteData(in string App, in string Key,in buffType Buff,in ULONG BLen);
         // write the Buffer

   void  WriteInt(in string App,in string Key,in long Num);
         // write an "int"

   ULONG GetDataSize(in string App,in string Key);
         // return the lenght of the data

   void  GetData(in string App,in string Key,in buffType Buff, inout ULONG BufMax);
         // return the data in Buff

   ULONG GetString(in string App,in string Key,in buffType Buff,in ULONG BufMax, \
            in string DefArg);
         // return the String in Buff, defaults to DefArg if App/Key not present

   ULONG GetStringNoDef(in string App,in string Key,in buffType Buff,in ULONG BufMax);
         // return the String in Buff

   long  GetInt(in string App,in string Key,in long DefArg);
         // return the "int" in App/Key or the DefArg if App/Key not present

   long  GetIntNoDef(in string App,in string Key);
         // return the "int" in App/Key

#ifdef __SOMIDL__
implementation
{
    ProfileFile INIFile;

    releaseorder: GetHandle,SetHandle,GetError,OpenFile, \
                  WriteString,WriteData,WriteInt,GetDataSize,GetData,GetString,GetStringNoDef, \
                  GetInt,GetIntNoDef;

    callstyle=oidl;
    filestem = somcpp;
    somInit: override;  // initialize instance variables to 0
    somUninit: override; // just for fun

    passthru C_xh_after=   "#define INCL_WINSHELLDATA" \
                           "#include <os2.h>" \
                           "#include \"iniflobj.h\"";


};
#endif /* __SOMIDL__ */
};

The line interface ProfileFile; declares a "SOM object" with the same name as
the "C++ Object" which manipulates the profile files.  This object name is then
used within the SOM object definition to declare an instance of ProfileFile.
The passthru section of the SOM object definition, is used to include the C++
header files that declare the C++ object, ProfileFile.  The C++ SOM bindings
allow SOM and C++ objects to be intermixed without any major syntax
differences.  Following is the source code for MAIN.CPP.

void main(){
   int i;

   SOM_CPPini *Prf=new SOM_CPPini;

   Prf->OpenFile("Test.ini");

   Prf->WriteInt("App","Key",10);
   i=Prf->GetIntNoDef("App","Key");

   printf("i= %i\r\n",i);

   delete Prf;
}

The new operator is used to create an instance of the SOM object, SOM_CPPini.
Thereafter, the -> operator is used to access its member functions.  Following
is a snippet of code from the file SOMCPP.CPP.

SOM_Scope void  SOMLINK OpenFile(SOM_CPPini *somSelf, string FileName)
{
    SOM_CPPiniData *somThis = SOM_CPPiniGetData(somSelf);
    SOM_CPPiniMethodDebug("SOM_CPPini","OpenFile");

   if(somThis->INIFile)
      delete somThis->INIFile;

   somThis->INIFile=new ProfileFile(FileName,0);

}

SOM_Scope SOM_CPPini_ULONG  SOMLINK GetError(SOM_CPPini *somSelf)
{
    SOM_CPPiniData *somThis = SOM_CPPiniGetData(somSelf);
    SOM_CPPiniMethodDebug("SOM_CPPini","GetError");

    /* Return statement to be customized: */
    { SOM_CPPini_ULONG retVal;
      if(somThis->INIFile)
         retVal=somThis->INIFile->GetError();
      else
         retVal=1;

      return (retVal); }
}

Remember that somThis->INIFile is a pointer to an instance of a C++ object.
Outside of the new ProfileFile(FileName,0); statement, the instantizing the C++
and SOM objects is the same.  This difference is due to the different way SOM
and C++ handle constructors. Methods are called using the same syntax.  This
allows for a fairly consistent style when mixing C++ and SOM objects.

C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 5.3. Wrapping Things Up ΓòÉΓòÉΓòÉ

Wrapping Things Up

Although a fairly simple example was presented here, we have seen that C++ and
SOM objects can be intermixed within a program and still maintain good
readability.  C++ objects can be used as data members of SOM objects to provide
lower level support for the SOM methods.  This type of interoperability allows
one to exploit each OOP model for it's unique features.  C++ is still faster
than SOM, but SOM provides a much richer environment.  In future articles, we
will look at DSOM and the new 2.1 SOM toolkit.

C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 6. Introduction to PM Programming ΓòÉΓòÉΓòÉ


ΓòÉΓòÉΓòÉ 6.1. Introduction ΓòÉΓòÉΓòÉ

Introduction to PM Programming

Written by Larry Salomon, Jr.

Introduction

The purpose of this column is to provide the readers out there who are not
familiar with PM application development the information necessary to satisfy
their curiosity, educate themselves, and give them an advantage over the
documentation supplied by IBM.  Of course, much of this stuff could probably be
found in one of the many books out there, but the problem with books in general
is that they don't answer the questions you have after you read the book the
first time through.

I will gladly entertain feedback from the readers about what was "glossed over"
or what was detailed well, what tangential topics need to be covered and what
superfluous crap should have been removed.  This feedback is essential in
guaranteeing that you get what you pay for.  <grin>

It should be said that you must not depend solely on this column to teach you
how to develop PM applications; instead, this should be viewed as a supplement
to your other information storehouses (books, the network conferences, etc.).
Because this column must take a general approach, there will be some topics
that you would like to see discussed that really do not belong here.  Specific
questions can be directed to me via email and I will do my best to answer them
in a timely fashion.

Last Month

Last month, we began looking at the WC_LISTBOX class.  This month, we will take
a good look at the ownerdraw capabilities of this control class.

Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 6.2. A Message For You, Sir ΓòÉΓòÉΓòÉ

A Message For You, Sir

Each month before I write the next installment of this column, I re-read what I
wrote the prior month to discover what I have covered in order to determine in
what direction I should continue.  As I read last month's column, it became
apparent that the message reference which I capitulated each month is nothing
more than a rehash of what's available in many sources, including the on-line
programming references and many books.  I would like to discontinue my
inclusion of this information, given this enlightening of mine, unless the
teeming masses tell me that I should do otherwise.  Any feedback on this would
be appreciated.

Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 6.3. This Isn't Picasso ΓòÉΓòÉΓòÉ

This Isn't Picasso

But ownerdraw listboxes give you quite an opportunity to do some interesting
things.  For the original LaMail product from IBM, I wrote a LaGrep utility
which searched mail folders for text.  The found text was displayed in a
listbox in a different color than the rest. Additionally, the configuration
options allowed to you change the color that the text was displaying using, and
the color selection was displayed in a listbox with the name of the color next
to it.  Both of these are perfectly valid, real-world examples of ownerdraw
listboxes, and while there might be other window classes better suited for
these tasks, knowing how the ownerdraw capabilities work is a useful asset to
have tucked in your cap.

The ownerdraw architecture with regard to listboxes is represented by two
messages, which - incidentally - are used in ownerdraw menuitems in a very
similar fashion.  These messages are the WM_MEASUREITEM and WM_DRAWITEM and
their purpose is just as their names suggest.  The former message is sent,
usually upon the creation of the listbox, to determine the maximum height and
(if LS_HORZSCROLL) maximum width of the items to be displayed.  The result is
returned to the listbox as MRFROM2SHORT(height,width).  The latter message is
where all of the work is done and is sent whenever an item needs to be redrawn.
PVOIDFROMMP(mpParm2) points to an OWNERITEM structure, but you won't find its
definition in the listbox section of PMWIN.H.  You have to look in the menu
section to find it, which is the following:

typedef struct _OWNERITEM {
   HWND hwnd;
   HPS hps;
   ULONG fsState;
   ULONG fsAttribute;
   ULONG fsStateOld;
   ULONG fsAttributeOld;
   RECTL rclItem;
   LONG idItem;
   ULONG hItem;
} OWNERITEM, *POWNERITEM

hwnd is the handle of the control.  hps is the handle to the presentation space
which must be used for drawing.  fsState and fsStateOld are, when the structure
refers to an ownerdraw listbox, BOOLs which are TRUE if the item is selected
and FALSE otherwise (fsStateOld is the selection state of the item the last
time it was drawn).  fsAttribute and fsAttributeOld are not used when dealing
with ownerdraw listboxes. rclItem is the bounding rectangle of the item to be
drawn. idItem is the index of the item to be drawn.  hItem is the item handle,
if set.

It needs to be noted that, if the listbox is ownerdraw, PM will not do anything
on your behalf except paint the highlight state of the item to be drawn.  It
does this using an XOR operation only if fsState and fsStateOld are different.
There is no way to change this unless you know that the OWNERITEM structure is
what the listbox checks upon return from this message when it determines if it
needs to highlight the item or not.  So, if you set fsState and fsStateOld to
the same value before returning, PM will not do anything at all.

The nice thing about the first sentence in the last paragraph is that PM
doesn't even look at the item text for you.  Thus, you could interpret the text
in a different way that would normally be done - for LaGrep, I changed the
color by putting a tab character in the text followed by a BYTE which was an
index into an array of CLR_* constants.  When I painted the control, I did not
draw this special sequence but used it to control the drawing.

The possibilities are endless and are only limited by your imagination.

Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 6.4. API of the Month Club ΓòÉΓòÉΓòÉ

API of the Month Club

Our API of the month is the one that the listbox uses to XOR the highlight of
an item.

(BOOL)WinInvertRect(HPS hpsWnd,PRECTL prclRect);

hpsWnd is the handle to the HPS to invert within. prclRect points to the
rectangle specifying the area to be inverted.  Inversion here refers to the
inversion of the colors within the rectangle.  Thus, black becomes white, white
becomes black, etc.

Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 6.5. Next Month ΓòÉΓòÉΓòÉ

Next Month

I need to get upon my soapbox for a moment.

As I looked through the past issues to see where this column has gone already,
in order to determine what shall be discussed next, I saw that, much to my
embarrassment, the listbox window class has already been discussed. Yet, this
is the third month in my second treatment of the topic and I never would have
known because the silence from my audience is deafening.  The embarrassment is
not what I am worried about; I am instead concerned about providing a quality
column, yet no one bothered to tell me that I was simply rehashing a topic that
was discussed just a few months prior.

Please give me feedback!  How else can I say it?  I need to know what you
think, where we should go next, etc.  Since I have always considered the
button, entryfield, and listbox classes to be the "simple" classes, it is more
important now because I need to know what class should be discussed next.
Should it be the menu, or the static?  Should it be the scrollbar, or the
titlebar?  Please let me know; this humble request alone I make.

Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7. Contributors to this Issue ΓòÉΓòÉΓòÉ

Are You a Potential Author?

We are always looking for (new) authors.  If you have a topic about which you
would like to write, send a brief description of the topic electronically to
any of the editors, whose addresses are listed below, by the 15th of the month
before the month in which your article will appear.  This alerts us that you
will be sending an article so that we can plan the issue layout accordingly.
After you have done this, get the latest copy of the Article Submission
Guidelines from ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory.
(The file is artsub.zip.)  The completed text of your article should be sent to
us no later than five days prior to the last day of the month; any articles
received after that time may be pushed to the next issue.

The editors can be reached at the following email addresses:

     Larry Salomon - [e-mail] (Internet).
     Carsten Whimster - [e-mail] (Internet).

 The following people contributed to this issue in one form or another (in
 alphabetical order):

     Larry Salomon, Jr.
     Carsten Whimster
     Johan Wikman
     Gordon Zeglinski
     Network distributors

 Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7.1. Larry Salomon, Jr. ΓòÉΓòÉΓòÉ

Larry Salomon, Jr.

Larry Salomon, Jr. wrote his first Presentation Manager application for OS/2
version 1.1 in 1989.  Since that time, he has written numerous VIO and PM
applications, including the Scramble applet included with OS/2 and the
I-Brow/Magnify/Screen Capture trio being distributed by IBM with the
Professional Developers Kit CD-ROM.  Currently, he works for Cheyenne Software
in Roslyn, New York and resides in Bellerose, New York with his wife Lisa.

Larry can be reached electronically via the Internet at [e-mail].

Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7.2. Carsten Whimster ΓòÉΓòÉΓòÉ

Carsten Whimster

Carsten is an undergraduate Computer Science student at the University of
Waterloo.  He is currently in third year, and is enjoying it immensely.  He
uses Watcom C/C++ 10.0 and Watcom VX-REXX 2.0b.

Carsten is the author of some commandline utilities and POV-Panel/2, a popular
shareware dashboard-like front-end for the POV-Ray 2.x compilers. POV-Panel/2
can be found on ftp-os2.cdrom.com in pub/os2/32bit/graphics and some of the
other major OS/2 ftp sites.  He is also a TEAM-OS/2 member, and has adopted a
little computer store called The Data Store in Waterloo, Ontario.

You may reach Carsten...

...via email:

[e-mail] - Internet

...Web homepage (I am just setting it up, so it may or may not be on-line):

http://www.undergrad.math.uwaterloo.ca/~bcrwhims  - WWW

...via snail mail (notice the changed address):

Carsten Whimster
318A Spruce Street
Waterloo, Ontario
Canada
N2L 3M7

Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7.3. Johan Wikman ΓòÉΓòÉΓòÉ

Johan Wikman

Johan Wikman received his Master's degree in Computer Science with a thesis
"Adding remote execution capability to operating systems".  He has been
programming for OS/2, using C++, ever since 1990.

Currently he works for Nokia Telecommunications where he takes part in a
project that developes network management software in a Unix environment.  In
his sparetime he continues working on RMX-OS2, a system that provides remote
execution for OS/2.

Johan can be reached electronically via the Internet at
[e-mail], or via ordinary mail:

Johan Wikman
Smedjeviksvagen 23 B 22
FI-00200 Helsinki
FINLAND

Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7.4. Gordon Zeglinski ΓòÉΓòÉΓòÉ

Gordon Zeglinski

Gordon Zeglinski is a freelance programmer/consultant who received his Master's
degree in Mechanical Engineering with a thesis on C++ sparse matrix objects.
He has been programming in C++ for 6 years and also has a strong background in
FORTRAN.  He started developing OS/2 applications with version 2.0 .

His current projects include a client/server communications program that
utilitizes OS/2's features which has entered beta testing.  Additionally, he is
involved in the development of a "real-time" automated vehicle based on OS/2
and using C++ in which he does device driver development and designs the
applications that comprise the control logic and user interface.

He can be reached via the Internet at [e-mail].

Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 7.5. Network distributors ΓòÉΓòÉΓòÉ

Network Distributors

These people are part of our distribution system to provide EDM/2 on networks
other than the Internet.  Their help to provide access to this magazine for
others is voluntary and we appreciate them a lot!

     Paul Hethmon ([e-mail]) - Compuserve
     Gess Shankar ([e-mail]) - Internet
     Jason B. Tiller ([e-mail]) - America On-line
     David Singer ([e-mail]) - IBM Internal
     Andre Asselin (ASSELIN AT RALVM12) - IBM Internal

 If you would like to become a "network distributor", be sure to contact the
 editors so that we can give you the credit you deserve!

 Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1


ΓòÉΓòÉΓòÉ 8. How Do I Get EDM/2? ΓòÉΓòÉΓòÉ

How Do I Get EDM/2?

EDM/2 can be obtained in any of the following ways:

On the Internet

     All back issues are available via anonymous FTP from the following sites:
        -  ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory.
        -  ftp.luth.se in the /pub/os2/programming/newsletter directory.
        -  generalhq.pc.cc.cmu.edu in the /pub/newsletters/edm2 directory.
     The EDM/2 mailing list.  Send an empty message to [e-mail]
      to receive a file containing (among other things) instructions for
      subscribing to EDM/2.  This is a UUCP connection, so be patient please.
     IBM's external gopher/WWW server in Almaden. The address is
      index.almaden.ibm.com and it is in the "Non-IBM-Originated" submenu of
      the "OS/2 Information" menu; the URL is
      "gopher://index.almaden.ibm.com/1nonibm/os2nonib.70".

 On Compuserve

 All back issues are available in the OS/2 Developers Forum 2.

 IBM Internal

     IBM's internal gopher/WWW server in Almaden. The address is
      n6tfx.almaden.ibm.com and it is in the "Non-IBM-Originated Files" menu;
      the URL is "gopher://n6tfx.almaden.ibm.com/1!!nonibm/nonibm.70".
     IBM's REQUEST command on all internal VM systems.  Enter the VM command
      REQUEST LIST FROM ASSELIN AT RALVM12 and a list of the requestable
      packages will be sent to you; in this list are the names of the packages
      containing the EDM/2 issues.

 How do I Get EDM/2? - EDM/2 - Jan 1995 - Volume 3, Issue 1