Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Hi Ibid, 1470 builds and works fine (not much testing done though). cd \ works again Good... HDPMI (HX 2.15 dpmi server) loads. What was broken before? Regarding the patch I saw mentioned, here's the thread: http://sourceforge.net/mailarchive/forum.php?thread_name=482838EE.7020707%40freenet.deforum_name=freedos-user (second post, by Eric, claims Arkady wrote a patch) Eric, can you clarify? You wrote that you later read more of the thread and found out, but what did you find out? Can you give a summary? Otherwise we all have to read the whole old thread again. 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... Note that any DOS does not support real pipes at all as far as I remember. Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
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
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
- 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
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
- 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 ... I suppose there's no way to get the kernel's build number for SHARE then? ... 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. So let's say I provide some information now. ... 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). Thanks for clarifying this. If the discussion does become too off-topic, I would appreciate being CC'd in any off list emails. No Denglisch (German + English terms) technical mails between me and Eric anymore ;-) To summarize discussions (and add a few points) about FreeDOS share: ... - 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 The functions in question (Int21.5D subfunctions 02h..05h) interestingly aren't supported by Novell/DR-DOS too. The functions are: Close file by name, Close all files for given machine number [probably used by networking?), Close all files for given machine number PSP, Get open file list entry (provides ASCIZ filename of a specified SFT to applications, might be useful). - 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. As mentioned in the SHARE source code (at the Int2F handler code), the inline assembler hack used for interrupt processing should be replaced by an external object module if the code stays C (thus options [1] and [2]). Regarding the updating of SFTs opened for the same file (previous mail), is that already in the kernel? If not, I want to add that point to your list for SHARE. Regards, Christian -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
2009/7/5 Christian Masloch c...@bttr-software.de: Regarding the updating of SFTs opened for the same file (previous mail), is that already in the kernel? If not, I want to add that point to your list for SHARE. Yes, that has been in the kernel since the initial implementation by Ron Cemer. It used to work on fnodes but now updates the SFTs. These routines (mainly merge_file_changes() in fatfs.c) could be moved to share.c if the hooks from RBIL table 01636 were implemented. 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). Bart -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
