home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 32 Periodic / 32-Periodic.zip / edmi3-1.zip / EDMI3-1.INF (.txt) < prev    next >
OS/2 Help File  |  1995-01-05  |  185KB  |  1,791 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. Jan 1995 Title Page ΓòÉΓòÉΓòÉ
  3.  
  4.                                       EDM/2
  5.                   The Electronic Developer's Magazine for OS/2
  6.                    Portions copyright (c) by Larry Salomon Jr.
  7.                                 Volume 3, issue 1
  8.  
  9. New Directions 
  10.  
  11. Merry Christmas, Happy New Year, etc. to each of you out there in net-land. 
  12. This issue marks the beginning of a new year, and with a new year comes new 
  13. directions.  From the magazine's perspective, many new directions will be 
  14. explored, beginning with this issue - what I have written, including what you 
  15. are reading now, I have written using a word processor. It has been decided 
  16. that one of the directives for 1995 is to make it easier for potential authors 
  17. to disseminate the information that they have learned and wish to share.  Since 
  18. writing in .IPF is quite daunting, this has often dissuaded people from 
  19. submitting an article, and this hurts the OS/2 community.  Additionally, it 
  20. never was easy to spell-check an .IPF file.  <grin>  Since many word processors 
  21. now support the rich-text format (or RTF), this will now become the requested 
  22. file format for new submissions.  Please see the new Article Submission 
  23. Guidelines, which has been rewritten and uploaded to hobbes.nmsu.edu, for more 
  24. information. 
  25.  
  26. Another directive for the magazine is to change the file format of the 
  27. magazine.  It only makes sense that, in order to increase the size of our 
  28. audience, the quickest way is to change the format to that which can be read 
  29. with viewers that are available on multiple platforms.  Since there are many 
  30. "arm-chair" programmers who do not develop OS/2 applications as part of their 
  31. daily routine, it would be nice if they could read the magazine on the machine 
  32. they use the most, whether that may be running DOS, Windows, or UNIX.  We will 
  33. keep you posted on this issue as we receive more information. 
  34.  
  35. You'd Be Surprised... 
  36.  
  37. at how many people thought the Title Page had nothing but legal drivel on it. 
  38. This came to light when I complained that only one person had voted for the 
  39. Reader's Choice Awards during the first three weeks following the release of 
  40. last issue; many people responded with "when was this mentioned?"  To prevent 
  41. this from happening in the future, we have moved the legal portions of the 
  42. magazine to the end of this page so that more people will read this section of 
  43. the magazine.  After all, we wouldn't want you to miss all of the humor. 
  44. <grin> 
  45.  
  46. And Speaking of Voting... 
  47.  
  48. I am pleasantly surprised at the response my complaint generated.  Since that 
  49. time, I have received many more than the fourteen I received last year. It 
  50. still isn't a flood, but I'll take what I can get.  Still, you have until 
  51. January 15 to send in your three votes for the best articles of the year 1994. 
  52. See last issue's Title Page for a complete list of the articles eligible for 
  53. this award. 
  54.  
  55. It's really funny what some of the votes were for.  I'm not trying to pick on 
  56. anyone, but receiving votes for software and books that weren't even mentioned 
  57. in the magazine, much less part of the magazine (for which your votes should 
  58. be) gave me quite a chuckle.  I will be including those in the results so that 
  59. you, too, can have a grin or two. 
  60.  
  61. Welcoming Another Network 
  62.  
  63. We would like to officially announce the arrival of EDM/2 on America On-line 
  64. (AOL).  Our network distributor for AOL approached us with the desire to do 
  65. this for us and we are glad to have Jason B. Tiller (PeerGynt@aol.com) on the 
  66. EDM/2 team!  Also, a Scooby Snack goes to David Pedigo who pointed out that, on 
  67. the site generalhq.pc.cc.cmu.edu, the directory name should be 
  68. /pub/NewsLetters/EDM2 and not /pub/newsletters/edm2 as was stated in previous 
  69. issues. 
  70.  
  71. Reader Feedback 
  72.  
  73. One reader, Tarjei T. Jensen, wrote in regarding the Coding for Dollars - Copy 
  74. Protection and Prevention article that appeared in last issue.  He suggested 
  75. that, for simultaneous access of an application, another scheme called NetBIOS 
  76. Name Defense can be used for tracking the number of licenses.  While his 
  77. explanation was detailed, I am a bungling idiot when it comes to anything 
  78. dealing with communications.  I invite Tarjei to write a "followup" article to 
  79. mine explaining this and the other methods that he mentioned in his letter. 
  80.  
  81. Michael Shillingford also wrote in and brought up a very good point that, if 
  82. you're bored with the gray on black coloring of your command prompt, you can 
  83. use ANSI escape sequences in your prompt string to liven things up. 
  84. Unfortunately, these must go in a .CMD file, which you can execute during the 
  85. opening of the command window using the /K parameter of CMD.EXE. The escape 
  86. sequence is $e[nm, where n is a color from the following list: 
  87.  
  88.  Value               Color 
  89.  30                  Dark gray 
  90.  31                  Red 
  91.  32                  Green 
  92.  33                  Yellow 
  93.  34                  Blue 
  94.  35                  Pink 
  95.  36                  Cyan 
  96.  37                  White 
  97.  
  98.  The background color may be changed also by using the following numbers: 
  99.  
  100.  Value               Color 
  101.  40                  Black 
  102.  41                  Red 
  103.  42                  Green 
  104.  43                  Brown 
  105.  44                  Blue 
  106.  45                  Purple 
  107.  46                  Dark cyan 
  108.  47                  Pale gray 
  109.  
  110.  Finally, using the number 0 indicates that foreground colors are to be from 
  111.  the low-intensity set, while using the number 1 specifies the high-intensity 
  112.  set. 
  113.  
  114.  If you don't want to set the prompt command twice, you may separate the 
  115.  numbers by a semicolon; the entire command ends with a lower-case m, e.g. 
  116.  prompt $e[37;40m[$p] sets the prompt to white on black with the directory name 
  117.  in brackets. 
  118.  
  119.  Is IBM Opening Up? 
  120.  
  121.  It would seem so.  After a discussion on comp.os.os2.programmer.misc about the 
  122.  undocumented APIs used in OS/2, I received from a friend who received from a 
  123.  friend (etc.  ad nauseum) the function prologues for the Session Manager APIs. 
  124.  It really doesn't help much more than any of the Programmer Reference guides 
  125.  that have been in the toolkits over the years, but it is better than what is 
  126.  readily available to most of the public. 
  127.  
  128.  Finally 
  129.  
  130.  Speaking of the Programmer's Toolkit, I received my copy of the DevCon 5, 
  131.  Special Edition CD-ROM during the last week of December, which I used to 
  132.  install the Warp toolkit.  Noted changes are the inclusion of the 
  133.  bi-directional interface and the MMPM/2 toolkit in the "base" toolkit. Also, 
  134.  while perusing through the folder, I was quite pleased to find the on-line 
  135.  documentation completely redone.  Granted, I was only browsing things and 
  136.  wasn't actually trying to use them, but it seems that they are actually usable 
  137.  now for more than just a reference guide.  Additionally, IBM has included new 
  138.  on-line documents such as Multimedia Application Programming Guide, Multimedia 
  139.  Subsystem Programming Guide, OS/2 Bi-directional Language Support Development 
  140.  Guide, and Workplace Shell Programming Guide.  Many, many thanks to IBM for 
  141.  this much-needed improvement of the toolkit. 
  142.  
  143.  Copyright Notice and Other Stuff 
  144.  
  145.  The Editor-in-Chief of this electronic magazine is Larry Salomon, Jr. 
  146.  
  147.  Portions of EDM/2 are copyrighted by the editors.  This publication may be 
  148.  freely distributed in electronic form provided that all parts are present in 
  149.  their original unmodified form.  A reasonable fee may be charged for the 
  150.  physical act of distribution; no fee may be charged for the publication 
  151.  itself. 
  152.  
  153.  All articles are copyrighted by their authors. No part of any article may be 
  154.  reproduced without permission from the original author. 
  155.  
  156.  Neither this publication nor the editors are affiliated with International 
  157.  Business Machines Corporation. 
  158.  
  159.  OS/2 is a registered trademark of International Business Machines Corporation. 
  160.  Other trademarks are property of their respective owners.  Any mention of a 
  161.  product in this publication does not constitute an endorsement or affiliation 
  162.  unless specifically stated in the text. 
  163.  
  164.  Title Page - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  165.  
  166.  
  167. ΓòÉΓòÉΓòÉ 2. The Design and Implementation of VIOWIN:  Part 5 ΓòÉΓòÉΓòÉ
  168.  
  169.  
  170. ΓòÉΓòÉΓòÉ 2.1. Introduction ΓòÉΓòÉΓòÉ
  171.  
  172. The Design and Implementation of VIOWIN:  Part 5 
  173.  
  174. Written by Larry Salomon, Jr. 
  175.  
  176. Introduction 
  177.  
  178. For my job, I once had to write an application that ran only when OS/2 booted 
  179. from the floppy diskettes.  Because I had no access to the functionality PM 
  180. provides, I resorted to a line-oriented interface, where messages were 
  181. displayed on the screen and scrolled up when necessary.  It was a good 
  182. interface, I thought; it was fully NLS enabled and had intelligent defaults so 
  183. the user basically only had to type in the name of the application. 
  184. Unfortunately, the Quality Assurance team didn't concur with my opinion.  "We 
  185. want a nice interface!"  one exclaimed.  "Yeah, one with different windows and 
  186. such!"  another shouted. 
  187.  
  188. I was backed into a corner that I could only get out of one way. 
  189.  
  190. This series describes the design and implementation of VIOWIN, a library that 
  191. implements a subset of the Win APIs provided by PM for fullscreen sessions. 
  192. The reasoning behind writing this series is that it provided me and will 
  193. hopefully provide you with some unique insights into how a windowing system is 
  194. developed; and since it is based on PM, your familiarity with the already 
  195. defined interface will increase your capability to fully understand what is 
  196. being described. 
  197.  
  198. Obviously, this series assumes you have PM application development experience, 
  199. but it isn't required. 
  200.  
  201. This Month 
  202.  
  203. This month we will wrap up our discussion of the base library so that we may 
  204. begin looking at the window classes next month. 
  205.  
  206. The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3, 
  207. Issue 1 
  208.  
  209.  
  210. ΓòÉΓòÉΓòÉ 2.2. Timers ΓòÉΓòÉΓòÉ
  211.  
  212. Timers 
  213.  
  214. Timers were probably the most exciting to develop for me, because never before 
  215. had I given thought to how they were implemented.  Seeing them work for the 
  216. first time was quite enjoyable.  Before we look at the VIOWIN/PM timer, we 
  217. should look at the timer-like services provided by the kernel - 
  218. DosStartTimer(), DosAsyncTimer(), and DosStopTimer().  The first one starts a 
  219. recurring timer with a specified timeout; the second starts a timer that ends 
  220. after the first timeout; and the third stops a timer started with either 
  221. function.  Timers signify their timeout by posting a shared ("public") event 
  222. semaphore which can be checked using the DosWaitEventSem() function. 
  223.  
  224. A first pass at guessing how to implement VIOWIN timers would lead you to use 
  225. the DosStartTimer() function.  Consider the situation when the user calls 
  226. vwStartTimer() on an already started timer with the desire to change the 
  227. timeout value.  Using DosStartTimer() makes implementing this ability more 
  228. difficult than is necessary.  Therefore, we instead use DosAsyncTimer() to 
  229. restart the kernel's timer each time, referencing the current timeout value. 
  230. Thus, to change the timeout, we simply change the appropriate variable, which 
  231. is used the next time DosAsyncTimer() is called. 
  232.  
  233. It should also be obvious that, since timers continue in the background, a 
  234. separate thread must be provided for the timers.  It is conceivable that a 
  235. single, auxilliary thread could be used for all timers in the system, but it is 
  236. easier to implement if we create a new thread for each timer created. 
  237.  
  238. Take a look at the vwStartTimer(), vwStopTimer(), and timerThread() functions 
  239. in the source provided; they should not be difficult to understand, especially 
  240. with the comments scattered throughout the source. 
  241.  
  242. The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3, 
  243. Issue 1 
  244.  
  245.  
  246. ΓòÉΓòÉΓòÉ 2.3. Resources ΓòÉΓòÉΓòÉ
  247.  
  248. Resources 
  249.  
  250. The title is actually misleading, because VIOWIN only supports STRINGTABLE 
  251. resources.  The problem is supporting resources is not getting the resources, 
  252. but decyphering the data that comes back from the kernel.  For this, I used 
  253. Microsoft's Quickhelp utility and Martin Lafaix's article Resources and 
  254. Decompiling Them from EDM/2 volume 2, issue 6. 
  255.  
  256. STRINGTABLEs are a curious beast because they are the only resource for which 
  257. one does not specify a resource identifier for the table itself.  Instead, the 
  258. resource compiler breaks the table into 16-string subtables whose strings have 
  259. contiguous identifiers.  So, if you have a table whose strings have identifiers 
  260. of 1, 17, 33, and 49, the resource compiler will create 4 subtables containing 
  261. strings from 0-15, 16-31, 32-47, and 48-63, though each of these subtables 
  262. contains only one string.  You can obviously see why you would benefit from 
  263. using contiguous identifiers for your strings in the STRINGTABLE. 
  264.  
  265. The kernel provides the DosGetResource() and DosFreeResource() functions for 
  266. loading the resource into memory and freeing the memory used by the resource 
  267. (the former returns a PVOID which is why the latter function is necessary). 
  268. Unfortunately, the online references do not tell you the format of the data, 
  269. which I had to figure out with the help of my two other references. 
  270.  
  271. STRINGTABLEs (actually, the subtables) have the following form: 
  272.  
  273. Size of the table (2 bytes)
  274. Length of string 0 (1 byte)
  275. String 0 (n bytes)
  276. Null-terminator (1 byte)
  277. Length of string 1 (1 byte)
  278. String 1 (n bytes)
  279. Null-terminator (1 byte)
  280.   :
  281. Length of string 15 (1 byte)
  282. String 15 (n bytes)
  283. Null-terminator (1 byte)
  284.  
  285. The null-terminator is not included in the length.  The identifier of the 
  286. subtable is calculated given the identifier of any string within it by dividing 
  287. the string identifier by 16 using integer division.  The position (0- 15) of 
  288. the string is calculate by taking the remainder of the previous division.  So, 
  289. string 120 is in the subtable with the id 120/16=7 and is in position 120%16=8 
  290. (meaning 7 when counting at base 0). 
  291.  
  292. The code for vwLoadString() should be easy to digest given the above 
  293. discussion.  Take a look and send me any questions. 
  294.  
  295. The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3, 
  296. Issue 1 
  297.  
  298.  
  299. ΓòÉΓòÉΓòÉ 2.4. Drawing ΓòÉΓòÉΓòÉ
  300.  
  301. Drawing 
  302.  
  303. Since PM clips the output of any window to the rectangle defining the window, I 
  304. couldn't use printf() for output, since it knows nothing of these rules imposed 
  305. by the UI.  However, one must be able to output something, and since graphics 
  306. are not allowed in text mode, I decided to limit myself to two functions: 
  307. vwDrawText() and vwFillRect().  These two deviate from their counterparts in 
  308. that they do not accept an HPS as the first parameter, and they use the window 
  309. rectangle as the maximum clipping region, which can be reduced using the 
  310. appropriate parameter.  Because these functions do not perform any black-magic, 
  311. per se, they will not be discussed, but you are encouraged to look at the 
  312. source for them to be sure you understand what they are doing.  It should be 
  313. noted that these functions are one of the very few that actually write anything 
  314. to the screen; these use the VIO subsystem, as documented in the 1.3 
  315. Programmer's Reference. 
  316.  
  317. The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3, 
  318. Issue 1 
  319.  
  320.  
  321. ΓòÉΓòÉΓòÉ 2.5. Cursors ΓòÉΓòÉΓòÉ
  322.  
  323. Cursors 
  324.  
  325. Cursors in PM are something that not many people use unless they are writing 
  326. their own general-purpose window classes, yet they are an integral part of PM. 
  327. Since our drawing in VIOWIN is limited to textual information, we cannot 
  328. support the wide-range of options in the WinCreateCursor() function, but we can 
  329. provide enough functionality to allow the creation and manipulation of a 
  330. blinking underline cursor.  This could probably be expanded to block cursors as 
  331. well, but I was lazy. 
  332.  
  333. It is important to note that a cursor is clipped and can be visible or not. 
  334. These two states are completely independent of each other, so you should resist 
  335. the urge to wrap them both up in a single flag.  I initially did this and then 
  336. found to my chagrin that the following sequence of events will produce a result 
  337. inconsistent with what should happen: 
  338.  
  339.    1. Move the cursor outside of the window so that it is clipped 
  340.    2. Hide the cursor 
  341.    3. Move the cursor inside of the window again 
  342.  
  343.  Having a single flag for both clipping and visibility results in the cursor 
  344.  being shown after step 3 although it is clearly obvious that it shouldn't be. 
  345.  
  346.  VIOWIN provides four functions for cursor support: vwCreateCursor(), 
  347.  vwDestroyCursor(), vwShowCursor(), and vwQueryCursorInfo().  These all behave 
  348.  much like their counterparts. 
  349.  
  350.  The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 
  351.  3, Issue 1 
  352.  
  353.  
  354. ΓòÉΓòÉΓòÉ 2.6. Source Code ΓòÉΓòÉΓòÉ
  355.  
  356. Source Code 
  357.  
  358. The complete source for the base library is provided in viowin.zip.  Of course, 
  359. the library is useless without the classes, but it is helpful to have 
  360. nonetheless.  The archive contains the following source files: 
  361.  
  362.  File                Contents 
  363.  VIOWIN.C            Miscellaneous functions. 
  364.  VWCLASS.C           Class functions. 
  365.  VWCURS.C            Cursor functions. 
  366.  VWDRAW.C            Drawing functions. 
  367.  VWMSG.C             Message functions. 
  368.  VWRECT.C            Rectangle functions. 
  369.  VWRES.C             Resource functions. 
  370.  VWTIMER.C           Timer functions. 
  371.  VWUTIL.C            Utility functions used internally by the library. 
  372.  VWWND.C             Window functions. 
  373.  
  374.  The provided makefile can be used to compile the library.  IBM's C-Set++ 
  375.  compiler was used; you may have to make modifications to the makefile in order 
  376.  to use another compiler. 
  377.  
  378.  The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 
  379.  3, Issue 1 
  380.  
  381.  
  382. ΓòÉΓòÉΓòÉ 2.7. Next Month ΓòÉΓòÉΓòÉ
  383.  
  384. Next Month 
  385.  
  386. That's it for the base library!  Next month, we will begin by looking at our 
  387. first window class - the button class - and how it is implemented.  Any 
  388. comments or suggestions will be quite welcome. 
  389.  
  390. The Design and Implementation of VIOWIN:  Part 5 - EDM/2 - Jan 1995 - Volume 3, 
  391. Issue 1 
  392.  
  393.  
  394. ΓòÉΓòÉΓòÉ 3. RMX-OS2:  An In-Depth View (Part 1) ΓòÉΓòÉΓòÉ
  395.  
  396.  
  397. ΓòÉΓòÉΓòÉ 3.1. Introduction ΓòÉΓòÉΓòÉ
  398.  
  399. RMX-OS2:  An In-Depth View (Part 1) 
  400.  
  401. Written by Johan Wikman 
  402.  
  403. Introduction 
  404.  
  405. This is the first in a series of articles where I am going to describe ReMote 
  406. eXecution for OS/2 - RMX-OS2, or simply RMX.  In this first article I am only 
  407. going to give an overview of RMX, but in the articles to follow - which I will 
  408. do my best to provide at a pace of one per month - I will dig into details and 
  409. present some stuff you'll find interesting (I hope :-). 
  410.  
  411. RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  412.  
  413.  
  414. ΓòÉΓòÉΓòÉ 3.2. Remote Execution ΓòÉΓòÉΓòÉ
  415.  
  416. Remote Execution 
  417.  
  418. I've been using and programming for OS/2 ever since version 1.1.  At the same 
  419. time I have also used various flavors of Unix and hence also the X Windowing 
  420. System. 
  421.  
  422. X and PM are essentially pretty much alike:  they provide an API with which 
  423. graphical applications can be written.  In one respect, however, X differs 
  424. radically from PM (and most other windowing systems for that matter) as it 
  425. allows applications to run remotely.  That is, the application can run on one 
  426. computer but the user can use it on another computer.  The two computers can 
  427. reside anywhere on a network, if necessary in different buildings or even in 
  428. different countries. 
  429.  
  430. This is something that OS/2 and PM does not support:  an application must run 
  431. on the same computer where it is used.  Yes, applications can, of course, be 
  432. explicitly split into client and a server parts where the two parts can run on 
  433. different computers (e.g. database applications), but you cannot take an 
  434. arbitrary PM application and run it on one computer and use it on another. 
  435.  
  436. Running PM applications remotely is what RMX is all about. 
  437.  
  438. Why would you want to do that then?  Well: 
  439.  
  440.    1. Remote execution allows you to run an application on the most appropriate 
  441.       (powerful) computer on the network, yet interact with the application 
  442.       where it is most convenient. 
  443.    2. Instead of being forced to have n powerful computers for n people, you 
  444.       can have 1 powerful computer, where resource hungry applications are run, 
  445.       and n - 1 less powerful (and much cheaper) computers that are used as 
  446.       display servers for remote applications and for running ordinary 
  447.       applications. 
  448.    3. Once OS/2 for PowerPC is available you can run applications on a PowerPC, 
  449.       yet use them on a cheap Intel. 
  450.    4. It offers a convenient way for monitoring other computers. 
  451.    5. It is simply a neat feature :-). 
  452.  
  453.  To be honest, the list above is slightly vapour as RMX currently is on beta 
  454.  level and couldn't be used in a production environment.  Nevertheless, the 
  455.  functionality for providing the services in the list (except item 3 of course) 
  456.  is there. 
  457.  
  458.  RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  459.  
  460.  
  461. ΓòÉΓòÉΓòÉ 3.3. RMX in Practice ΓòÉΓòÉΓòÉ
  462.  
  463. RMX in Practice 
  464.  
  465. Ok, so what does remote execution mean in practice?  A PM application's 
  466. structure can schematically be pictured as: 
  467.  
  468. Figure 1) Schematic picture of a PM application. 
  469.  
  470. The application consists of application code that more or less frequently call 
  471. operating system and PM functions.  All user interaction is handled through 
  472. calls to PM.  If we for each call to PM instead... 
  473.  
  474.    1. make a packet out of the function arguments, 
  475.    2. send the packet to another computer, 
  476.    3. on the other computer extract the arguments from the packet, 
  477.    4. execute the actual function, 
  478.    5. make a packet out of the returned value, 
  479.    6. send the packet back to the other computer, 
  480.    7. extract the returned value from the packet, and 
  481.    8. return the result back to the application 
  482.  
  483.  ...the visual appearance and interaction of the application can be moved to 
  484.  another computer. 
  485.  
  486.  Figure 2) Schematic picture of a RMX application. 
  487.  
  488.  In practice, each PM call (i.e., a call to a Win or Gpi function) is replaced 
  489.  with the following pseudo code.  We ignore for the moment exactly how that 
  490.  replacing is done. 
  491.  
  492.   ReturnType WinFunction(arguments)
  493.   {
  494.     Copy all arguments to a transfer buffer
  495.     Send buffer to server
  496.     Read buffer from server (this call blocks until there is something to read)
  497.     Extract result
  498.     Return result to caller
  499.   }
  500.  
  501.  The arguments of the function is simply copied into a buffer and sent over a 
  502.  communications link to the server.  On the server the arguments are extracted 
  503.  and the actual function is executed. 
  504.  
  505.   void winFunction()
  506.   {
  507.     Read buffer from client
  508.     Extract arguments from buffer
  509.     Call actual PM function
  510.     Copy return value into buffer
  511.     Send buffer to client
  512.   }
  513.  
  514.  The server reads the raw data, converts it into arguments of proper type and 
  515.  calls the actual PM function.  Essentially it is a question of transparently 
  516.  turning local procedure calls (LPCs) into equivalent remote procedure calls 
  517.  (RPCs).  Seems rather trivial doesn't it?  In practice, however, there some 
  518.  rather interesting problems to be solved: 
  519.  
  520.      How can the functions be replaced without a need for a recompilation or 
  521.       relink? 
  522.      It is not only the application that calls PM functions, PM calls window 
  523.       procedures of the application. 
  524.      PM often reads resources from the executable.  How should this be handled 
  525.       when the actual executable is in another computer? 
  526.      Arguments passed by value are trivial to handle, but what about pointers? 
  527.  
  528.  I'll return to these questions in a later article. 
  529.  
  530.  RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  531.  
  532.  
  533. ΓòÉΓòÉΓòÉ 3.4. Design Requirements ΓòÉΓòÉΓòÉ
  534.  
  535. Design Requirements 
  536.  
  537. When I started designing RMX - which actually is a part of my Master's Thesis - 
  538. I made a list of requirements that would have to be fulfilled if RMX was ever 
  539. to become an product people would use. 
  540.  
  541. No recompilations - if somebody would suggest to me, "Hey, if you write your 
  542. application according to these fancy guidelines, then you'll get this neat 
  543. remote execution feature," I wouldn't even look at the stuff.  Even a relink is 
  544. too much as it effectively means that only developers could use the product. 
  545. Hence, an absolute design requirement was that it should be possible to run any 
  546. executable remotely without a recompile or relink.  (An observant reader 
  547. notices that I don't rule out patching :-). 
  548.  
  549. Localized cost - of course there is a performance cost involved when 
  550. applications are run remotely and LPCs are replaced with RPCs.  (However, this 
  551. applies only to threads that call PM; non-PM threads run at the full speed of 
  552. the CPU-server.  The remote execution and the speed of the display-server do 
  553. not influence them at all.)  That cost is acceptable as long as the added value 
  554. of remote execution in itself is bigger. However, it would be unacceptable if 
  555. you would have to pay for the remote execution mechanism also when you run the 
  556. application locally, i.e., when you run and use it on the same computer. 
  557.  
  558. Any communications media - remote execution is ultimately a question of moving 
  559. data between a client and a server.  The entire remote execution mechanism can 
  560. be built so that it does not depend on the media or actual low-level data 
  561. transfer mechanism used.  Hence, RMX had to be designed so that the data 
  562. transfer mechanism can be replaced without a need for changes in RMX. 
  563.  
  564. Optional security - remote execution opens a loophole in the security as it 
  565. allows remote applications to connect to a computer and start monitoring 
  566. keystrokes.  In many environments a lack of security is not an issue; in others 
  567. it would prevent RMX from being used.  The conclusion is that security is 
  568. needed, but it must be provided in such a way that different levels of security 
  569. can easily be supported. 
  570.  
  571. Visual appearance - it should not be possible to detect any difference between 
  572. an application running remotely and an application running locally. 
  573.  
  574. Simultaneous Use - it must be possible to run remote and local application 
  575. side-by-side. 
  576.  
  577. So, those were some of the requirements I specified before I started designing 
  578. RMX. 
  579.  
  580. RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  581.  
  582.  
  583. ΓòÉΓòÉΓòÉ 3.5. Example ΓòÉΓòÉΓòÉ
  584.  
  585. Example 
  586.  
  587. In the following I'll show you a concrete example of how RMX is used.  The 
  588. basic requirement is two computers that are connected somehow.  This example 
  589. assumes that we are using a network that supports named pipes. 
  590.  
  591. Although RMX essentially does not care what mechanism is used for transferring 
  592. data between the client and server computers, it has to be told what mechanism 
  593. to use.  That is done by specifying an environment variable: 
  594.  
  595. set RMXCOMMS=RMXPIPE
  596.  
  597. The value of the variable should be the name of a DLL that provides certain 
  598. functionality (I'll tell exactly what in the next article).  That variable 
  599. usually needs to be set only once - in CONFIG.SYS - but it is quite possible to 
  600. specify on a case by case basis what communications DLL to use. 
  601.  
  602. An application must be marked (patched) before it can be run remotely. This has 
  603. to be done only once, and it does not influence the application's normal use 
  604. (apart from the requirement that certain DLLs of RMX must be present), and if 
  605. need be the application can be unpatched. 
  606.  
  607. rmxpatch -p -d app.exe
  608.  
  609. I'll explain the flags and describe exactly what RMXPATCH does in a later 
  610. article. 
  611.  
  612. Then we have the question of how to start a remote application.  After all, it 
  613. will be running on a computer that may physically reside quite far from the 
  614. computer where we will use it.  For that purpose there is RMXSTRTR.EXE and 
  615. RMXSTART.EXE. RMXSTRTR.EXE is a daemon application whose only responsibility is 
  616. to start remote applications upon requests from RMXSTART.EXE.  Being a daemon 
  617. it is usually started when the CPU-server is booted. 
  618.  
  619. detach rmxstrtr.exe
  620.  
  621. Before we can start a remote application that will appear on the display-server 
  622. we must start a server application that provides services to the remote 
  623. application.  This is also something that normally is done when the computer is 
  624. booted. 
  625.  
  626. start pmserver.exe
  627.  
  628. Now everything is set and we can start the remote application.  Assume that 
  629. \\ODIN is the network name of the CPU-server and that \\LOKE is the name of the 
  630. display-server. 
  631.  
  632. rmxstart \\LOKE \\ODIN app.exe
  633.  
  634. This command will start app.exe on the computer \\ODIN but the application will 
  635. appear on \\LOKE.  Note, in the normal case this last step is the only thing 
  636. that is needed in order to start a remote application. 
  637.  
  638. RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  639.  
  640.  
  641. ΓòÉΓòÉΓòÉ 3.6. Conclusion ΓòÉΓòÉΓòÉ
  642.  
  643. Conclusion 
  644.  
  645. Ok, so that was a brief introduction to RMX.  In the articles that follow I 
  646. will go a lot deeper and provide a lot more details.  As I haven't written 
  647. those articles yet, I don't know exactly what they will contain, but the 
  648. following list shows roughly what I will cover. 
  649.  
  650. Low level transfer - as mentioned, the low-level transfer mechanism of data 
  651. between the remote application and the display server is completely outside 
  652. RMX.  In this article I will thoroughly describe the mechanism along with a 
  653. detailed description of the current implementation that relies on named pipes. 
  654. Based on this article it should be possible to write an implementation for 
  655. TCP/IP, for example. 
  656.  
  657. Marking applications for remote execution - basically any 32-bit PM application 
  658. can be marked for remote execution.  In this article I will describe how it is 
  659. done. 
  660.  
  661. Starting remote applications - RMXSTRTR.EXE and RMXSTART.EXE provide the means 
  662. for starting an application on a remote computer.  In this article I'll 
  663. describe exactly what they do and how they do it. 
  664.  
  665. Protocol - when data is transferred between two processes a protocol is needed. 
  666. That is also the case in RMX. 
  667.  
  668. Turning LPCs into RPCs. - basically remote execution is a question of turning 
  669. certain LPCs into equivalent RPCs.  In this article I will describe how that is 
  670. done for the OS/2 PM API. 
  671.  
  672. Threads - quite a few PM program use threads and obviously they must be 
  673. supported as well.  How are tightly coupled threads in in two separate 
  674. processes managed? 
  675.  
  676. Performance - replacing LPCs with RPCs means in the context of RMX that the 
  677. performance of the display updating will suffer.  Fortunately, there are 
  678. measures with which the perfomance penalty can be reduced. 
  679.  
  680. Security - RMX offers a possibility for adding a certain level of security.  In 
  681. this article I will describe how a security DLL can be written. 
  682.  
  683. The only thing I guarantee about this list is that the next article will be 
  684. about the low-level transfer.  Apart from that, the items on the list and their 
  685. order may change. 
  686.  
  687. As I mentioned, I developed RMX as part of my Master's Thesis.  If you can't 
  688. wait for the articles, drop me a note and I'll mail the thesis to you. Being a 
  689. thesis it is more general than this article series will be, but on the other 
  690. hand it also contains material that I won't include in the articles. 
  691.  
  692. If you want to give RMX a try, keep an eye on hobbes.nmsu.edu. I'll will upload 
  693. the first proper beta-release real-soon-now :-).  Drop me a note if you want me 
  694. to notify you when that happens. 
  695.  
  696. RMX-OS2:  An In-Depth View (Part 1) - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  697.  
  698.  
  699. ΓòÉΓòÉΓòÉ 4. /dev/EDM/BookReview ΓòÉΓòÉΓòÉ
  700.  
  701.  
  702. ΓòÉΓòÉΓòÉ 4.1. Introduction ΓòÉΓòÉΓòÉ
  703.  
  704. /dev/EDM2/BookReview 
  705.  
  706. Written by Carsten Whimster 
  707.  
  708. Introduction 
  709.  
  710. /dev/EDM2/BookReview is a monthly column which focuses on development oriented 
  711. books and materials.  The column is from a beginning PM programmer, but 
  712. intermediate REXX programmer's eyes.  Pick up whichever book strikes your 
  713. fancy, and join the growing group of people following our PM programming 
  714. columns.  I will review books aimed at beginners for a while, and then move on 
  715. from there. 
  716.  
  717. Please send me your comments and thoughts so that I can make this column as 
  718. good as possible.  All mail gets read and responded to. 
  719.  
  720. Designing OS/2 Applications is not a normal programming book. In fact, it talks 
  721. very little about programming, and a lot about designing programs, as might be 
  722. expected from its title.  If that sounds a little cryptic, read on... 
  723.  
  724. /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  725.  
  726.  
  727. ΓòÉΓòÉΓòÉ 4.2. Errata ΓòÉΓòÉΓòÉ
  728.  
  729. Errata 
  730.  
  731. This month is a month of corrections.  I obviously try to be accurate and fair, 
  732. but recently I made a couple of minor blunders: 
  733.  
  734. In last month's review I criticized Charles Petzold's new book for using 
  735. "Windows graphics" in some of the figures.  Of course it wasn't Windows 
  736. graphics, but rather OS/2 1.x graphics which happen to look identical. This is 
  737. a hangover from the first version of the book.  One reader told me that the new 
  738. version is very similar to the old version, and that there is hardly any new 
  739. material, just some updates.  If you can live with this (which means little, if 
  740. any, 2.1+ material), then I still recommend this book for its thoroughness. 
  741.  
  742. Even further back, I managed to miss the WPS coverage in Anthony Rudd's 
  743. Application Development Using OS/2 REXX.  When I looked closer, it actually 
  744. covered almost as much as the REXX Reference Summary Handbook, so I have 
  745. changed its rating in WPS from "No Coverage" to "Introductory Coverage", which 
  746. is now the same for both.  The handbook covers a little more, but it is less 
  747. tutorial, so they end up about the same. 
  748.  
  749. Well, with that off my chest... 
  750.  
  751. I have rearranged the Content Index in a more logical order, and created a new 
  752. table called SYSTEM AND DESIGN BOOKS to suit books like this one, and other 
  753. non-programming books for programmers.  At the moment, the first two tables are 
  754. near identical in layout, but that will change over time. In any case, 
  755. comparing programming books with design books doesn't make any sense, and the 
  756. separate tables reinforce that. 
  757.  
  758. /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  759.  
  760.  
  761. ΓòÉΓòÉΓòÉ 4.3. Designing OS/2 Applications ΓòÉΓòÉΓòÉ
  762.  
  763. Designing OS/2 Applications 
  764.  
  765. Designing OS/2 Applications is a unique type of book.  It does not attempt to 
  766. teach you how to program, but rather how to design programs, or how to think 
  767. about programming.  These are the chapter titles: 
  768.  
  769.    1. OS/2 as an End-User Platform 
  770.    2. Why Program for OS/2? 
  771.    3. OS/2 as a Development Platform 
  772.    4. Good Programs Have Good Up-Front Design 
  773.    5. OS/2 Kernel Architecture 
  774.    6. Presentation Manager, Graphics, and the User Interface 
  775.    7. Features for Your Application 
  776.    8. Application Structure 
  777.    9. Block Design and Architecture 
  778.   10. Designing the User Interface 
  779.   11. Where's the Beef? 
  780.   12. The Development Environment 
  781.   13. Prototyping the User Interface 
  782.   14. Building the Core Functions 
  783.   15. Using Advanced Functions 
  784.   16. Non-English-Language Support 
  785.   17. Base Tuning 
  786.   18. Visual Tuning 
  787.   19. Testing Methodology 
  788.   20. Code Change 
  789.   21. Designing the Installation Program 
  790.   22. Appendix A: Summary and Conclusions 
  791.   23. Appendix B: Bibliography 
  792.  
  793.  In addition to this layout, the chapters are divided into sections as follows: 
  794.  
  795.    1. Why OS/2? - chapters 1 through 3 
  796.    2. Overall Application Design - chapters 4 through 8 
  797.    3. Use Building Blocks or Your App Will Crumble - chapters 9 through 11 
  798.    4. Making It Happen - chapters 12 through 16 
  799.    5. Performance - chapters 17 and 18 
  800.    6. Testing and Code Changes - chapters 19 and 20 
  801.    7. Installation Programs - chapter 21 
  802.  
  803.  I will concentrate on the sections, rather than the chapters, since the 
  804.  divisions between the chapters are much fuzzier than in actual programming 
  805.  books. 
  806.  
  807.  Section I explains the advantages of OS/2 over other platforms.  This is 
  808.  explained both from an end-user's point of view, as well as from the 
  809.  programmer's point of view.  We all know the advantages of pre-emptive 
  810.  multi-tasking, multi-threading, a flat 32-bit address space, device 
  811.  independence, the object-oriented interface (WPS), DDE, virtual memory, 
  812.  paging, swapping, drag-and-drop, and a consistent user interface (CUA).  These 
  813.  are all elaborated on.  In addition, the API is touted as an advantage, both 
  814.  with respect to power, and also with respect to the (theoretical) portability 
  815.  of it.  Third, the advantages of OS/2 as a development platform are outlined, 
  816.  and include crash protection (tm), multi-tasking, and debugging support. 
  817.  
  818.  Section II is a large section, which outlines the overall application design 
  819.  theory and procedures.  The importance of good, solid, up-front design are 
  820.  stressed over and over again.  Examples of poor design practices are listed, 
  821.  and their faults explained.  Proper design techniques are carefully explained. 
  822.  One funny quote which is a favorite of the author's is "There's never enough 
  823.  time to do it right the first time, but there's always time to do it over". 
  824.  This is so true!  It doesn't take long thinking about the various products on 
  825.  the market to come up with concrete examples of this.  Even large 
  826.  multi-platform companies with huge resources seem to think that if they 
  827.  release a suite of programs quickly, and then fix it later, it will gain a 
  828.  large, devoted user base.  Wrong!  Doing it wrong the first time loses a 
  829.  developer a lot of potential respect, which is replaced by suspicion and 
  830.  mistrust.  Finally, the 60% design/30% code/10% test rule is introduced, and 
  831.  the logic behind it is explained. 
  832.  
  833.  Starting in chapter 5, an overview of the inner workings of OS/2 is given, 
  834.  beginning with the kernel, and proceeding through to the Presentation Manager, 
  835.  The GPI, and the WPS.  This section is important in that it gives those of us 
  836.  who don't yet own a copy of The Design of OS/2 an insight into what goes on 
  837.  behind the scenes.  Following that, there is a section which explains what 
  838.  features are available to programmers, on a purely conceptual level.  Again, 
  839.  this is very helpful, since it is hard to know what is available when you 
  840.  haven't done much OS/2 programming.  Then again, even if you had, there are 
  841.  enough additions from version to version that keeping up with all the new 
  842.  features would be difficult.  Each feature available is explained in terms of 
  843.  advantages and disadvantages, and intended use. 
  844.  
  845.  Application structure is the next stop on the journey, with device 
  846.  independence featured prominently up front, closely followed by modular design 
  847.  and using threads.  Multi-process applications are also discussed, along with 
  848.  some reasons that you probably shouldn't use them, unless you can't do it any 
  849.  other way.  DLLs, code sharing, resource sharing, and synchronization are all 
  850.  stops along our merry way, and the chapter finishes with a mini lecture on 
  851.  upgradability, portability, and serviceability concerns. 
  852.  
  853.  The next section discusses modularization in much greater detail.  Reich 
  854.  presents his idea of design (which is tempered by years of writing for OS/2, 
  855.  so listen up), starting with the overall design accomplished by taking a 
  856.  black-box approach to your app.  The user interface is the next stop along the 
  857.  design path, and CUA, data presentation, and window controls are all lightly 
  858.  visited.  Dialogs are paid a slightly longer visit, application defaults and 
  859.  CASE tools are discussed.  The Workplace Shell is treated particularly well, 
  860.  as is fitting.  The various levels of integration with the WPS are discussed, 
  861.  and the ways of accomplishing them (in theoretical detail) are presented.  I 
  862.  particularly liked this chapter, and learned a lot about things that I only 
  863.  had a vague idea about before.  Core functions are discussed next, and 
  864.  modularization, memory management, device drivers, application layout, file 
  865.  system support, EXEs versus DLLs, INI files and multiprocess applications are 
  866.  all revisited in greater detail than last time. 
  867.  
  868.  Making it Happen is the title of section IV.  Practical decisions are the main 
  869.  focus here, such as the choice of development environment, tools, source code 
  870.  revision systems, and so on.  Writing the code for the user interface is next, 
  871.  and the pros and cons of using separate threads to do things like painting 
  872.  your window are presented.  Prototyping the interface is also a good way to 
  873.  check the validity of your design, since only a little code needs to be 
  874.  written to allow "walking through" your application.  Self-verification steps 
  875.  are common in this book, and allow you to get a better feel for whether you 
  876.  are on the right track with your application design or not.  Multi-threading 
  877.  the interface is discussed in great depth at this point, and ways of keeping 
  878.  the user interface responsive are presented, while keeping the code 
  879.  manageable. 
  880.  
  881.  The next chapter deals with setting up the core function of your program 
  882.  properly.  Again, multi-threading is discussed, and semaphores are 
  883.  re-introduced as one way of sharing resources safely. 
  884.  
  885.  Note:  the example on semaphores and deadlock is, strictly-speaking, 
  886.  inaccurate.  I quote:  "You can see there are three threads.  Threads 1 and 2 
  887.  make use of semaphore A. Threads 2 and 3 make use of semaphore B, and threads 
  888.  1 and 3 make use of semaphore C. No two threads make use of the same 
  889.  resources, but you can see that if thread 1 has semaphore A, thread 2 has 
  890.  semaphore B, and thread 3 has semaphore C, any semaphore request by any of the 
  891.  three will cause a deadlock."  In fact, if, say, thread 1 requests semaphore 
  892.  C, it is still possible for the three threads to complete as follows:  thread 
  893.  1 requests semaphore C, and locks.  Thread 2 requests semaphore A, and locks. 
  894.  Thread 3 finishes with semaphore C, releases it, requests semaphore B, and 
  895.  locks.  Thread 1 can now get semaphore C, and run to completion, releasing 
  896.  semaphore A and C. Now thread 2 can get semaphore A, and run to completion, 
  897.  releasing semaphore A and B. Finally, thread 3 gets semaphore B, and runs to 
  898.  completion.  In fact, any sequence of events will complete, which has one 
  899.  thread giving up a semaphore before requesting another.  If all three threads 
  900.  needed two semaphores at the same time, and each acquired one, then any 
  901.  further requests causes deadlock.  This is slightly different than the 
  902.  statement of the problem, but it is significant.  I imagine this is what was 
  903.  meant. 
  904.  
  905.  Critical sections are introduced next, as a still safer way to share 
  906.  resources.  The large expense of critical sections is explained, however, 
  907.  emphasizing that if other designs are possible, they should be pursued. 
  908.  
  909.  The next topic is IPC.  Various mechanisms, such as queues, pipes, and shared 
  910.  memory are explored.  Data formats, file formats, and file system dependency 
  911.  is discussed, including LANs.  Advanced functions come next in the ASCII 
  912.  stream of the book.  Getting the basic user interface and functionality into 
  913.  code has been the priority so far, but now is the time to add the advanced 
  914.  features that you want your application to have.  It is good to do this long 
  915.  before adding the advanced functions, partly because of the reluctance to 
  916.  change something major after you have added lots of code.  As Reich points 
  917.  out, if you add the simple stuff first, changes are easier to make because 
  918.  they don't make for much longer development cycles. DDE, printing, fonts, and 
  919.  the help facility come under this heading. Non-English language support is 
  920.  another, frequently overlooked item on the long list of things to look for. 
  921.  It is very easy to do, when done right, and extremely tedious when done wrong. 
  922.  How you can do it right the first time is carefully explained. 
  923.  
  924.  The next section deals with performance tuning.  Many little neat performance 
  925.  tricks are presented, such as minimizing fix-up costs, accessing DLLs 
  926.  intelligently, thread priorities, EXE packing, and DLL placement.  User 
  927.  interface speed is also discussed in some detail. 
  928.  
  929.  The penultimate section deals with testing and changing code.  These two 
  930.  chapters are short, sweet, and use common sense, so I will leave them out 
  931.  here. 
  932.  
  933.  The final section is on installation programs, and this happens to be a pet 
  934.  peeve of mine.  Frequently, you pick up some really neat program, but get 
  935.  frustrated trying to install it correctly.  In my opinion, a decent 
  936.  installation procedure should include instructions on how to install manually, 
  937.  in case the installation program fails.  This is obviously difficult to do in 
  938.  the case of something as complex as OS/2 itself.  With the types of programs 
  939.  that most of us write, however, it should be a breeze.  In addition, 
  940.  reinstalling and uninstalling are mentioned. 
  941.  
  942.  There is a brief summary following this, which concludes the book. 
  943.  
  944.  /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  945.  
  946.  
  947. ΓòÉΓòÉΓòÉ 4.4. Summary ΓòÉΓòÉΓòÉ
  948.  
  949. Summary 
  950.  
  951. Designing OS/2 Applications is a different kind of book than anything else I 
  952. have reviewed so far.  It is theoretical in nature, and avoids actual code as 
  953. much as possible.  Instead, it concentrates on teaching the proper design 
  954. principles needed to create a new OS/2 application.  As such, in many ways it 
  955. is much more valuable and important than a "mere" programming book, but it 
  956. sacrifices programming detail to do this.  If you have ever wanted to know how 
  957. to go about designing and creating an OS/2 application, get this book.  Once 
  958. you need to know about the nuts and bolts of programming, you'll have to look 
  959. elsewhere, however. 
  960.  
  961. I like this book very much, yet there are a number of small areas that could be 
  962. addressed. 
  963.  
  964. The few examples that are in the book are in C.  Much of the material is 
  965. inherently bound to C programming, as well.  For example, talking about the 
  966. message implementation in OS/2 doesn't make much sense in VX-REXX or PM-Cobol. 
  967. Because this inherent bias is there, I would like to see it be more explicit 
  968. and upfront.  The alternative would be to abstract the material away from C 
  969. even more than it is, but I think it would be more workable to simply state 
  970. that 99% of all OS/2 programming is done in C, and that therefore there will be 
  971. a C bias in the examples.  Even C++ programming is quite different, and many of 
  972. the topics covered in the book become irrelevant when programming in C++. 
  973.  
  974. Some parts of the book have a vague feel to them, perhaps due to the fact that 
  975. the author tried to avoid a language bias.  Specifically, the earlier parts 
  976. read slowly, and there is a fair amount of repetition.  I do not mean that the 
  977. book is difficult or tedious to read, merely that it is sometimes slow going. 
  978. Tightening up the earlier parts might help a bit. 
  979.  
  980. Of course, the semaphore and deadlock example should be reworded. 
  981.  
  982. There are some OS/2 2.1+ features that warrant mentioning.  This book has been 
  983. around for a bit, but a newer book is currently being written, and hopefully 
  984. this information will be included there. 
  985.  
  986. /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  987.  
  988.  
  989. ΓòÉΓòÉΓòÉ 4.5. Books Reviewed ΓòÉΓòÉΓòÉ
  990.  
  991. Books Reviewed 
  992.  
  993. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  994. ΓöéBOOK                              ΓöéAUDIENCE    ΓöéMARKΓöéCOMMENTS                               Γöé
  995. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  996. ΓöéReal-World Programming for OS/2   ΓöéIntermediateΓöéB+  ΓöéLots of good code examples, but        Γöé
  997. Γöé2.1, Blain, Delimon, and English, Γöéto Advanced Γöé    Γöésometimes it is too complex for        Γöé
  998. ΓöéSAMS Publishing.  ISBN            ΓöéPM C        Γöé    Γöénovices. Accurate.  Well organized.    Γöé
  999. Γöé0-672-30300-0.  US$40, CAN$50.    Γöéprogrammers Γöé    ΓöéThe index needs a little beefing up.   Γöé
  1000. Γöé                                  Γöé            Γöé    ΓöéGood, but not entirely complete how-to Γöé
  1001. Γöé                                  Γöé            Γöé    Γöéreference.  Good purchase.             Γöé
  1002. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1003. ΓöéLearning to Program OS/2 2.0      ΓöéBeginning PMΓöéB-  ΓöéThis book can be both frustrating and  Γöé
  1004. ΓöéPresentation Manager by Example,  ΓöéC           Γöé    Γöévery rewarding.  It is not very large, Γöé
  1005. ΓöéKnight, Van Nostrand Reinhold.    ΓöéProgrammers Γöé    Γöéand a bit pricey, but has some         Γöé
  1006. ΓöéISBN 0-442-01292-6.  US$40,       Γöé            Γöé    Γöéexcellent chapters on certain beginningΓöé
  1007. ΓöéCAN$50.                           Γöé            Γöé    Γöétopics, such as messages, resources,   Γöé
  1008. Γöé                                  Γöé            Γöé    ΓöéIPF, and dialog boxes.  Strictly for   Γöé
  1009. Γöé                                  Γöé            Γöé    Γöébeginners.  This book has only one     Γöé
  1010. Γöé                                  Γöé            Γöé    Γöé(large) sample program!                Γöé
  1011. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1012. ΓöéWriting OS/2 2.1 Device Drivers inΓöéAdvanced C  ΓöéA-  ΓöéThe only thing a device driver         Γöé
  1013. ΓöéC, 2nd Edition, Mastrianni, Van   ΓöéProgrammers,Γöé    Γöéprogrammer would not find in here is   Γöé
  1014. ΓöéNostrand Reinhold.  ISBN          Γöéfamiliar    Γöé    Γöéhow to write SCSI, ADD, and IFS        Γöé
  1015. Γöé0-442-01729-4.  US$35, CAN$45.    Γöéwith        Γöé    Γöédrivers.  Most everything else is in   Γöé
  1016. Γöé                                  Γöéhardware    Γöé    Γöéhere, along with skeleton examples.  AnΓöé
  1017. Γöé                                  Γöéprogramming Γöé    Γöéoptional DevHlp library of C-callable  Γöé
  1018. Γöé                                  Γöé            Γöé    Γöéfunctions can be purchased by those whoΓöé
  1019. Γöé                                  Γöé            Γöé    Γöédon't have time to write their own.    Γöé
  1020. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1021. ΓöéOS/2 Presentation Manager GPI,    ΓöéIntermediateΓöéC+  ΓöéThis book needs updating for OS/2 2.x. Γöé
  1022. ΓöéWinn, Van Nostrand Reinhold. ISBN Γöéto advanced Γöé    ΓöéIt is a well-written in-depth coverage Γöé
  1023. Γöé0-442-00739-6.  US$35, CAN$45.    ΓöéPM C        Γöé    Γöéof the OS/2 way of programming for     Γöé
  1024. Γöé                                  Γöéprogrammers Γöé    Γöégraphics.  It is not an introductory PMΓöé
  1025. Γöé                                  Γöé            Γöé    Γöéor graphics programming book.  You     Γöé
  1026. Γöé                                  Γöé            Γöé    Γöéshould know the basics of PM           Γöé
  1027. Γöé                                  Γöé            Γöé    Γöéprogramming already.                   Γöé
  1028. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1029. ΓöéThe Art of OS/2 2.1 C Programming,ΓöéBeginning   ΓöéB+  ΓöéThis is a great introductory PM        Γöé
  1030. ΓöéPanov, Salomon, and Panov,        ΓöéOS/2 and PM Γöé    Γöéprogramming book.  It covers basic OS/2Γöé
  1031. ΓöéWiley-QED.  ISBN 0-471-58802-4.   Γöéprogrammers Γöé    Γöéissues like threads before it jumps    Γöé
  1032. ΓöéUS$40, CAN$50.                    Γöé            Γöé    Γöéinto PM programming.  The coverage is  Γöé
  1033. Γöé                                  Γöé            Γöé    Γöéquite thourough, with just enough      Γöé
  1034. Γöé                                  Γöé            Γöé    Γöéreference material to make it useful   Γöé
  1035. Γöé                                  Γöé            Γöé    Γöéafter you read it through the first    Γöé
  1036. Γöé                                  Γöé            Γöé    Γöétime.  The upcoming revised edition    Γöé
  1037. Γöé                                  Γöé            Γöé    Γöéshould be a killer.                    Γöé
  1038. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1039. ΓöéMastering OS/2 REXX, Gargiulo,    ΓöéIntermediateΓöéB   ΓöéThis book is very easy to understand.  Γöé
  1040. ΓöéWiley-QED.  ISBN 0-471-51901-4.   ΓöéOS/2 users  Γöé    ΓöéIf you program with any regularity,    Γöé
  1041. ΓöéUS$40, CAN$50.                    Γöéand         Γöé    Γöélook elsewhere, but if you need an     Γöé
  1042. Γöé                                  Γöébeginning   Γöé    Γöéeasily read, well-explained beginner's Γöé
  1043. Γöé                                  Γöéprogrammers Γöé    Γöébook, look no further.  Some more      Γöé
  1044. Γöé                                  Γöé            Γöé    Γöédetailed, and complex real-world       Γöé
  1045. Γöé                                  Γöé            Γöé    Γöéexamples might be useful as you learn  Γöé
  1046. Γöé                                  Γöé            Γöé    Γöéthe material.  Good coverage of REXX's Γöé
  1047. Γöé                                  Γöé            Γöé    Γöécapabilities.                          Γöé
  1048. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1049. ΓöéREXX Reference Summary Handbook,  ΓöéBeginning toΓöéA   ΓöéThis little handbook is packed full of Γöé
  1050. ΓöéGoran, C F S Nevada.  ISBN        Γöéadvanced    Γöé    Γöéuseful information.  Includes chapters Γöé
  1051. Γöé0-9639854-1-8.  US$20, CAN$25     ΓöéREXX        Γöé    Γöéon both built-in and some popular      Γöé
  1052. Γöé                                  Γöéprogrammers Γöé    Γöécommercial libraries.  Well-written andΓöé
  1053. Γöé                                  Γöé            Γöé    Γöécomprehensively indexed.  A must for   Γöé
  1054. Γöé                                  Γöé            Γöé    ΓöéREXX programmers.                      Γöé
  1055. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1056. ΓöéApplication Development Using OS/2ΓöéIntermediateΓöéA-  ΓöéExcellent coverage of everything REXX, Γöé
  1057. ΓöéREXX, Rudd, Wiley-QED.  ISBN      Γöéto advanced Γöé    Γöéwith the occasional sparse section. It Γöé
  1058. Γöé0-471-60691-X.  US$40, CAN$50     ΓöéREXX        Γöé    Γöéis a decent reference book, and has    Γöé
  1059. Γöé                                  Γöéprogrammers Γöé    Γöéenough unusual material that it will   Γöé
  1060. Γöé                                  Γöé            Γöé    Γöéprobably find its way into many REXX   Γöé
  1061. Γöé                                  Γöé            Γöé    Γöéprogrammers' libraries.                Γöé
  1062. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1063. ΓöéOS/2 Presentation Manager         ΓöéBeginning PMΓöéA-  ΓöéThis book has the most thorough        Γöé
  1064. ΓöéProgramming, Petzold, Ziff-Davis  ΓöéC           Γöé    Γöéintroduction to PM basics in any book IΓöé
  1065. ΓöéPress.  ISBN 1-56276-123-4.       Γöéprogrammers Γöé    Γöéhave read so far.  It leaves the field Γöé
  1066. ΓöéUS$30, CAN$42                     Γöé            Γöé    Γöéwide open for a more thorough advanced Γöé
  1067. Γöé                                  Γöé            Γöé    ΓöéPM book later.  Very well written, veryΓöé
  1068. Γöé                                  Γöé            Γöé    Γöéthorough, and very understandable. OnlyΓöé
  1069. Γöé                                  Γöé            Γöé    Γöéa lack of in-depth treatment of controlΓöé
  1070. Γöé                                  Γöé            Γöé    Γöéwindows and common dialog boxes keep itΓöé
  1071. Γöé                                  Γöé            Γöé    Γöéfrom being perfect.                    Γöé
  1072. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1073. ΓöéDesigning OS/2 Applications,      ΓöéAll         ΓöéA   ΓöéThis book is about design, and making  Γöé
  1074. ΓöéReich, John Wiley &  Sons. ISBN   Γöéprogrammers Γöé    Γöéintelligent decisions in this process. Γöé
  1075. Γöé0-471-58889-X.  US$35, CAN$45     Γöé            Γöé    ΓöéIt describes the OS/2 programming      Γöé
  1076. Γöé                                  Γöé            Γöé    Γöéenvironment well, and thus helps you   Γöé
  1077. Γöé                                  Γöé            Γöé    Γöémake the proper choices in designing   Γöé
  1078. Γöé                                  Γöé            Γöé    Γöéapplications.  Highly recommended to   Γöé
  1079. Γöé                                  Γöé            Γöé    Γöéanyone creating more than just         Γöé
  1080. Γöé                                  Γöé            Γöé    Γöécommand-line tools and very small      Γöé
  1081. Γöé                                  Γöé            Γöé    Γöéprograms.                              Γöé
  1082. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1083.  
  1084. This table contains all books I have reviewed, so that you can find what you 
  1085. are looking for at a glance.  I will be careful to rate books fairly.  If I 
  1086. feel a need to adjust ratings, I will adjust all of them at the same time, and 
  1087. write a note explaining why I felt this necessary.  Please note that books 
  1088. aimed at different audiences should only be compared with great care, if at 
  1089. all.  I intend to concentrate on the strong points of the books I review, but I 
  1090. will point out any weaknesses in a constructive manner. 
  1091.  
  1092. LEGEND: 
  1093.  
  1094. BOOK:  The name of the book, author(s), publishing company, ISBN, and 
  1095. approximate price. 
  1096.  
  1097. AUDIENCE:  This is a description of the audience I think the book targets best. 
  1098. This is not intended as gospel, just a guideline for people not familiar with 
  1099. the book. 
  1100.  
  1101. MARK:  My opinion of the success of the book's presentation, and how well it 
  1102. targets its audience.  Technical content, accuracy, organization, readability, 
  1103. and quality of index all weigh heavily here, but the single most important item 
  1104. is how well the book covers what it says it covers.  Many books try to cover 
  1105. too much, and get a lower mark as a result. 
  1106.  
  1107. ΓöîΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1108. ΓöéA+ ΓöéGround-breaking, all-around outstanding book                               Γöé
  1109. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1110. ΓöéA  ΓöéExcellent book.  This is what I want to see happen a lot                   Γöé
  1111. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1112. ΓöéA- ΓöéExcellent book with minor flaws                                            Γöé
  1113. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1114. ΓöéB+ ΓöéVery good book with minor flaws or omissions                               Γöé
  1115. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1116. ΓöéB  ΓöéGood book with some flaws and omissions                                    Γöé
  1117. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1118. ΓöéB- ΓöéGood book, but in need of improvement                                      Γöé
  1119. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1120. ΓöéC+ ΓöéMediocre book with some potential, but in need of some updating            Γöé
  1121. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1122. ΓöéC  ΓöéMediocre book with some good sections, but badly in need of fixing         Γöé
  1123. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1124. ΓöéC- ΓöéMediocre book, little good material, desperately in need of an overhaul    Γöé
  1125. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1126. ΓöéD  ΓöéDon't buy this book unless you need it, and nothing else exists            Γöé
  1127. Γö£ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1128. ΓöéF  ΓöéDon't buy this book.  Period                                               Γöé
  1129. ΓööΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1130.  
  1131. COMMENTS:  This is a very brief summary of the review proper. 
  1132.  
  1133. /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1134.  
  1135.  
  1136. ΓòÉΓòÉΓòÉ 4.6. Content Index ΓòÉΓòÉΓòÉ
  1137.  
  1138. Content Index 
  1139.  
  1140. This Content Index is designed to let you find the book that covers the topics 
  1141. you need to learn about.  It will eventually have a lot of categories, with 
  1142. each book being rated along each row.  These tables will be quite large, and 
  1143. will continually grow, so please give me your feedback regarding what 
  1144. categories you would like to see, and which you don't.  It may take me a while 
  1145. to flesh them out, so have a little patience. 
  1146.  
  1147. Note:  books which cover the same material can look similar in this table, but 
  1148. be different in real life.  The style of a book, for example, can not be seen 
  1149. from a quick table, so make sure that you follow up by reading the reviews of 
  1150. the books you find here.  Finally, be sure that the books you are comparing are 
  1151. aimed at the same audiences. 
  1152.  
  1153. PM BOOKS: 
  1154.  
  1155. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1156. ΓöéBOOK ΓöéMARK ΓöéKernel ΓöéDevice ΓöéVIO andΓöéPM     ΓöéGPI    ΓöéFonts  ΓöéPrint  Γöé
  1157. Γöé     Γöé     ΓöéBasics ΓöéDriver ΓöéAVIO   ΓöéIntro  Γöé       Γöé       Γöé       Γöé
  1158. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1159. ΓöéRWP  ΓöéB+   Γöé2      Γöé0      Γöé0      Γöé4      Γöé4      Γöé4      Γöé3      Γöé
  1160. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1161. ΓöéPME  ΓöéB-   Γöé1      Γöé0      Γöé0      Γöé2      Γöé2      Γöé2      Γöé0      Γöé
  1162. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1163. ΓöéODD  ΓöéA    Γöé0      Γöé5      Γöé0      Γöé0      Γöé1      Γöé0      Γöé1      Γöé
  1164. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1165. ΓöéGPI  ΓöéC+   Γöé0      Γöé0      Γöé0      Γöé0      Γöé5      Γöé2      Γöé3      Γöé
  1166. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1167. ΓöéTAO  ΓöéB+   Γöé3      Γöé2      Γöé1      Γöé4      Γöé1      Γöé2      Γöé0      Γöé
  1168. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1169. ΓöéPMP  ΓöéA-   Γöé1      Γöé0      Γöé1      Γöé5      Γöé3      Γöé4      Γöé2      Γöé
  1170. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1171.  
  1172. SYSTEM AND DESIGN BOOKS: 
  1173.  
  1174. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1175. ΓöéBOOK ΓöéMARK ΓöéKernel ΓöéDevice ΓöéVIO andΓöéPM     ΓöéThreadsΓöéGPI    ΓöéFonts  ΓöéPrint  Γöé
  1176. Γöé     Γöé     Γöé       ΓöéDriver ΓöéAVIO   Γöé       Γöé       Γöé       Γöé       Γöé       Γöé
  1177. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1178. ΓöéDOA  ΓöéA    Γöé4      Γöé4      Γöé2      Γöé4      Γöé5      Γöé3      Γöé2      Γöé3      Γöé
  1179. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1180.  
  1181. REXX BOOKS: 
  1182.  
  1183. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1184. ΓöéBOOK ΓöéMARK ΓöéREXX     ΓöéWPS      ΓöéReferenceΓöé
  1185. Γöé     Γöé     ΓöéIntro    Γöé         Γöé         Γöé
  1186. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1187. ΓöéMOR  ΓöéB    Γöé4        Γöé0        Γöé2        Γöé
  1188. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1189. ΓöéRSH  ΓöéA    Γöé1        Γöé2        Γöé5        Γöé
  1190. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1191. ΓöéADO  ΓöéA-   Γöé3        Γöé2        Γöé4        Γöé
  1192. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1193.  
  1194. BOOK LEGEND: 
  1195.  
  1196. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1197. ΓöéReal-World Programming for OS/2 2.1                                ΓöéRWP  Γöé
  1198. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1199. ΓöéLearning to Program OS/2 2.0 Presentation Manager by Example       ΓöéPME  Γöé
  1200. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1201. ΓöéWriting OS/2 2.1 Device Drivers in C, 2nd Edition                  ΓöéODD  Γöé
  1202. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1203. ΓöéOS/2 Presentation Manager GPI                                      ΓöéGPI  Γöé
  1204. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1205. ΓöéThe Art of OS/2 2.1 C Programming                                  ΓöéTAO  Γöé
  1206. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1207. ΓöéMastering OS/2 REXX                                                ΓöéMOR  Γöé
  1208. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1209. ΓöéREXX Reference Summary Handbook                                    ΓöéRSH  Γöé
  1210. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1211. ΓöéApplication Development Using OS/2 REXX                            ΓöéADO  Γöé
  1212. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1213. ΓöéOS/2 Presentation Manager Programming                              ΓöéPMP  Γöé
  1214. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1215. ΓöéDesigning OS/2 Applications                                        ΓöéDOA  Γöé
  1216. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1217.  
  1218. RATINGS LEGEND: 
  1219.  
  1220. ΓöîΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1221. Γöé0ΓöéNo coverage           Γöé
  1222. Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1223. Γöé1ΓöéVery light coverage   Γöé
  1224. Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1225. Γöé2ΓöéIntroductory coverage Γöé
  1226. Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1227. Γöé3ΓöéGood Coverage         Γöé
  1228. Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1229. Γöé4ΓöéIn-depth coverage     Γöé
  1230. Γö£ΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1231. Γöé5ΓöéAuthoritative         Γöé
  1232. ΓööΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1233.  
  1234. /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1235.  
  1236.  
  1237. ΓòÉΓòÉΓòÉ 4.7. Coming Up ΓòÉΓòÉΓòÉ
  1238.  
  1239. Coming Up 
  1240.  
  1241. I am running a little low on books at the moment, but there is relief in sight. 
  1242. Next month I may be looking at OS/2 Presentation Manager GPI, 2nd edition, 
  1243. Winn.  The following are the books I intend to review, in no particular order. 
  1244.  
  1245.      OS/2 Presentation Manager GPI, 2nd edition, Winn 
  1246.      OS/2 Unleashed, Moskowitz and Kerr 
  1247.      The Design of OS/2, 2nd Edititon, Kogan and Deitel 
  1248.      Designing High Powered OS/2 Applications, Reich (tentative title) 
  1249.  
  1250.  I am considering reviewing the IBM OS/2 Redbooks, since they are readily and 
  1251.  cheaply available, and look like good reference. 
  1252.  
  1253.  If anyone has a book they want to see reviewed, I will be happy to oblige. 
  1254.  Just mail me and tell me.  Publishers can send me books at the address on my 
  1255.  personal page at the end of the magazine, and I will review all OS/2 
  1256.  development-related and advanced user books I receive. 
  1257.  
  1258.  /dev/EDM2/BookReview - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1259.  
  1260.  
  1261. ΓòÉΓòÉΓòÉ 5. C++ Corner ΓòÉΓòÉΓòÉ
  1262.  
  1263.  
  1264. ΓòÉΓòÉΓòÉ 5.1. Introduction ΓòÉΓòÉΓòÉ
  1265.  
  1266. C++ Corner 
  1267.  
  1268. Written by Gordon Zeglinski 
  1269.  
  1270. Introduction 
  1271.  
  1272. Having a large collection of C++ objects, I was motivated to see if and how I 
  1273. could use these objects within a SOM object.  To keep things nice and familiar, 
  1274. let's use the profile (INI) file manipulation objects as our test case. 
  1275.  
  1276. C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1277.  
  1278.  
  1279. ΓòÉΓòÉΓòÉ 5.2. Using C++ Objects in SOM ΓòÉΓòÉΓòÉ
  1280.  
  1281. Using C++ Objects in SOM 
  1282.  
  1283. In the second SOM article, we compared SOM and C++ versions of objects designed 
  1284. to manipulate profile files.  In each of these objects we went to the OS/2 API 
  1285. to access the profile file.  This time, the SOM object will use the C++ object 
  1286. to manipulate the profile file. 
  1287.  
  1288. The hardest part of this task is determining how to define things in a manner 
  1289. that SOM will accept.  Utilizing structures from other languages in SOM seems 
  1290. somewhat cumbersome to me.  Pointer types are not supported by CORBA, which 
  1291. makes sense given the cross platform nature of CORBA.  Ideally, we want some 
  1292. way of storing a pointer to the instance of the C++ object within our SOM 
  1293. object.  Recall that in the IDL file, when you declare an instance of a SOM 
  1294. object within another object, that instance is accessed through a pointer in 
  1295. the C/C++ bindings.  Also in SOM, you can declare an object "type"  without 
  1296. defining it's body.  What if we declared an object type and then later included 
  1297. C++ headers that defined a C++ object as the formentioned "object type"? 
  1298.  
  1299. Using this idea, we create the following IDL file. 
  1300.  
  1301. interface ProfileFile;
  1302.  
  1303. interface SOM_CPPini : SOMObject
  1304. {
  1305.    typedef unsigned long ULONG;
  1306.    typedef sequence<char> buffType;
  1307.  
  1308.    void OpenFile(in string FileName);
  1309.    ULONG GetError();
  1310.  
  1311.    unsigned long GetHandle();
  1312.    void SetHandle(in unsigned long H);
  1313.  
  1314.    void  WriteString(in string App,in string Key, in string String);
  1315.          // write a string
  1316.  
  1317.    void  WriteData(in string App, in string Key,in buffType Buff,in ULONG BLen);
  1318.          // write the Buffer
  1319.  
  1320.    void  WriteInt(in string App,in string Key,in long Num);
  1321.          // write an "int"
  1322.  
  1323.    ULONG GetDataSize(in string App,in string Key);
  1324.          // return the lenght of the data
  1325.  
  1326.    void  GetData(in string App,in string Key,in buffType Buff, inout ULONG BufMax);
  1327.          // return the data in Buff
  1328.  
  1329.    ULONG GetString(in string App,in string Key,in buffType Buff,in ULONG BufMax, \
  1330.             in string DefArg);
  1331.          // return the String in Buff, defaults to DefArg if App/Key not present
  1332.  
  1333.    ULONG GetStringNoDef(in string App,in string Key,in buffType Buff,in ULONG BufMax);
  1334.          // return the String in Buff
  1335.  
  1336.    long  GetInt(in string App,in string Key,in long DefArg);
  1337.          // return the "int" in App/Key or the DefArg if App/Key not present
  1338.  
  1339.    long  GetIntNoDef(in string App,in string Key);
  1340.          // return the "int" in App/Key
  1341.  
  1342. #ifdef __SOMIDL__
  1343. implementation
  1344. {
  1345.     ProfileFile INIFile;
  1346.  
  1347.     releaseorder: GetHandle,SetHandle,GetError,OpenFile, \
  1348.                   WriteString,WriteData,WriteInt,GetDataSize,GetData,GetString,GetStringNoDef, \
  1349.                   GetInt,GetIntNoDef;
  1350.  
  1351.     callstyle=oidl;
  1352.     filestem = somcpp;
  1353.     somInit: override;  // initialize instance variables to 0
  1354.     somUninit: override; // just for fun
  1355.  
  1356.     passthru C_xh_after=   "#define INCL_WINSHELLDATA" \
  1357.                            "#include <os2.h>" \
  1358.                            "#include \"iniflobj.h\"";
  1359.  
  1360.  
  1361. };
  1362. #endif /* __SOMIDL__ */
  1363. };
  1364.  
  1365. The line interface ProfileFile; declares a "SOM object" with the same name as 
  1366. the "C++ Object" which manipulates the profile files.  This object name is then 
  1367. used within the SOM object definition to declare an instance of ProfileFile. 
  1368. The passthru section of the SOM object definition, is used to include the C++ 
  1369. header files that declare the C++ object, ProfileFile.  The C++ SOM bindings 
  1370. allow SOM and C++ objects to be intermixed without any major syntax 
  1371. differences.  Following is the source code for MAIN.CPP. 
  1372.  
  1373. void main(){
  1374.    int i;
  1375.  
  1376.    SOM_CPPini *Prf=new SOM_CPPini;
  1377.  
  1378.    Prf->OpenFile("Test.ini");
  1379.  
  1380.    Prf->WriteInt("App","Key",10);
  1381.    i=Prf->GetIntNoDef("App","Key");
  1382.  
  1383.    printf("i= %i\r\n",i);
  1384.  
  1385.    delete Prf;
  1386. }
  1387.  
  1388. The new operator is used to create an instance of the SOM object, SOM_CPPini. 
  1389. Thereafter, the -> operator is used to access its member functions.  Following 
  1390. is a snippet of code from the file SOMCPP.CPP. 
  1391.  
  1392. SOM_Scope void  SOMLINK OpenFile(SOM_CPPini *somSelf, string FileName)
  1393. {
  1394.     SOM_CPPiniData *somThis = SOM_CPPiniGetData(somSelf);
  1395.     SOM_CPPiniMethodDebug("SOM_CPPini","OpenFile");
  1396.  
  1397.    if(somThis->INIFile)
  1398.       delete somThis->INIFile;
  1399.  
  1400.    somThis->INIFile=new ProfileFile(FileName,0);
  1401.  
  1402. }
  1403.  
  1404. SOM_Scope SOM_CPPini_ULONG  SOMLINK GetError(SOM_CPPini *somSelf)
  1405. {
  1406.     SOM_CPPiniData *somThis = SOM_CPPiniGetData(somSelf);
  1407.     SOM_CPPiniMethodDebug("SOM_CPPini","GetError");
  1408.  
  1409.     /* Return statement to be customized: */
  1410.     { SOM_CPPini_ULONG retVal;
  1411.       if(somThis->INIFile)
  1412.          retVal=somThis->INIFile->GetError();
  1413.       else
  1414.          retVal=1;
  1415.  
  1416.       return (retVal); }
  1417. }
  1418.  
  1419. Remember that somThis->INIFile is a pointer to an instance of a C++ object. 
  1420. Outside of the new ProfileFile(FileName,0); statement, the instantizing the C++ 
  1421. and SOM objects is the same.  This difference is due to the different way SOM 
  1422. and C++ handle constructors. Methods are called using the same syntax.  This 
  1423. allows for a fairly consistent style when mixing C++ and SOM objects. 
  1424.  
  1425. C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1426.  
  1427.  
  1428. ΓòÉΓòÉΓòÉ 5.3. Wrapping Things Up ΓòÉΓòÉΓòÉ
  1429.  
  1430. Wrapping Things Up 
  1431.  
  1432. Although a fairly simple example was presented here, we have seen that C++ and 
  1433. SOM objects can be intermixed within a program and still maintain good 
  1434. readability.  C++ objects can be used as data members of SOM objects to provide 
  1435. lower level support for the SOM methods.  This type of interoperability allows 
  1436. one to exploit each OOP model for it's unique features.  C++ is still faster 
  1437. than SOM, but SOM provides a much richer environment.  In future articles, we 
  1438. will look at DSOM and the new 2.1 SOM toolkit. 
  1439.  
  1440. C++ Corner - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1441.  
  1442.  
  1443. ΓòÉΓòÉΓòÉ 6. Introduction to PM Programming ΓòÉΓòÉΓòÉ
  1444.  
  1445.  
  1446. ΓòÉΓòÉΓòÉ 6.1. Introduction ΓòÉΓòÉΓòÉ
  1447.  
  1448. Introduction to PM Programming 
  1449.  
  1450. Written by Larry Salomon, Jr. 
  1451.  
  1452. Introduction 
  1453.  
  1454. The purpose of this column is to provide the readers out there who are not 
  1455. familiar with PM application development the information necessary to satisfy 
  1456. their curiosity, educate themselves, and give them an advantage over the 
  1457. documentation supplied by IBM.  Of course, much of this stuff could probably be 
  1458. found in one of the many books out there, but the problem with books in general 
  1459. is that they don't answer the questions you have after you read the book the 
  1460. first time through. 
  1461.  
  1462. I will gladly entertain feedback from the readers about what was "glossed over" 
  1463. or what was detailed well, what tangential topics need to be covered and what 
  1464. superfluous crap should have been removed.  This feedback is essential in 
  1465. guaranteeing that you get what you pay for.  <grin> 
  1466.  
  1467. It should be said that you must not depend solely on this column to teach you 
  1468. how to develop PM applications; instead, this should be viewed as a supplement 
  1469. to your other information storehouses (books, the network conferences, etc.). 
  1470. Because this column must take a general approach, there will be some topics 
  1471. that you would like to see discussed that really do not belong here.  Specific 
  1472. questions can be directed to me via email and I will do my best to answer them 
  1473. in a timely fashion. 
  1474.  
  1475. Last Month 
  1476.  
  1477. Last month, we began looking at the WC_LISTBOX class.  This month, we will take 
  1478. a good look at the ownerdraw capabilities of this control class. 
  1479.  
  1480. Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1481.  
  1482.  
  1483. ΓòÉΓòÉΓòÉ 6.2. A Message For You, Sir ΓòÉΓòÉΓòÉ
  1484.  
  1485. A Message For You, Sir 
  1486.  
  1487. Each month before I write the next installment of this column, I re-read what I 
  1488. wrote the prior month to discover what I have covered in order to determine in 
  1489. what direction I should continue.  As I read last month's column, it became 
  1490. apparent that the message reference which I capitulated each month is nothing 
  1491. more than a rehash of what's available in many sources, including the on-line 
  1492. programming references and many books.  I would like to discontinue my 
  1493. inclusion of this information, given this enlightening of mine, unless the 
  1494. teeming masses tell me that I should do otherwise.  Any feedback on this would 
  1495. be appreciated. 
  1496.  
  1497. Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1498.  
  1499.  
  1500. ΓòÉΓòÉΓòÉ 6.3. This Isn't Picasso ΓòÉΓòÉΓòÉ
  1501.  
  1502. This Isn't Picasso 
  1503.  
  1504. But ownerdraw listboxes give you quite an opportunity to do some interesting 
  1505. things.  For the original LaMail product from IBM, I wrote a LaGrep utility 
  1506. which searched mail folders for text.  The found text was displayed in a 
  1507. listbox in a different color than the rest. Additionally, the configuration 
  1508. options allowed to you change the color that the text was displaying using, and 
  1509. the color selection was displayed in a listbox with the name of the color next 
  1510. to it.  Both of these are perfectly valid, real-world examples of ownerdraw 
  1511. listboxes, and while there might be other window classes better suited for 
  1512. these tasks, knowing how the ownerdraw capabilities work is a useful asset to 
  1513. have tucked in your cap. 
  1514.  
  1515. The ownerdraw architecture with regard to listboxes is represented by two 
  1516. messages, which - incidentally - are used in ownerdraw menuitems in a very 
  1517. similar fashion.  These messages are the WM_MEASUREITEM and WM_DRAWITEM and 
  1518. their purpose is just as their names suggest.  The former message is sent, 
  1519. usually upon the creation of the listbox, to determine the maximum height and 
  1520. (if LS_HORZSCROLL) maximum width of the items to be displayed.  The result is 
  1521. returned to the listbox as MRFROM2SHORT(height,width).  The latter message is 
  1522. where all of the work is done and is sent whenever an item needs to be redrawn. 
  1523. PVOIDFROMMP(mpParm2) points to an OWNERITEM structure, but you won't find its 
  1524. definition in the listbox section of PMWIN.H.  You have to look in the menu 
  1525. section to find it, which is the following: 
  1526.  
  1527. typedef struct _OWNERITEM {
  1528.    HWND hwnd;
  1529.    HPS hps;
  1530.    ULONG fsState;
  1531.    ULONG fsAttribute;
  1532.    ULONG fsStateOld;
  1533.    ULONG fsAttributeOld;
  1534.    RECTL rclItem;
  1535.    LONG idItem;
  1536.    ULONG hItem;
  1537. } OWNERITEM, *POWNERITEM
  1538.  
  1539. hwnd is the handle of the control.  hps is the handle to the presentation space 
  1540. which must be used for drawing.  fsState and fsStateOld are, when the structure 
  1541. refers to an ownerdraw listbox, BOOLs which are TRUE if the item is selected 
  1542. and FALSE otherwise (fsStateOld is the selection state of the item the last 
  1543. time it was drawn).  fsAttribute and fsAttributeOld are not used when dealing 
  1544. with ownerdraw listboxes. rclItem is the bounding rectangle of the item to be 
  1545. drawn. idItem is the index of the item to be drawn.  hItem is the item handle, 
  1546. if set. 
  1547.  
  1548. It needs to be noted that, if the listbox is ownerdraw, PM will not do anything 
  1549. on your behalf except paint the highlight state of the item to be drawn.  It 
  1550. does this using an XOR operation only if fsState and fsStateOld are different. 
  1551. There is no way to change this unless you know that the OWNERITEM structure is 
  1552. what the listbox checks upon return from this message when it determines if it 
  1553. needs to highlight the item or not.  So, if you set fsState and fsStateOld to 
  1554. the same value before returning, PM will not do anything at all. 
  1555.  
  1556. The nice thing about the first sentence in the last paragraph is that PM 
  1557. doesn't even look at the item text for you.  Thus, you could interpret the text 
  1558. in a different way that would normally be done - for LaGrep, I changed the 
  1559. color by putting a tab character in the text followed by a BYTE which was an 
  1560. index into an array of CLR_* constants.  When I painted the control, I did not 
  1561. draw this special sequence but used it to control the drawing. 
  1562.  
  1563. The possibilities are endless and are only limited by your imagination. 
  1564.  
  1565. Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1566.  
  1567.  
  1568. ΓòÉΓòÉΓòÉ 6.4. API of the Month Club ΓòÉΓòÉΓòÉ
  1569.  
  1570. API of the Month Club 
  1571.  
  1572. Our API of the month is the one that the listbox uses to XOR the highlight of 
  1573. an item. 
  1574.  
  1575. (BOOL)WinInvertRect(HPS hpsWnd,PRECTL prclRect);
  1576.  
  1577. hpsWnd is the handle to the HPS to invert within. prclRect points to the 
  1578. rectangle specifying the area to be inverted.  Inversion here refers to the 
  1579. inversion of the colors within the rectangle.  Thus, black becomes white, white 
  1580. becomes black, etc. 
  1581.  
  1582. Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1583.  
  1584.  
  1585. ΓòÉΓòÉΓòÉ 6.5. Next Month ΓòÉΓòÉΓòÉ
  1586.  
  1587. Next Month 
  1588.  
  1589. I need to get upon my soapbox for a moment. 
  1590.  
  1591. As I looked through the past issues to see where this column has gone already, 
  1592. in order to determine what shall be discussed next, I saw that, much to my 
  1593. embarrassment, the listbox window class has already been discussed. Yet, this 
  1594. is the third month in my second treatment of the topic and I never would have 
  1595. known because the silence from my audience is deafening.  The embarrassment is 
  1596. not what I am worried about; I am instead concerned about providing a quality 
  1597. column, yet no one bothered to tell me that I was simply rehashing a topic that 
  1598. was discussed just a few months prior. 
  1599.  
  1600. Please give me feedback!  How else can I say it?  I need to know what you 
  1601. think, where we should go next, etc.  Since I have always considered the 
  1602. button, entryfield, and listbox classes to be the "simple" classes, it is more 
  1603. important now because I need to know what class should be discussed next. 
  1604. Should it be the menu, or the static?  Should it be the scrollbar, or the 
  1605. titlebar?  Please let me know; this humble request alone I make. 
  1606.  
  1607. Introduction to PM Programming - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1608.  
  1609.  
  1610. ΓòÉΓòÉΓòÉ 7. Contributors to this Issue ΓòÉΓòÉΓòÉ
  1611.  
  1612. Are You a Potential Author? 
  1613.  
  1614. We are always looking for (new) authors.  If you have a topic about which you 
  1615. would like to write, send a brief description of the topic electronically to 
  1616. any of the editors, whose addresses are listed below, by the 15th of the month 
  1617. before the month in which your article will appear.  This alerts us that you 
  1618. will be sending an article so that we can plan the issue layout accordingly. 
  1619. After you have done this, get the latest copy of the Article Submission 
  1620. Guidelines from ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory. 
  1621. (The file is artsub.zip.)  The completed text of your article should be sent to 
  1622. us no later than five days prior to the last day of the month; any articles 
  1623. received after that time may be pushed to the next issue. 
  1624.  
  1625. The editors can be reached at the following email addresses: 
  1626.  
  1627.      Larry Salomon - os2man@panix.com (Internet). 
  1628.      Carsten Whimster - bcrwhims@undergrad.math.uwaterloo.ca (Internet). 
  1629.  
  1630.  The following people contributed to this issue in one form or another (in 
  1631.  alphabetical order): 
  1632.  
  1633.      Larry Salomon, Jr. 
  1634.      Carsten Whimster 
  1635.      Johan Wikman 
  1636.      Gordon Zeglinski 
  1637.      Network distributors 
  1638.  
  1639.  Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1640.  
  1641.  
  1642. ΓòÉΓòÉΓòÉ 7.1. Larry Salomon, Jr. ΓòÉΓòÉΓòÉ
  1643.  
  1644. Larry Salomon, Jr. 
  1645.  
  1646. Larry Salomon, Jr. wrote his first Presentation Manager application for OS/2 
  1647. version 1.1 in 1989.  Since that time, he has written numerous VIO and PM 
  1648. applications, including the Scramble applet included with OS/2 and the 
  1649. I-Brow/Magnify/Screen Capture trio being distributed by IBM with the 
  1650. Professional Developers Kit CD-ROM.  Currently, he works for Cheyenne Software 
  1651. in Roslyn, New York and resides in Bellerose, New York with his wife Lisa. 
  1652.  
  1653. Larry can be reached electronically via the Internet at os2man@panix.com. 
  1654.  
  1655. Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1656.  
  1657.  
  1658. ΓòÉΓòÉΓòÉ 7.2. Carsten Whimster ΓòÉΓòÉΓòÉ
  1659.  
  1660. Carsten Whimster 
  1661.  
  1662. Carsten is an undergraduate Computer Science student at the University of 
  1663. Waterloo.  He is currently in third year, and is enjoying it immensely.  He 
  1664. uses Watcom C/C++ 10.0 and Watcom VX-REXX 2.0b. 
  1665.  
  1666. Carsten is the author of some commandline utilities and POV-Panel/2, a popular 
  1667. shareware dashboard-like front-end for the POV-Ray 2.x compilers. POV-Panel/2 
  1668. can be found on ftp-os2.cdrom.com in pub/os2/32bit/graphics and some of the 
  1669. other major OS/2 ftp sites.  He is also a TEAM-OS/2 member, and has adopted a 
  1670. little computer store called The Data Store in Waterloo, Ontario. 
  1671.  
  1672. You may reach Carsten... 
  1673.  
  1674. ...via email: 
  1675.  
  1676. bcrwhims@undergrad.math.uwaterloo.ca - Internet 
  1677.  
  1678. ...Web homepage (I am just setting it up, so it may or may not be on-line): 
  1679.  
  1680. http://www.undergrad.math.uwaterloo.ca/~bcrwhims  - WWW 
  1681.  
  1682. ...via snail mail (notice the changed address): 
  1683.  
  1684. Carsten Whimster
  1685. 318A Spruce Street
  1686. Waterloo, Ontario
  1687. Canada
  1688. N2L 3M7
  1689.  
  1690. Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1691.  
  1692.  
  1693. ΓòÉΓòÉΓòÉ 7.3. Johan Wikman ΓòÉΓòÉΓòÉ
  1694.  
  1695. Johan Wikman 
  1696.  
  1697. Johan Wikman received his Master's degree in Computer Science with a thesis 
  1698. "Adding remote execution capability to operating systems".  He has been 
  1699. programming for OS/2, using C++, ever since 1990. 
  1700.  
  1701. Currently he works for Nokia Telecommunications where he takes part in a 
  1702. project that developes network management software in a Unix environment.  In 
  1703. his sparetime he continues working on RMX-OS2, a system that provides remote 
  1704. execution for OS/2. 
  1705.  
  1706. Johan can be reached electronically via the Internet at 
  1707. johan.wikman@ntc.nokia.com, or via ordinary mail: 
  1708.  
  1709. Johan Wikman
  1710. Smedjeviksvagen 23 B 22
  1711. FI-00200 Helsinki
  1712. FINLAND
  1713.  
  1714. Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1715.  
  1716.  
  1717. ΓòÉΓòÉΓòÉ 7.4. Gordon Zeglinski ΓòÉΓòÉΓòÉ
  1718.  
  1719. Gordon Zeglinski 
  1720.  
  1721. Gordon Zeglinski is a freelance programmer/consultant who received his Master's 
  1722. degree in Mechanical Engineering with a thesis on C++ sparse matrix objects. 
  1723. He has been programming in C++ for 6 years and also has a strong background in 
  1724. FORTRAN.  He started developing OS/2 applications with version 2.0 . 
  1725.  
  1726. His current projects include a client/server communications program that 
  1727. utilitizes OS/2's features which has entered beta testing.  Additionally, he is 
  1728. involved in the development of a "real-time" automated vehicle based on OS/2 
  1729. and using C++ in which he does device driver development and designs the 
  1730. applications that comprise the control logic and user interface. 
  1731.  
  1732. He can be reached via the Internet at zeglins@cc.umanitoba.ca. 
  1733.  
  1734. Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1735.  
  1736.  
  1737. ΓòÉΓòÉΓòÉ 7.5. Network distributors ΓòÉΓòÉΓòÉ
  1738.  
  1739. Network Distributors 
  1740.  
  1741. These people are part of our distribution system to provide EDM/2 on networks 
  1742. other than the Internet.  Their help to provide access to this magazine for 
  1743. others is voluntary and we appreciate them a lot! 
  1744.  
  1745.      Paul Hethmon (hethmon@apac.ag.utk.edu) - Compuserve 
  1746.      Gess Shankar (gess@knex.mind.org) - Internet 
  1747.      Jason B. Tiller (PeerGynt@aol.com) - America On-line 
  1748.      David Singer (singer@almaden.ibm.com) - IBM Internal 
  1749.      Andre Asselin (ASSELIN AT RALVM12) - IBM Internal 
  1750.  
  1751.  If you would like to become a "network distributor", be sure to contact the 
  1752.  editors so that we can give you the credit you deserve! 
  1753.  
  1754.  Contributors - EDM/2 - Jan 1995 - Volume 3, Issue 1 
  1755.  
  1756.  
  1757. ΓòÉΓòÉΓòÉ 8. How Do I Get EDM/2? ΓòÉΓòÉΓòÉ
  1758.  
  1759. How Do I Get EDM/2? 
  1760.  
  1761. EDM/2 can be obtained in any of the following ways: 
  1762.  
  1763. On the Internet 
  1764.  
  1765.      All back issues are available via anonymous FTP from the following sites: 
  1766.         -  ftp.cdrom.com in the /pub/os2/2_x/program/newsltr directory. 
  1767.         -  ftp.luth.se in the /pub/os2/programming/newsletter directory. 
  1768.         -  generalhq.pc.cc.cmu.edu in the /pub/newsletters/edm2 directory. 
  1769.      The EDM/2 mailing list.  Send an empty message to edm2-info@knex.mind.org 
  1770.       to receive a file containing (among other things) instructions for 
  1771.       subscribing to EDM/2.  This is a UUCP connection, so be patient please. 
  1772.      IBM's external gopher/WWW server in Almaden. The address is 
  1773.       index.almaden.ibm.com and it is in the "Non-IBM-Originated" submenu of 
  1774.       the "OS/2 Information" menu; the URL is 
  1775.       "gopher://index.almaden.ibm.com/1nonibm/os2nonib.70". 
  1776.  
  1777.  On Compuserve 
  1778.  
  1779.  All back issues are available in the OS/2 Developers Forum 2. 
  1780.  
  1781.  IBM Internal 
  1782.  
  1783.      IBM's internal gopher/WWW server in Almaden. The address is 
  1784.       n6tfx.almaden.ibm.com and it is in the "Non-IBM-Originated Files" menu; 
  1785.       the URL is "gopher://n6tfx.almaden.ibm.com/1!!nonibm/nonibm.70". 
  1786.      IBM's REQUEST command on all internal VM systems.  Enter the VM command 
  1787.       REQUEST LIST FROM ASSELIN AT RALVM12 and a list of the requestable 
  1788.       packages will be sent to you; in this list are the names of the packages 
  1789.       containing the EDM/2 issues. 
  1790.  
  1791.  How do I Get EDM/2? - EDM/2 - Jan 1995 - Volume 3, Issue 1