> Hello all, > It is true that no DOS provides pipes. HX makes up for this by creating > a > new file and opening 2 instances (1 read only)--per the HX docs that I > looked at on Sunday.
This is very similar to what COMMAND.COM (/FreeCOM/4DOS/RxCMD) does for I/O redirection and pipes between commands ( |, <, > on the command line). > If SHARE is not loaded, this ostensibly "may not > work as expected." Yes, because the file might be written by other processes than the one that got to write the pipe, or it might be deleted by a process. The former causes unexpected input for the reading process, the latter might cause filesystem corruption and/or data loss. > Christian: > Is your file sharer ready yet (able to load & reliably share files)? No. Most code of the actual hook handling is done, but it doesn't load yet and some of the code to call it from DOS is not yet integrated in the kernel. The former will be fixed by migrating the TSR installation/command line parsing/configuration from another TSR I wrote some time ago. > Does it work under FreeDOS, or RxDOS only? Currently I'm only working on RxDOS, so it doesn't work on DOS-C (FreeDOS kernel). Since the hook method uses a far call with a number of parameters in registers, some complicated interfacing will be required if it's to be used with DOS-C's C source code. Another problem is that the file sharer installation code currently requires RxDOS. It checks whether the running DOS is RxDOS (7.30+, so my new version only) by issuing Int21.335E - a newly defined call that returns a special value in ax to tell that a DOS version supporting this call is present. RxDOS returns "Rx", along with some version information in the other registers (dx, cx, bx, si, di). If that check succeeds, the new RxDOS internal list of pointers is retrieved using Int21.335F. The version number at the beginning is checked, the pointer to the list of hooks is retrieved and the version number at the beginning of the hook list is checked as well. Also, to set the "file sharing installed" flag in the SDA, the file sharer calls the original Int21 entry (found in the list of pointers too) to get the address of the SDA. DOS-C needs at least a reliable installation check with build number, and a new function to return the address of the file sharing hook if it was to support the RxDOS file sharer. Instead of changing DOS-C to use my file sharer, the current FreeDOS SHARE could be adapted to handle things correctly. The API would at least require an update, however. If Jeremy is looking into SHARE right now, you won't have to use my code. > It seems to me that use of assembly is better than C _under certain > conditions_: > If the active developers prefer to write assembly > If C is unclear/unportable > If an assembly program is ready > If a C version is deemed stable and unlikely to change, a translation is > fit If the code is to stay in memory If developers tend to care more about source compatibility to different compilers than actual source content ;-) If the assembler is "more free" :-P (recent NASM versions are 2-clause BSD) Regards, Christian ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
