Announcement

**Lance Edmonds** · 30 Jul 2001, 06:59 AM

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

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

**Mike Luther** · 30 Jul 2001, 07:41 AM

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:

Code:

   HUMAN ORIENTED PRINTABLE ASCII CHARACTER TABLE * NUL = 0
!=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:

Code:

            ' +++++ Mouse second segment subroutine section ends here
CHOMP:
         ' 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.

Cheers!

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

**Mel Bishop** · 30 Jul 2001, 08:10 AM

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.

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

**Amos Vryhof** · 3 Aug 2001, 12:58 AM

Using the program to detect what keys do:

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

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
get:

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"

Amos

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

------------------
Amos

**Mike Luther** · 3 Aug 2001, 04:51 AM

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]

**Tom Hanlin** · 3 Aug 2001, 07:16 AM

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

------------------
Tom Hanlin
PowerBASIC Staff

**Ian Cairns** · 3 Aug 2001, 08:06 AM

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.
regards,

------------------
[email protected]

**Mike Luther** · 4 Aug 2001, 10:39 AM

PS!

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]

**Lance Edmonds** · 4 Aug 2001, 04:03 PM

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

Thanks!

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

**Mike Luther** · 4 Aug 2001, 09:51 PM

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]

**Lance Edmonds** · 5 Aug 2001, 03:54 AM

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 x86.com, "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...

References:
http://msowww.anu.edu.au/~peterson/pentium_lock.htm

http://www.x86.org/errata/dec97/f00fbug.htm

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

**Mike Luther** · 5 Aug 2001, 08:08 AM

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 x86.com, "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]

Announcement

Using Ctrl-Arrows and Arrows on PB/DOS

Using Ctrl-Arrows and Arrows on PB/DOS

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment