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