>>>> - doesn't check whether it runs on the correct DOS version. It doesn't > .. >> I know about the OEM ID and the DOS-C release string which can be >> retrieved by Int21.33FF. I don't see how SHARE could use that to >> differentiate kernel releases. Does the string have a fixed format >> specified anywhere? Is there any other call to get specific information? > > No; the string has no fixed format ...
I suppose there's no way to get the kernel's build number for SHARE then? > ... >> I don't see where not complaining about FreeDOS SHARE makes it better >> either, so I decided to complain. > ... > > complaining never accomplishes anything except perhaps making one feel > better - however, information about deficiencies in current > implementations is encouraged, and perhaps the only way they will ever > improve. So let's say I provide some information now. > ... >> If you're interested in more information about my development (as >> opposed >> to FreeDOS SHARE complaints), tell me. We could proceed here if another >> DOS kernel's software isn't too much off-topic on the Freedos-kernel >> list >> ;-) or move to private e-mails. > > as long as the discussion is relevant to kernel compatibility, > discussing on this list is fine (it is a pretty low volume list and I > think those here either are watching out to ensure the FD kernel > doesn't diverge into an incompatible mess or find the inner workings > of DOS/OSes interesting). Thanks for clarifying this. > If the discussion does become too > off-topic, I would appreciate being CC'd in any off list emails. No "Denglisch" (German + English terms) technical mails between me and Eric anymore ;-) > To summarize discussions (and add a few points) about FreeDOS share: > ... > - does not fully implement the API as implemented by MS share (no > specific applications known to require them mentioned / useful for > testing?) - need to research further The functions in question (Int21.5D subfunctions 02h..05h) interestingly aren't supported by Novell/DR-DOS too. The functions are: Close file by name, Close all files for given machine number [probably used by networking?), Close all files for given machine number & PSP, Get open file list entry (provides ASCIZ filename of a specified SFT to applications, might be useful). > - is currently tied to Borland Turbo C compilers - options are to [1] > update to be more compiler neutral C, [2] convert to OW compatible > only, [3] merge into kernel so not a standalone app any more, [4] > rewrite in assembler, or [5] something I missed. As mentioned in the SHARE source code (at the Int2F handler code), the inline assembler hack used for interrupt processing should be replaced by an external object module if the code stays C (thus options [1] and [2]). Regarding the updating of SFTs opened for the same file (previous mail), is that already in the kernel? If not, I want to add that point to your list for SHARE. Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
