#1 2019-06-12 12:18:24

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Delphi Compilers Support

Hi, I'm not the big fun of 1999' Delphi 5, but if you build a library under the mORMot framework you have to support it.
The next project can't be compiled under standard clean ISO Delphi 5 (Build 5.62) with clean ISO Windows XP Professional Version 2002 Service Pack 2 32-bit sad

program Project1;
{$APPTYPE CONSOLE}
uses SynCommons;
begin
end.

I got the next result with Project / Build All Projects run under Delphi 5:

1.18.5234: Build failed: dcc50.dll exception
1.18.5135: Build failed: dcc50.dll exception
1.18.5122: Build failed: Internal error: C1093
1.18.5119: Build failed: dcc50.dll exception
1.18.5118: Build success
1.18.5116: Build success
1.18.5110: Build success
1.18.5086: Build success
1.18.5036: Build success

If I got an Internal error or dcc50.dll exception I was tried to reopen Delphi 5 IDE and Build All Projects again.

@ab,
  On what OS (Win XP/Vista/7/8.1/10) and what architecture (x86/32-bit or x64/64-bit) and what version of Delphi 5 the TestSQL3.dpr verification provided?
  Is Delphi 5 support dropped since 1.18.5118 (116 releases ago / since Mar 19, 2019)?
  Are Delphi 5 tests (TestSQL3.dpr) passed before fossil commit appeared in repository?

Last edited by Eugene Ilyin (2019-06-24 13:29:21)

Offline

#2 2019-06-12 13:10:47

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

An another observation.
For the next "more complex" project:

program Project1;
{$APPTYPE CONSOLE}
uses SynCommons, mORMot;
begin
end.

I receive the next compilation errors in Delphi 5 version 5.62 enterprise edition under the Windows XP Professional Service Pack 2 32-bit edition:

1.18.5234: Build failed: dcc50.dll exception
1.18.3179: Build failed: [Error] mORMot.pas(4293): Undeclared identifier: 'TDocVariantData'
1.18.2734: Build failed: [Error] mORMot.pas(4265): Undeclared identifier: 'TDocVariantData'
1.18.1000: Build failed: [Error] SynSSPIAuth.pas(302): Undeclared identifier: 'RaiseLastOSError'
1.18.500: Build failed: [Error] SynSSPIAuth.pas(302): Undeclared identifier: 'RaiseLastOSError'
1.18.260: Build failed: [Error] SynSSPIAuth.pas(302): Undeclared identifier: 'RaiseLastOSError'

Offline

#3 2019-06-12 13:56:51

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,655
Website

Re: Delphi Compilers Support

Note that the mORMot unit was NEVER compatible with Delphi 5.
Only some ground units, like SynCommons, and some shared features, like SynPdf or SynDB.
But not the ORM/SOA/MVC features of the framework.

But you can compile a Delphi 5 client, using the cross-platform client units.

Sadly, Delphi 5 compilation does not work any more since a few months.
I was not able to find out the reason.
On my Delphi 5 setup, the compiler just quit - with no error message.

There is a C1093 error reported on your side.
So it sounds like a Int64 compilation problem on this very old compiler....

I tried to circumvent the problem with https://synopse.info/fossil/info/aff7fc6b62 - but with no big success. sad
Have you any line error number at compilation on your side?

Offline

#4 2019-06-12 14:28:46

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

ab wrote:

Note that the mORMot unit was NEVER compatible with Delphi 5.

This is a good news for me. I'm not a big fun to support Delphi 5 and compile code under XP SP 2 virtual boxes smile

I'm updating mORMotBP to the resent HTML Boilerplate release now.
Some people here noticed that lack of support of old Delphi versions for this library stops them to use it.
So I decided to find a way to pass all library tests scenarios under Delphi 5 & 7. As the result this topic occurred.
I've add Delphi 7 support, so I keep it as is and stop trying to run THTTPServer under Delphi 5.

ab wrote:

Have you any line error number at compilation on your side?

The dcc50.dll AV crush always occurred when the line 62570 displayed on compiling window (the last file line is 62569).
So some unit post-processing crushed this ancient compilator.

Isn't is easy to remove this 20 years old "Delphi 5" partial support notice from SAD 1.18 Documentation (only 2 places in a whole document)?

Offline

#5 2019-06-13 09:44:05

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,655
Website

Re: Delphi Compilers Support

I would like eventually to restore Delphi 5 compatibility, since we were able to maintain it since the beginning...
But I would need a bit luck to find out what was wrong.

Offline

#6 2019-06-13 12:14:15

igors233
Member
Registered: 2012-09-10
Posts: 241

Re: Delphi Compilers Support

> The dcc50.dll AV crush always occurred when the line 62570 displayed on compiling window (the last file line is 62569).
> So some unit post-processing crushed this ancient compilator.

Perhaps it has to do with unit size, I remember some Delphi versions had limit on file size or line numbers.

Offline

#7 2019-06-13 13:05:00

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,655
Website

Re: Delphi Compilers Support

Yes, I already cut down, a few days ago, the unit size to a lower number of lines, by moving content to SynTable.pas.

But unit size is not about C1093 internal error, but about internal error PRO-3006.
It is more like a problem with inc() or dec() over Int64 values...

Offline

#8 2019-06-24 13:39:19

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

Hi @ab,
Let's continue compilers testing smile

What about Kylix 3 (over CrossKylix) support?

program Project1;

{$I Synopse.inc} // define HASINLINE USETYPEINFO CPU32 CPU64 OWNNORMTOUPPER

{$APPTYPE CONSOLE}

{$R *.res}

uses
  {$I SynDprUses.inc} // will enable FastMM4 prior to Delphi 2006, and enable FPC on linux
  SysUtils,
  SynCommons;

begin
  WriteLn(FormatDateTime('dd.mm.yyyy hh:nn:ss.zzz', Now));
end.

Run on recent XUbuntu 18.04, Bionic Beaver 32-bit:

mORMot 1.18.5036

Successful compilation and run on Linux terminal:

./Project1

24.06.2019 17:05:32.445
mORMot 1.18.5086 and later

Successful compilation but when run on Linux terminal - 1 CPU Core load 100% without any messages.
When press ^C displays:

./Project1

Runtime error 230 at 080596E1
Segmentation fault (core dumped)

Offline

#9 2019-06-24 13:51:20

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,655
Website

Re: Delphi Compilers Support

Since we switched to FPC for Linux compilation, Kylix3 support was indeed less tested since a few weeks.
My Cross-Kylix IDE just stopped to work, eating 100% of one core for ever.

Do you have any clue what is creating the SegFault on your side?

Offline

#10 2019-06-24 14:25:31

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

@ab,

After testing of 26 mORMot versions between 4578 and 5254 (the recent one), I found that issue was introduced in 1.18.5037 (2019-02-13 17:11:25)

5037: ensure PatchCode() will work even if OS memory page size is not 4KB

Seems like you change something with SystemInfo.dwPageSize / AlignedAddr on non-Windows OS'es which is broke program execution after compilation under CrossKylix.

Can you add some {$IFDEF}'s and bring Kylix support back?

Offline

#11 2019-06-24 14:58:59

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

@ab, found a root cause:

When the main program executes the SystemInfo.dwPageSize is initialized as expected with 4096 ($1000) value.

But when the code in on line SynCommons.pas: 39538 (we talk about 1.18.5037 build) executes:

  WriteLn('SystemInfo.dwPageSize:39538=', SystemInfo.dwPageSize);
  PageSize := SystemInfo.dwPageSize;
  AlignedAddr := PtrUInt(Old) and not (PageSize-1);
  while PtrUInt(Old)+PtrUInt(Size)>=AlignedAddr+PageSize do
    Inc(PageSize,SystemInfo.dwPageSize);

The Project1 shows that:

SystemInfo.dwPageSize:39538=0
SystemInfo.dwPageSize:39538=0
SystemInfo.dwPageSize:39538=0
SystemInfo.dwPageSize:39538=0
SystemInfo.dwPageSize:39538=0
SystemInfo.dwPageSize:39538=0

Seems like initialization sequence is wrong and SystemInfo is initialized after it is used in TMemoryMap.Map method (SynCommons.pas:38677 in 1.18.5254, the recent mORMot build).

Also please check SynCommons.pas:62617 in 1.18.5254 (not sure that SystemInfo.dwPageSize is also initialized before this code executes):

    if aCustomOffset and (SystemInfo.dwPageSize-1)<>0 then
      raise ESynException.CreateUTF8('fpmmap(aCustomOffset=%) with SystemInfo.dwPageSize=%',
        [aCustomOffset,SystemInfo.dwPageSize]) else
      aCustomOffset := aCustomOffset div SystemInfo.dwPageSize;

Offline

#12 2019-06-24 15:30:21

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

Yeap, the initialization section in SynCommons.pas:

initialization
  ...
  InitRedirectCode;
  InitSynCommonsConversionTables;
  RetrieveSystemInfo;

InitRedirectCode uses RedirectCode, which is uses PatchCode, which is based on SystemInfo.dwPageSize, which is equal zero and crush an execution code because dwPageSize initialized later in RetrieveSystemInfo call in initialization section.

Seems that is a reason why processor core goes 100% and execution frozen in some infinite loop inside the random broken execution.

Offline

#13 2019-06-24 16:19:39

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

@ab, seems like the fix will not be trivial, it's not possible just to put InitSynCommonsConversionTables and RetrieveSystemInfo with fillCharFast usage before InitRedirectCode where the code patched.
And we can't keep InitRedirectCode before RetrieveSystemInfo because it will use SystemInfo.dwPageSize.

Offline

#14 2019-06-24 17:57:13

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

@ab,

Finally I got the recent build 1.18.5254 self-tests start executing under XUbuntu 18.04, Bionic Beaver LTS 32-bit

I do the next change in SynCommons.pas:

Comment/remove the original SystemInfo.dwPageSize initialization in SynCommons.pas:26135:

procedure RetrieveSystemInfo;
...
  modname := nil;
  // SystemInfo.dwPageSize := getpagesize; // use libc for this value
...

And put if before InitRedirectCode in SynCommons.pas:62569:

initialization
...
  MoveFast := @System.Move;
  {$ifndef MSWINDOWS}
  SystemInfo.dwPageSize := getpagesize; // use libc for this value
  {$endif}
  {$ifdef FPC}
  FillCharFast := @System.FillChar; // FPC cross-platform RTL is optimized enough
  {$ifdef Linux}
...

Unfortunately ECC cryptography tests failed.
The whole 1.6 Protocols section frozen and requires ^C to be pressed to let the other tests pass.

#44   !!! ECC cryptography - Certificates and signatures "" failed !!!
#55   !!! ECC cryptography - Certificates and signatures "" failed !!!
#90   !!! ECC cryptography - Certificates and signatures "" failed !!!
!  - Certificates and signatures: 3 / 91 FAILED  3.77s

#602 EControlC  !!! Protocols - RTSP over HTTP "EControlC" failed !!!
!  - RTSP over HTTP: 1 / 602 FAILED  5m27
  Total failed: 1 / 602  - Protocols FAILED  5m27

Here is the summary (please pay attention to the last line):

Ubuntu 18.04.2 LTS - Linux 4.18.0-22-generic (cp1252)
    2 x Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (x86)
Using mORMot 1.18.5254 PRTL
    TSQLite3LibraryDynamic 3.22.0 with internal MM
Generated with: Kylix 3 32 bit compiler

Time elapsed for all tests: 7m05
Performed 2019-06-24 21:26:31 by * on *

Total assertions failed for all test suits:  6 / 39,072,532
! Some tests FAILED: please correct the code.
? H@Vunknown: MM Operation after uninstalRuntime error 204 at 0804AD84

@ab, can you please make the fix, validate Kylix under 64-bit Linux system (CrossKylix is unable to build executable 32-bit code for the recent 64-bit platforms) and check why the couple of ECC tests and whole 1.6 Protocols section failed?

Offline

#15 2019-06-25 07:58:37

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,655
Website

Re: Delphi Compilers Support

Please check https://synopse.info/fossil/info/4c89d1596a

I guess the ECC issue is a problem with the "pure pascal" version of the computation.
Kylix may be confused by the high-performance 128-bit computation algorithms used in pascal.
But in practice, SynEcc will use the built-in asm version, so I guess it should work for programs, outside of the tests.

I can't validate anything, sadly, since my CrossKylix installation is broken (taking 100% of one core for ever at compiling).
And we strongly advice not to use Kylix anymore, but FPC, for compiling for Linux: it will produce both 32-bit and 64-bit x86 executables - and also ARM !
We use FPC x86-64 Linux target on production since years now, with very good stability and performance.

Offline

#16 2019-07-01 09:08:34

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

Hi @ab,

I can confirm that preliminary dwPageSize initialization fixed the Kylix 3 test execution run.
All test cases except couple ECC cases and all 1.6 Protocols sections passed.

Sorry for delay with the response, I'm preparing more issues with compiles support.

Offline

#17 2019-08-01 23:14:46

Eugene Ilyin
Member
From: milky_way/orion_arm/sun/earth
Registered: 2016-03-27
Posts: 132
Website

Re: Delphi Compilers Support

Hi @ab,

Based on updated mORMotBP 2.0 release development, I want to suggest the next changes to make mORMot more developer friendly in different IDEs:

Delphi 6

mORMot\RTL7\SynCrtSock.pas: 4264

  if Sep=' ' then
  {$IFDEF VER140}
  ip := nil; // make Delphi 6 happy
  {$ENDIF} 
  if Sep=' ' then

mORMot\RTL7\SynCrtSock.pas:9779

  fState := wsConnecting;
  {$IFDEF VER140} // make Delphi 6 happy
  wsRequestHeaders := nil;
  wsServerHeaders := nil;
  {$ENDIF}
  fState := wsConnecting;

mORMot\RTL7\mORMot.pas:41597

  {$ifdef KYLIX3}
  TableIndexes := nil; // make Kylix happy
  {$endif}
  {$if defined(VER140) or defined(KYLIX3)}
  TableIndexes := nil; // make Delphi 6 and Kylix happy
  {$ifend}

SynCommons.pas:11866

SetThreadName cann't be disabled on Delphi 6 (it has no ability to block some exceptions). This makes debug or development under Delphi 6 with this thread names turned on looks like hell. Of course we can define NOSETTHREADNAME in project options, but discover it and analyse how to disable will be strange for new developers with Delphi 6 because it doesn't support thread naming anyway. So here the suggested patch:

procedure SetThreadName(ThreadID: TThreadID; const Format: RawUTF8;
  const Args: array of const);
procedure SetThreadName(ThreadID: TThreadID; const Format: RawUTF8;
  const Args: array of const);
{$IFDEF VER140}{$DEFINE NOSETTHREADNAME}{$ENDIF} // Not supported by Delphi 6
Delphi 6 with DEBUG defined

mORMot\RTL7\FastMM4.pas:3282

          System.RunError(reInvalidOp);
          System.RunError(Byte(reInvalidOp));

mORMot\RTL7\FastMM4.pas:3328

        System.RunError(reInvalidOp);
        System.RunError(Byte(reInvalidOp));

mORMot\RTL7\FastMM4.pas:7015

  System.RunError(reInvalidOp);
  System.RunError(Byte(reInvalidOp));
Delphi 7

mORMot\RTL7\FastMM4Options.inc

Add to the end of file to be aligned with main Synopse.inc

{$IFDEF CONDITIONALEXPRESSIONS}  // Delphi 6 or newer
  {$ifndef VER140}
    {$warn UNSAFE_CODE OFF} // Delphi for .Net does not exist any more!
    {$warn UNSAFE_TYPE OFF}
    {$warn UNSAFE_CAST OFF}
  {$endif}
{$endif}
Delphi 2009

This will also fix: https://synopse.info/fossil/tktview?name=9f87542b74 (your can close it after patch)

SynCommons.pas:5870

    procedure Lock; {$ifdef HASINLINE}inline;{$endif}
    procedure Lock; {$ifndef VER200}{$ifdef HASINLINE}inline;{$endif}{$endif}

SynCommons.pas:5879

    function TryLock: boolean; {$ifdef HASINLINE}inline;{$endif}
    function TryLock: boolean; {$ifndef VER200}{$ifdef HASINLINE}inline;{$endif}{$endif}

SynCommons.pas:5890

    procedure UnLock; {$ifdef HASINLINE}inline;{$endif}
    procedure UnLock; {$ifndef VER200}{$ifdef HASINLINE}inline;{$endif}{$endif}

mORMot.pas:2831

    function ClassType: PClassType; {$ifdef HASINLINENOTX86}inline;{$endif}
    function ClassType: PClassType;
      {$ifndef VER200}{$ifdef HASINLINENOTX86}inline;{$endif}{$endif}

mORMot.pas:2858

    function EnumBaseType: PEnumType; {$ifdef HASINLINENOTX86}inline;{$endif}
    function EnumBaseType: PEnumType;
      {$ifndef VER200}{$ifdef HASINLINENOTX86}inline;{$endif}{$endif}

mORMot.pas:2863

    function DynArrayItemType(aDataSize: PInteger=nil): PTypeInfo;
      {$ifdef HASINLINE}inline;{$endif}
    function DynArrayItemType(aDataSize: PInteger=nil): PTypeInfo;
      {$ifndef VER200}{$ifdef HASINLINE}inline;{$endif}{$endif}
Delphi 6 - Delphi 2007

SynCommons.pas:12850

{$ifdef DELPHI6OROLDER}

// define some common constants not available prior to Delphi 2009
const
  HoursPerDay   = 24;
{$IF DEFINED(FPC) OR (CompilerVersion < 20)}

// define some common constants not available prior to Delphi 2009
const
  HoursPerDay   = 24;

SynCommons.pas:12872

{$endif DELPHI6OROLDER}
{$ifend}
FPC

Extract Auto: IAutoFree variable required by Free Pascal but missed in some places.

Samples\ 30 - MVC Model

MVCModel.pas:284

  with Lock.ProtectMethod, TAutoFree.One(tag,TSQLTag.CreateAndFillPrepare(
     aRest,'order by Ident','RowID,Ident,Occurence')) do begin

MVCModel.pas:313

  with TAutoFree.Several([
     @tag,TSQLTag.CreateAndFillPrepare(aRest,'','RowID,Occurence'),
     @batch,TSQLRestBatch.Create(aRest,TSQLTag,1000)]), Lock.ProtectMethod do begin

Offline

Board footer

Powered by FluxBB