Hi Eric,

> Well if it aborts then it will have a reason to do so.
> You cannot force a program to continue just by, say,
> IRETing from int 21.4c...

Yeah. But that's (exactly) what DOS-C does.

>> Disassembling parts of the MS-DOS handler
>> for Int21.4C revealed that it does:
> Seriously, it is not the goal of FreeDOS to reverse-engineer MS DOS.

Seriously, it is (one of) the goal(s) of DOS-C. See below.

> If you want MS DOS, just get the files from your torrent. You might
> even be able to get the sources but both would be evil license-wise.

If I want to use MS-DOS I use my paid copy, which was included in my paid  
copies of Microsoft Windows (both 98 SE and NT 5.1, the later containing a  
modified MS-DOS in its NTVDM). I'm not aware of any available MS-DOS  
source code.

> Feel free to READ the return_user() source code of FreeDOS, it
> is open source. But please do NOT WRITE MS DOS code into FreeDOS!

What about looking at my fix before complaining? "Writing MS-DOS code into  
FreeDOS" (rather DOS-C) would be to move return_user to a assembly routine  
which would (partly) consist of disassembled code. Reading the MS-DOS code  
to see what it does isn't copying it. My description of steps taken by  
MS-DOS closely shows what code I found in the memory of my computer. You  
may call it a crime to show this description. My presented DOS-C fix  
however is not based on emulating this particular MS-DOS code, it only  
emulates the behaviour of the code, to generate the expected result.

> We implement 21.4c mostly in return_user,

Which is a good thing. Bad is that the "fix" for self-owning PSPs was  
added to the Int21.4C handler itself, not return_user where it belongs.

> it handles int 22, 23,
> 24 vectors, network process end, network closeall, close all files,
> parent stuff, indos, then you have to read exec_user which mostly
> disables A20 and returns to the caller. Parts depend on whether
> you go TSR or not :-).

As my fix (which is not copied from MS-DOS's code) shows, the parts that  
depend should also depend on whether the PSP is it's own parent. [FYI, I  
did read DOS-C's "case 0x4c:" and return_user() source code but not yet  

> Maybe 2a.82 is missing but maybe only in STABLE.
> Dunno about flushing buffers or virtual open or whatever.

Flushing buffers is a good idea I think. You have to do that sometimes,  
and the termination handler might execute because Abort was selected on  
Int24. "Virtual open" (couldn't find much about it inside RBIL except the  
flag in the SDA, which the disassembled code uses) seems to be an aborted  
SFT open operation that is reversed there.

> I do not think we should use code reversed from MS DOS sorry.

Your assumption that this code is the same as what MS-DOS contains is  
completely wrong. Microsoft won't be silly enough to write a DOS kernel in  
C anyway. That is, at least the disassembled code didn't contain any  
C-specific quirks, and it's said (f.e. in "Undocumented DOS") that the  
MS-DOS kernel is written in Assembly only.

If you want to avoid reverse-engineered information, then also stop  
reading the RBIL, at least the complete Int2F.12, Int2F.11 and  
Int21.52/Int21.5D06 (DOS internal data) descriptions. These are completely  
based on disassembling MS-DOS, as stated in "Undocumented DOS". Of course  
you won't stop using this information, because it is required (and was  
used) to create what DOS-C aims to be: a compatible replacement of MS-DOS.

> They checked the protocol (transferred data) not the binary.
> It is kind of more noble to just sniff network contents and
> keep the software as it is, a black box with closed source.

If you really think it's just "more noble", why are you that sensitive to  

> As DOS is no server, I think it is okay to look for example
> at data structures and how they change over time. This does
> leave the binary / machine code in nice black box land :-).

I hope you don't really believe that "looking how data structures change  
over time" is all the "Undocumented DOS" and RBIL guys did to write the  
current description of the List of Lists, the Buffer Information Record,  
the Extended Swappable Data Area (!), the System File Tables, the Drive  
Parameter Blocks, the Current Directory Structure, and all these other  
data structures. Read "Undocumented DOS" and get to know that they're all  
unethical criminals disassembling other people's software. [I could also  
cite a few paragraphs from my copy of the book if you don't own one, but I  
would probably take those that fit my point of view best.]

I would like to hear what other kernel developers think about this. Or, if  
Eric can't find any other active kernel developer, anyone else interested  
in DOS-C or the FreeDOS project too.


Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
Freedos-user mailing list

Reply via email to