> Given the number of hooks, some of which are not even documented, > I would say that the current implementation of SHARE is smoother.
I agree. > This "format of share exe hooks" table about MS SHARE lists: > > - a routine of unknown purpose, probably not called Since SHARE of MS-DOS 3.3+ is documented to set this pointer to an invalid value, calling it would crash the system. Conclusion: Yes, it's not called. > - something called on open and something called on close > > - routines called by DOS when int 21.5d02/03/04 are requested > (so share implements those close-all-matching things for dos) > > - routines to lock/unlock regions and check for locking > > - a get open file list access thing This is for Int21.5D05. (BTW, if you want to use another notation than Interrupt dot function, you don't have to use mine.) > - something possibly about updating FCB from SFT and knowing clusters Which shows that MS-DOS SHARE.EXE, at least minimally, knows about such low-level stuff as clusters. Bad. You forgot the function about checking an opened SFT against FCB. > - a routine to "close file if duplicate for process" Important to note that the file must have sharing mode 7 (111 binary): this is the special "Net FCB" mode only enabled during server calls. Since this mode is apparently only described (in RBIL) at Int21.3D (Open) and for this hook, I presume MS-DOS handles it like local FCBs when applying sharing rules (so the mode is matched like mode 0, COMPAT), and collapses multiple net FCBs opened for the same file from the same (net) process. Need to test what mode MS-DOS passes to the redirector when opening remote files with FCBs itself. > - something to close the most recently opened files? What is "the most recently opened file"? Possibly it means SHARE.EXE uses the SFT pointer in the SDA, which is called "pointer to current SFT" in RBIL (table at Int21.5D0B). > - a routine to update directory info from SFT entries (size, time) > > Most of those MS SHARE hooks use DOS SS and DS and manipulate > kernel data structures instead of having normal call parameters. What we are used to with the redirector calls. > Certainly not a nice API either, compared to FreeDOS SHARE > which uses custom extensions to the int 2f SHARE API for > open, close, check, lock and unlock. Note that I do think > it might be nice to support int 21.5d02/03/04, but you can > also put that bit into the kernel instead of into SHARE. Or you could add some more functions to the Int2F API. >> share exe as part of the kernel is of course a trade-off: it's natural >> for an OS, but for DOS you'd like the base kernel small and only >> include things that most people use (and most people don't need >> SHARE). > > Good question - what apart from Windows uses SHARE? Maybe MSCLIENT? Any software opening files at the same time, in theory. COMMAND.COM opens temporary files for pipes and I/O redirections that are left open for the child process(es), file sharing is useful to prevent the child(s) from deleting/writing these files (with other handles than that inherited from COMMAND.COM). MSCLIENT really requires it only when used as server. Any other DOS file server probably requires it as well, at least those allowing reading and writing of files. > I also wonder how big, roughly, a kernel built-in SHARE would be. See the other mail for that. Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
