[fpc-pascal] Writeln() behaves differently on Windows and Linux, why?
Tomas Hajny
XHajT03 at hajny.biz
Fri Jul 10 11:25:47 CEST 2020
On 2020-07-10 07:45, Bo Berglund via fpc-pascal wrote:
> On Fri, 10 Jul 2020 01:26:24 +0200, Tomas Hajny
> <XHajT03 at hajny.biz> wrote:
>
>
> Well I do not believe the problem I am seeing is because of thread
> safe or not.
> This test server is just running the main thread (the program itself)
> where the detection of keyboard entry q is in a loop to make it
> possible to end execution in a controlled way.
> Nothing is output to the console from this loop when the server is
> running, only after it is commanded to shut down following detection
> of q.
> Additionally the TIdTCPServer is created and started prior to getting
> to the loop. This is for sure multi-threaded but by itself does not
> interact with the console.
If you want others to check the real reason, you should provide your
compilable source so that others may try to reproduce and analyze the
problem. Obviously, there may be other issues as well like particular
setting of your terminal, etc.
.
.
> Instead I think that this what you mention here is the real culprit.
> So Crt changes the way the console displays data on the screen as you
> describe and this screen position access is probably what I see as the
> messages from inside the server being output without the CR only using
> LF when executing the Writeln() command.
That could be, but please note that Crt.WriteLn has been used many times
without issues by others, so if it doesn't work correctly in your case,
it is probably related either to other parts of your program, or to
particular settings and/or features of your terminal.
> I posted here because I thought I had discovered a bug or that I had
> somehow mis-interpreted the way Writeln() works and could get an
> immediate advice concerning the cause of the problem.
>
> It is not that important since this is just a test program evaluating
> the TCP server class I am building.
> It would just be more convenient to stop the application using a
> single keypress than two, but ths only happens while I am testing.
>
> So by removing the loop, I can just hit Enter and it shuts down:
.
.
> Here I use the blocking Read(ch) instead and now Enter makes the code
> move on to the termination phase.
> It will not be used at all in the production program...
Fine. I provided an alternative solution for checking a single keypress
without using unit Crt, but it's obviously up to you whether you want or
need to use it. BTW, both Crt.ReadKey and Keyboard.GetKeyEvent are
blocking as well, but both Crt and Keyboard provide ways for
non-blocking access as well (Crt.KeyPressed and Keyboard.PollKeyEvent).
> But I really asked about the *difference* between Windows and Linux
> behaviour because on Windows the original code works fine without any
> screen mess.
The difference comes from different features and behaviour of console in
Windows and Linux (especially from the lack of API access to more
advanced features of the console - which, to be fair, is mostly due to
the need to provide universal remote access to the console / terminal in
the Unix world, which is not supported in the Windows world).
Tomas
More information about the fpc-pascal
mailing list