Page 13 of 13 FirstFirst ... 3111213
Results 121 to 130 of 130

Thread: So whatever happened to the whole PGDCE thing?

  1. #121
    Quote Originally Posted by Akira13 View Post
    @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.

  2. #122
    Quote Originally Posted by SilverWarior View Post
    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:

    Code:
    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.

  3. #123
    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.

  4. #124
    Quote Originally Posted by Chebmaster View Post
    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?

    Code:
    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.
    Last edited by Akira13; 17-09-2017 at 12:23 AM.

  5. #125
    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:
    Code:
    {$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:
    Code:
    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
    Last edited by Chebmaster; 17-09-2017 at 04:46 AM.

  6. #126
    I think this thread has degenerated a lot, hasn't it?
    No signature provided yet.

  7. #127
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    511
    Quote Originally Posted by Ñuño Martínez View Post
    I think this thread has degenerated a lot, hasn't it?

    I hope you typed that in unicode
    Last edited by phibermon; 23-09-2017 at 06:15 PM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  8. #128
    Quote Originally Posted by phibermon View Post
    I hope you typed that in unicode
    Hahaha.

    Honestly though, I'm still unsure why exactly Chebmaster has issues with that code even compiled under FPC 3.0+... maybe it's a Linux thing?

    Wasn't trying to start a war... I'm just generally very skeptical anytime someone says "Yeah, I'm using [insanely old version of something], for [XYZ reason]."

    XYZ reason is, 90% of the time, completely avoidable/preventable...

  9. #129
    maybe it's a Linux thing?
    No, it's a Windows-only problem.

    Long ago, when going unicode, Linux did the sensible thing by adopting utf-8. Microsoft though they know better, plus they had to uphold backward compatibility. Thus, all the *A/*W fuss and stuff. And this is the roor of Free Pascal's problems. While Linux making AnsiString encoding-aware was pretty enough, in Windows you have to switch all classes to using UnicodeString because that's what Windows uses natively.

    90% of the time, completely avoidable/preventable...
    This case falls into these pesky 10%.
    Free Pascal's class library is *horribly* out of date with regards to Unicode file names on the Windows platform. If you develop a Windows application in pure FP, without using Lazarus-specific fixes, your application will be stomped by competition because it could fail where any sensible Windows applications have no problems since 15 years ago.
    And while fpc 3 *did* fix the RTL, it *DID NOT* fix the classes. So good luck if you are using TStream *or* any third-party library that uses streams to read from files.
    It's a glaring flaw that should have been addressed a decade ago.

    P.S. So I have to use hacks in fpc 3 to make my application Unicode.
    And I am *lucky* I don't have to deal with third-party libraries because they have no such hack...
    Oh, wait, I do. I use Vampyre Imaging and I cannou use its functions of loading image from file. I have to load files into memory buffer myself then call vampyre function that loads images from memory. I'm lucky Vampyre *does* have such functions.

    Code:
      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;
    ...
    constructor TFileStream.Create(const AFileName: UnicodeString; Mode: Word);
    begin
      Create(AFileName, Mode, 438);
    end;
    
    
    constructor TFileStream.Create(const AFileName: UnicodeString; Mode: Word; Rights: Cardinal);
    var
      h: THandle;
    begin
      FFileName:= AFileName;
      If (Mode and fmCreate) > 0 then
        h:= FileCreate(AFileName,Mode,Rights)  // it IS already unicode in 3.0.0
      else
        h:= FileOpen(AFileName,Mode);
    
      If (h = feInvalidHandle) then
        If Mode = fmcreate then
          Die(RuEn('Не удалось создать файл "%0"','Failed to create file "%0"'),[AFileName])
        else
          Die(RuEn('Не удалось открыть файл "%0"','Failed to open file "%0"'),[AFileName]);
      inherited Create(h);
    end;
    
    destructor TFileStream.Destroy;
    begin
      FileClose(Handle);
    end;
    P.P.S. I'd call it "dick move" if didn't know the devs are mostly focused on Linux. This probably slipped their mind. And that Lazarus patch and everyone using it probably didn't help as it negated the problem somehow.
    Still, this one great pitfall marginalizes Free Pascal by making it harder to write serious business applications for Windows.

    P.P.P.S Worst case scenario: you write an application, going to great pains to make 100% sure it works. Like 90% people out there you are unaware that fpc is not unicode.
    Finally it's time to show it to your boss. You launch it on his machine... Which coincidentally has user name like "фañ"... And your application flops with a weird error. Why? What? You lost your face.
    You try fixing the problem ASAP pulling all-nighter to be ready try the next day, but... The problem is not easily fixable, you miss some instances of non-unicodeness in your tired state. Your application flops again in the face of your boss.
    "What it is written in?" he asks. "Free Pascal...? Forget that crap and learn proper coding tools. You're fired."
    Last edited by Chebmaster; 01-10-2017 at 11:08 AM.

  10. #130
    Quote Originally Posted by phibermon View Post
    Quote Originally Posted by Ñuño Martínez View Post
    I think this thread has degenerated a lot, hasn't it?
    I hope you typed that in unicode
    I know this is a sort of joke, but I don't get it.
    No signature provided yet.

Page 13 of 13 FirstFirst ... 3111213

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •