So whatever happened to the whole PGDCE thing?

[Chebmaster]

Uh, why are you still using FPC 2.6.4?

Is very stable.

Trunk and 3.0.0 compilers, on the other hand, crash with internal errors trying to build my project (I reported many a bug). It seems that that was fixed in 3.0.2 but I want to be ABSOLUTELY sure when something crashes it's a problem in my mindscrewy code, not in the compiler or RTL.
I had very bad experience of spending several months on difficult debugging and practically had my project die due to my confidence failing -- all because of a faulty tool causing random *unrelated* crashes.
Let's say I would be boasting the first multi-threaded first-person shooter for DOS in human history (made in 1998 ) if not for that faulty piece of excrement. It killed my motivation.
Since then I ONLY use stable tools. So, until the managers of Debian Stable say it's okay by raising its FPC over 2.6.4... Just no.
I carefully prepare my code to move over to 3.0.x and periodically test if it compiles, of course, but not yet.

[phibermon]

Chebmaster : having developed cross platform code using FPC for a number of years, I've encountered many bugs, usually OS specific. I'd recommend that you build on at least two operating systems - It helps to identify the source of problems, to eliminate common code etc.

I've found FPC 3.0.x to be very stable, my code is working on all the OSes I currently support and it touches everything you'd expect from a modern engine - I had a few issues with 2.6.x.

There may be some issues that were introduced perhaps but don't dismiss it entirely just in case you spend ages trying to get round a bug that was later fixed - which is a more likely scenario.

[Chebmaster]

I'm not dismissing it, I'm waiting for it to mature to the point of usability.
Which, in my estimate, will eventually happen as fpc reaches 3.0.4 or 3.0.6
For example, classes in 3.0.0 are not unicode so I *still* had to create this hackaround:

  TFileStream = class(classes.THandleStream)
  Private
    FFileName : UnicodeString;
  public
    constructor Create(const AFileName: UnicodeString; Mode: Word);
    constructor Create(const AFileName: UnicodeString; Mode: Word; Rights: Cardinal);
    destructor Destroy; override;
    property FileName : UnicodeString Read FFilename;
  end;

That wasn't hard. I already have one for 2.6.4:

{
  This is a permanent fix for the broken RTL of FPC 2.6.4
  See http://bugs.freepascal.org/view.php?id=27221

  This fix is required to get Platinum level of Wine compatibility
}
{$ifndef windows}
  {$fatal Windows ONLY}
{$endif}
type
  TFileStream = class(classes.TFileStream)
  public
    destructor Destroy; override;
  end;

  //The rest of the classes are dragged along by the need to base them on the fixed TFileStream
  TStringList = class(classes.TStringList)
  public
    procedure LoadFromFile(const FileName: AnsiString);
    procedure SaveToFile(const FileName: AnsiString);
  end;

  TIniFileKey = class

//..... and so on
// where 

destructor TFileStream.Destroy;
begin
  if Handle <= 4 then CloseHandle(Handle);
  inherited;
end;

P.S. Truly universal code compatible with both 2.6 and 3.0 branches goes like this:

{$if FPC_FULLVERSION>=20700}
  {$define che_unicode}
{$endif}  

...

{$ifdef che_unicode}
  {$if FPC_FULLVERSION<30000}
    {$fatal Impossible to use this compiler version: RTL is not unicode} //The sad truth
  {$endif}

  { modeswitch unicodestrings} //is in the main project file

  {$warn IMPLICIT_STRING_CAST_LOSS Error}
  {$warn EXPLICIT_STRING_CAST_LOSS Error}
  { if FPC_FULLVERSION<=40000} //***TODO Replace with version in which it is fixed
     {$define fix_fpc3_unicode} // Use custom mods of TFileStream, TStringList and TIniFile
  { endif}

  AnsiString1251 = type AnsiString(1251);
  TFileNameString = UnicodeString;
  PFileNameChar = PUnicodeChar;

{$else}
  //Legacy Free Pascal below 3.0 (2.6.0 to 2.6.4)
  RawByteString = AnsiString;
  AnsiString1251 = AnsiString;
  {$ifdef windows}
    //no unicode support for file names
    TFileNameString = AnsiString;
    PFileNameChar = PAnsiChar;
  {$else}
    TFileNameString = Utf8String;
    PFileNameChar = PAnsiChar;
  {$endif}
{$endif}

P.P.S. This is getting far off-topic. Dear mods, please feel free to snip this discussion off.

[phibermon]

Yes there are still problems - you do raise a good point - code you've patched to suit your purposes is effectively more 'advanced' - better the devil you know and all that jazz

[Akira13]

@Chebmaster: I still don't understand how your filenames could possibly require unicode support. Why would anyone specifically go out of their way to use unicode characters in a filename to begin with? It makes no sense. I've also never encountered a "unicode" situation with FPC that normal "AnsiStrings" couldn't handle. For example, the following code compiles fine and displays correctly:

procedure TForm1.FormShow(Sender: TObject);
var
  MyString: AnsiString;
begin
  MyString := '¶' + '¿' + 'ÆÆÆ' + '®®®®®®' + '¢¢¢¢¢' + 'ȾȾȾȾȾȾȾȾ' + 'ɎɎɎɎɎɎɎɎ' + 'ΏΏΏΏΏΏΏΏΏ' + 'ϼϼϼϼϼ';
  ShowMessage(MyString);
end;

Also, you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus, right?....

[SilverWarior]

@Chebmaster: I still don't understand how your filenames could possibly require unicode support. Why would anyone specifically go out of their way to use unicode characters in a filename to begin with?

Why do you think they would "go out of their way" in order to use Unicode characters in the file name? You do realize there are bunch of languages in the world that actually can't write without the use of Unicode characters or at least customized Charset?
So what seems for you to "go out of their way" in order to use Unicode characters it seems perfectly normal to them. In fact to them using only ANSI characters seems "to go our of their way" big time.

Also you need to realize that since newer versions of Windows support using Unicode characters in user names. This also means that any username based paths like "C:\Users\%Username%\..." could already contain Unicode characters in it so not having Unicode support in your application file handling means you have a large possibility that your application won't work on such system. Especially since based on windows guidelines most of the settings should be stored in one of the sub-folders of the above mentioned user folder.

[Akira13]

Why do you think they would "go out of their way" in order to use Unicode characters in the file name? You do realize there are bunch of languages in the world that actually can't write without the use of Unicode characters or at least customized Charset?
So what seems for you to "go out of their way" in order to use Unicode characters it seems perfectly normal to them. In fact to them using only ANSI characters seems "to go our of their way" big time.

Also you need to realize that since newer versions of Windows support using Unicode characters in user names. This also means that any username based paths like "C:\Users\%Username%\..." could already contain Unicode characters in it so not having Unicode support in your application file handling means you have a large possibility that your application won't work on such system. Especially since based on windows guidelines most of the settings should be stored in one of the sub-folders of the above mentioned user folder.

I'm very aware of all of that. I was really just questioning whether or not he realizes that things such as the code sample in my last post work perfectly as written in current FPC versions. Here's another sample explicitly declaring an "AnsiString" yet happily using Unicode characters:

procedure TForm1.FormShow(Sender: TObject);
var
  AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
begin
  AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
  if FileExists('C:\Test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
    ShowMessage('It exists!');
end;

If that file does indeed exist, the code will properly return true.

[Chebmaster]

how your filenames could possibly require unicode support.

Simple. Assume a Windows XP user who chose user name like "／人◕‿‿◕人＼". Windows creates his Application data folder with that string as part of the path. Non-Unicode applications fail.
I tested it and proved it.
Of course that user is an idiot noob, but still.

the following code compiles fine and displays correctly:

Do you realize your example is invalid because it uses Lazarus? Lazarus includes tons of hacks and custom RTL patching to make UTF-8 work on Windows as if it was default.
I write in pure FPC. The FPC RTL doesn't have the Lazarus hacks. If I try accessing TFileStream.Create('c:\Users\／人◕‿‿◕人＼\Application Data\chentrah\chentrah.ini', fmOpenRead); it will fail even with the file in place.
Fpc 3.x does have much better support for Unicode paths and only requires minor patching. sadly, it is not ready yet.

you do realize the people who maintain Debian are entirely unrelated to the developers of FPC/Lazarus

I do indeed. The Debian maintainers are much more thorough in their approach to stability and they deem fpc 3.x not ready. I agree with them.

[Akira13]

Do you realize your example is invalid because it uses Lazarus? Lazarus includes tons of hacks and custom RTL patching to make UTF-8 work on Windows as if it was default.
I write in pure FPC. The FPC RTL doesn't have the Lazarus hacks. If I try accessing TFileStream.Create('c:\Users\／人◕‿‿◕人＼\Application Data\chentrah\chentrah.ini', fmOpenRead); it will fail even with the file in place.
Fpc 3.x does have much better support for Unicode paths and only requires minor patching. sadly, it is not ready yet.

Uh, what are you talking about?

program Test;

uses
  SysUtils;

var
  AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
begin
  AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
  if FileExists('C:\Test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
    WriteLn('It exists!');
end.

There's the command line version of my example, which I just compiled and ran without issues using the FPC binary directly. I'm also unsure as to how you think Lazarus could "hack" or "patch" the RTL at compile time, considering that you cannot build it without an entirely pre-built FPC to link against.

I do indeed. The Debian maintainers are much more thorough in their approach to stability and they deem fpc 3.x not ready. I agree with them.

lol. I think the vastly more realistic scenario is "the people who maintain Debian are Linux power-users who don't remotely care about anything to do with Pascal and may even look down on the language as something for simpletons, and have just forgotten to update it for a really long time." I'd imagine the only reason it was ever added as a standard Debian package in the first place was because like one specific guy who just happened to use it on Linux and was also a Debian maintainer took the time to do it himself.

FPC/Lazurus is far more stable than most of what's out there. I've used nothing but the trunk of both of them for several years and have almost never experienced a situation where one of them conflicted with the other. And any time there was an issue it was either something I could easily work around myself, or it was just fixed in the actual codebase within a day or so.

[Chebmaster]

There's the command line version of my example,

Does NOT work when I compile this using fpc 2.6.4 => non-unicode executable
While fpc 3.x was crashing last time I tried building my project using it => no executable at all

Which one would you prefer? One that works badly or one that does not work at all?
That is the difference between fpc 2.6.4 (lame but stable) and fpc 3.x (supposedly better but chokes on internal errors).

P.S. And fpc 3.0.2 IS STILL INCOMPLETE:
See this example:

{$codepage utf-8}
{$mode objfpc}
program Test;
uses
  SysUtils, classes;

var
  AFileNameConsistingEntirelyOfUnicodeCharacters: AnsiString;
  s: TFileStream;
begin
  AFileNameConsistingEntirelyOfUnicodeCharacters := '௵௵௵௵實實實電電電電參參參ݠݠݼݼݼݼݼਈਈਈ.txt';
  if FileExists('d:\tmp\test\' + AFileNameConsistingEntirelyOfUnicodeCharacters) = True then
    WriteLn('It exists!')
    else WriteLn('false.');
  try
    s:= TFileStream.Create('d:\tmp\test\' + AFileNameConsistingEntirelyOfUnicodeCharacters, fmOpenRead);
    s.Free;  
  except
    WriteLn((ExceptObject as Exception).Message);
  end;
  readln; 
end.

Now see it FAIL to open a stream:

It exists!
Unable to open file "d:\tmp\test\????????????????????????.txt"

That's it folks. The RTL may be Unicode now (FileExists & friends) but CLASSES ARE NOT!

P.S. That's why I have a hack in my engine to be used with FPC 3, containing modified versions of TFileStream, TIniFile and TStrings.
I hope it will not be needed someday.
But as it is, FPC 3 was rolled out prematurely. It should've stayed 2.9.x for a while longer.

P.P.S. I was planning to make a similar patch for fpc 2.6.4 with Unicode FileExists & friends, but I decided: why bother when fpc 3 would be there soon. Yeah. That 'soon' proved to be relative