1. Forum
  2. Newsgroups
  3. alt.bbs.pcboard

  • PCBoard fossil bug

    From Trifle Menot@triflemenot@protocol.invalid to alt.bbs.pcboard on Mon Dec 1 08:36:38 2014
    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 corey blake@ainewslv@gmail.com to alt.bbs.pcboard on Mon Dec 1 06:51:38 2014
    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 Trifle Menot@triflemenot@protocol.invalid to alt.bbs.pcboard on Mon Dec 1 18:21:14 2014
    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