Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!nrl-cmf!ukma!psuvm.bitnet!ahs
From: AHS@PSUVM.BITNET
Newsgroups: comp.sys.ibm.pc
Subject: Re: Decency on the net.
Message-ID: <46157AHS@PSUVM>
Date: 27 Jun 88 06:13:21 GMT
Organization: The Pennsylvania State University - Computation Center
Lines: 147


Keith write:
>>From: keithe@tekgvs.TEK.COM (Keith Ericson)
>>Subject: Decency on the Net (was Re: Keyboard "fix" TSRs)
>>Date: 24 Jun 88 17:37:44 GMT
>>Organization: Tektronix, Inc., Beaverton,  OR.
>>
>>In article <45919AHS@PSUVM> AHS@PSUVM.BITNET writes:
>>>
>>>Tom replies:
>>>>In article <8806190331.AA02653@slvblc.UUCP> AHS%psuvm.bitnet@rutgers.edu writes:
>>>
>>>>This program does work as advertised!
>>>
>>>                Prove it.  Publish the correct symbolic dissassembly.  I am
>>>                not going to load in my machine routines that deeply alter
>>>                its guts without looking at the code first.
>>>
>>
>>["deeply alter its guts" referring to stack manipulation in the
>> program - kde]


        Manipulating the stack will not move keys around the keyboard.

        No.  To move the keys around, you need to alter the guts of the machine
        such as re-vectorizing some interupts, such as Int 09 (or 15, or ???),
        and perhaps play with IN and OUT ports -- these are not trivial
        programs.  If done improperly (and bugs are always a possibility), they
        will create instabilities or conflicts.  (I am sure you have heard of
        TSR conflicts, especially among those who use Int 09).

        Now, these interrupts are so hush hush that, for example:

        Int 9 (the keyboard interrupt):

        Int 9 is not described in Ray Duncan's Advanced DOS.  He only
        discourages such programing and says to those who must ignore his
        advice to go and study the assembly code for the keyboard handler in
        the IBM tech ref manual.

        Int 9 is not described in Ralf Brown's superb and super-extensive
        documentation of practically all interrupts.  His only entry is:

            Last edited 1/30/88
            -----------------------------------------------------------
            INT 09 - MATH UNIT PROTECTION FAULT (80286 protected-mode internal)
            -----------------------------------------------------------

        Not a word on the keyboard (I am *not* blaming Ralf -- I am *too*
        grateful to him for having done this compilation.  I am just saying
        that Int 9 is undocumented and information on Int 9 is hard to come
        by -- which increases the chance of programming bugs).


>>You know, some people would complain if they were handed the earth
>>on a silver platter.
>>
>>The person posting this veiled accusation


                Which accusation ?



>>is certainly not worth my
>>time of posting a rebuttal, but Tom's work and reputation most
>>certainly are.
>>
>>It distresses me greatly that  (why
>>doesn't he or she include their name in their postings, by
>>the way?) feels that their cautious skepticism must be
>>blasted all over the Net instead of conducted in civil,
>>private e-mail. QUESTIONS such as this should be asked and
>>answered via private e-mail, with RESULTS posted to this
>>wider forum.


                The challenge to dissassemble the KBD* programs was made
                publicly, not privately.


>>Anyway, simply because  is incapable of
>>properly disassembling Tom's program is not grounds for accusations of
>>skulduggery or devious programming.


                No personal remarks were made.  Only questions about the code
                and the programming intentions of the programmer concerning the
                program flow were asked.



>>I know Tom as a co-worker and
>>friend; the reason the code may be difficult to exegete is that it is
>>well written by a craftsman who knows the ins and outs of the
>>IBM-PC/AT/Clone/DOS architecture better than anyone else I know.


                The code to be dissassembled was written by a compiler.
                Typically, a human writes assembly differently; often clearer,
                sometimes elegantly.  From my readings, the best compilers are
                not yet there.

>>Not
>>satisfied with the size/speed performance of "conventional"
>>programming languages, Tom is an acknowledged expert in FORTH
>>programming, having written (among many other things) a compiler which
>>inhales FORTH code and exhales tight, well-optimized machine code.


                Tight and well optimized code are relative notions.  I cannot
                believe that the standard of comparison you are using is
                hand-crafted assembly.  More likely, you are comparing to the
                output of a set of comparable compilers.


>>It
>>is this output that you have as his keyboard macros. FORTH uses stacks
>>as a matter of course and this is exemplified in Tom's keyboard
>>macros. To castigate the program and/or Tom (as was done in these
>>postings)

                Again, read the original.  No personal remarks were made.  Only
                questions about the code and programming intentions were asked.
                Remember, the posting of the programs contained a public
                challenge to dissassemble them.  The wording was ambiguous and
                suggested that dissassembly was either trivial or a challenge.


>>is simply a demonstration of one's onwn ineptitude and lack
>>of proper human-relationship abilities.
>>
>>This will be my only posting on the subject: public rebuttals and
>>retorts will be ignored; private e-mail will be answered (given a
>>useable return path is provided/discernable).
>>
>>Thank you for your patience in reading this.
>>
>>keith


                A final note:  I have both separately and by private mail
                thanked Tom Almy for showing us how to use Int 15 to remap the
                keyboard.


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