No announcement yet.

Using Ctrl-Arrows and Arrows on PB/DOS

  • Filter
  • Time
  • Show
Clear All
new posts

  • Using Ctrl-Arrows and Arrows on PB/DOS

    Potsdam July 30/2001

    We are upgrading one software applitacion to move one
    Telescope using PB in a DOS PC and decided to use the
    arrows keys and the combinations Ctrl-Arrows

    If we activate the Ctrl-Arrow defined Keys alone all works OK,
    both on activating also the keys 11-14 the subruotines
    associated with the Ctrl-Arrow Keys are never called.

    I can send a small test program showing the effect

    any suggestions?


  • #2
    Please post the example code... maybe we can spot something. Thanks!

    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      How interesting this should show right now! I'm in the middle
      of enabling the old WordStar control key strokes in an editor
      written in PB 3.5 for DOS ..

      Thus, what I have for the translate table that we use here may
      be of use to all .. John R(ob) Barnaby did a WONDERFUL job when
      he took the old initial arrow keys on the CP/M keyboard and
      expanded it to what we all either love or hate as those control
      stroke and stacked control stroke operations.

      Here's, as I know it, what the keyboard does with all this:

      !=33 )=41 1=49 9=57 Aa=65/97  Ii=73/105 Qq=81/113 Yy=89/121 SCH=1  HT=9  DC1=17  EM=25
      "=34 *=42 2=50 :=58 Bb=66/98  Jj=74/106 Rr=82/114 Zz=90/122 STX=2  LF=10 DC2=18 SUB=26
      #=35 +=43 3=51 ;=59 Cc=67/99  Kk=75/107 Ss=83/115 [{=91/123 ETX=3  VT=11 DC3=19 ESC=27
      $=36 ,=44 4=52 <=60 Dd=68/100 Ll=76/108 Tt=84/116 \|=92/124 EOT=4  FF=12 DC4=20  FS=28
      %=37 -=45 5=53 ==61 Ee=69/101 Mm=77/109 Uu=85/117 ]}=93/125 ENQ=5  CR=13 NAK=21  GS=29
      &=38 .=46 6=54 >=62 Ff=70/102 Nn=78/110 Vv=86/118 ^~=94/126 ACK=6  SO=14 SYN=22  RS=30
      '=39 /=47 7=55 ?=63 Gg=71/103 Oo=79/111 Ww=87/119 _`=95/96  BEL=7  SI=15 ETB=23  US=31
      (=40 0=48 8=56 @=64 Hh=72/104 Pp=80/112 Xx=88/120  DEL=127   BS=8 DLE=16 CAN=24 SPC=32
      INKEY$ ASCII Codes
      Keypress      Plain   +Shift  +Ctrl   +Alt        +Ctrl  +Alt
      ---------------------------------------------   ---------------
      Backspace     8               127     0+14      A   1    0+30
      Tab           9       0+15    0+148   0+165     B   2    0+48
      Enter         13              10         28     C   3    0+46
      ESC           27                                D   4    0+32
      F1            0+59    0+84    0+94    0+104     E   5    0+18
      F2            0+60    0+85    0+95    0+105     F   6    0+33
      F3            0+61    0+86    0+96    0+106     G   7    0+34
      F4            0+62    0+87    0+97    0+107     H   8    0+35
      F5            0+63    0+88    0+98    0+108     I   9    0+23
      F6            0+64    0+89    0+99    0+109     J   10   0+36
      F7            0+65    0+90    0+100   0+110     K   11   0+37
      F8            0+66    0+91    0+101   0+111     L   12   0+38
      F9            0+67    0+92    0+102   0+112     M   13   0+50
      F10           0+68    0+93    0+103   0+113     N   14   0+49
      F11           0+133   0+135   0+137   0+139     O   15   0+24
      F12           0+134   0+136   0+138   0+140     P   16   0+25
      Up Arrow      0+72            0+141   0+152     Q   17   0+16
      Down Arrow    0+80            0+145   0+160     R   18   0+19
      Left Arrow    0+75            0+115   0+155     S   19   0+31
      Right Arrow   0+77            0+116   0+157     T   20   0+20
      PgUp          0+73            0+132   0+153     U   21   0+22
      PgDn          0+81            0+118   0+161     V   22   0+47
      Insert        0+82            0+146   0+162     W   23   0+17
      Delete        0+83            0+147   0+163     X   24   0+45
      Home          0+71            0+119   0+151     Y   25   0+21
      End           0+79            0+117   0+159     Z   26   0+44
      =============================================   ==============
      Now, not being WIN-xx oriented, I can't tell you what the WIN key
      does, huge grin! Or those others curiously intended to do neat
      things in his camp!

      These results all come from what INKEY$ returns when it is hit.

      You can handle the CRL stroke combinations for dealing with things
      like the old WordStar <CTRL Q. plus the following <R> for not
      page top but document top as follows.

      Set a flag integer variable to TRUE, for example, when the key
      <CTRL Q> is first discovered. You of course are waiting for the
      INKEY$ loop to return the next keystroke. For the NEXT stroke
      delivered, if the flag variable is set and you find that the
      needed <R> key is punched, you do what is required, then clear
      the flag integer. As well you clear the flage integer whenever
      any keystroke is hit which does not conform to the matrix table
      you have coded up.

      For example, set DDIQ% to value of 1 if <CTRL Q> is discovered.
      Then you go right back to the INKEY$ loop to see what is hit next.
      On exit with it you examine the ASCI value of what was hit,
      converted to an integer, say, Z6% for the raw code and Z7% if
      it was a two byte control code return. INKEY$ returns more than
      one byte for control strokes!

      You get something like this to decode what you want to do with
      those strokes:

                  ' +++++ Mouse second segment subroutine section ends here
               ' First check double dip flag
                  IF DDIQ% = 1 THEN '                 Waiting for next key value
                     ' Looking for a letter C here - End of Document
                     IF Z6% = 3 OR Z6% = 99 THEN '    Go to end of document
                        Z7% = 79 '                    Set Home key
                        DMY% = LEN(FORM$) '           Check length of I/O
                        DMQ% = LEN(LNPT$) '           Check length of prompt
                        IF DMY% < DMQ% THEN '         Initial input here
                           FORM$ = LNPT$ '            Pick off current line here
                        END IF
                        GOTO FI39970 '                Bail out here
                     END IF
                     ' Looking for a letter R here - Top of Document
                     IF Z6% = 18 OR Z6% = 114 THEN '  Go to Top of document
                        Z7% = 71 '                    Set Home key
                        DMY% = LEN(FORM$) '           Check length of I/O
                        DMQ% = LEN(LNPT$) '           Check length of prompt
                        IF DMY% < DMQ% THEN '         Initial input here
                           FORM$ = LNPT$ '            Pick off current line here
                        END IF
                        GOTO FI39970 '                Bail out here
                     END IF
      ' ... and so on
                  END IF 
               DDIQ% = 0 '                            Clear control flag
      In the above the variable Z6% is the ASCI value for the raw key
      stroke <CTRL C> produces a value of three <3> for example. Once
      we know it was that, we mark it as a special Z7% flag of 79 in
      the above to indicate that it was also to be the function needed
      later in the code to "Go to the top of the document", in that
      since DDIQ was set, we know that <CTRL Q> proceeded it!

      After which we clear the DDIQ% flag.

      As you use all these things, turn an eye toward California and
      give a wink to John Barnaby who gave us all this lo these many
      years ago and far away. His work is precious in that those folks
      who are trained typists never have their fingers leave the normal
      touch typing position on the keyboard. Data we have long ago
      worked up indicate that for keyboard intensive work, his legacy
      produces about 25% more output per unit of time as opposed to an
      infernal mouse.

      This thing escaped into everything from EDIT for DOS to the,
      the PD7 compiler, to even PB 3.5 for DOS! But at least we
      should pay the compliment to the man who thought it up. So
      when one of these gets posted, Mikey does...

      Every time you have to take your hand of a keyboard from that
      touch typing position and reach for the mouse it costs you a
      few pennies. They add up, they add up.


      Mike Luther
      mike.[email protected]
      Mike Luther
      [email protected]


      • #4
        To the best of my knowledge, you can't trap more than one ASCII
        oriented key at one time. You can, however, use int16h sub-function 02h
        to detect certain control keys, i.e. Shift, Alt, Cntrl. I would
        recommend using this so that if, for example, both a shift key
        AND ctrl key is down along with the up arrow key, send the
        telescope to the NW.

        Another, simpler, way would be to just use your mouse.

        Now, since you are programming in DOS, call interrupts will work.

        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.


        • #5
          Using the program to detect what keys do:

          do until a$=chr$(27)
          if a$="" then
          'Dont do anything...this controls what you see
          'on the screen
          print a$, len(a$) 'simply shows that chr$(0)
          'is invisible
          end if

          I evaluated that the arrow keys return

          UP - chr$(0)+"H"
          DOWN - chr$(0)+"P"
          LEFT - chr$(0)+"K"
          RIGHT - chr$(0) + M

          Since the scancode list doesn't list
          the codes supplimented with control, I figured out that you

          CTRL+UP - chr$(0)+chr$(141)
          CTRL+DOWN - chr$(0)+chr$(145)
          CTRL+LEFT - chr=$(0)+"s"
          CTRL+RIGHT - chr$(0)+"t"

          I beleive that the best way to trap such things is with inkey.
          Otherwise you might not get the whole "keystroke"


          P.S. If your using Windows, and want to know what the "Win key"
 CTRL+ESC's an alias for that.



          • #6
            Amos ..

            Now that you've done that .. take another look at the table I gave
            in my earlier post. It might not be perfect .. but it'a a lot
            faster to at least try what it suggests. If you look in the table
            you've just confirmed exactly what I posted as both a suggeestion
            and what you could expect from that suggestion.

            Sure, it's just a start as keyboards as well are the subject, it
            seems, for computer world re-creations of the Great Train Robbery!
            That said, in humor, grin.

            Key theft occurs in more ways in one in this world!

            That table was created, BTW, grin, by running just what you suggested
            in a DOS-VDM session in OS/2, and transfering the output across the
            desktop before WIN-95 was ever created!

            The "Windows Key", CTRL-ESC, was used (and still is!) to pop the
            active session list on top the desktop in OS/2 before WIN-95 ever
            even appeared! Moreover - I think you will find that the extra key
            in the old Northgate Omni-key Ultra keyboards from back about 1982 (?)
            has an extra key on the bottom row between the 'standard' left
            <CTRL> and <ALT> keys that is an upper and lower case ">" and "<"
            when 'shifted'.

            Up at the top left hand corner of these priceless keyboard treasures
            in a little trap door, which you can lift and use to reset any key
            on the keyboard to do something else in returning what you want it
            to do. That was part of the huge fight way back then over whether
            the left <CTRL> key should be down there on the bottom row or up on
            a row above it! 'sfact that these keyboards were shipped with a
            pre-set alternate version of the key position reversal for that left
            <CTRL> key postion debate! You even got replacement key caps to use
            and a key cap puller to use to do the job to replace them if your
            pinkeys were too old fashioned and couldn't be re-trained to use the
            "new" <CTRL> key position!

            Which brings us to the other use for the Omnikey Ultra's! There is
            also a preset auto-map in them for the "DVORAK" sty;e keyboard
            template, instead of the "QWERTY" one we all know and love so well!
            You have to pull all the key caps and swap them all around if you
            want to use the "DVORAK" mapping or was it "DVORK" and something
            else right of that. Heck, I can't remember .. GDRFC!

            Thus if your post is really quite important in that it helps teach
            folks how to settle the issue and that INKEY$ does return more than
            one output code which is the exact way this game is produced in the
            easiest way I knew about to suggest a solution. It also explains
            how to troubleshoot just a boiler plate deal and figure out what
            the latest and greates GREAT KEYBOARD ROBBERY has done with those
            bytes! Huge Grin!

            For those whom want to know, the priceless Northgate Omnikey Ultra
            keyboards are now being made again, brand new, it seems. So said,
            the "WINDOWS" key, sigh, is just exactly what I described as the
            original placement key between the left <CTR> and <ALT> keys, the
            "new" <CTRL ESC> we all now know and love for 'task switch lists' as
            opposed to what it now means. Smile.

            The price of the these keyboards has only risen from about $125 in
            I think 1984 when I bought the four I still use today to the new
            price of $169 US funds from the nice folks in California, so told me.

            Now, if only this web site and Netscape would only cross-enable the
            old WordStar <CTRL key> typing command strokes, us old goats could
            post at least 30% more content into a post like this in the same
            time it takes us to use the silly mouse cut and paste game now!

            Yes, key 'theft' does go back a long way, but the scan code from it
            does seem to have been stable too!

            An it is terribly important in the creation of a program, if you
            want to maximize the through-put of a user with your code, to maje
            sure that however you use scan code output keeps those pinkeys
            glued to that board in the standard accepted touch-typing position!

            All in fun here!

            Mike Luther
            [email protected]
            Mike Luther
            [email protected]


            • #7
              Ah, Mike, but if your messages were 30% longer, we'd have to get a new hard drive...

              Tom Hanlin
              PowerBASIC Staff


              • #8
                Ah, Tom, I find a 'Mike Luther' posting to be one of the "must reads" on
                this board! He is always informative, entertaining, and he makes me think.
                I really appreciate that.

                [email protected]
                :) IRC :)


                • #9

                  If you do choose to implement keyboard routines which use INKEY$
                  please consider *CAREFULLY* looking at what happens to the CPU
                  utilization in multi-tasking platforms.

                  If you use this in a loop, and this operation is involved in a
                  system where the box is used for different tasks which must share
                  the CPU, there is generally a need for providing for time slice
                  releases in PB 3.5 programs when used this way. That is to keep
                  the process from gobbling up the majority of all available time
                  slices for the CPU.

                  A number of ways exist to do that. They have all been posted a
                  number of times in the forums.

                  One particular now more rare but very fatal incidence of this is
                  known to exist for anyone still using an older Intel Classic Pentium
                  or MMX through about 350Mhz, I think is where it was fixed by Intel.
                  You may research it by doing a search on the F0 Bug for those CPU
                  chips. Keyboard pollers like INKEY$ in a loop are not the only
                  source of this problem. It also can be produced by COMM port routines
                  and other ways.

                  An undamped INKEY$ routine which saturates a certain semaphore register
                  in these CPU chips during certain hard disk I/O can TOTALLY destroy a
                  hard disk in a heartbeat at worst and produce even at best a total
                  abend of the box involved.

                  To my information, the most interesting one of these system-wide
                  very difficult to trace scenarios, was the reported OS/2 Rockwell
                  Collins USAF world-wide strategic command voice server network.
                  Used for such reported things as the U2 flight circuits and the
                  Air Force One game, all of the CPU's had to be replaced with
                  different ones, where just the voice server load maxed the CPU
                  and broke the boxes. However any run-away polling problem like
                  the INKEY$ game can trigger it.

                  For safe use of any application in a multi-tasking environment,
                  it is absolutely crucical to provide for some method of time-slice
                  release for the operation system(s) involved.

                  The programmer, to my experience, in the case of the PB 3.5 use
                  of either INKEY$ or ON COMM or whatever, has the tools to do this
                  job in the compiled code.

                  Even though you are not developing on a multi-tassking system, you
                  really need to consider this if any of the uses for the compiled
                  finished code could possibly be run in, say a DOS window in OS/2 or
                  a DOS box in WIN-whatever..

                  Please don't shoot the messenger ..

                  Mike Luther
                  [email protected]
                  Mike Luther
                  [email protected]


                  • #10
                    Mike, where did you hear about that? Is it documented anywhere, such as on the Intel site?


                    PowerBASIC Support
                    mailto:[email protected][email protected]</A>
                    mailto:[email protected]


                    • #11
                      Lance ..

                      Simple documentation .. Just hit GOOGLE and search on "F0 BUG" and
                      it will start you down the incredible pig trail, Lance.

                      I hit it spam on with the PowerBASIC IDE and Debugger here. I
                      completely and totally wiped a hard disk TWICE and had to back
                      up the entire system from tape over the PB IDE's inability to
                      throttle keyboard polling in DOS-VDM sessions in OS/2. In
                      *MAY* particular box operational mix it provokes it. I doubt
                      if you will ever see it., but it may explain some things ..

                      My development machine uses a Modular Industrial System single
                      board CPU insert in an Interlogic linear power supply relay
                      rack case with a PCI passive backplane assembly. The box had
                      just undergone an upgrade to the cited type CPU from this vendor.

                      Recall that this box is deliberately styled to stress the whole
                      operation as hard as possible, under the theory that if you can
                      do an entire development operation simultaneously with all four
                      serial ports going, the entire server game, as well as the entire
                      network and TCP/IP game all going on at once, it is very unlikely
                      that most ordinary installations will fail.

                      What started happening was that as usual, dog tired after yet
                      another day bashing at all the rest of the stuff, I'd not quite
                      literally, but almost, fall asleep (again) at the keyboard. There
                      would be another one of these massive programs still loaded in the
                      IDE running for debugging when I'd simply have to quit.

                      Of course the CPU is TRASHED .. not only TRASHED, but so badly
                      with the PB IDE, that all the whole server and TCP/IP and disk
                      operations are at a CRAWL. Remember, I've been after this
                      inability to clean up the IDE polling game ever since the toolset
                      for PB was installed?

                      Come morning, I would come in and the box would be total locked.
                      Files would be corrupted, the work operation smashed. Hours or
                      days of work would get lost until I learned (the hard way!) that
                      you ****NEVER**** go off and leave the IDE or the DEBUGGER in
                      focus in a multi-tasking system, at least given any of four
                      different tools that I have to fight this with. NONE of them
                      can break it in the IDE, in stark contrast to being able to
                      throttle it in every other DOS-VDM application I have ever
                      been able to run ..

                      In working *VERY* carefully with the MIS crew at this, it came
                      to light that the symptoms were very close to those at the time they
                      hit it with the USAF Rockwell Collins operation. MIS is/was
                      the industrial CPU card vendor to Rockwell Collins for the
                      project, so told me. So told me, IBM's OS/2 crew had beat their
                      heads against a wall with the lockups for a while when MIS was
                      finally called in. MIS has one gent who is a certified INTEL
                      support engineer. When IBM walked the job unable to find the
                      flaw in OS/2, MIS was called in for the complete down to the CPU
                      trace runs in cooperation with Intel. It is, as I was told,
                      here, that Intel first learned about the issue of what became
                      to be the F0 Bug.

                      MIS confirmed what we had going on with the PB IDE polling problem,
                      which, in and of itself, was not thought to be such that in OS/2
                      the fatal 64th level of the semaphore register on the CPU would
                      be busied out for what I was seeing. However, under the intense
                      telecommunications data operations with the required I/O buffering
                      which has to go on in any pre-emptive system, the guess was that
                      my box would, very easily, fall into exactly the same trap which
                      hit the USAF project, Lance.

                      I couldn't afford to replace the whole CPU card or update CPU's at
                      the time, as this was the then near top-of-the-line system! So
                      the decision was to simply not go off and ever leave the IDE or
                      the debugger up in the focus mode when actually not in use.

                      The issue *NEVER* arose after that to the extent
                      that I ever had to re-build a hard drive over it.

                      Again .. PowerBASIC is *NOT* responsible for the damage, I've
                      never ever said so, although early on I was very angry over the
                      loss of the time and work, more so until I learned the whole
                      story from MIS and Intel. Sometimes it takes a while to
                      dig out the real reasons for things Lance.

                      My insistent posts as to the absolute necessity to pay careful
                      attention to poll damping requirements in any PB 3.5 compiled
                      program are rooted in this very real nightmare here.

                      The issue was resolved by prudent behavior until a while back
                      when the CLASSIC Pentium was replaced with yet a better board
                      and CPU. At that time in the pile of data there was a small
                      program in a ZIP file which circulates on some of the BBS
                      systems here and there.

                      I'm sending you a copy of it as a MIME file attach via EMAIL
                      to you as F0BUG.ZIP. You folks are free to do what you want
                      for investigation, but the issue is a long way back in CPU
                      versions from today's units. Yet there are millions of these
                      CPU units still out there though, so the Cautionary Tale
                      is still important.

                      Most important of all, as far as PowerBASIC is concerned, is
                      the thought I've expressed a few times. Ya'll should give us
                      some serious thought at how to damp the keyboard polling in
                      the IDE and Debugger. The tool of choice for, I think, many
                      of us is what is now up to TAME333.

                      Most important, it was *YOU* who furnished the suggested way
                      to include WIN-9x time slicing in my compiled code to catch
                      that as well as for the OS/2 DOS-VDM sessions.

                      As this is being written, there are 15 active tasks on this
                      box with 32 processes and 129 active threads on it, Lance,
                      of which there are three simultaneous PB 3.5 apps for DOS
                      running simultaneously in separate DOS-VDM sessions. The CPU
                      load is seldom ever over 10% at all. If I just load the IDE
                      or the debugger - we are at a flat 100% CPU load instantly and
                      it cannot be broken that I can tell.

                      There are many people here far smarter and capable than I ever
                      will be. Yes, what I see and discover is often way out in right
                      field, but there *IS* one in every ball park. Once and a while
                      even the right fielder gets to throw one all the way home to
                      block a home run from the opposition!

                      Blocking this one means you have to strike out the heavy hitter
                      before he ever gets a chance to shuck you out of the ball park,
                      or else....

                      Mike Luther
                      [email protected]
                      Mike Luther
                      [email protected]


                      • #12
                        Mike, "locking up the CPU" and "frying the CPU" are not really the same thing at all.

                        The "FO BUG" (as it is variously known), is a Classic Pentium (ie, 1st generation Pentium) bug that causes the CPU to lock up if a particular set of machine code instructions are executed.

                        Can you explain how 100% CPU usage can possibly be because of the FO BUG? Logic tells me that if FO BUG is present on a given test CPU, then the lock up WILL occur the first time the particular code is executed - not when the CPU is running at 100% for some number of hours.

                        According to, "The serious nature of this bug has prompted Intel to give it their highest attention. Within one week, they announced a software workaround, which can be incorporated into virtually any operating system (except real-mode operating systems, like DOS).".

                        Mike, has IBM incorporated the patch into OS/2 yet?

                        Anyway, I would suggest the real cause of your particular problem is a simple matter of a lack of adequate CPU cooling, resulting in an overheated CPU when running at 100% utililzation for some hours at a stretch...



                        PowerBASIC Support
                        mailto:[email protected][email protected]</A>
                        mailto:[email protected]


                        • #13
                          Rememebr Lance ..

                          I'm *NOT* posing as any expert. I'm learning even from these
                          conversations here as well, OK?

                          Can you explain how 100% CPU usage can possibly be because of the
                          FO BUG?
                          If that is what came out of the post(s), that is not what was
                          intended. looking back over all of this for years now, I think
                          it is clear that I've never said nor implied that the F0 bug
                          causes 100% CPU usage.

                          Applications do, of which the IDE and Debugger are only one of
                          a rather large number of DOS applications which do so, per what
                          I have seen here. Others may either substantiate that or refute
                          it. If *ANYONE* else here has a work-around to break this up
                          with an OS/2 VDM session, *PLEASE* don't just sit and read, but
                          furnish the vector to that solution.

                          Logic tells me that if FO BUG is present on a given test
                          CPU, then the lock up WILL occur the first time the particular
                          code is executed - not when the CPU is running at 100% for some
                          number of hours.
                          That is not what MIS told me. The damage is related, per what was
                          told to me, to hard disk I/O operations, of which a certain pattern
                          of use is necessary, at the same time the 64th level roll-over
                          occurs, to trigger the damage. It may be hours before the odd
                          combination of hard disk I/O, caching, application I/O sequencing
                          and the F0 Bug and program loading combine to provoke the disaster.

                          Again, I am not posing as any authority, only revealing what I've
                          had to do to 'cure' the thing here. In my case, it wasn't to
                          cure it by replacing the product, but by fixing the symptom.

                          According to, "The serious nature of this bug has prompted Intel to give it their highest attention. Within one
                          week, they announced a software workaround, which can be incorporated into virtually any operating system (except
                          real-mode operating systems, like DOS).".
                          I am aware of that statement.

                          Mike, has IBM incorporated the patch into OS/2 yet?
                          I do not know.

                          Further, I can also, only as a result of long experience, and not
                          from hard evidence, tell us here that in the case of a box with
                          multiple telecommunications apps there is another side to this.
                          If any of them are DOS-VDM's it may be that you can stop the
                          lockups with OS/2 if you will turn the "INT_DURING_IO" DOS session
                          setting option to "ON." However also from long experience, that
                          will *NOT* help the issue if it has been provoked by the IDE or
                          Debugger, Lance.

                          Religions, personal relationships, software development projects
                          all have a common attribute, I think! I knew, rather well, two
                          very intelligent A&M professors who traded wives, formally.
                          Thereafter, each also traded for someone else, one of them ruefully
                          telling me, "Mike, every jewel has its flaws."

                          One of the flaws about IBM is that you must pay to play the. "It
                          doesn't work!", gambit. Now, not all the time does this happen!
                          But, essentially, for IBM to consider a bug report, you file a
                          written complaint on a specific form application. When you file
                          it, you agree that if it is IBM's problem, they will fix it for
                          free. If not, in their opinion, you pay the going senior engineering
                          rate to fix it, about $175 an hour for this or that, whatever.
                          The figure is a common figure for senior level support time, as
                          even you'll attest about PowerBASIC, I'm sure.

                          Bottom line is that large organizations such as DeutchBank or
                          Daimler-Benz, for example, are capable of working at the level
                          of support. Little fisheys like Mikey, and I suspect, Lance,
                          are not. Some things that rise to the attention of IBM, and
                          PowerBASIC, and all such operations, get fixed without paid-for
                          support; some do bring money! Thus, what gets fixed, ultimately
                          seems to be that which is economically productive to fix, either
                          driven from a positive or negative side of the fence!

                          "Bugs", in software and computerese, so named after an IBMer found
                          a bug inbetween a set of relay contacts back in the INIAC days,
                          are a fact of life. The war on bugs will continue forever here.

                          With *VERY* few exceptions in human history, all wars are economic,
                          Lance. Even the Children's Crusade had economic underpinnings,
                          per the wonderful Dr. Peter Ford here a A&M who wound up giving
                          up the priesthood in marriage over an affair at Sourbonne (sic?)
                          All wars are economic, and as he also noted, business is the modern
                          day civilized equivalent of war. Animals we are, Lance, all.
                          He was a remarkable professor, probably touched far more lives than
                          had he ever done as a Priest, in my view.

                          As the other of these two far smarter than I will ever be A&M
                          profs told me who was involved in the trade, "Mike, I can't put my
                          my finger on it, but there is a pattern here!"

                          Economically, later on, the wives wound up with most everything.
                          So noted an associate of both of them, "Caeser plowed and
                          Cleopatra cropped."

                          I've already told you that PowerBASIC isn't, in my opinion, the
                          cause of any damage from the F0 Bug, of which it, here, has
                          been a part of evoking...

                          The PowerBASIC 3.5 compiler is one of the most faithful mules
                          I've ever had the pleasure of plowing with! He is certainly
                          licensed to plow! In jest here, I can always wear earplugs
                          when riding behind the go-devil when I'm awake! But "When I
                          lay me down to sleep ..", if perchange the 64th Angel rolls
                          over on us all and unleashes Armagedon in the Kingdom, either
                          because this or any other mule insists on braying, so nobody
                          can hear the Angel trumpet; I'll pen him where we can't
                          hear him, or any like him!

                          In practice, it's either that or miss the call!

                          All wars are economic. Thank you Peter Ford.

                          In the mean-time, we really shouldn't oughta have to take a
                          two by four to any mule to stop it from braying if it's
                          hitched to the Borox wagon as part of the team!

                          Kindly accomodate us back-country mule skinners when the next
                          one comes throught the auction for us to buy, OK?

                          All in humor here Lance ...

                          Mike Luther
                          [email protected]
                          Mike Luther
                          [email protected]