#134 FNP fnp_rtx_input_accepted fails to do due virtual address translation on buffer address

[Charles Anthony]

FNP fnp_rtx_input_accepted fails to do due virtual address translation on buffer address. This causes the input data to be written to the wrong memory location, causing havoc. This bug has gone undetected due to MCS specifing small buffer sizes on dialup lines, causing the FNP to use input_in_mailbox instead of accept_input.

[Eric Swenson]

Are there other places where MCS uses these non-IOM DCWs that might also provoke other bugs in the FNP emulator -- or was the accept_input the only place where these are used?

[Charles Anthony]

On Fri, Dec 22, 2017 at 5:35 PM, Eric Swenson eswenson1@users.sf.net
wrote:

Are there other places where MCS uses these non-IOM DCWs that might also
provoke other bugs in the FNP emulator -- or was the accept_input the only
place where these are used?

It is the only place in the FNP emulation where they are used; however the
FNP emulation is incomplete -- it has been use-driven: Run Multics, MCS
says 'do this', the FNP emulation reports "unimplemented", and some goes in
and implements it.

When the 3270 code was turned on, several new calls were were made to the
FNP and had to be implemented. As more and more subsystems are used more
support will be needed, hopefully in a downward trend. X.25 and HDLC
support is lacking, polite mode is ignored, echo negotiation is ignored,
discard output is ignored, VIP terminal multiplexer support is missing UNCP
support is missing, DN6661 and DN6670 support - those are off the top of my
head. Due to the poor documentation, many surprises lie ahead.

The MCS code is too large, complex and poorly documented to try to forward
engineer the missing bits.

There is however, the start of a DN355 instruction level simulator which
should be able to run the map355 core files directly (when finished).

-- Charles

[Charles Anthony]

Fixed in 145e2d4