Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!ahs From: AHS@PSUVM.BITNET Newsgroups: comp.sys.ibm.pc Subject: Re: Re: Re: Keyboard "fix" TSRs Message-ID: <45919AHS@PSUVM> Date: 23 Jun 88 04:35:16 GMT Organization: The Pennsylvania State University - Computation Center Lines: 94 In the article: From: toma@tekgvs.TEK.COM (Tom Almy) Date: 21 Jun 88 15:50:53 GMT Tom replies: >In article <8806190331.AA02653@slvblc.UUCP> AHS%psuvm.bitnet@rutgers.edu writes: >>Tom Almy, toma@tekgvs.TEK.COM, writes of his set of KBD*.com programs: >> >< All of these [AT only] programs were written by me, using the CFORTH >< Forth Compiler, and are placed in public domain for the benefit of >< other PC users who are frustrated with these keyboard designs. >> >< I am not supplying sources, the programs are small enough that DEBUG >< can be used to reverse-engineer them. >> >>I attempted a dissassembly of: >> >< KBDL COM 332 6-15-88 7:03a >> >>I include the dissassembly below. The dissassembled code is logically >>consistent in its jumps, calls, reads, and writes, but is very strange. The >>resulting flow is very simple, yet this dissassembled code is so strange that I >>wonder..... Further, the file KBDL.COM contains several CD 21 op-codes but >>contains *no* CD 27 or CD 31 op-codes which are *necessary* to terminate and >>stay resident. Is it Forth, is it Almy, is it me..... I don't know, I don't >>have an AT to try it (if I would still dare try it). > >Well, what it is is the disassembler you used! That's why I said "DEBUG can >be used". The sequence > MOV DX, 0CH > MOV AX, 3100H > INT 21H >exists, as part of: Yes, I saw these opcodes. I list that dissassembly in one of my two subsequent postings on comp.binaries.ibm.pc . Now you said debug "can be used", you did not say "must be used". Further you did not say that using debug's "U" command would not be enough to Unassemble the code. Should you have said "debug's Trace command *must* be used, and better watch the stack after making a call and before returning to that call"?. >>;The following DB are bytes unused by the program >.... >< DB [...],0BA >< DB 0C,0,0B8,0,31 >< DB 0CDH,21 >> >>L017F: CALL L01FE > >The disassembler failed to see most of the code, because of some >assumptions it made. *I* made the assumptions, not the machine, when I saw what followed the CALL L01FE. In my third posting, I show in detail why I made those assumptions. > For instance, this call is followed by by about >50 bytes of "unused by the program", but it is! There are few data areas, >and some ASCII strings are embedded in the code (such as immediately after >the above CALL L01FE). The subroutine pops the return address into a register, >increments through the string, and pushes the now correct return address back >on the stack, before eventually returning. Please explain why you make a CALL (which means: "After completing the call, I want to resume execution at the line that follows the call"), and then play with the stack so that execution will *not* resume at the line following the call?. Why?. Why not use JMP?; it would be straighforward. The only reason I know for (1) destroying (in the stack) the normal return address of a CALL, and (2) filling the lines that follow the CALL with non-code (either garbage, or a data-area, or text) is to foil dissassembly. Was this you purpose?. If not, what was your purpose in destroying the normal return address of the call?. >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. >Tom Almy >toma@tekgvs.TEK.COM > ---------------------------------------------------------------