Pascal version of the UCI Filter program

[Roland57]

Then don't be surprised if the output isn't as expected. The c-code seems to follow the convention, the translation doesn't.

OK, I will take a closer look.

[Roland57]

@TRon

It is better now. I have three lines, as with the C program. (Previously I had only one.) So, you were right.

But there are still unwanted characters. Maybe I did something wrong.

I attach the latest version of ucifilter.pas.

[Fred vS]

Hello Roland!
I try your project here on Linux via wine (dont have a Win machine disposable at the moment).

Running this:

Code: Pascal  [Select][+][-]

1. ~$ wine CT800_V1.34_x32.exe

gives that:

CT800 V1.34 32 bit UCI version
2016-2019 by Rasmus Althoff
Free software under GPLv3+

And running that:

Code: Pascal  [Select][+][-]

1. ~$ wine ucifilter.exe CT800_V1.34_x32.exe

gives this:

$_CT800 V1.34 32 î$_'D_2016-2019 by Raî$_a_Free software uî$_

So yes there is a problem.
I would try to do it isolating the thing: create a simple test prog that only runs CT800_V1.34_x32.exe via a TProcess + pipe output, taking inspiration from the wiki example:
https://wiki.lazarus.freepascal.org/Executing_External_Programs#TProcess

And maybe, do a try with TProcessUTF8 (I think it is possible to use it for console app)

TProcessUTF8 is part of Lazarus (introduced in the development version which will end up as Lazarus 1.4 in future) in the UTF8Process unit; it can be used from command-line programs by setting a requirement to LCLBase

[EDIT] With your last change there is indeed 3 lines:

╕_CT800 V1.34 32 î╕_'╫_
2016-2019 by Rî╕_⌠_
Free software î╕_

[TRon]

It is better now. I have three lines, as with the C program. (Previously I had only one.) So, you were right.

Thank you for reporting back and that is at least some progress 

But there are still unwanted characters. Maybe I did something wrong.

Don't forget options writings when command "uciok" is received.

There might be other subtle differences but then I would have to take a closer look (which might take some time, that is if I'm even able to detect it at all)

[Roland57]

I would try to do it isolating the thing: create a simple test prog that only runs CT800_V1.34_x32.exe via a TProcess + pipe output, taking inspiration from the wiki example:
https://wiki.lazarus.freepascal.org/Executing_External_Programs#TProcess

Hello Fred! Thank you for testing.

Yes, I could use TProcess. I know that it will work, because I already did it. But my project here is to translate the C program, as it is (using Windows API).

But, following you idea, maybe I could add more details in log files, to see where things go wrong. For now the log files of the C program and of the Pascal program have no differences.

I would have hoped that someone would see immediately which error I made.

Don't forget options writings when command "uciok" is received.

OK, I will review the whole thing tomorrow.

[Fred vS]

Hello Roland.

I did try too with CreateProcessW()  (with the "W" at end for widestring) but same result.
Indeed in your project eschecs, using TProcess works perfectly.  I never used CreateProcess() that is Windows only.

[TRon]

@Roland57:
Feel free to correct me when wrong but

Code: C  [Select][+][-]

1.   str[len] = '\n';

Literally means

Code: Pascal  [Select][+][-]

1.   str_ := str_ + #13#10

But because str being a pchar

Code: Pascal  [Select][+][-]

1.     str_[len] := #13;
2.     str_[len+1] := #10;
3.  

I am aware of the len+1 in the functions that are invoked after the addition in str so it might very well be enough to only use

Code: Pascal  [Select][+][-]

1.    str_[len] := #13;

Perhaps worth a bit of testing/experimenting ?

[Roland57]

@TRon

Thank you for the code. I made the modifications that you suggested. But the unwanted characters are always here.

[Fred vS]

Hello Roland!

I did try to use, before CreateProcess():

Code: Pascal  [Select][+][-]

1. SetConsoleOutputCP(CP_UTF16);

or

Code: Pascal  [Select][+][-]

1. SetConsoleOutputCP(CP_UTF8);

or

Code: Pascal  [Select][+][-]

1. SetConsoleOutputCP(437);

or

Code: Pascal  [Select][+][-]

1. SetConsoleOutputCP(CP_NONE);

Each time there are other chars but not the wanted...

[tetrastes]

The problem is in WriteFile. You must dereference str_:

Code: Pascal  [Select][+][-]

1. WriteFile(pFilter^.hNachGui, str_^, len + 1, AnzGeschrieben, nil)

Then the first variant works like C code, the second has some regression.

[TRon]

The problem is in WriteFile. You must dereference str_:

Not according to the windows defined API.

If it is (for which I have no reason to doubt) then someone messed up the header translation (again) and reason I did not flagged it. The jedi units are far more superior in that regards.

[Fred vS]

The problem is in WriteFile. You must dereference str_:

Not according to the windows defined API.

If it is (for which I have no reason to doubt) then someone messed up the header translation (again) and reason I did not flagged it. The jedi units are far more superior in that regards.

Yes, it is possible, but I may be wrong (I hope it), it seems to me that fpc usage of the Windows CreateProcess() API does not handle Stdoutput as it should.
PS: 

[Thaddy]

It is much easier to rip out all that windows specific stuff and simply use rtl equivalents for file handling and pipes.

[tetrastes]

The problem is in WriteFile. You must dereference str_:

Not according to the windows defined API.

If it is (for which I have no reason to doubt) then someone messed up the header translation (again) and reason I did not flagged it. The jedi units are far more superior in that regards.

There were holiwars about it, f.e. https://forum.lazarus.freepascal.org/index.php/topic,59388.msg442698.html#msg442698

[TRon]

There were holiwars about it, f.e. https://forum.lazarus.freepascal.org/index.php/topic,59388.msg442698.html#msg442698

Thank you for that link tetrastes as I seem to have missed that discussion.

Shame that I missed it because for sure I would have strongly advocated my opinion on that topic. Every excuse to deviate from an official API is simply wrong and I am positive that someone who believes otherwise has never had to work with these API's in practice (other than an occasional call here and there. For someone disagreeing with that try translating code with hundreds of API calls and try keep that point of view).

I am already fed up with all these API parameters being var'ed while many API's explicitly state that the "values" of these (pointer) parameters can be nil (and actually makes a whole lot of difference in behaviour of such a function).

Lesson learned to never ever use the windows unit (not that I did since my switch to linux but even there this kind of crap is creeping up more and more).

And for the literate: yes, I am aware that the original official declaration also exist .... but whaddayouknow sometimes a function declaration follows the official API except for a parameter here and there being var'ed so you never know unless explicitly looking at the available translation(s) of such declaration(s). Complete randomness with a sauce of Delphi compatibility (and no excuse makes it smell less) 

And now it makes also perfect sense why TS has these issues so thank you for that hint tetrastes :thumbsup: