Image Map Image Map
Page 1 of 5 12345 LastLast
Results 1 to 10 of 44

Thread: DOS mysteries

  1. #1

    Default DOS mysteries

    There are a few questions that even after working on DOS and seeing all of the source code I was unable to find an answer for:

    2.0+ Why was INT 21h/RETF (CDh 21h CBh) added to the PSP at 50h ? Described as "portable method of system call" in the DOS source code (inc\pdb.inc) - portable to what ? Some people speculate it was intended for DOS/Xenix portability.

    2.0+ What was the purpose for the undocumented INT 2Eh COMMAND.COM backdoor which executes a command as if it was entered from the command line and did any software actually use this ?

    3.2+ In the floppy disk boot sector validation code why is 69h checked for as a valid first byte ? The DOS source code (bios\msdisk.asm) refers to 69h as a "direct jump" and in later versions also as a "long jump". Of course opcode 69h is IMUL on 80286 and later and undefined on 8086/8088 (likely functioning as an alias for opcode 79h JNS) so the comment makes no sense. The 69h could instead be part of a signature (69h = 'i') and the comment is wrong but since no disk has ever been found which uses this it is unknown why this check was added in DOS 3.2.

    3.0+ Why was INT 21h function 62h (get current PSP) added when function 51h already existed ?
    4.0+ Why was INT 21h function 6Ah (commit file) added when function 68h already existed ?

  2. #2
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,570
    Blog Entries
    1

    Default

    PSP:50h Besides Xenix, HandHeld DOS might be the other possible target of a portable system call. HHDOS differs from MS-DOS by using INT 42h for the interface. I haven't seen any shared code generator for either Xenix/DOS or HHDOS/MSDOS that went to PSP:50h.

    INT 2Eh has a long discussion in Undocumented DOS. OPENDos lists Novell menus as a reason to upgrade Int 2eh support specifically to launch batch programs from within the menus.

    New public functions that duplicate old undocumented functions: of course, those will be listed at the end. No one checks through the old API list to see what functions have newly become visible. Funny, Undocumented DOS first edition lists 6Ah as being unknown.

  3. #3
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,404
    Blog Entries
    18

    Default

    The 69h boot sector thing has been the subject of many discussions over the years, with no solid resolution.

    I suspect a typo--the 69h should be E9h.

  4. #4

    Default

    Quote Originally Posted by krebizfan View Post
    INT 2Eh has a long discussion in Undocumented DOS. OPENDos lists Novell menus as a reason to upgrade Int 2eh support specifically to launch batch programs from within the menus.
    Interesting book but nothing there would be official.

    Quote Originally Posted by krebizfan View Post
    New public functions that duplicate old undocumented functions: of course, those will be listed at the end. No one checks through the old API list to see what functions have newly become visible. Funny, Undocumented DOS first edition lists 6Ah as being unknown.
    Whomever added the duplicate functions had to know they were duplicates. The undocumented functions were clearly marked as such in the source code. In the case of function 62h, my best guess is that they didn't want to mention any of functions 50h-53h so they just added a duplicate even though function 51h was already there since DOS 2. I can't imagine why function 6Ah was added when function 68h was already there since DOS 3.3 and documented. Another foolish thing done in DOS 4.

    Quote Originally Posted by Chuck(G) View Post
    The 69h boot sector thing has been the subject of many discussions over the years, with no solid resolution.

    I suspect a typo--the 69h should be E9h.
    Definitely not a typo, the code explicitly checks for all three: 69h, E9h and EBh.

  5. #5
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,404
    Blog Entries
    18

    Default

    Definitely not a typo, the code explicitly checks for all three: 69h, E9h and EBh
    That doesn't mean anything, in my opinion. The DOS code is littered with kludges that deal with prior errors.

  6. #6

    Default

    Quote Originally Posted by Chuck(G) View Post
    That doesn't mean anything, in my opinion. The DOS code is littered with kludges that deal with prior errors.
    The 69h check wasn't there in DOS 3.1 so it was specifically added to deal with something. I remember there was also a comment about Symphony diskettes in that part of the code, presumably referring to Lotus Symphony.

  7. #7

    Default

    Quote Originally Posted by krebizfan View Post
    PSP:50h Besides Xenix, HandHeld DOS might be the other possible target of a portable system call. HHDOS differs from MS-DOS by using INT 42h for the interface. I haven't seen any shared code generator for either Xenix/DOS or HHDOS/MSDOS that went to PSP:50h.
    I had never heard of HHDOS. Apparently a Tandy 600 specific thing. That Tandy 600 actually seems less PC compatible than the PCjr. Anyway it is from 1985 and the PSP:50h stuff was added in DOS 2 which came out in 1983.

  8. #8
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    4,570
    Blog Entries
    1

    Default

    Quote Originally Posted by pcdosretro View Post
    I had never heard of HHDOS. Apparently a Tandy 600 specific thing. That Tandy 600 actually seems less PC compatible than the PCjr. Anyway it is from 1985 and the PSP:50h stuff was added in DOS 2 which came out in 1983.
    Not just the Tandy 600. The Zenith ZP150 from 1984 is a more expensive version of a similar machine. And there may have been some Oki prototypes predating that. It would seem the idea of a MS-DOS variant sitting on a different interrupt would have been available in 1983. PSP:50h needs something that handles parameters the same as MS-DOS since all it does is pass control to the interrupt. With something like HHDOS code intended to also run on MS-DOS, it could make the call to PSP:50h and then get sent to the correct interrupt for the OS it is running on.

    I should check Xenix function calls more carefully but I am fairly certain that a shared library would need to do a lot of work turning Xenix calls into MS-DOS calls, so much work that one might as well include the INT 21h call in the process.

  9. #9

    Default

    Quote Originally Posted by krebizfan View Post
    Not just the Tandy 600. The Zenith ZP150 from 1984 is a more expensive version of a similar machine. And there may have been some Oki prototypes predating that. It would seem the idea of a MS-DOS variant sitting on a different interrupt would have been available in 1983. PSP:50h needs something that handles parameters the same as MS-DOS since all it does is pass control to the interrupt. With something like HHDOS code intended to also run on MS-DOS, it could make the call to PSP:50h and then get sent to the correct interrupt for the OS it is running on.

    I should check Xenix function calls more carefully but I am fairly certain that a shared library would need to do a lot of work turning Xenix calls into MS-DOS calls, so much work that one might as well include the INT 21h call in the process.
    DOS 2 development began in 1982 so it seems unlikely the PSP:50h far call was for a system which used different interrupts for the DOS API. Did the Tandy 600 BIOS use INT 21h for something else ? Intel originally reserved interrupts 05h-1Fh for future use but IBM went ahead and used a bunch of them anyway.

  10. #10
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,404
    Blog Entries
    18

    Default

    Anent PSP:50h, probably a dead-end development. It would be interesting to see the internal PCDOS 2.0 design documents.

    Discussion on the 69h thing here

    As noted, the comment in MSDISK doesn't make any sense; 69h is not a direct jump; EAh is.

    Code:
                   ; put a sanity check for the boot sector in here to detect
                    ; boot sectors that do not have valid bpbs. we examine the
                    ; first two bytes - they must contain a long jump (69h) or a
                    ; short jump (ebh) followed by a nop (90h), or a short jump
                    ; (e9h). if this test is passed, we further check by examining
                    ; the signature at the end of the boot sector for the word
                    ; aa55h. if the signature is not present, we examine the media
                    ; descriptor byte to see if it is valid. for dos 3.3, this
                    ; logic is modified a little bit. we are not going to check
                    ; signature. instead we are going to sanity check the media
                    ; byte in bpb regardless of the validity of signature. this is
                    ; to save the already developed commercial products that have
                    ; good jump instruction and signature but with the false bpb
                    ; informations
                    ; that will crash the diskette drive operation. (for example, symphony diskette).
    
             cmp    byte ptr [disksector],069h      ; is it a direct jump?
             je     check_bpb_mediabyte             ; don't need to find a nop
             cmp    byte ptr [disksector],0e9h      ; dos 2.0 jump?
             je     check_bpb_mediabyte             ; no need for nop
             cmp    byte ptr [disksector],0ebh      ; how about a short jump.
             jne    invalidbootsec
             cmp    byte ptr [disksector]+2,090h    ; is next one a nop?
    Note that a "long jump" is called 69h in the commentary. But it isn't. Tell me that it's not an error!
    Last edited by Chuck(G); January 20th, 2020 at 05:03 PM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •