Hi Christian, > 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.
True. It might be interesting to rewrite it in pure Assembly, for size. > Increases memory usage much. Already much better than some years ago: Just a few kB now. > - 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? Note that our SHARE does not implement int 21.5d02/03/04/05 yet. I wonder which apps actually use those functions, though. > hook which dispatches to different functions using the function number in > ax. The latter will of course be described within the release's > documentation.) I assume that means you introduce a whole new API and claim it is better just because you did not like the old one...? ;-) > - can't be removed once installed. I think this limitation isn't just in > SHARE but also in the kernel. It is also in every other version of SHARE that I know. Shrug... If I had to re-invent SHARE anyway, I would actually make it a PART of the kernel, lowering memory footprint. Of course you cannot unload it then either. You could still have some way to resize the data structures used, on the fly, after booting... > - 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. The int 2f.1000 install check works fine, thank you. Apps which respond to the check usually do so because they already support what SHARE does. I think Windows 3 implements the share stuff itself for DOS apps started from Windows? Of course you can and probably will invent a new API, the "yes the only good SHARE, the one from Christian, is loaded", but what will call it? ;-) > - 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. I do not get the point you are trying to make here. But maybe this means that our SHARE is not workgroups compatible yet? > - 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). I am not familiar enough with the intricate details of SHARE to comment on that. Suggest a patch if you want to... ;-) > - 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. Sounds like a tuning possibility - suggest a patch :-) > - 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. Basically you say "SHARE misbehaves if you use network drives and apps on different computers open the same file" after you already said that SHARE does not yet support network node addresses anyway. > - (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. As said above - I do not know enough about details to comment on this. > - 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. If by the kernel you mean the FreeDOS kernel - there are enough ways to get the version number. Most basic would be getting the normal DOS version number, possibly checking for "OEM is 0xfd and version is at least 3.something". You can also check for "true" number and even get FreeDOS specific version information if you want to be very picky. > I initially considered to use DOS-C's SHARE but dropped that idea > after my examination. And now you probably wrote something completely new, with a completely new API, which does what you think a SHARE should do instead of enabling DOS to do what other DOSes do when they have SHARE loaded ;-). Or maybe you will write something more compatible :-). In any case complaining about FreeDOS SHARE will of course not make it better. Neither will the complete redesign of the API unless there are very good reasons for it. Eric :-) ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
