Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer <e.a...@jpberlin.de>: > > 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 :-).
Okay, but I won't depend on that. Some SETVER TSRs completely take over Int21.30 (and Int21.3306), or only pass some of the values from the DOS kernel. >>> - 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 The code usage would be smaller. Think how both the kernel and file sharing code could omit the interfacing and function number/dispatching code. Also, all code part of the main kernel code would be relocated to UMA or HMA too. > 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. What exactly prevents a modular (i.e. not part of the kernel) SHARE from putting data elsewhere? > I also do > think that 4. might be a nice idea :-). I presume you don't want to use the (free) NASM source of my RxDOS file sharer ;-P Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
