MB> The 64 KB problem permeates the file system interface, and pipes go
 MB> through the FS router.  Everything in the whole FS
 MB> chain has to observe the 64 KB limit in case the data
 MB> block is eventually mapped down into a physical DMA
 MB> operation.  There is no appropriate method by which
 MB> the IFS, for example, can know whether the controller
 MB> operating its disk will have a 64 KB DMA limit, nor
 MB> even whether DMA will be used at all.

 MB> I do agree that the pipes subsystem should not fail as
 MB> it does in the presense of greater than 64 KB
 MB> transfers, but I suspect that it would be hard to fix.

If the only problem was that it couldn't handle transfers larger than 64KB,
that would not be so bad.  The problem is worse, however,because any
DosRead() or DosWrite() call on a named pipe using a buffer that crosses a
64KB boundary (but is not larger than 64KB) will fail.

Lifting the 64KB message size limit is not trivially easy given that named
pipes are supported on multiple platforms (not just OS/2) and the pipes can
transport data across networks.  Perhaps a new \PIPE32 prefix could be
added for pipes that can handle 32-bit message sizes and the existing \PIPE
prefix could be left for pipes that can only handle 16-bit message sizes?


--- Maximus/2 2.02