On Sun, Jul 5, 2009 at 8:09 AM, Christian Masloch<c...@bttr-software.de> wrote: >>> - uses an interface on Int2F which probably isn't as good as an internal >>> hook. (MS-DOS uses a number of hooks partly documented in RBIL, I use >>> one >> >> You mean table 01636, format of share exe hooks? > > It doesn't matter, but probably yes. (I don't know the number, but it's > inside the Int21.52 "Get List of Lists" description.) .. >>> - 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 - it has and will change to ensure that end users can easily provide useful version information when reporting usage information (be it bugs or works properly information). ... > 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. ... > 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). If the discussion does become too off-topic, I would appreciate being CC'd in any off list emails. > > > I forgot to complain about one thing of FreeDOS SHARE in my list: Unless > the kernel does it itself (even without SHARE), multiple open SFTs aren't > updated when file information (such as file size and first cluster) is > changed by one process accessing the file. > > Regards, > Christian > To summarize discussions (and add a few points) about FreeDOS share: - specific to FreeDOS kernel (ie do not use with other DOS versions, may not work with earlier/later kernels than one distributed with) - kernel specific is fine, not checking is bad - does not do any sort of version checking (ie attempting to run with the wrong kernel will cause undefined results) - see previous point - 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 - 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. - size (in memory usage) is an important factor as much as compatibility - does not currently handle networked/windows multiple VM issues - may be possible to simplify the logic and thus improve it I have just started looking into share, as I need to have it building with OW so I can add to the builds on my kernel page. I lean heavily to integrating the support into the kernel, with a CONFIG.SYS and runtime option to enable/disable - if it can be done in a manner that does not increase the kernel's size (on disk and RAM usage) unreasonably; however initially my focus will be on making the current version compilable with OW. Comments are welcome, especially pointers to applications that make [known] use share's functionality for testing purposes. Thank you, Jeremy ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
