>> I guess SHARE might be something to test w/ HX. >> Japheth's documentation claims that SHARE is needed for pipes, Cygwin >> requires pipes, and FD SHARE is too "crippled" to work. > > If Japheth knows about a bug, he should explain what EXACTLY > is wrong so somebody has a chance to fix it...
I don't know what Japheth has to complain about it, but I know that DOS-C's SHARE: - is a C program that stays in memory without usage of any assembler code. Increases memory usage much. - 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 hook which dispatches to different functions using the function number in ax. The latter will of course be described within the release's documentation.) - can't be removed once installed. I think this limitation isn't just in SHARE but also in the kernel. - doesn't provide a dedicated installation check. The original MS-DOS SHARE.EXE installation check Int2F.1000 is most unreliable. For example, Win3.x reports that SHARE.EXE is installed disregarding whether it actually is, as do a number of TSRs designed to fake file sharing support. - doesn't use the (under Win3.x virtual, else network) machine number at all. Since SHARE also works without access to SFTs, the sharing records require a new field to support the machine number. - was written by people that probably understood "first sharing mode" and "first access mode" wrong. There is no single "first" mode. The "first" mode fields in the sharing record are unnecessary. The allowed mode table must be applied between the mode of EACH existing open and that of the new open for the same file. I think the problem doesn't just ignore subsequent more restrictive opens of a file (allowing too much for new opens), but could also carry on restrictions of one open after it was already closed (disallowing too much for new opens). - uses a complicated allowed mode (and exception) table that can be simplified, since entries that create critical errors (value 2 in the table) are simply all entries disallowing the new open (otherwise value 1 in the table) where the new open is in compatibility mode. - allows opening the same file two times in compatibility mode always, but it should only be allowed if the (virtual/network) machine number of the opening process matches. (This isn't documented in RBIL, the tests were apparently done without usage of Win3.x or the "Server Call" Int21.5D00.) Since SHARE doesn't know about machine numbers anyway, this can't be done. - (according to the commentary) returns sharing record numbers of 0..32767 (positive 16-bit values) to indicate success on opening the file. The kernel should increase such a returned value before using it as sharing record number in the SFT. Value 0 indicates the file isn't handled by file sharing in MS-DOS. - doesn't check whether it runs on the correct DOS version. It doesn't even check whether it runs on its kernel at all. Even if it would, since the kernel provides no way to get its version number, it couldn't check for that anyway. I initially considered to use DOS-C's SHARE but dropped that idea after my examination. Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
