Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Hi Bart, 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. Given the number of hooks, some of which are not even documented, I would say that the current implementation of SHARE is smoother. This format of share exe hooks table about MS SHARE lists: - a routine of unknown purpose, probably 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 - something possibly about updating FCB from SFT and knowing clusters - a routine to close file if duplicate for process - something to close the most recently opened files? - 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. 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. 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? I also wonder how big, roughly, a kernel built-in SHARE would be. 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
Hi Christian, 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... I suppose there's no way to get the kernel's build number for SHARE then? The revision number (eg 38 for 2038) is returned in BL if you call int 21.30, which also returns OEM ID 0xfd for FreeDOS :-). 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). This is an old missing feature - while I know no software that uses it, I agree that it would be potentially useful, both the get open file list entry and the close-some ones. - 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. I am not sure how big 3. would be but the main RAM usage is in data tables... It might be interesting to put those into HMA when SHARE would become a part of the kernel. I also do think that 4. might be a nice idea :-). 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]). True... 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
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
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer e.a...@jpberlin.de: Hi Christian, 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... I suppose there's no way to get the kernel's build number for SHARE then? The revision number (eg 38 for 2038) is returned in BL if you call int 21.30, which also returns OEM ID 0xfd for FreeDOS :-). Okay, but I won't depend on that. Some SETVER TSRs completely take over Int21.30 (and Int21.3306), or only pass some of the values from the DOS kernel. - 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. I am not sure how big 3. would be The code usage would be smaller. Think how both the kernel and file sharing code could omit the interfacing and function number/dispatching code. Also, all code part of the main kernel code would be relocated to UMA or HMA too. but the main RAM usage is in data tables... It might be interesting to put those into HMA when SHARE would become a part of the kernel. What exactly prevents a modular (i.e. not part of the kernel) SHARE from putting data elsewhere? I also do think that 4. might be a nice idea :-). I presume you don't want to use the (free) NASM source of my RxDOS file sharer ;-P 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
Please explain in what way Win 3 uses virtual(?) machine numbers and why supporting them is needed to get a Win compatible SHARE. MS-DOS usually sets the net machine number (offset 1Eh of SDA, table at Int21.5D0B) to zero (indicating local) inside its Int21 dispatcher, unless the server call (Int21.5D00) is used with another value but zero in the DPL's machine field. The machine number is used when opening files to put it into the SFT machine field. It's also checked against the SFT field when accessing an opened SFT (error 0006h, Invalid handle is returned if they don't match). Windows jumps in by enabling it's virtual machine number handling per DOS patches (there's also a bit for that in the Patch DOS request from DOSMGR, Int2F.1607 with bx 0015h). The machine number in the SDA is set to the virtual machine number (probably same as returned by Int2F.1683) by Windows itself, and MS-DOS doesn't modify the value when Windows is present. This means it doesn't (A) clear the value to zero inside the Int21 dispatcher and (B) doesn't use the machine field of the DPL passed to Int21.5D00. I don't know how exactly the latter affects DOS servers. Despite forcing the machine number to the VM ID, the patch also disables checking whether the machine number of the SFTs match. A wild guess: This is to enable local handles left open from before Windows started (value zero as machine) being accessed by the owning programs from inside VMs (non-zero machine number). I also wonder what enumerates machines and how in a real network. MS probable does not use anything fancy like checksum of IP/name? With the DOS file server support, this is determined by the server/network software. (MS-)DOS only uses the word value provided inside the server call's (Int21.5D00) DPL. Regarding the new API thing: More like MS is not the same as exactly like MS, I aim to leave the main differences in the internal API. The external API (and file sharing behaviour) should be the same. and as you already said, if MS designed some weird thing then it is not necessarily good to clone that. As the MS style hooks manipulate kernel internal data, they do not make adding 64 bit support any smoother than our current API. I DID NOT copy the MS-DOS hooks. My (single) file sharing hook doesn't depend on SS or DS pointing to DOSDATA and uses call parameters instead. All passed pointers are far, so they can point the file sharer into DOSDATA or anywhere else. Here's a draft of the API's short description (not anything coded yet): === RxDOS file sharing hook functions: h RxDOS file sharer installation check [currently not called by the kernel] 0001h Open file (es:di- SFT, ds:si- filename) 0002h Change access mode (es:di- SFT, bx = new mode) 0003h Close file (es:di- SFT) [kernel assumes this always succeeds] 0004h Read from file (es:di- SFT, ds:si- region structure, dx = PSP) 0005h Write to file (es:di- SFT, ds:si- region structure, dx = PSP) [size of zero indicates to truncate file] 0006h Lock file (es:di- SFT, ds:si- region structure, dx = PSP) 0007h Unlock file (es:di- SFT, ds:si- region structure, dx = PSP) 0008h Create new file or directory (ds:si- filename, dx = PSP, cx = machine) [always allowed by current file sharer, still calls function 0001h to open] 0009h Delete file or directory (ds:si- filename, dx = PSP, cx = machine) [directory must be empty. allowed by file sharer unless file open] 000Ah Update file's metadata with filename (ds:si- filename, dx = PSP, cx = machine, bx = flags which metadata is updated, es:di- metadata update callback structure) [renaming of directories containing opened files disallowed by file sharer, since the path would change] 000Bh Update file's metadata with SFT (es:di- SFT, dx = PSP, cx = machine, bx = flags which metadata is updated, ds:si- metadata update callback structure) 1000h Int2F.1000 hook (ss:bp- stack frame with bp, ip, cs, flags) 10xxh Int2F.10 hook (ss:bp- stack frame with bp, ip, cs, flags) 5Dxxh Int21.5D hook (ds:si- stack frame (ax..flags), es:di- DPL) [kernel only calls this for appropriate subfunctions] === Adding 64-bit file size support here is as easy as declaring that the file region structure contains 64-bit values (always, even if FAT+ and 64-bit file size support isn't compiled into the kernel). If it was defined otherwise initially, the compatible version (version number checked for API compatibility) of the kernel would be increased so older file sharer versions would refuse to run on the new kernel. 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 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
[Freedos-kernel] Past bugs and CONFIG dot SYS
Hello all, 1470 builds and works fine (not much testing done though). cd \ works again (resources handled correctly) from Christian's test program. HDPMI (HX 2.15 dpmi server) loads. 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? 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. Right now, I'm dual-booting ktc8616 (2039-svn, r1470) and ktc18632 (same trunk source) on an Aspire One. Thank you, Ibidem -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
