• Please review our updated Terms and Rules here

Dos 2.0 source released

The change was not the release which happened a few years ago; MS appears to have decided to put the code under the MIT license so using the code for something is possible while the earlier release was largely limited to researching articles about MS-DOS.
 
It is present. What is not present, unfortunately, is a description of a working build process (ie. how to turn the source into a bootable disk). An old MASM is required, but that's easy to fix.
 
Trixter said:
It is present. What is not present, unfortunately, is a description of a working build process (ie. how to turn the source into a bootable disk). An old MASM is required, but that's easy to fix.
Click to expand...

has anyone compared what MSFT released to what was given to CHM?
 
The Version 2 seems to be the same except about half of the ASM files cause my diff program to announce "different in blanks only." V1.1 versus V1.25 directories show the same thing: files are identical except for most ASM files having different blanks.
 
eeguru said:
Is SKELIO.ASM not it? It's my understanding IO.SYS is where OEM customizations went.
Click to expand...

That's true--worked on a custom IO.SYS myself years back. I may even have the printed (probably now very faded) OEM build instructions somewhere deep in my paper files. I do remember that in that file, MS stated that DOS 2.0 was the first step in getting DOS and Xenix to a common product.
 
I have a version of MS-DOS 2.0 for my Seattle Gazelle that's basically the "OEM Adaptation Kit" version. I'd have to dig up the instructions but basically it was a batch file that compiled and linked the IO.SYS source files and a few utility and build programs, including one to write it to the boot sector of a diskette (but different than sys.com). It also had a fixed disk driver skeleton which, in my case, produced an installable driver for the 10MB hard drive I have, and a custom "format.com".

The Gazelle distribution, while similar to, isn't the same as the Microsoft distribution for the PC -- many utility programs are missing because they either don't apply to the system or were written by IBM for the PC.
 
The MIT release was missing a couple of source files needed for the MSDOS.SYS build. I've reconstructed these based on the binary MSDOS.SYS in the same release, so you can find building 2.00 and 2.11 versions of MSDOS.SYS at http://www.seasip.info/DOS/

Next step, fix that bug in DEBUG that gets the CALL 5 offset 2 bytes too low (still present in the Windows 10 DEBUG!)
 
So I have to ask, will anyone be compiling dos2 to milk the most performance out of a old 8080 or 286 systems?
 
JohnElliott said:
Next step, fix that bug in DEBUG that gets the CALL 5 offset 2 bytes too low (still present in the Windows 10 DEBUG!)
Click to expand...

How about rewriting the CALL 5 hack entirely, so that it doesn't rely on address wraparound?

My idea is to set the byte at PSP:5 to 3Dh ('CMP AX,iw'), which skips over the memory size. This leaves two bytes for an INT 30h to invoke the real handler. Possibly fixes DEBUG too, or breaks it further, depending on whether it uses the DOS function or its own code to create the child PSP.

Code: 
;MSCODE.ASM - line 112 (+1 byte)
entry   CALL_ENTRY                      ; System call entry point and dispatcher
        POP     AX                      ; IP from the INT at 8
        POP     AX                      ; Segment from the INT at 8
        POPF                            ; Restore flags

;MISC.ASM - line 629 (-3 bytes)
HAVDIF:
;       MOV     BX,ENTRYPOINTSEG
;       SUB     BX,AX
        MOV     CL,4
        SHL     AX,CL
        MOV     DS,DX
        MOV     WORD PTR DS:[PDB_CPM_Call+1],AX
;       MOV     WORD PTR DS:[PDB_CPM_Call+3],BX
	MOV	WORD PTR DS:[PDB_CPM_Call+3],(30H SHL 8) + mi_INT
        MOV     DS:[PDB_Exit_Call],(int_abort SHL 8) + mi_INT
;       MOV     BYTE PTR DS:[PDB_CPM_Call],mi_Long_CALL
        MOV     BYTE PTR DS:[PDB_CPM_Call],3DH

;MSINIT.ASM - line 272 (-5 bytes)
;       MOV     BYTE PTR DS:[ENTRYPOINT],mi_Long_JMP
;       MOV     WORD PTR DS:[ENTRYPOINT+1],OFFSET DOSGROUP:CALL_ENTRY
        MOV     WORD PTR DS:[ENTRYPOINT],OFFSET DOSGROUP:CALL_ENTRY
;       MOV     WORD PTR DS:[ENTRYPOINT+3],AX
        MOV     WORD PTR DS:[ENTRYPOINT+2],AX
 
dreNorteR said:
How about rewriting the CALL 5 hack entirely, so that it doesn't rely on address wraparound?
Click to expand...

You would break WordStar 3 if you do that. WordStar is one of the CP/M derived programs that checked the value of memory size in that position. I think a lot more programs used the memory size value than bothered with CALL 5, especially since CALL 5's stack rearranging and other CP/M oddities were poorly documented.
 
krebizfan said:
You would break WordStar 3 if you do that. WordStar is one of the CP/M derived programs that checked the value of memory size in that position. I think a lot more programs used the memory size value than bothered with CALL 5, especially since CALL 5's stack rearranging and other CP/M oddities were poorly documented.
Click to expand...

Yes, that's why I leave that intact, embedded in a 'CMP AX,xxxx' instruction (affects only flags).

Code: 
PSP looks like this:
0005 DB 3Dh ;opcode for cmp ax,
0006 DW memory_size
0008 INT 30h

The only thing this would break is code that relies on a far jump being at 0000:00C0
 
dreNorteR said:
Yes, that's why I leave that intact, embedded in a 'CMP AX,xxxx' instruction (affects only flags).

Code: 
PSP looks like this:
0005 DB 3Dh ;opcode for cmp ax,
0006 DW memory_size
0008 INT 30h

The only thing this would break is code that relies on a far jump being at 0000:00C0
Click to expand...

You are correct that the memory size is handled correctly. My mistake there. But wouldn't an extra RET be needed at PSP offet 0Ah to get back to the correct address of the CALL since the RET in DOS 21h code would only bring the code back to after the INT 30h call? CALL 5 uses multiple jumps to keep from resetting the return address so only the same RET that normal INT 21h calls would use is required. I don't know if any programs rely on the PSP 0A - 0D INT 22h Termination alias.
 
krebizfan said:
You would break WordStar 3 if you do that. WordStar is one of the CP/M derived programs that checked the value of memory size in that position. I think a lot more programs used the memory size value than bothered with CALL 5, especially since CALL 5's stack rearranging and other CP/M oddities were poorly documented.
Click to expand...

That is probably a myth. The OS/2 Museum analyzed the code of WordStar 3.24 (the oldest surviving version) and found that it did not use CALL 5. Instead the blame most likely lies with Microsoft's own Pascal compiler, which did use CALL 5:

http://www.os2museum.com/wp/the-a20-gate-it-wasnt-wordstar/
 
You must log in or register to reply here.
Back
Top