Pascal version of the UCI Filter program

[Roland57]

@tetrastes

Great! Many thanks. I can't wait to test by myself. (Unfortunately I am at home today, where I have only a Linux installation.)

[TRon]

(Unfortunately I am at home today, where I have only a Linux installation.)

Now, if you only had .... 

BTW: in the case that was indeed the (only) issue then you might be able to get away with just using #10 but be advised that in case of issues the specification explicitly mentions to use #13#10 for windows. In practice most code simply ignores the #13 and 'chops' on the #10 (but that could differ per engine).

[Roland57]

Now, if you only had .... 

I don't understand. Sorry, english is not my native language. 

BTW: in the case that was indeed the (only) issue then you might be able to get away with just using #10 but be advised that in case of issues the specification explicitly mentions to use #13#10 for windows. In practice most code simply ignores the #13 and 'chops' on the #10 (but that could differ per engine).

Thanks for the clarification.

[TRon]

I don't understand. Sorry, english is not my native language. 

I ruins the (bad) joke but...

The full sentence would have been: "Now, if you only had used Free Pascal's RTL functions for the file- and pipe- handling, then you would have been able to compile/run it on/for Linux"

(and yes I understand that defeats the purpose of your translation of this program, which was the second layer of the joke).

[Roland57]

I see. 

Maybe when I have time, I will try to make a multiplatform version.

By the way, I already made something similar, using TProcess.

When you say RTL, do you mean the Process unit, or something else?

[TRon]

Maybe when I have time, I will try to make a multiplatform version.

That was not the intention of the "joke" but could perhaps be a nice exercise.

By the way, I already made something similar, using TProcess.

Ah yes, I see. Not the exact same functionality as the filter program but the base functionality seems to be in place.

When you say RTL, do you mean the Process unit, or something else?

Indeed TProcess but perhaps also in combination with the pipes unit.

[Thaddy]

The last sentence is exactly what I meant.

[Fred vS]

Hello.
The boring one is back! 

Doing this:

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

1. program launchprogram;
2.  
3. uses
4.   Process;
5.  
6. var
7.   AProcess: TProcess;
8.  
9. begin
10.    AProcess := TProcess.Create(nil);
11.    AProcess.Executable:= 'CT800_V1.34_x32.exe';
12.    AProcess.Options := AProcess.Options + [poWaitOnExit];
13.    AProcess.Execute;
14.    AProcess.Free;  
15. end.

Gives this:

$ wine launchprogram.exe

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

As you can see, using TProcess gives a good result in the standard output.
So I still have doubts about how fpc handles the standard output while using the Windows API CreateProcess() and related methods.

[Thaddy]

Fred, your only and biggest problem is that in a Lazarus GUI app, stdin/out/err are not available by default on Windows.
That is all.
This is also true for Delphi.
The easiest way to get around it is specifying {$apptype console} and hide the console.
I have shown quite a few times how to do that. On almost all other platforms, there is always a working set of stdin/out/err by default.

[Fred vS]

Fred, your only and biggest problem is that in a Lazarus GUI app, stdin/out/err are not available by default on Windows.
That is all.

Hello Thaddy.
I hope this is my only problem!
But it shouldn't be this time, in Roland's demo I added right at the beginning of testing:

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

1. {$APPTYPE CONSOLE}

Also added this to be sure (but it is done by default):

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

1.  StartInfo.hStdInput := GetStdHandle(STD_INPUT_HANDLE);
2.   StartInfo.hStdoutput := GetStdHandle(STD_OutPUT_HANDLE);

And the StartInfo.hStdoutput has not same result than the STD_OutPUT from TProcess.
Sadly, I dont have Delphi installed to test the demo of Roland compiled with Delphi vs with fpc.

[tetrastes]

As you can see, using TProcess gives a good result in the standard output.
So I still have doubts about how fpc handles the standard output while using the Windows API CreateProcess() and related methods.

What do you mean? At windows TProcess uses CreateProcess (CreateProcessW to be precise). So "how fpc handles ... etc" you can see in sources of TProcess (packages\fcl-process\src\win\process.inc). How the particular programmer handles this, is the matter of this programmer.

[Fred vS]

As you can see, using TProcess gives a good result in the standard output.
So I still have doubts about how fpc handles the standard output while using the Windows API CreateProcess() and related methods.

What do you mean? At windows TProcess uses CreateProcess (CreateProcessW to be precise). So "how fpc handles ... etc" you can see in sources of TProcess (packages\fcl-process\src\win\process.inc). How the particular programmer handles this, is the matter of this programmer.

Hello Tetrastes.
Many thanks for pointing packages\fcl-process\src\win\process.inc
But there is this as note line 280:

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

1. // Beware: CreateProcess can alter the strings

So I will study the code using CreateProcessW.
[EDIT] I did try using CreateProcessW, with the vars adapted for widestring and following the code of process.inc but there is still garbage in the output strings.  So there is something I don't catch. I pass my turn. 

[Roland57]

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.

I finally could test that modification and indeed it solves the issue. So thank you very much! 

I have to do a last review of the whole code, for proper line endings management, as suggested by TRon.

[Roland57]

I fixed a last (?) error. This line was not properly translated:

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

1. sscanf(str, "%15s", Kommando);

My first translation was:

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

1.     StrLCopy(Kommando, str_, SizeOf(Kommando) - 1);

Which is obviously wrong.

Now it is:

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

1.     FillChar(Kommando, SizeOf(Kommando), #0);
2.     i := 0;
3.     while (i < len) and (i < SizeOf(Kommando)) and ((str_ + i)^ <> #32) do
4.     begin
5.       Kommando[i] := (str_ + i)^;
6.       Inc(i);
7.     end;

I know there is a Pascal sscanf function, but I didn't find how to use it in that case. 

@TRon
After reflection, '\n' (please notice the single quotes) is the equivalent of #10, not #13#10. So, it would probably be better to use #13#10 as you suggested, but as my first goal was to translate the C program as it is, I went back to my first translation.

Here is the final (?) state of the program, if ever someone is interested. Thank you all for your help!