Hi Christian, >>> 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...
> I suppose there's no way to get the kernel's build number for SHARE then? The revision number (eg 38 for 2038) is returned in BL if you call int 21.30, which also returns OEM ID 0xfd for FreeDOS :-). > 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). This is an old missing feature - while I know no software that uses it, I agree that it would be potentially useful, both the get open file list entry and the close-some ones. >> - 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. I am not sure how big 3. would be but the main RAM usage is in data tables... It might be interesting to put those into HMA when SHARE would become a part of the kernel. I also do think that 4. might be a nice idea :-). > 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]). True... Eric ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
