From Newsgroup: alt.bbs.pcboard

My tcp fossil was working well with the Novell Client32 TCP/IP stack. So
then I tried the older 16-bit TCP/IP stack with the VLM client.

It dropped characters badly, but I doubted Novell was at fault. So I
started debugging, and discovered that the 16-bit stack is more likely
to do partial block writes. And it became obvious, without even looking
at PCBoard source code, that PCBoard fails to check for partial block
writes, or retry as needed.

The fossil write block function (19h) returns a value in register AX
telling how many characters of a block were written. The application
should check AX, and retry as needed. But PCBoard blindly assumes that
the block size requested in register CX always succeeds, thus ignoring
and dropping any data that remains.

I can work around the problem by modifying my fossil driver to do the
retries internally, releasing a timeslice before every retry. Another
PCBoard mystery solved ...


--- Synchronet 3.17a-Linux NewsLink 1.108

From Newsgroup: alt.bbs.pcboard

On Monday, December 1, 2014 12:36:38 AM UTC-8, Trifle Menot wrote:

My tcp fossil was working well with the Novell Client32 TCP/IP stack. So
then I tried the older 16-bit TCP/IP stack with the VLM client.

It dropped characters badly, but I doubted Novell was at fault. So I
started debugging, and discovered that the 16-bit stack is more likely
to do partial block writes. And it became obvious, without even looking
at PCBoard source code, that PCBoard fails to check for partial block
writes, or retry as needed.

The fossil write block function (19h) returns a value in register AX
telling how many characters of a block were written. The application
should check AX, and retry as needed. But PCBoard blindly assumes that
the block size requested in register CX always succeeds, thus ignoring
and dropping any data that remains.

I can work around the problem by modifying my fossil driver to do the
retries internally, releasing a timeslice before every retry. Another PCBoard mystery solved ...

yeah, it was written to work only in dos.
I wonder how it would work in msdos 7.1 thou

--- Synchronet 3.17a-Linux NewsLink 1.108

From Newsgroup: alt.bbs.pcboard

On Mon, 1 Dec 2014 06:51:38 -0800 (PST), corey blake
<ainewslv@gmail.com> wrote:

yeah, it was written to work only in dos.
I wonder how it would work in msdos 7.1 thou

The PCBoard "who" command does not work on dos 7.1. So it's not 100% compatible with dos 6.22.

If you can find the compatibility bugs in the PCBoard source code, dos
7.1 may work. But I don't need a large filesystem on the client, I can
use a Netware server.

A multitasker (like Windows) can handle 3 or 4 nodes, but beyond that, performance suffers. For more nodes, you need multiple clients and a
central server for shared files. Netware is the best solution, others
can't match its speed.

So for me, DOS 6.22 filesystem size does not matter.


--- Synchronet 3.17a-Linux NewsLink 1.108