Page 1 of 1

Bug or line flushing protocol changes from FEu0 to FEu2 [SOLVED]

Posted: Wed Feb 12, 2025 8:32 pm
by gdridi
Hello!

Con-handler is not taking into account multiline in FEu2 or FEa1222, like "abc\ndef" as one string received instead of two strings "abc\n" and "def", with previous venerable FEu0

Code: Select all

int main() {
  int c;
  while( (c = getchar()) != EOF ) putchar(c);
  return 0;
}
TESTING THIS UNDER FE2 unleashed NL at end??
Image
It seems a bug or a protocol changes for output since FE update 2 (SAM440)

My program works well with FE update 1 (and u0!)
AmigaOS4.1FEu0
Con-handler 53.72 (3.10.2014)
Console.device 53.83 (1.10.2014)
And
Console.device 53.99 (05/05/2016)
Exec.library 53.89 (11/28/2016)
GOOD INTERLEAVING OF ACTION_READ/ACTION_WRITE FEu0
Image

BUT,

Not with FE update 2
Console.device 53.105 (01/25/2017)
Exec.library 54.30 (01/01/2021)

Not with A1222
AmigaOS4.1FEu2(A1222)
Con-handler 53.82 (11.02.2018)
Console.device 53.120 (14.12.2023)
No interleaving : two consecutive READ/two consecutive WRITE
Image

Wow
Tonyw tells me here if your con-handler handles correctly this piece of code or it displays more NewLine control characters at the end when CTRL_\? is entered after two lines of text.

Please help ? Why two consecutive READ with FEu2 and well interleaved ACTION_READ/ACTION_WRITE with venerable FEu0
DGILLES - os4depot.net

Re: Bug or line flushing protocol changes from FEu0 to FEu2

Posted: Sat Feb 15, 2025 11:21 pm
by colinw
Sorry, I have nothing to add via your PM.

The console-handler uses DOS Packets to communicate with DOS,
but you are not doing that in the example shown directly,
instead, the example is using getchar() and putchar() from clib.

Please remove all and any other extraneous layers between
you and the packet call and isolate where the issue actually is first.

The OS calls are all I handle, also Tony Wyatt is the console-handler
man, he wrote it and will understand any behaviour issues.

Re: Bug or line flushing protocol changes from FEu0 to FEu2

Posted: Sun Feb 16, 2025 4:22 pm
by gdridi
Hello!

When I used this code:

Code: Select all

int main() {
  int c;
  while( (c = getchar()) != EOF ) putchar(c);
  return 0;
}
In interactive mode, with this code,
Under A1222+
I enter 3 lines but each line is not output as soon as I type Return [key].

Say :
abc<Return>
def<Return>
ghi<Return><Ctrl-\>
Outputs :
abc
def
ghi

And internally it’s a multiline: "abc\ndef\ghi\n"

But when I used a regular input/output interleaved like SDK:Local/C/cat, it intermingled well lines.
Outputs them as soon as I type <Return>
Say :
abc<Return>
abc
def<Return>
def
ghi<Return>
ghi
<Ctrl-\>

and there’s no more a multiline to treat but 3 simple lines. That’s Good!

I test this with my Arabic console [os4depot.net].

So it’s a line discipline problem(that is to "flush" make an ACTION_WRITE each time a NewLine char is encountered).

But I don’t know if the responsibility of my handler.
Or something going wrong with clib and kernel code handling getchar/putchar macros as the code at the beginning shows it.

Merely your Amigan

DGILLES - author of Arabic console -

Re: Bug or line flushing protocol changes from FEu0 to FEu2

Posted: Tue Feb 18, 2025 12:35 am
by salass00
In newlib the buffering mode for stdout will default to line buffered (i.e. buffer is flushed implicitly if full or when a newline character is written) if the stdout file handle is a terminal. To see if stdout is a terminal it checks with IsInteractive(fh) and then ObtainConsoleDataTags(OCD_FileHandleInput, fh, TAG_END). If stdout is not a terminal the buffer is only flushed when full or on explicit fflush().

You can also change the flushing mode to line buffered manually by using the setlinebuf() or setvbuf() functions.

Re: Bug or line flushing protocol changes from FEu0 to FEu2

Posted: Tue Feb 18, 2025 4:06 pm
by gdridi
salass00 wrote: Tue Feb 18, 2025 12:35 am In newlib the buffering mode for stdout will default to line buffered (i.e. buffer is flushed implicitly if full or when a newline character is written) if the stdout file handle is a terminal.
salass00 wrote: Tue Feb 18, 2025 12:35 am To see if stdout is a terminal it checks with IsInteractive(fh) and then ObtainConsoleDataTags(OCD_FileHandleInput, fh, TAG_END). If stdout is not a terminal the buffer is only flushed when full or on explicit fflush().
For recognition of a terminal ; I use SDK v53
Seems IsInteractive(fh) is ok but the problem might be:
ObtainConsoleDataTags() which is not present in FinalEdition update 0(no update) SDK.
Can’t see how to bypass this function call. Any idea ?
To recompile my arabcon-handler under FE2? But this is no backward compatibility. . .
Ideas welcome
You can also change the flushing mode to line buffered manually by using the setlinebuf() or setvbuf() functions.
Can’t use setlinebuf() or setvbuf() because I compile with -no-startup-code and INewlib shared pointer is not present.

Thank you so much, nevertheless

Can someone explained me the fields in:

struct ConsoleWindowData {. . .}

So I can implement ACTION_OBTAIN_CON_INFO

I apologize with this DOS packet, we have backward compatibility (i.e not the ObtainConsoleDataTags() if it was solely a function. . .)

Best regards to Tonyw and ColinW too.

I credit for the work.

DGILLES

Re: Bug or line flushing protocol changes from FEu0 to FEu2

Posted: Tue Feb 18, 2025 10:27 pm
by salass00
If you have the latest V54.16 SDK from:
https://hyperion-entertainment.com/inde ... &parent=30

you should be able to find the struct ConsoleWindowData definition in "SDK:include/include_h/dos/dosextens.h" and documentation on the ACTION_OBTAIN_CON_INFO/ACTION_RELEASE_CON_INFO packets in "SDK:Documentation/AutoDocs/dos.dospackets.doc".