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 exec_user.] > 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 disassembling? > 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. Regards, Christian ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
