Pascal version of the UCI Filter program

[Roland57]

Hello everybody.

I translated to Pascal the program UCI Filter. It's a program designed to be used as a filter between a UCI chess engine and a chess GUI.

The Pascal version doesn't work correctly. Would someone help me to find the error?

Here is how to compile and test the original program:

(You need to have make and fpc available on the command line.)

D:\c\echecs\ucifilter-pascal-241011>make
gcc -Wall ucifilter.c -o ucifilter.exe

D:\c\echecs\ucifilter-pascal-241011>make test
ucifilter .\CT800_V1.34_x32.exe
CT800 V1.34 32 bit UCI version
2016-2019 by Rasmus Althoff
Free software under GPLv3+
quit

Here is how to compile and test the Pascal version:

D:\c\echecs\ucifilter-pascal-241011>make ucifilterpas
fpc -Mobjfpc -Sh -dDEBUG ucifilter.pas -oucifilterpas.exe
Compiling Debug Version
Free Pascal Compiler version 3.2.0 [2021/02/21] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling ucifilter.pas
Compiling log.pas
Linking ucifilterpas.exe
524 lines compiled, 0.3 sec, 170256 bytes code, 6724 bytes data

D:\c\echecs\ucifilter-pascal-241011>make testpas
ucifilterpas .\CT800_V1.34_x32.exe
| a♠CT800 V1.34 32☻  | a♠►' £ a♠2016-2019 by R☻  | a♠╣ a♠Free software ☻  | aquit

You can see that the output of the UCI engine is corrupted.

Which error did I make?

[bobby100]

Are you sure about using ansichar and ansistring? To me, it looks like you are getting multibyte text, and the garbage comes from reading it as singlebyte (ansi) chars.

[af0815]

Best way, write the original raw stringdata to a file and analyse this file. I have see this, if i read output from a Delphi programm (2 Byte Chars) and misinterpret this in my first try.

[Roland57]

Are you sure about using ansichar and ansistring?

I think ansichar is the equivalent of the char type used in the C program. The ansistring type is used only for the executable path, and it seems to work (since the executable starts).

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

1. function EngineStarten(EnginePath: AnsiString): THandle; forward;

[Fred vS]

I think ansichar is the equivalent of the char type used in the C program. ;

There is also cchar from ctypes.pp.

[Thaddy]

The equivalent of a C char is usually a byte, not a Pascal char.

[TRon]

A byte is equivalent to a unsigned char.

[Thaddy]

That is compiler dependant. You can only assume that the size is sizeof(byte). See remark in ctypes.

[Roland57]

Thank you all for your answers.

I wonder if my buffers are properly initialized, here :

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

1. procedure GuiNachEngine(pFilter: PFilterDaten);
2. // ...
3. begin
4.   // ...
5.  
6.   lp.hDatei := pFilter^.hVonGui;
7.   lp.Groesse := 10000;
8.   lp.pPuffer := StrAlloc(lp.Groesse + 1);
9.  
10.   //FillChar(lp.pPuffer, lp.Groesse * SizeOf(ansichar), #0);
11.   StrPCopy(lp.pPuffer, StringOfChar(#0, lp.Groesse));

And here :

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

1. function EngineNachGui(pParam: Pointer): DWORD; stdcall;
2. // ...
3. begin
4.   // ...
5.  
6.   pFilter := PFilterDaten(pParam);
7.  
8.   lp.hDatei := pFilter^.hVonEngine;
9.   lp.Groesse := 10000;
10.   lp.pPuffer := StrAlloc(lp.Groesse + 1);
11.  
12.   //FillChar(lp.pPuffer, lp.Groesse * SizeOf(ansichar), #0);
13.   StrPCopy(lp.pPuffer, StringOfChar(#0, lp.Groesse));

[TRon]

Is the text output from the server still garbled ? or does the engine not respond ?

What platform is the engine running on, and what platform the client ? (the UCI documentation mentions some specifics)

[Thaddy]

Sigh, use AllocMem when translatinng C code.

[Roland57]

Is the text output from the server still garbled ? or does the engine not respond ?

What platform is the engine running on, and what platform the client ?

The engine responds but the output of the filter is corrupted. The filter uses Windows API. Please see my first post.

Sigh, use AllocMem when translating C code.

Thanks, I will try.

[TRon]

The engine responds but the output of the filter is corrupted. The filter uses Windows API. Please see my first post.

"\n" means #13#10 on/for windows (as expressed in the UCI specifications)

[Roland57]

AllocMem works, but doesn't solve the issue.

@TRon
Thanks, but I don't think that this be the issue.

[TRon]

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

There is very little specifications written down, so I would personally stick to what actually is available.