>> - 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.) > Note that our SHARE does not implement int 21.5d02/03/04/05 yet. > I wonder which apps actually use those functions, though. I don't know. I'll support these, however. (Still didn't write them, but planned.) >> - 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... Yes, great. Since Microsoft made it bad, let's make it bad too, especially when doing it another way but still as bad (without compatibility reasons). > If I had to re-invent SHARE anyway, I would actually make it a > PART of the kernel, lowering memory footprint. That's what Udo said too. I prefer a TSR-type solution (without hooking interrupts) however, since some obscure things might better work with file sharing disabled. If you want the option to disable it, why not free the memory used by the code then? > 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... Not as difficult when using a dynamic heap structure for all data ;-) >> - 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? It does not. > 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? ;-) You didn't forget yet that I'm working on a kernel? So my "yes the only good kernel the one from Christian" as you say ;-) will call it. I designed my only-good API so that it would be usable easily by both the one calling it (the kernel) as well as the one providing it (the file sharer, or a dummy handler which always returns error 0001h - invalid function). >> - 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? Yes. SHARE is neither DOS network compatible (if the FreeDOS machine acts as server) nor Win3.x DOS box compatible (disregarding whether there's any network). > I am not familiar enough with the intricate details of SHARE > to comment on that. Suggest a patch if you want to... ;-) > > [...] > > Sounds like [...] > > [...] > > As said above - I do not know enough about details to comment on this. Anyone there familiar enough with it? Any kernel developer to work on file access? And please don't say you know the kernel part of file access but not SHARE. Aren't they developed together? > 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. Yes, that's what I said. >> - 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 I thought that's implied by the list :-) > there are enough ways > to get the version number. Most basic would be getting the normal DOS > version number, Most unreliable since SETVER and similar programs as VERSION=, ANYDOS, CALLVER. > 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 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? >> 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 :-). I do my best. > In any case complaining > about FreeDOS SHARE will of course not make it better. I don't see where not complaining about FreeDOS SHARE makes it better either, so I decided to complain. > I assume that means you introduce a whole new API and claim it > is better just because you did not like the old one...? ;-) > > [...] > > Neither will the > complete redesign of the API unless there are very good reasons for it. There are. My API is better because (A) it works more like MS-DOS's SHARE.EXE (than FreeDOS's SHARE) in regards to file sharing behaviour, (B) it allows to monitor/prevent file system access transparently (of course only with software that knows this new API), by adding a few new functions not used/required by the file sharer, (C) it can be removed from memory disregarding whether IISP-incompatible TSRs hooked Int21 or Int2F, (D) it allows for extensions/changes such as these required for 64-bit file size support, and (E) I didn't like the old one. 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. 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 ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
