





              WW     WW     WW      PPPPPPPP              JJ
              WW     WW     WW      PP    PP              JJ
               WW   WWWW   WW       PP    PP              JJ
               WW  WW  WW  WW       PPPPPPPP              JJ
               WW  WW  WW  WW       PP             JJ     JJ
                WWWW    WWWW        PP              JJ   JJ
                 WW      WW         PP               JJJJJ

          ----------------------------------------------------------------
          The Windows Programmer's Journal                       Volume 01
          Copyright 1993 by Peter J. Davis                       Number 06
          and Mike Wallace                                          Jun 93
          ----------------------------------------------------------------
          A monthly  forum for  novice-advanced programmers to  share ideas
          and concepts  about programming in the  Windows (tm) environment.
          Each  issue is uploaded  to the info systems  listed below on the
          first of the month, but made available at the convenience  of the
          sysops, so allow for a couple of days.

          You can get in touch with the editors via Internet or Bitnet at:

          HJ647C at GWUVM.BITNET   or   HJ647C at GWUVM.GWU.EDU  (Pete)

          CompuServe: 71141,2071 (Mike)

          GEnie: P.DAVIS5

          or you can send paper mail to:

          Windows Programmer's Journal
          9436 Mirror Pond Dr.
          Fairfax, Va. 22032

          We can also be reached by phone at: (703) 503-3165.

          The WPJ BBS can be reached at: (703) 503-3021.

          The WPJ  BBS  is currently  2400 Baud  (8N1). We'll  be going  to
          14,400 in the near future, we hope.

















                                     LEGAL STUFF


          - Microsoft,  MS-DOS, Microsoft Windows, Windows  NT, Windows for
          Workgroups,  Windows for  Pen  Computing, Win32,  and Win32S  are
          registered trademarks of Microsoft Corporation.

          -  Turbo Pascal for Windows,  Turbo C++ for  Windows, and Borland
          C++   for   Windows   are   registered   trademarks   of  Borland
          International.

          -   WordPerfect   is  a   registered  trademark   of  WordPerfect
          Corporation.

          - Other  trademarks mentioned  herein are the  property of  their
          respective owners.

          -  WPJ is available from the WINSDK, WINADV and MSWIN32 forums on
          CompuServe, and  the IBMPC, WINDOWS and BORLAND  forums on Genie.
          It  is also  available  on  America  Online  in  the  Programming
          library.   On Internet,  it's available on WSMR-SIMTEL20.ARMY.MIL
          and FTP.CICA.INDIANA.EDU.  We upload it by the 1st  of each month
          and it is usually available by  the 3rd or 4th, depending on when
          the sysops receive it.

          - The  Windows Programmer's  Journal takes no  responsibility for
          the  content of the  text within this  document. All  text is the
          property  and  responsibility  of  the  individual  authors.  The
          Windows  Programmer's Journal  is solely  a vehicle  for allowing
          articles to be  collected and distributed in a common and easy to
          share form.

          - No part of the Windows Programmer's Journal may be re-published
          or  duplicated in  part  or whole,  except  in the  complete  and
          unmodified form of the  Windows Programmer's Journal, without the
          express written permission of each individual author. The Windows
          Programmer's  Journal  may not  be  sold for  profit  without the
          express  written permission  of the  Publishers, Peter  Davis and
          Michael  Wallace,   and  only  then  after   they  have  obtained
          permission from the individual authors.















                              Table of Contents

          Subject                                        Page Author(s)
          --------------------------------------------------- ------
          WPJ.INI .....................................     4 Pete Davis

          Letters .....................................     8 Readers

          Beginner's Column ...........................    12 Dave Campbell

          Internally Yours ............................    15 Pete Davis

          Pascal in 21 Steps ..........................    18 Bill Lenson

          Moving Away from ...  .......................    29 Pete Davis

          C++ Beginner's Column .......................    30 Rodney Brown

          WPJ BBS Update ..............................    31 Pete Davis

          Windows Messaging ...........................    32 Mike Wallace

          WinEdit Review ..............................    35 Jeff Perkell

          White House Letter ..........................    38 Mike Strock

          Text Manager ................................    40 Mike Wallace

          Getting in Touch with Us ....................    42 Pete & Mike

          Last Page ...................................    43 Mike Wallace


          Windows Programmer's Journal Staff:

          Publishers ......................... Pete Davis and Mike Wallace
          Editor-in-Chief .................... Pete Davis
          Managing Editor .................... Mike Wallace
          Contributing Editor ................ Dave Campbell
          Contributing Editor ................ Bill Lenson
          Contributing Editor ................ Rodney Brown
          Contributing Editor ................ Mike Strock
                                              
          Contributing Writer ................ Jeff Perkell












                                       WPJ.INI
                                    by Pete Davis

               Ah, it's that time of month again (actually, a bit past it).
          As  usual,  we're  late.  Lately  we've  been  getting  VERY  FEW
          SUBMISSIONS!!!!! Come  on people, let's get  things moving along.
          I'm  serious, we're going to  have to switch  over to every other
          month if things  don't pick up. We get a lot  of mail from people
          saying, "yeah,  I want to  write about  ..." and we  say, "Great,
          let's see  it." But it  never shows  up. I hate  to start off  an
          issue complaining,  but  really...  Sure,  everyone's  busy,  but
          s   u   r   e   l   y   y   o   u   c   a   n   t   a   k   e   a
          few hours now and then to put together an article. Do you realize
          that if only  1% of  our readers actually  wrote an article  we'd
          have  more articles  than we  know what  to do  with? And  still,
          99.999% of you don't take the time to submit an article.

               I  know what  you're thinking,  what's in  it for  me? Well,
          let's  start with my story. Sure, I'm  one of the editors and the
          publishers, but this isn't exactly a 'real' magazine. Yet, I have
          signed a contract to write a book and I've got a two part article
          showing up in Dr. Dobb's Journal (more on this later).

               Does that  mean that any of you can do it? Actually, yes, it
          does.  I'm no genius, I'm just a  regular guy willing to take the
          time to  do the work. You  may remember Alex Federov,  one of our
          earliest  contributors. You can  look forward to  seeing his next
          article  in Dr. Dobb's Journal also! Not  to hack on Alex, he's a
          smart  guy and a good guy. His english isn't perfect. Reading his
          writing, you know  it's not his native  language, yet here  he is
          writing  for Dr. Dobb's Journal  only a few  months after writing
          for us. I'm not saying that  we're the reason he got published in
          Dr. Dobb's. But I doubt that writing his first few article for us
          did any damage.

               You'd be surprised who reads this magazine.  I only recently
          found  out  that  Rob  Burk, Editor  of  Windows/DOS  Developer's
          Journal  reads this magazine.  I know it has  been read by Andrew
          Schulman (see his  letter in Issue  #2). I am told  that Mitchell
          Waite  of the Waite Group Press has  also read it. Whether or not
          these  people read  it regularly  or not,  I don't know.  I'm not
          trying  to pat  myself on  the back  here, I'm  just saying  that
          articles written for our  magazine don't necessarily go unnoticed
          by others in the industry.

               I'm sorry to be going off like this, I should be chipper and
          happy, but I'd  just REALLY HATE to see this  magazine have to go
          to every other month. From the response I've gotten from a lot of
          our  readers, they  don't want  to see  that happen  either, yet,

                                        - 4 -









          where are their articles?

               Ok, enough of that, you  guys figure out if you want  to get
          it every month. Remember, it's only going to take a few of you to
          make the difference and if you're counting on  someone else to do
          it, forget it, they haven't done it yet.

               On to happier things... Yes, as  I mentioned, I have a  two-
          part  article  coming  out  in  Dr.  Dobb's   Journal  in  Andrew
          Schulman's "Undocumented Corner" column  (which happens to be the
          same one Alex  Federov's article is in). I don't  want to say too
          much about  it, basically because  I haven't checked  with Andrew
          about how much I can say. I will simply say it involves work I've
          been  doing  with the  aforementioned Ron  Burk  of W/DDJ  in the
          WinHelp area. There, that should get you wondering.

               I've been REAL  busy lately with  this and the book,  but it
          looks like  I might be picking up some relief in the near future,
          again, can't discuss it now, but maybe next month.

               Things  are looking  good for  Windows NT.  Looks like  it's
          going to  be shipping soon.  If you are a  Windows programmer and
          you have the  hardware, I highly recommend getting  it. If for no
          other reason, it's an incredible Windows development environment.
          I'm  serious, it's NICE. Don't you hate  it when you're testing a
          program, it crashes, and  you have to re-boot? Kiss  that problem
          good-bye.  Under NT, your  program crashes,  and the  session for
          that program  closes. Nothing  else is affected.  Everything else
          works just fine.

               Mike took a little flack for his 'review', last month, of an
          OS/2 2.1 review  in a popular  computer magazine.  At the time  I
          agreed with Mike, for the most part. You have  to understand that
          what  we  write in  WPJ.INI  and  the Last  Page  are  not to  be
          construed as fact  or serious (well, sometimes:  I'm dead serious
          about  switching  the magazine  to  every  other month!).  Mike's
          comments such as, "that useless operating system" is not meant to
          mean that OS/2  is useless,  just an expression  that he  doesn't
          like it.

               So, as I said, I agreed  with him at the time. Recently I've
          had a chance to use OS/2  2.1 quite a bit. Do I still  agree with
          Mike? Mostly, yes. I  had to install OS/2 2.1 three  times before
          it  would actually let me switch  between OS/2 boot and DOS boot,
          and  back  to OS/2.  The  first  two  installs it  wiped  out  my
          \OS2\SYSTEM  directory in the switch from DOS to OS/2. Now, after
          the third install (we're talking 18 disks and a real slow install
          program), it  works, sort of. It  still locks up quite  a bit. It

                                        - 5 -











          took me three re-boots the other day just to get  past my network
          requester startup.

               So,  my  opinions? I  don't think  OS/2 2.1  is particularly
          stable. I didn't think OS/2 2.0 was particularly stable either. I
          had many  of the same problems with it. OS/2 2.1 is  signficantly
          faster,  especially   for   running  Windows   Apps,  than   it's
          predecessor,  2.0. Still, as I  said, it's not  very stable. I'll
          admit  this was  a beta,  but let's  compare it  to another  beta
          product, NT.


               I've  installed all three beta  versions of NT.  Each one, I
          installed once and only  once. Each worked the first time. We did
          have a  small problem with the  October '92 version because  of a
          hardware  conflict which, once we posted a note on CompuServe, we
          received a fix within a few  days. That's not a bad turnaround in
          my  book. Try  getting  IBM to  send  you a  "STABLE"  version of
          OS/2...

               As far as OS/2 2.0 and 2.1 performance, I think they are
          both slow, for the most part. When compared with Windows NT,
          there's no comparison. NT is blazing fast. I keep waiting to
          smell smoke coming out of the computer. When OS/2 runs, for one
          thing, just booting up takes forever. Then, when you finally boot
          up, it crawls, even with a machine that is well above the minimum
          requirements.

               I  haven't  used  NT with  a  machine  at  the bare  minimum
          requirements, but I've used OS/2 on machines of equal caliber and
          there's no comparison.

               Ok,  so let me get my  flack, but that's my PERSONAL opinion
          of  OS/2 as  I have  experienced it. I  know there  are a  lot of
          people out  there that like it.  That's fine, I'm  not hacking on
          you. A lot of people  like Snickers. I don't, but it's  fine with
          me that they do. Understand? I think that was the way Mike wanted
          his article to be viewed. I think he's writing in response to one
          of the letters he got, so you can read that too.  I think this is
          enough about OS/2 for a magazine that doesn't cover it!

               On  to other topics, that damn WinHelp file. Well, we've had
          some problems with it in the past,  but I think we're going to be
          past them on  this issue. I say that because  I have been working
          with Ron  Burk and in the process have learned a great deal about
          WinHelp of which I was previously unaware. We'll have the bitmaps
          in this time.  We'll also  have the browse  buttons that we  keep
          getting complaints on. 

                                        - 6 -










               Our deepest thanks to Kerim Erden for a lot of the ideas and
          know-how to produce the WinHelp File. He came up with some really
          great ideas and  showed us  how to implement  them. We're  deeply
          indebted  to him  for  the help.  Hope  everyone enjoys  the  new
          format. So, sit back, fire  up Windows, and check out the  latest
          issue.

               Peace.

            _Pete Davis






                                        - 7 -










                                       Letters

          Date:  16-May-93 11:49 EDT
          From:  Ian Pawson [100015,1364]
          Subj:  WinStub

          Hi,

                  I was  interested  to read  the article  on enhancing  the
          WinStub program on page 31 of the May 93 issue.

                  To make  this a  truly generic  windows stub,  it needs  a
          couple  of minor modifications to enable it to launch ANY program
          to  which it is attatched.  The spawnlp() function  call needs to
          pass Windows the name of the .exe file so that Windows can run it
          after it has started. This is achieved by  using the argc[0] var.
          (Note  that  argv[0] is  the  full dos  path  name, not  just the
          program name.)

          Two lines need to be changed and one added, as shown below:

          #pragma argsused
          int main( int argc, char *argv[] )  // get command line
          Parameters

          returncode = spawnlp( P_WAIT, "win.com", " ", argv[0], NULL ); 
          // pass filename to Windows

                  The  added #pragma command  is just  to stop  the compiler
          complaining that argc is declared, but not used.

          Cheers, Ian.

          [Thanks for the note, Ian.  Good tip. - Ed.]

          ----------------------------------------------
          ------------------------

          From: Jeff Miller <jmiller@hp1.terra.colostate.edu>
          Date: Wed, 12 May 93 12:01:01 MDT

          I enjoyed your Windows Programmer's Journal, v.1 n.5, but as much
          of a fan of Windows as I am, I feel that your "Last  Page" column
          was misleading.

          You  mention reading an article  about OS/2 2.1,  and getting the
          impression  that the author was trying to make OS/2 into Windows.
          Of course  OS/2 isn't Windows,  but just  like Windows NT,  it is

                                        - 8 -









          Windows  compatible, which  would  make  it  of interest  to  any
          current Windows user.

          The first  thing that really got  my attention was when  you call
          OS/2 "that useless operating system".  What is your rationale for
          calling it "useless"?  Have you run  DOS,  Windows  or OS/2  apps
          under OS/2 (even version 2.0?) if you had, I hardly believe you'd
          think OS/2 was "useless".  Next you state that for Windows [under
          OS/2] you  need "a 486 with 12MB of  RAM and a 100MB hard drive".
          First  off, the minimum requirements of OS/2 (at least v2.0) are:
          60MB hard drive, 4MB RAM, 386SX+ processor.  Of course this won't
          be an optimal setup,  but I would  consider this setup a  minimal
          (practical) Windows 3.1 setup.  The last I heard, Windows NT will
          require a  386, 16MB  RAM (that  might have been  for the  beta -
          perhaps it's 8MB? [According to the Microsoft press releases, the
          production version of NT will require 8MB. The beta NT "requires"
          16MB  if you include everything, but this requirement can drop to
          8MB if you remove the networking software. -Ed.]) and 80MB (again
          for the beta, perhaps less on release) for the OS.

          You mention that you could run OS/2, but you've opted for Windows
          NT instead. How much space is that operating system  taking?  How
          much RAM  do you have?  What type of  processor do you  have (and
          what speed)?   Have you tried comparing the speed of Windows apps
          under OS/2 vs.  Windows (3.1)  apps under Win  NT? From the  beta
          versions of Win NT I've seen, I'd have to believe that OS/2 would
          be faster.

          In closing you  say "If you want to run  Windows, why buy OS/2?".
          I  would  say  because  OS/2  (and Win  NT)  will  give  you more
          performance  and features  out of  that machine  that's currently
          running a DOS  based GUI extender.   Hey,  just try formatting  a
          floppy under Win 3.1 and  doing anything else.  You go  on to say
          "anyone buying OS/2 on  this promise [to run windows  apps better
          than Windows]  will only be disappointed,  I think."   Why?  OS/2
          (v2.1) seems to run Windows  3.1 apps just as if they  were under
          Windows 3.1.   What's disappointing about that?    Lastly you say
          that "an operating system should  be able to stand on what  makes
          it unique,  or it will  end up  being nothing more  than a  cheap
          imitation".  I agree, but this doesn't apply to OS/2. You make it
          sound like all OS/2 does is  run Windows 3.1 and DOS apps  with a
          different  look to  it.   OS/2  as an  operating  system is  very
          powerful,  even   without  the  Win3.1  and   DOS  compatibility.
          Remember that  compatibility doesn't necessarily  mean there's no
          innovation involved.

          Well, I  hope I haven't  come off sounding  too harsh.   I _am_ a
          Windows  3.1  user,  but   I  felt  in  fairness  to   OS/2  that

                                        - 9 -










          unsubstantiated claims shouldn't go unchallenged.

          Jeff Miller

          [Thanks for the letter, Jeff.  I was getting the idea  no one was
          reading the "Last  Page".  I'd  rather get negative mail  than no
          mail  at all.  You had some questions/comments I want to address,
          so here goes:

           a) OK, perhaps "useless"  was too strong a term.   My experience
          with  OS/2 has been limited, but  I haven't seen anything to make
          it stand apart from Windows (particularly NT).  My main point  of
          contention is stability - I've heard several horror stories about
          OS/2 2.1  locking up regularly  (see Pete's  "WPJ.INI" column  in
          this month's issue).   Under NT, if a program  crashes, only that
          program  stops  running -  nothing else  is  affected.   The only
          problem  I've  had   with  NT  was  the   NTDETECT.COM  file  was
          incompatible with my monitor. A note posted  on CompuServe netted
          a  new NTDETECT.COM file within a couple  of days and the bug was
          gone.   If you haven't had  problems with OS/2, then  I'm glad to
          hear it.  As a programmer, nothing is more frustrating to me than
          an  OS that  hinders  my productivity.    I  only used  the  word
          "useless"  based on my  own experience with  OS/2.  If  there are
          advantages  to running OS/2 instead  of NT, then  I haven't heard
          them.

          b) I'm running Windows NT on a 486/50 with 16MB RAM, and it takes
          up about  72MB (including the 24MB swap  file) on the hard drive.
          Again,  my experience  with OS/2  has been different  than yours.
          I've seen OS/2 on more powerful PCs than the minimum required for
          OS/2,  and it  crawls compared  to NT.   When  I wrote  about the
          minimum  requirements for OS/2 (e.g., 16MB  RAM), I was referring
          to  a practical  setup.   I  apologize for  the misunderstanding.
          I've seen  OS/2 run  on a PC  with a  setup less  than the one  I
          described as  practical, and, to me, it was just unusable when it
          came  to response time.  If your experience  differs, then that's
          great.  I hope other people have had better luck with OS/2 than I
          have.

          c)  I  will be  the  first  to admit  that  Windows  3.1 has  its
          limitations. Anything based on an OS as old as DOS will have some
          problems, especially  if you're developing software.   Your point
          about formatting a floppy under 3.1 is  a valid one.  This is why
          I  have NT.   It avoids  DOS problems  such as  the 64K  limit on
          segments.  Sure,  so does OS/2.   But what does it offer  that NT
          doesn't?   You write that OS/2 "...is very powerful, even without
          the  Win3.1 and DOS compatibility."  If  you want to elaborate on
          this, we'll  be glad to print  it.  This brings  up another issue

                                        - 10 -









          for  programmers: availability of programming aids.  When I go to
          the  bookstore for  help  on  programming  Windows,  there  is  a
          plethora of  choices for me to look at and decide which ones will
          help me the most.  I've looked for books on programming OS/2, and
          I've  rarely seen any.   Since  you read  WPJ, Jeff,  I'll assume
          you're a programmer.  How many book have you seen on writing OS/2
          apps?  I hope you've  had better luck than  me.   One measure  of
          the success of  an operating system should  be the the  amount of
          literature available  on  programming in  it.   This  is  another
          reason I choose Windows (3.1 and NT) over OS/2.

          I don't think your  letter was too harsh.  On  the contrary,  I'm
          glad you took  the time to write.   I'm not trying to  preach the
          gospel, just write about my own experiences.  If people are happy
          with OS/2 and they're productive, then  more power to them.  OS/2
          just isn't for me.  If you (or anyone else) has comments about my
          response, then please write.  I hope I've been fair to Jeff in my
          response to  his letter.  If  you disagree, let me  know.  Thanks
          for the letter, Jeff. -Mike]

          ------------------------------------------------------------ ----
          -------------------

          Hi,

          I'm a  novice windows programmer, and  I just wanted to  write to
          you to thank you, and encourage you to continue your efforts, and
          those of your other writers, in the Windows Programmer's Journal.
          It is  quite useful for   people like  me, with columns  for both
          beginners and  advanced programmers.    I'm especially  glad that
          you are expanding the  authorship to include other topics.   Keep
          up the good work!

          Thanks

          jeff
          perkel_j@a1.mscf.upenn.edu
          71404,123

          [Thanks Jeff.  I'm  glad you like the magazine so much.  All past
          and  current authors  should give  themselves a  good pat  on the
          back.  You've  all done a  great job in  helping us put  out this
          magazine every month.  We couldn't have done it without  you.  In
          this month's issue, you may notice an article from  Jeff.  Thanks
          for helping  us out with the article, Jeff. Now, if only we could
          get more people to show us their appreciation for WPJ the way you
          have. - Editor]


                                        - 11 -










                                  Beginner's Column
                                   By Dave Campbell

          Ok, I'm gonna be honest here. It is June 6th, Pete and Mike have
          been very understanding, and I'm late. I've got a diet coke, and
          a bag of cheap donuts, and it's time to go. Don't try this at
          home boys and girls, it should only be done by .... (guess that
          leaves me out).

          I promised to put the file dialog from last time into a DLL, and
          I am not going to make it. Instead I am going to answer a couple
          of people's questions about Borland vs Microsoft in terms of make
          files.  The files as I have been submitting them so far have been
          Microsoft compatible (but you Borland turkeys already knew that,
          didn't you?). I am in a sort of enviable position (except for
          disk space) in that I have both compilers at-hand. I started out
          Borland, and will still go that way for expedience, but I am
          trying to become more literate of Microsoft also.

          In this month's HELLO.ZIP file, you will find two make files. The
          two are named HELLO.MAK (for Borland), and MHELLO.MAK (for
          Microsoft). This is how I will ship from now on. The syntax for
          executing the make is:

          1) Borland
             make -fhello.mak

          2) Microsoft
             nmake -fmhello.mak

          The Microsoft make file is void of pathspecs and such compared to
          the Borland make file. The reason for this is that the Microsoft
          compiler builds all that stuff into your environment when it
          installs, so my environment contains (amongst other things):

             TOOLROOTDIR=E:\MSVC
             INCLUDE=E:\MSVC\INCLUDE;E:\MSVC\MFC\INCLUDE;
             LIB=E:\MSVC\LIB;E:\MSVC\MFC\LIB;
             INIT=E:\MSVC;

          This allows the make file to be somewhat more streamlined.


          Building Make Files
          -----------------------------

          If there's one piece of code that could use an entire book
          written just for it, it is the make files. I don't care if you

                                        - 12 -










          are Borland or Microsoft-compatible, they are both confusing. So,
          how do I build them? Simple, I steal them. Honest! (or is that
          Dishonest!?) 

          My first choice of a make file was the last one that worked. If
          that isn't possible, and I am using Borland's tools, I get into
          the IDE, select Project/Open, give it a name, and then use the
          Ins key to add the filename.c and filename.rc. Then go to
          Options, and setup a small model Windows EXE file default
          selection, and save everything. I get out of the IDE, and run:

             PRJ2MAKE <filename> <filename>

          This converts the <filename>.prj file to <filename>.mak that we
          wanted. Once I have a make file, I can modify it like a madman,
          but just getting the first one drives me crazy.

          This same technique can be used (sort of) with VC++. The
          difference is that part way through the process, it asks if this
          is to be an external make file, and you say YES.


          Hello
          --------

          I have made some slight changes to hello this time around,
          besides the two make files. I added the items necessary to
          produce 3.0/3.1 files with newer tools:

          #define WINVER 0x0300

          This line must be before #include'ing windows.h, and:

          RC -30 hello.res hello.exe

          This is in the make file, and instructs the RC executable that we
          want to execute under both 3.0 and 3.1.

          The only other change is the line:

          wc.lpfnWndProc = (WNDPROC)WndProc;

          in the InitInstance function. This fully qualifies the WndProc
          pointer by casting it correctly.


          Tease
          ----------

                                        - 13 -









          I must apologise for a short article, but as you can see, I am
          late, and have been jammed all month. Next month we'll continue
          with hello.c and the DLL carry-over from last month.

          In addition, next month I'll explain the code I put into hello
          this month. I quickly coded up a surprise that will  lead into a 
          in addition to the Beginner's Column. I'm not going to discuss it
          here, you have to find it, and execute the code to see what I've
          done.

          Have fun, and enjoy the code!!


          EndDialog
          ----------------

          Another month down the tubes, so to speak, but before I go I do
          want to mention one thing. It is my opinion that any code I put
          in this magazine is in the public domain as of the time Pete and
          Mike post it. I pull code from books and magazines, and anywhere
          else I can find it to save me time and get a job out quicker, and
          I am not about to put any restrictions on anything I talk about
          here. That's all.

          Next month, we do the DLL, so watch for us. Feel free to contact
          me in any of the ways below.  Thanks to those of you that have e-
          mailed me questions, keep them coming.  Notice that I now have an
          internet address, to make it real easy to get in touch with me. I
          want to rat out the things other people are having questions
          about, not just what I think people want to hear.

          Dave Campbell
             WynApse PO Box 86247 Phoenix, AZ 85080-6247 (602)863-0411    
             wynapse@indirect.com
             CIS: 72251,445
             Phoenix ACM BBS (602) 970-0474 - WynApse SoftWare forum













                                        - 14 -









                                   Internally Yours
                                    By Pete Davis

             It's about time we had another book review, and every once in
          a while a book comes by that I can't wait to review. Windows
                                                               Windows
                                                               _______
          Internals by Matt Pietrek is just such a book. This book is
          Internals
          _________
          published by Addison-Wesley and is the latest in the Andrew
          Schulman Programming Series. You might think I'm a little biased
          since my book will be in the same series. I can't exactly deny
          that, but I try to be objective when doing book reviews.

             I have been waiting a long time for this book to show up and I
          have to say that I'm not disappointed at all. Windows Internals
                                                        Windows Internals
                                                        _________________
          provides a view at the inner workings of Windows that you won't
          find anywhere else, unless you work for Microsoft and have the
          source code., of course. To write the book Mr. Pietrek reverse-
          engineered many different parts of Windows. From the disassembly
          he has managed to create C-like pseudo code to show how the
          different routines inside Windows work.

             One of the things Mr. Pietrek discusses early on is how easy
          it is for one to forget that WIndows is nothing more than a
          program or, more accurately, a collection of programs. There's no
          magic involved. When it comes down to it, the different parts of
          Windows are simply routines that perform operations, just like
          any other program.

             The main purpose of this book is to provide an understanding
          of how things work under the hood, as opposed to providing some
          sort of direct programming aid. The idea is that if you
          understand how things work internally, you'll understand why a
          function works the way it does.

             Chapter 1 is entitled "The Big Bang" and covers the startup
          and shutdown processes of Windows.  From WIN.COM to exiting
          Kernel and dropping back into DOS(without all the stuff in-
          between, actually), you see what Windows is doing to create its
          environment. There's some really good information in here that
          lets you clearly see how Windows is really a DOS extender with a
          GUI wrapping. All of the pseudo code is clear and well
          documented.

             Chapter 2, "Windows Memory Management", will have a bit of a
          broader appeal to most of you. Chapter 2 begins with a
          description, in brutal detail, how the selector functions work.
          As selectors are the basis for the Local and Global memory
          mangement routines, it provides a strong foundation for the
          information which follows, the Local and Global memory management

                                        - 15 -









          functions, of course. I believe there is pseudo code for EVERY
          Global and Local function, including many of the lower-level
          functions (unavailable to the Windows programmer) used by the
          Global and Local functions.  If Mr. Pietrek missed any, you'd be
          hard-pressed to find them. This is the information that I found
          most useful. It really gives you a good feel for Windows as a DOS
          extender.

             Chapter 3, "Starting a Process: Modules and Tasks", again,
          goes into gory  detail, this time on how programs are loaded and
          run by Windows. In addition, he also covers the loading and
          execution of Win32s programs under Windows 3.1. Another very
          thorough and informative set of functions in pseudo-code.

             Chapter 4, "The Windowing System", is what I considered the
          second most important chapter. You need to keep in mind that
          everything on the screen in Windows is a Window (just about). A
          button is a window, as is a scroll bar or a dialog box. Keeping
          that in mind, the chapter explains how the windows are kept in
          memory, how they are displayed, etc. Many useful functions are
          pseudo-coded.

             I must admit I haven't given chapter 5, "The Graphics Device
          Driver Interface", the attention it deserves, yet. It covers
          selected GDI functions such as CreateDC, CreateBrush, etc. There
          enough of it to keep you busy, if that's your cup of tea.

             Chapter 6, "The Windows Scheduler", is another favorite of
          mine. This has some fantastic information on how tasks are
          scheduled and prioritized. I personally have quite an interest in
          task management, so I really spent some time here. I, personally,
          would have preferred a little more in this chapter, but that is a
          personal preference.

             Chapter 7, "The Windows Messaging System", is another
          important chapter. Messages are the heart of Windows programs.
          Understanding how messages and message queues work at a lower
          level gives a lot of real insight into how Windows programs will
          react in different situations.

             The last chapter, "Dynamic Linking" is a bit shorter than I
          would have expected, but in retrospect, I can't think what I
          would have added. Again, painful detail is the name of the game.

             Ok, I admit it, I liked this book a lot. I know it might be
          hard to see me as objective, when reviewing a book in this
          series, but I think that under any circumstances I would feel the
          same about this book. It's well organized, extremely detailed,

                                        - 16 -









          and covers most of the major areas you'd expect to be covered.
          There is a hint of a second book on Windows Internals. I see this
          as a fix for the one problem the book has, it doesn't have
          everything. It would probably take more than two books to cover
          ALL of Windows, but two should cover just about all of the most
          important areas.

             I recommend this book highly to anyone doing Windows
          programming. This book gets into the nitty-gritty details of
          implementation. It's not light or easy reading, but it provides a
          solid understanding of how Windows works under the hood. Any
          programmer who's had to wonder why Windows did something in one
          circumstance and not in another will probably find either the
          answer or some good clues in this book. Again, I recommend it
          highly. Go to your local book store and check out a few chapters.
          If you can understand it, then you'll want to get it, trust me.

































                                        - 17 -









                                  Pascal in 21 Steps
                  (A Beginner's Column for Turbo Pascal for Windows)
                                    By Bill Lenson

          Step One - Fundamentals
          (or, "you can't get by without this stuff")

          OK, here we go.  Last month we talked about what to expect from
          this Pascal column.  In brief, this is going to be a crash course
          designed to introduce any devoted reader to the fundamentals of
          programming Borland Pascal for Windows.  At the end of this
          months column you should be able to write a simple program to
          display a calculation to the screen, know what a program is, what
          a variable is, and what some common data types are.

          Try not to get too hung up on one or two concepts you may not
          understand the first time.  Read this through once and follow the
          instructions.  If it's not clear, read it through again until you
          master the problem. Sometimes understanding just 'how' to do
          something is better initially and then the 'why' gets solved by
          itself later.  This first column may seem a little wordy but I
          think it needs to be to make sure everyone understands the
          basics.  Future columns will progress much quicker.

          If you have any ideas for future directions with this column, or
          any comments and have access to e-mail on a Bulletin Board,
          please send them to me at the address at the end of this article. 
          Thanks in advance!

          Where to begin?  Ah yes, the beginning.


          1) A Very Brief History of Pascal

          Pascal is one of several hundred "languages" you use to talk to a
          computer.  Originally it was designed as a learning tool by a
          Swiss Professor of Computer Science by the name of Nicklaus
          Wirth.  It seemed that other languages had too many barriers for
          his students to easily learn fundamental computer concepts. 
          These computer concepts are called Data Structures and
          Algorithms.  We'll talk more about what these are in a later
          column.  As an aside, one of Nicklaus' early students later went
          on to write his own adaptation of Pascal.  That person is
          Philippe Kahn, founder and CEO of Borland Corporation, and his
          Pascal extension is, of course, Turbo Pascal.

          OK, we know Pascal is a language which we use to talk to the
          computer.  Why not just talk to the computer in English. 

                                        - 18 -









          Frankly, it's too difficult to do efficient "natural language"
          processing (although this is one of the hottest topics in
          Universities today).  English has thousands of  words with
          multiple meanings for each so we settle for Pascal with it's
          fifty or so common words in it's language.  How you compose a
          program is the topic you will be studying from now on.

          2) Programs

          The Pascal language is concise.  We only need to type one or two
          words to get our point across and instruct the computer to carry
          out our wishes.  For instance we can write some text on the
          screen or read numbers we type from the keyboard.  But what is a
          program and how does the computer understand it?

          Programs are just a series of instructions written out in a text
          file.  Borland Pascal comes with a text file editor which you
          should use to type in your programs.  After typing them in you
          can save them to disk just like a letter in a word processor. 
          The Borland manuals and online help will give you plenty of help
          with the editor and how to use it.

          Now, you have a program, so how does the computer know how to
          execute the instructions written out in that file?  It doesn't
          yet because (don't worry I'll explain this) computers don't
          understand Pascal.  Computers only understand one language known
          as machine language.  Machine language is very powerful but very
          difficult to learn.  What you can say with one instruction in
          Pascal could take 100 instructions in machine language.  Now
          we're still left with a problem:  we write programs in the Pascal
          language but the computer only understands machine language. 
          What do we do?  And the answer is - Borland Pascal comes with a
          translator which will convert Pascal to machine language.  It
          will even tell you if your program isn't written properly (at
          least it will find spelling mistakes). This magical translator is
          called a compiler.  And what a compiler!  Borland Pascal's
          compiler will translate up to 85,000 lines of Pascal code to
          machine language in one minute.

          The Borland Environment is complete.  You can compose your
          programs using the editor, compile them to machine language using
          the compiler, and it will let you execute the program and tell
          you where problems are.  The compiler will even make an EXE file
          so you can run it at any time.  There's even a debugger built in. 
          A debugger is a program used to help you find potential problems
          in your program.  Here's goes another tangent...  The term bug
          actually dates back to the 1950's when an early computer suddenly
          stopped executing a small program it was running.  When the

                                        - 19 -









          researchers opened up the back and looked at the mounds of wires
          and vacuum tubes, they discovered a moth had flown in and shorted
          it out.  From this time forward, whenever a program "crashes" or
          does something unexpected, it is said to have a bug in it
          somewhere.
           

          3) The Underlying Idea Behind Programming

          The idea behind writing a program is relatively simple.  You
          aren't really programming a computer, you're controlling the
          devices and memory that make up a computer.  Whether you program
          for DOS or Windows, the idea is the same.  All too often,
          programmers forget this and find themselves writing code that is
          just plain crazy.

          So what are the devices?  Well, there are input devices which
          supply data to your computer and output devices which do
          something with data coming from your computer.  Examples of input
          devices are:  keyboard and mouse.  Examples of output devices
          are:  display and printer.

          Memory is a little different.  I like to group memory into two
          categories.  First there is RAM which acts like a temporary
          storage for numbers like a memory on a calculator.  The
          difference is that calculators usually only store a few numbers,
          RAM can store thousands if not millions of numbers.  Like
          calculators, RAM gets erased when you turn your machine off.  The
          other type of memory is a more permanent store, the disk.  This
          can be a floppy diskette or a hard disk.  You can write to and
          read from disks just like you can from RAM but data on disks are
          persistent (doesn't go away when you turn your computer off, only
          when you explicitly erase it).  For sake of clarity, I'll call
          "RAM" memory and "disks" disks.

          Behind all this is the controller, the thing you talk to to get
          things done, the thing that processes all your commands, the
          Central Processor Unit (CPU).  The CPU reads instructions one
          after another and carries out what they're supposed to do.  Some
          instructions read input, some write output, some read or write
          from the disk drive, and some manipulate data we store in the
          RAM.  What's important is programs are usually driven by taking
          input from the user and storing the information in RAM,
          performing some calculations on the data, and either store the
          results on a diskette for later use or display the results on an
          output device.  This can be illustrated by the old-faithful
          computer drawing:


                                        - 20 -









                                    +-----------+
                                    |   RAM     |
                                    |           |
                                    +-----------+
                                          /\
                                          ||
                                          \/
                +-----------+       +-----------+      +-------------+
                |  Input    |------>|   CPU     |----->|    Output   |
                | Device    |       |           |      |     Device  |
                +-----------+       +-----------+      +-------------+
                                          /\
                                          ||
                                          \/
                                    +-----------+
                                    |  Disk     |
                                    |  Drive    |
                                    +-----------+


                      Fig. 1) Typical Flow of Data in a Computer


          It may not become apparent how important this drawing is right
          now but when you get better at programming you'll realize that
          each block is a major area of study.  Input and output device
          control should be fairly obvious - you want the most efficient
          and user friendly inputs and the clearest, most user friendly
          output.  RAM study focuses on Data Structures which are different
          ways to think of data stored in the RAM while running your
          program.  Disk drive study is the study of database design.  No
          matter if you're saving a mailing list, word processor letters,
          or EXEcutable files, a disk drive can be thought of as a filing
          cabinet.  How you organize those files is the real trick.  When
          you can successfully control each of these and have your program
          perform something of value, then you've learned to program. 

          OK, enough of sounding like Master Po from Kung Fu.  Let's get
          down to the real stuff - writing a program.


          4)  Writing Your First Program - Hello world.

          So, now you're armed with the compiler and editor waiting to
          blast away at the first program.  Good!  I'm assuming you are
          using Borland Pascal for Windows and you have it loaded up on the
          screen.  The first thing you'll need to do is change some
          environment Options to make sure what I tell you will work.

                                        - 21 -









          Click on Options, then Environment, then Preferences.  Click on
          the field that says Alternate in the top right corner.  This
          ensures the keyboard presses I do will function the same for you
          (for example, F3 will load a program and F2 will save it to disk
          now).  Click OK.  Click Options, Environment, then Editor and
          change Tab Size to be 4.  I believe TAB will be set to 8 spaces
          by default.  Click OK.  Click the Options menu option one more
          time and then Click on Save.  You're now set up with the same
          basic editor options as me.
           
          To write your first program press F3.  A file open dialog box
          should appear.  Type EX1 and press Enter.  You have just created
          a blank file called EX1.PAS which is stored on the disk.  The
          editor is now opened up and waiting for you to type in your
          program.  Type the following EXACTLY!


                  program HELLO_WORLD;
                  uses WINCRT;
                  begin
                     writeln('Hello, World');
                  end.


          When this is entered, press F2 to save it to disk.  Now hold down
          the Ctrl key and then press F9.  If you typed everything
          correctly you should see a window appear on the screen with the
          words Hello, World written in the top left corner.  If you didn't
          get everything quite right, you will probably get an Undefined
          Identifier message which just means you spelled something wrong. 
          The editor will even highlight the line that has a problem. 
          Compare your program with mine in that case.  To close the
          window, double-click the mouse on the close box in the top left
          corner of the window you just created.

          Your first program!  Well done!

          OK, it's not much but it's a start.  But what does it mean? 
          Funny you should ask...  There are several things I should point
          out about this program before we go on.

          Every program is made up of a series of statements.  Statements
          end in a semi-colon (;) and are kind of like a sentence in
          English.  The compiler will translate each statement one by one. 
          In the program above there are three statements.  Begin and End
          act like book-ends and surround instructions of actions to carry
          out.  In this program, there is only one instruction (
          writeln('Hello, World'); ).  The last End in a program always has

                                        - 22 -









          a period after it.  Other Ends, if present, usually have a semi-
          colon instead.

          The first line of a program is really just for information
          purposes and gives a one word description of what the program
          does.  Notice I said one word.  That's why it's spelled
          HELLO_WORLD, not HELLO WORLD.  The underline tricks the compiler
          into treating it as one word.  Another term you might hear every
          now and then is identifier.  An identifier is often used to
          describe words you make up and place in programs.  HELLO_WORLD is
          something we made up.  We could just as easily have put
          THE_FIRST_ONE, or EXAMPLE1.  Program is part of the Pascal
          language so we usually don't call it an "identifier".  We call
          words that are part of the  language "reserved words".

          The second statement, USES WINCRT;, well, let's leave that one
          for later.

          As we said above, the Begin and End surround a group of
          instructions.  In the future we'll have many more instructions
          inserted where our one lonely writeln instruction (pronounced
          "write line") is now.

          Our first program deals with two of the blocks in the diagram
          above:  CPU and an Output device (Window on the screen).  The CPU
          was used to execute the instruction.  Now we'll turn our
          attention to memory and talk a little bit about variables.


          5) The Second Program - Hello World 2.

          Any program of significance is made up of two parts, instructions
          and memory storage.  The number of instructions that manipulate
          memory far outnumber the number that control devices and disks. 
          We better talk about memory and variables before we go too far.

          Machine language programmers often think of memory as a long
          string of millions of bytes (MegaBytes).  Pascal treats memory
          more abstractly as small chunks.  Each chunk can store different
          types of data such as numbers or strings of characters (letters,
          numbers, symbols).  In Pascal, we call the chunk a variable.  We
          don't care where in memory a variable is located or how big it
          is.  We tell the compiler we want a variable that will hold a
          number 4 digits wide (for example), and it sets aside a section
          of memory for our use that is big enough for that number.  So we
          can refer to variables in our program, we give them names. Some
          examples of reserving variables are:


                                        - 23 -









          x    : integer;
          ch   : char;
          name : string;

          These are three variable declarations telling the compiler to
          reserve three distinct chunks of memory.  The first variable, x,
          will hold integer numbers. We say that x is a variable which can
          store a data type of integer.  The next one, ch, is a character
          type variable and will hold a single character (letter, number (0
          to 9), or symbol).  The last variable is a string var (variable)
          called name which can hold up to 255 characters.  From its name,
          'name', we can probably conclude it will be used for storing
          somebody's name for later processing.

          Integer, String, and char are three of Pascal's pre-defined  data
          types.  There are others, which we'll study in time, that reserve
          chunks of memory too.

          How do we put variables into a program and where?  Pascal needs
          to know about variables and their types before the instructions
          can execute them. We therefore declare them to the compiler,
          before the begin, in a 'var' section.  Here's an example to
          illustrate variables better.  To type this in, press F3, type EX2
          and press the Enter key.


                  program HELLO_WORLD_2;
                  uses WINCRT;
                  var
                     s : string;
                  begin
                     s := 'Hello, World';
                     writeln(s);
                     s := 'From Bill';
                     writeln(s);
                  end.


          Don't forget to press F2 when done typing this program to save it
          to disk.

          In the above, var starts a series of variable declarations. 
          Another way you can think of a variable is like a box.  You can
          put one thing in the box and then take it out but only one thing
          can be in the box at one time. Also, the box can contain only one
          kind of data.  From the program above, we see a variable called s
          that can hold a string of up to 255 characters. 


                                        - 24 -









          The first instruction is called an assignment statement.  ':='
          (pronounced "assign") means take what's to the right and move it
          into the variable on the left.  I could have more easily written
          the instructions as:

          begin
             writeln('Hello, World');
             writeln('From Bill');
          end.

          but this seemed like more fun and I could explain variables along
          the way.  So, the first instruction moves the string into the
          string variable.  The second instruction writes the string to the
          screen and then moves the cursor to the beginning of the next
          line.  s then gets assigned a different value, 'From Bill',
          erasing the previous contents.  It too gets displayed in the
          window.  Before you run this program, what do you think the
          output will be?  Try the program and see if you were right.
           

          6)  Conclusion

          There you have it.  You should be able to now look at sample
          programs and at least spot the variables and the main Begin...End
          statements at the bottom of the program file.  The function of
          the programs might be a little advanced yet but this will soon
          change.

          Next month things really start to fly.  You'll learn more about
          variables, data types, functions, procedures, and units.

          See you next month!



          7)  How to Contact Me

          Please don't try to contact me for programming problems.  I have
          a full time job and won't have time to respond.  If, however, you
          would like to send me comments or suggestions for future columns,
          I can be reached the following ways:

          a) From CompuServe

             - Type GO MAIL
             - Enter your message
             - When done and prompted for the mailing address put:


                                        - 25 -









                              >INTERNET:Bill.Lenson%canrem@uunet.ca

             - The address must be entered EXACTLY as shown.  Any character
          left off will cause the message to be sent but won't get to me.


          b) From a Bulletin Board with Internet Access

             A surprising number of BBS's have Internet access.  If you
          have a local mail system, there's a good chance it could also
          have a "gateway" to Internet.

             - Contact your BBS Sysop or mail administrator to find out how
          to send mail through Internet.
             - Address your message to:

                  Bill.Lenson%canrem@uunet.ca


          c) From a BBS with FidoNet Access

             - Contact your BBS Sysop to find out how to send mail  through
          FidoNet.
             - Address your message to:

                  Bill.Lenson@f15.n229.z1.fidonet.org


             Please note that in the three addresses given above, there are
          NO spaces embedded anywhere in them.  It's one character after
          another.

             There are several mail systems which can send mail through
          Internet.  If you are on any of the following systems you MAY
          have access:  AppleLink, AT&T Mail, Bitnet, BIX, BMUG,
          CompuServe, Connect, Easynet, Envoy, FidoNet, GeoNet, MCIMail,
          MFENet, NasaMail, PeaceNet, SIGNet(through FidoNet), SINET, SPAN,
          SprintMail, THENET, or UNINet.  Contact your mail administrator
          to see if you can mail through Internet.  If so, drop a message
          and your comments will be considered for future columns.









                                        - 26 -









                 Moving Away from Moving into Windows NT Programming
                                  Moving into Windows NT Programming
                                  __________________________________
                                    By Pete Davis

             Boy, I'm really going to sound biased this month. I can see
          the flames from here. In my review of Windows Internals I had
                                                Windows Internals
                                                _________________
          nothing but good things to say. This review is of the book Moving
                                                                     Moving
                                                                     ______
          into Windows NT Programming published by SAMS Publishing and
          into Windows NT Programming
          ___________________________
          written by Jason Loveman.

             First of all, I must give Mr. Loveman some credit. His book is
          the first real Windows NT programming book to come out (that I've
          seen), so he really had his work cut out for him. Also, the book
          was finished only weeks after the third beta release of Windows
          NT, so the book can sort of be considered a "beta" book. As soon
          as I started looking through it, there was one thing that stuck
          out really bad to me and left a real bad taste in my mouth. About
          1/6 of the book is devoted to a chapter called "A Port of WINIO."
          WINIO, for those of you not familiar with it, is an API to allow
          programmers to perform console-type operations (printf and the
          like) under Windows. In addition it allows you to structure your
          programs more like DOS or Unix C programs with a main() function.
          Well, that sounds good, so why would that leave a bad taste in my
          mouth? The authors of WINIO are David Maxey and Andrew Schulman,
          for one. Not Jason Loveman. Again, I tried to be objective,
          though, and bought the book anyway. I started reading that one
          chapter, just to see if I could find a justification, not for
          having it, but devoting 1/6 of the book to it.

             After reading a few paragraphs here and there, it quickly
          became clear that the only true purpose WINIO served was to give
          the author the pages he needed to finish the book. To quote the
          author, "Changing all the code to bring up a simple WINIO
          application ... took about 20 minutes ..." I'm sorry, did you say
          55 pages (the number of pages required for the dump of the WINIO
          code) took you as long as 20 whole minutes? "Actually, there
          wasn't much work at all.", he says. Well, really, and that was
          worth 55 pages? I'm sorry folks, but I paid $40.00 for this book
          and I'm saying, if it's not much work to do this 55 page sample
                                                           55 page 
          port, perhaps it wasn't the best example. In fact, he says that
          most programs would have a little more work involved. It seems to
          me that maybe one of these 'other' program would have been a
          better example. Ok, but enough of that. Let's look at the book
          and pretend that chapter doesn't exist.

             The main focus of the book is porting existing Windows 3.x
          code to the Win32 API. It also stresses portable replacement of
          code as opposed to simply modifying the code to be Win32
          compatible. These are good goals and the author makes it clear

                                        - 27 -









          that these are goals. The 1st, 3rd, and 4th chapters do a
          reasonably good job of this, though the 4th is simply the WINIO
          port. Oops, I was going to forget about  that, wasn't I.
           disappointed by this chapter. The author skims over the sections
          on Threads and Synchronization. I know, I'm kinda big on these
          topics, but I feel they are very important topics and they're
          probably going to be the two toughest problems for most Windows
          3.x programmers to overcome when going to NT, at least, that's my
          opinion. Unless you've used threads before, there's a lot to
          learn. I think it is unreasonable to assume the reader of this
          book is going to have a working knowledge of threads and
          synchronization. There also doesn't appear to be any real
          organization to the chapter. First he talks about Objects, then
          DLLs, then Process synchronization, then on to InterProcess
          Communication (DDEML in particular), and then, whoah,
          Asynchronous Objects where he covers more about synchronization
          objects. It seems to be a sort of mish-mash of different topics
          without any sort of cohesive theme.

             Chapter 6 is titled, "The NT is for New Technology". It's more
          like "the NT means I have 'No Title' better than this". The title
          gives no insight into the contents which, again, is a bunch of
          unrelated topics that could be either here or in chapter 5 and
          you wouldn't notice the difference.

             Chapter 7 is titled, simply "Win32s". Believe it or not, I
          actually enjoyed this chapter. There was some really good
          information about Win32s and how it relates to Win32. In
          particular, he covers areas where they are different. This is
          useful information and it is well presented.

             Chapter 8, "Portability" started off well. The first 8 pages
          discussed important portability questions. This is then followed
          by a sample program using the MFC libraries. The purpose, being
          to demonstrate MFC. I have nothing against MFC, but, again, it
          just sort of sticks out after the first 8 pages and seems oddly
          placed.

             Chapter 9, "Tools" is a fairly mediocre discussion of the
          compiler options, linker, etc. Nothing really earth shaking.

             Ok, I'm sure I'm going to get some serious heat for being so
          biased on this review. Different publishing house, doing a book
          on the same topic that my book will be on (sort of, not exactly).
          Really, when some more books come out, I can almost guarantee
          that I'll bring some up that are really good books and I'll be
          objective about them. I've tried to be objective about this book.
          It's hard to feel objective when you feel like you got burned,

                                        - 28 -









          though.

             The overall appearance of the book shows signs of average
          writing. There are a lot of editing errors that also stick out.
          There are sentences that I thought didn't make sense the first
          time and never made sense after that either. The organization of
          the book doesn't seem to be very well thought-out. There appear
          to be a lot of sections of unrelated topics thrown in together.
          The book's initial goals seem to sort of get lost after the first
          few chapters.

             The book does have its good points. It does have some good
          information on porting existing code from Windows 3.x to Windows
          NT. The problem is, I've seen an equal job done in Microsoft's
          documentation. There's not $40.00 worth of new porting
          information.

             I cannot recommend this book. I will admit my expectations
          have been a little high for the first Window NT/Win32 programming
          books. I wanted to see some good writing. I like a good
          programming book as much as the next nerd. Unfortunately, I don't
          think this is such a book. You can certainly check it out at your
          local bookstore and see what you think. Skim through it and see
          if you agree or disagree. Personally, I'd like to hear from
          readers who have already paid for the book to see if maybe they
          disagree with my review. This is the first negative review I've
          done, and I feel a bit guilty, but I also feel there's a need to
          warn the readers. Again, if there are readers out there who
          disagree with my review, I'd like to hear your responses.




















                                        - 29 -









                                C++ Beginner's Column
                                   By Rodney Brown

             Welcome to C++ For Beginners.  Like Mike, I am also just
          starting out in C++, but I can see the many advantages, and some
          disadvantages that C++ has.  For starters, I am going to devote
          this column to each of the new features that C++ provides.  Once
          we get these basics down pat, we will then start on a (No, not
          another one!) 'Hello World' program (You knew it was coming,
          didn't you?).

             Some of the items we will be discussing in the next few months
          are:

                  Objects/Encapsulation
                  Polymorphism
                  Inheritance
                  And much much more


             I'm sure you will enjoy learning C++ as much as I am.  Next
          month, we will begin looking at the differences between C and
          C++, and begin discussing Objects.

             Due to time constraints (my hard drive crashed!), I was not
          able to write a complete article.  If you have any suggestions,
          obstacles you can't get around or hints/tips, please send them to
          the e-mail addresses shown below.  Next month, we'll have a full-
          fledged article for you.  Sorry about that.


             My E-mail addresses are:

                  CompuServe: 72163,2165
                  America Online: RodneyB172

             Since my last article, I dropped GEnie for America Online

             You can also contact me at the following Internet addresses:

                  CompuServe: 72163.2165@compuserve.com
                  America Online: RodneyB172@aol.com   (Preferred InterNet
          Address)

          See ya next month!




                                        - 30 -









                           Windows Programmer's Journal BBS
                                    By Pete Davis

             I'm going to start doing updates every few months on what's
          going on with the Windows Programmer's Journal BBS. I thought
          that, apart from informing you, the reader, about what's going on
          there, it might provoke some of you to tell us exactly what you'd
          like to see there.

             The Windows Programmer's Journal BBS, right now, is still in
          its infancy. I haven't had the kind of time I'd like to really
          get it configured the way I want. One of my main objectives is to
          get the WPJ BBS on FidoNet. Configuration for FidoNet is no small
          affair and requires a good deal of work. I have some vacation
          time coming in July and I'm hoping I can get to that then. Once
          on FidoNet we'll be able to open ourselves up to some of the
          active conferences out there and, hopefully, maybe even get one
          started for the magazine eventually.

             Right now the BBS only has 128 megs. Much of this is taken up
          with software that isn't really necessary for the BBS. I'll be
          removing some of that soon as I get a new computer to relocate
          the software to. In addition, I plan on upgrading the modem to
          9600 baud. This will make it easier on many of our long-distance
          callers. Both of these should be in place within the next 4-6
          weeks. We also have a CD-ROM drive which currently houses the
          SIMTEL CD-ROM. The CD contains more than 600 megs of public
          domain and shareware software. We currently have two other CDs
          that we hope to make available to the BBS as soon as we can get
          additional drives. The other major purchase for the BBS is a 1+
          gig hard drive. This purchase will be put off for at least the
          next 6 months due to a shortage of green paper.

             The biggest news on the WPJ BBS front is the APIs in the
          download section. I've been working hard to get APIs and have
          found some pretty good ones and more are coming soon. Among the
          ones there now are: OLE Specs for 16-bit and 32-bit Windows, ODBC
          Specs, Message API Specs (MAPI), and much more. Soon we'll be
          adding the Telephony API and a few other odd ones that have
          reared their heads. It seems Microsoft is going API crazy. I'm a
          bit of an API fan myself, so no complaints from me.

             As I said, I plan on having some time early in July to get
          some work on the BBS done. Please leave us comments and
          suggestions to let us know what you'd like to see.




                                        - 31 -









                             The Windows Messaging System
                                   By Mike Wallace

                  An integral part of learning how  to program in Windows is
          understanding the Windows messaging system.  Unfortunately, it is
          one of  the most  poorly documented areas  of Windows,  deserving
          much more  attention  than  it gets.  Writing  a  robust  Windows
          program  demands a  good understanding  of how  your program  and
          Windows  communicate, and this is done via the messaging system -
          Windows sends messages to your program and your program responds,
          and vice-versa.  This is all done via the message queue.

                  There  are two types  of message queues: a) system harware
          event queue; and b) application message queue.  The former is for
          the hardware (e.g., keyboard,  mouse) and timers.  The  latter is
          for the applications.  There is only one  system queue, but there
          is an application queue for each running program.  So,  when your
          program is running and it generates a message from Windows (e.g.,
          the  user  changed  the  active  window,  generating  a  WM_PAINT
          message),  Windows will post that  message on the  queue for your
          application, and on no other queue.

                  Every message is  serviced by  a function declared in  one
          of the following two formats:

          LONG FAR PASCAL Function(HWND hWnd, unsigned msg, WORD WPARAM,
          LONG LPARAM);

          BOOL FAR PASCAL Function(HWND hWnd, unsigned msg, WORD WPARAM,
          LONG LPARAM);

          The first is for registered dialog and/or window classes, and the
          second  is for internal class  dialogs.  The  parameters for both
          are  the  same: hWnd  provides a  handle  to the  window (telling
          Windows  where the internal info  for that window  is in memory),
          msg is  the  message, and  WPARAM and  LPARAM contain  additional
          information about the message (e.g., parameters).  For example, a
          common  message  Windows  sends  is  WM_COMMAND.    This  can  be
          g e n e r a t e d       b y       t h e       u s e r       c l i
          cking  on a  control (e.g., a  button) in  the window.   For your
          program  to know which control was selected, it needs the numeric
          identifier  (every  control  in  a  window  must  have  a  unique
          identifier).  The WPARAM parameter contains this information, and
          LPARAM  is similar (as an aside,  if you're wondering how to pass
          other  data to and  from the  window's function  (avoiding global
          variables),  an  excellent  way  is  to  use  the  "SetProp"  and
          "GetProp" functions).


                                        - 32 -









                  This is  the work of the  messaging system:  it sends your
          program messages  generated by Windows in response to the actions
          of the user running your program.  Make sense?  This leads to the
          "big switch"  functions, so  called because   functions receiving
          these  messages are  typically  set up  with  the first  line  as
          "switch  (message) {", followed by a "case" statement (with code)
          for each message your  program wants to act on.   These functions
          can be several pages long.

                  After your  program has  received a  message and  acted on
          it,  control should  be  returned to  Windows.   This  can  cause
          problems when you're trying  to learn how to program  in Windows.
          Most programmers are  used to  sequential code -  the program  is
          executed  one line at a time.   Under Windows, your program waits
          to get  called by the messaging  system.  For example,  let's say
          the user has  just pushed a  button in a  window created by  your
          application. This generates a  WM_COMMAND message.  Windows knows
          that  the window belongs to  your application, so  the message is
          put in the message queue for your application (remember? each app
          has its  own message queue).   This "wakes up" your  program, and
          control  is passed to the  function that handles  the window that
          the user  is in.    When Windows  gets to  the  line inside  your
          "switch (message) {" block that reads "case WM_COMMAND:", it will
          usually  find a line that reads "switch (WPARAM) {", which starts
          a new "big switch"  block, which will have a "case" statement for
          each  control  in  your window  (it  can  handle  other types  of
          messages as well, such  as menu items and accelerator  keys). The
          "case"  statements will get read until Windows finds the one with
          the  identifier for the button  that was pressed.   Then, at long
          last, Windows will execute the code for the button pressed by the
          user.  It's about time, isn't it?  These things are never simple.
          Sure, I could  rant and rave about  how bizarre this whole  thing
          is, but  you could probably guess exactly what I would say, so it
          would all  be kind of  pointless.  If  you want to  write a good,
          robust Windows  application, you  need to  understand how  all of
          this  works,  and  it's  not always  intuitive  what's  going on.
          There's  a lot of information  a Windows programmer  must keep in
          mind.   If you  don't understand (at  a minimum)  how Windows and
          your program are communicating, you're in trouble.

                  If you want  a more detailed  explanation of the messaging
          system, there are two good articles that may help clear it up:

          - C User's Journal  (May 1993) : "The Windows  Messaging System",
          by Mike Klein; and

          - Dr. Dobbs Journal  (Feb. 1993) : "Inside the  Windows Messaging
          System", by Matt Pietrik.

                                        - 33 -









                    A Review of a Windows-hosted Programming Aid:
                             Wilson WindowWare's WinEdit
                                    By Jeff Perkel

          Let me introduce myself.  My  name is "Jeff", and I'm a shareware
          junkie.    For those  of  you who  don't  know, "shareware"  is a
          marketing concept in   which you  are allowed to  try a piece  of
          software free,  usually for  30  days,  after which time  you are
          supposed either to register  the program, or delete it  from your
          hard disk.  It's really sort of  an honor system  thing.  In most
          cases, even if you don't register, the only thing that happens is
          that you continue to get  an annoying "Unregistered" message upon
          startup.

          Because I  am a shareware junkie,  I'm always on the  lookout for
          new  and useful shareware.  You'd be  amazed at some of the truly
          wonderful utilities  available out in  netland for a  fraction of
          what their
          commercial counterparts  cost. Why, I've got two  text editors, a
          checkbook balancing program, a few games, and a few miscellaneous
          utilities - all shareware.   So, after talking with  Mike Wallace
          via  e-mail, I've  taken  it upon  myself  to try  and alert  the
          readers of the WPJ  to new shareware programming utilities.   You
          may  recall  that  last  month  (issue  5),  a    product  called
          WinDisassembler was reviwed.   This  column will be  similar   to
          that. And now, without further ado . . . 

                          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

          One of the small pet  peeves I have is writing a  Windows program
          in  DOS.  This is because, until recently,  I had to code in DOS,
          compile, and then   run Windows to see that I have made an error,
          and  then return to  DOS.  I   know I  could have done  this in a
          Windows DOS session, but  it's much   easier, I thought, just  to
          compile in DOS.  Not to mention faster.

          I  currently am using the  Microsoft C/C++ 7.0  compiler with the
          Windows  3.1   SDK.    This  package  comes  with  an  Integrated
          Development Environment  (  IDE)  called  the  Programmer's  Work
          Bench.   This IDE runs  from DOS, looks  like DOS's EDIT.COM, and
          is, I thought, difficult to use.  I wanted to be able to write my
          programs in  Windows, in order to  have access to my  on-line SDK
          help, and, later, to the Developer Network CD.

          Not  having a  lot of  money to  spend on  this,  I looked  for a
          shareware  utility that would do the job.   I found one in Wilson
          WindowWare's WinEdit (reviewed in PC/Computing, April, 1993, page
          129).   This is a very useful programmer's aid.  The key features

                                        - 35 -









          are:

                  -  Context-sensitive  help.     You  double  click  on   a
          function,   such  as  CreateWindow(),  and  WinEdit  will  search
          through the Win3.1 SDK on-line help reference to find that topic.
          Not  even Microsoft's  Visual  C++ Visual  Workbench offers  that
          feature.

                  - Multiple  open files.   Limited  only by your  available
          memory.

                  -  Ability to  launch a  program  from  WinEdit.   You can
          actually  launch  any  program from  WinEdit,  but  the Menu  Bar
          contains  a Project sub-menu,  containing Compile,  Make, Remake,
          Debug,  and Execute  functions.   You  can configure  the command
          lines however  you wish,  and even save  multiple configurations.
          For  example, you  might have  a "windows"  configuration, and  a
          "dos" configuration, in order  to compile using different command
          line switches.

                  Unfortunately, I  was  never able  to successfully  launch
          CodeView   for  Windows  from within  WinEdit  - out  of  memory.
          However, I've  also  only got  4MB  of RAM  (for  that matter,  I
          couldn't launch CVW from  the PWB, either!)  I  suspect, however,
          that on a  better programming  platform (i.e., 8MB  RAM or  more)
          that this would not be a problem.

                  -  Compiler   capture.    The  program  captures  compiler
          output,  and moves you to the line with the first error.  You can
          then skip  to   the next  error, or  to the  previous error.   In
          addition, you can view the compiler output itself.

                  - Macro language in the Professional edition.

                  - On-line help.  Very comprehensive.

                  - Toolbar.  This  is not user-configurable, but just about
          any feature that you could ever need is already in there.

                  - User created extension DLLs.   This allows you to modify
          WinEdit  to suit  your  needs.   The  on-line help  explains  the
          implementation of these DLLs, as well as the WinEdit API.

          I think that  WinEdit offers us about all that  one could ask for
          in a programmer's text editor.  It's compiler capture feature and
          context  sensitive  help  features  make  it  a  program  that is
          certainly worth your while  to examine - especially if  you, like
          me, were laboring in the pit of DOS unnecessarilly.

                                        - 36 -









                            -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

          WinEdit   comes  in   three  versions:     Lite,   Standard,  and
          Professional, all  in the same ZIPped file.

          The registration  fees  are $30,  $60,  and $90,  respectively.  
          However, only the standard and professional versions can compile.
          The professional  version is simply  the standard version  plus a
          macro language. 

          Registration  nets you a disk, a dialog editor, a printed manual,
          and shipping in the US and Canada.

          WinEdit  is available  from  PCCONTACT on  Compuserve.   Type  GO
          PCCONTACT.     WinEdit  is  in  library   3  (utilities/misc)  as
          WINEDT.ZIP.  It  is also  available via anonymous  ftp on  SIMTEL
          20 and its mirror sites as pd1:< windows3>WE-20N.ZIP.

          [The author can be contacted at "perkel_j@a1.mscf.upenn.edu" on
          the Internet, and on CompuServe at 71404,123.]





























                                        - 37 -









          Date:  02-Jun-93 16:36 EDT
          From:  Mike Strock   >INTERNET:MikeS@asymetrix.com
          Subj:  FW: White House Announcement About E-Mail (fwd)

           ----------
          From: Brian Granowitz
          To: Cool (The Suave Group)
          Subject: FW: White House Announcement About E-Mail (fwd)
          Date: Wednesday, June 02, 1993 12:25PM


                                   THE WHITE HOUSE

                        Office of Presidential Correspondence

          ____________________________________________________________ __
          For Immediate Release                             June 1, 1993


                     LETTER FROM THE PRESIDENT AND VICE PRESIDENT
                IN ANNOUNCEMENT OF WHITE HOUSE ELECTRONIC MAIL ACCESS




                  Dear Friends:

                  Part of  our commitment  to change  is to  keep the  White
          House in step with today's changing technology.  As we move ahead
          into the twenty-first century, we must have a government that can
          show  the way  and lead  by example.   Today,  we are  pleased to
          announce that for the first time in history, the White House will
          be  connected to you via  electronic mail.   Electronic mail will
          bring  the Presidency and this  Administration closer and make it
          more accessible to the people.

                  The White House will be connected  to the Internet as well
          as  several  on-line  commercial  vendors, thus  making  us  more
          accessible and more in touch with people across this country.  We
          will  not  be alone  in this  venture.  Congress is  also getting
          involved, and  an exciting announcement regarding electronic mail
          is expected to come from the House of Representatives tomorrow.

                  Various government  agencies also will  be taking part  in
          the  near future.  Americans  Communicating  Electronically is  a
          project  developed by  several government agencies  to coordinate
          and improve  access to  the nation's educational  and information
          assets  and resources.   This  will be  done through  interactive

                                        - 38 -









          communications such as electronic mail, and brought to people who
          do not have ready access to a  computer.

                  However, we  must be realistic  about the limitations  and
          expectations of  the White House  electronic mail  system.   This
          experiment  is the first-ever e-mail project done on such a large
          scale.   As  we work  to reinvent  government and  streamline our
          processes, the e-mail project can help  to put us on the  leading
          edge of progress.

                  Initially, your  e-mail message will  be read and  receipt
          immediately acknowledged.  A  careful count will be taken  on the
          number received as well as the subject of each message.  However,
          the White House  is not  yet capable of  sending back a  tailored
          response via electronic mail.  We  are hoping this will happen by
          the end of the year.

                  A   number   of   response-based   programs  which   allow
          technology to help  us read your  message more effectively,  and,
          eventually respond to you electronically in a timely fashion will
          be tried out as well.  These programs will change periodically as
          we  experiment with the best  way to handle  electronic mail from
          the public.    Since this  has  never been  tried  before, it  is
          important  to allow for some  flexibility in the  system in these
          first stages.  We welcome your suggestions.

                  This is  an historic moment in the White House and we look
          forward to  your participation and enthusiasm  for this milestone
          event.  We eagerly  anticipate the day when electronic  mail from
          the  public is  an integral  and normal  part of the  White House
          communications system.



                          President Clinton      Vice President Gore

                   PRESIDENT@WHITEHOUSE.GOV                                
          VICE.PRESIDENT@WHITEHOUSE.GOV











                                        - 39 -









                                 Text Manager Review
                                   By Mike Wallace

                  Windows programmers get touchy when it comes to editors. 
          All of the best editors, it seems, are DOS-based, and it's a pain
          to write the code under DOS, compile, and then start up Windows
          to test your app.  A lot of time could be saved if there was a
          good Windows-based editor, but there don't seem to be very many
          to choose from.  One choice is Text Manager.  I've been a beta-
          tester for it, and it's a good program.  Version 1.0 has been
          around for a while, but Digital Software is about ready to
          release version 2.0.

                  Text Manager can be used to edit any text file, but has
          added functionality for C files, INI files and batch files.  If
          you select "Open..." from the "File" menu bar item, you can have
          it only list files with a filetype of ".C", ".INI", ".BAT",
          ".TXT" or ".*" to get all files.  This comes in handy when you're
          writing C code.  You can also open multiple files, and if you
          minimize the file, the icon for it is determined by the file
          type, so a ".C" file is readily distinguishable from a ".INI"
          file.  Other features include:

          - Toolbar and status bar

          - Pressing on a menu bar item or button will cause the status bar
          to tell you what it does

          - You can set the printer font to be different than the screen
          font

          - Closing Text Manager when it is either maximized or minimized
          will cause it to open the same way the next time you run it (the
          author tells me this also is true for any text file you open, but
          I wasn't able to get it to work).

          - Text Manager will remember the files you worked with the last
          time you were running Text Manager

          -  A full online help file (the author is working on this part
          now so I haven't seen it)

          - Print preview

          - Standard editing capabilities (e.g., cut, copy, paste, find,
          replace)

          - Support from Digital Software - the author (Kerim Erden) checks

                                        - 40 -









          his CompuServe mail several times a day and always answers all of
          his mail.  All of my contact with Mr. Erden has been by e-mail
          and he has always responsed very quickly to my questions.

           - Registration will net you an install disk (the installation
          program is graphical)  with some extra utilities on it.

                  If you're looking for a straightforward, easy-to-use
          Windows-based text editor, try out Text Manager.  It could be
          well worth your time to try it out.  It's available as shareware
          and only costs $10.  Text Manager 2.0 will soon be available on
          the IBMSYS, WINSHARE and NORUTL forums on CompuServe.  Questions
          can be directed to Kerim Erden of Digital Software at CompuServe
          ID 72133,257.



































                                        - 41 -








                              Getting in touch with us:

          Internet and Bitnet:

          HJ647C at GWUVM.GWU.EDU -or- HJ647C at GWUVM.BITNET (Pete)

          GEnie: P.DAVIS5 (Pete)

          CompuServe: 71141,2071 (Mike)

          WPJ BBS (703) 503-3021 (Mike and Pete)

          You can also send paper mail to:

          Windows Programmer's Journal
          9436 Mirror Pond Drive
          Fairfax, VA   22032
                U.S.A.

                  In future issues  we will be  posting e-mail  addresses of
          contributors  and columnists  who  don't mind  you knowing  their
          addresses. We will also contact any  writers from previous issues
          and see if they want their mail addresses made available for  you
          to respond to them. For  now, send your comments to us  and we'll
          forward them.
























                                        - 42 -









                                    The Last Page
                                   by Mike Wallace

                  Got this in  the mail a few days  ago.  Hope you like  it.
          If you read  this column last month (it was  about OS/2) and want
          to read  a different point of view from reader Jeff Miller, go to
          the  "Letters" section  at the  beginning of  the issue.   Jeff's
          letter is  included (in its  entirety), followed by  my response.
          This is  the kind of debate I was hoping this column would spark.
          If anyone else has some criticism about  this column or any other
          part of the magazine,  please write.   We want WPJ  to be one  of
          your sources of help when you're programming, and if we can  make
          WPJ better, then we want to know how. Talk to you next month.


          Date:  24-May-93 11:31 EDT
          From:  Mike Strock   >INTERNET:MikeS@asymetrix.com
          Subj:  NEWS BULLETIN - Men and women are NOT alike.

          Sure, you thought you already knew  that.  But now we have proof!
          After countless  hours of  surveys and  studies on  the following
          topics, these facts have emerged.

          Relationships:

          Women  have deep,  meaningful, mutually  nurturing relationships.
          Men have  "that time when me  and Suzie was  doing it on  a semi-
          regular basis".

          When a relationship ends, a woman will cry and pour her heart out
          to her girfriends, and she will write a poem titled  "All Men Are
          Idiots".    Then    she    will    get    on    with    her    li
          fe,  usually by meeting another man and doing an emotional belly-
          flop.

          A man will call six months after the break-up, at  3:00 a.m. on a
          Saturday  night, and  say, "I  just wanted  to let  you know  you
          ruined my life,  and I'll never forgive you, and  I hate you, and
          you're a  total floozy.  But I want you  to know there's always a
          chance  for us".  This is  known as the "I Hate  You/ I Love You"
          drunken phone call, that 99% of all men have made at least once.

          Women prefer 30-40 minutes of foreplay.  Men prefer 30-40 seconds
          of foreplay.   Men consider driving back to her  place as part of
          the foreplay.  Women  consider getting  married  as part  of  the
          foreplay.

          Maturity:

                                        - 43 -









          Women  mature before men do. 17-year-old females can function  as
          adults, but  don't. 17-year-old  males can't function  as adults,
          and don't care.  This is why high school romances rarely work.

          Handwriting:

          Women use scented,  coloured stationery and they dot their "i's",
          with circles and hearts.   Women use ridiculously large  loops in
          their "p's" and "g's".   It is a royal pain to read a note from a
          woman.  Even when she's dumping you, she'll put a  smiley face at
          the end of the note. Men  do not decorate their penmanship.  They
          chicken-scratch.

          Bathrooms:

          A  man has six items  in his bathroom:  a toothbrush, toothpaste,
          shaving cream,  razor, a bar of  Dial soap, and a  towel from the
          Holiday Inn. The  average number  of items in  a typical  woman's
          bathroom  is 437.  A  man would not  be able to  identify most of
          these items.  A woman uses each of them every morning.

          Groceries:

          A man waits till the only item left in his fridge are half a lime
          and  a  Blue.  Then he  goes  to  the  grocery  store,  and  buys
          everything  that looks  good.   By  the time  a  man reaches  the
          checkout counter, his cart is packed tighter  than the Clampett's
          car on Beverly  Hillbillies.  Of  course, this will not  stop him
          from going to the 10-items-or-less lane.  When a woman does this,
          it is called shopping.

          Going out:

          When a man says he is ready to go out, it means he is ready to go
          out. When a woman says she is ready to  go out, it means she WILL
          be ready  to go out, as  soon as she finds  her earring, finishes
          putting on her makeup...

          Cats:

          Women love  cats.  Men say  they love cats, but  when women are't
          looking, men kick cats.

          Dressing up:

          A woman will dress up to go shopping, water the plants, empty the
          garbage, answer the phone, read a book, get the mail.  A man will
          dress up for: weddings, funerals.

                                        - 44 -









          David Letterman:

          Men think  David Letterman is the funniest man on the face of the
          earth. Women think he is a mean, semi-dorky guy who  always has a
          bad haircut.

          Laundry:

          Women  do laundry every  couple of days.   A man  will wear every
          article of clothing  he owns, including  his surgical pants  that
          were hip  about eight years  ago, before he will  do his laundry.
          When  he  is  finally  out  of  clothes,  he  will  wear  a dirty
          sweatshirt inside out,  rent a  U-Haul and take  his mountain  of
          clothes to the laundromat.   Men always expect to  meet beautiful
          women at the laundromat.  This is a myth.

          Weddings:

          When reminiscing about weddings, women talk about "the ceremony".
          Men talk about "the bachelor party".

          Socks:

          Men  wear sensible socks.   They wear  standard white sweatsocks.
          Women wear strange  socks.   They are cut  way below the  ankles,
          have pictures of clouds on them, and have a big fuzzy ball on the
          back.

          Slippers:

          Men wear leather slippers that have been brought to them by their
          faithful  dog.  Women wear  huge fuzzy orange  things with faces,
          that look like puppies.

          Nicknames:

          If Gloria, Suzanne, Deborah and Michelle get together for  lunch,
          they will  call each other Gloria, Suzanne, Deborah and Michelle.
          But if  Mike, Dave, Rob and Jack go out  for a brewsky, they will
          affectionately  refer  to each  other  as  Bullet-Head, Godzilla,
          Peanut Brain and Useless.








                                        - 45 -



