Invalid Compiler Directive: 'MESSAGES'

[Angus Robertson 574]

Looked at old compiler sources and found our InterlockedIncrement functions came from a Borland insert file, including 64-bit longint.  We only used that one function so renamed it to the modern name for use with old compilers only.  Thanks for your help

 

Angus

 

[Angus Robertson 574]

For SuperObject, try changing the UNIX defines to POSIX the the Windows stuff should go away, probably there for FPC.  And change PtrInt from Longint to Integer which should make the memory error go away. 

 

Still thinking about dates, and wondering why SO thinks dates are numeric when they are mostly ISO 8601/RFC3339 now, and ICS handles those. 

 

Angus

 

[Incus J 10]

Yes, changing PtrInt to Integer solves the 'exceeds 2GB' error.

 

I've swapped UNIX for POSIX, and made a few other adjustments here in OverbyteIcsSuperObject:

uses
 {$IFDEF RTL_NAMESPACES}System.SysUtils{$ELSE}SysUtils{$ENDIF}
 {$IFDEF POSIX}
   {,baseunix, unix}, DateUtils
 {$ELSE}
     ,{$IFDEF RTL_NAMESPACES}Winapi.Windows{$ELSE}Windows{$ENDIF}
 {$ENDIF}
 {$IFDEF FPC}
   ,sockets
 {$ELSE}
   {$IFDEF MSWINDOWS}
     ,{$IFDEF RTL_NAMESPACES}Winapi.WinSock{$ELSE}WinSock{$ENDIF}
   {$ENDIF}
 {$ENDIF}
  ;

Commented 'baseunix' and 'unix' as those units don't seem to exist.  That provides DateUtils and bypasses Winapi.Windows effectively.  

I've also wrapped Winapi.WinSock in {$IFDEF MSWINDOWS}.  Not sure whether POSIX needs some sort of sockets unit (FPC and Windows each have something here).

 

So now I'm as far as [dccosx64 Error] OverbyteIcsSuperObject.pas(1072): E2003 Undeclared identifier: 'PSystemTime'

{$IFDEF WINDOWSNT_COMPATIBILITY}
function DayLightCompareDate(const date: PSystemTime;
  const compareDate: PSystemTime): Integer;

{$DEFINE WINDOWSNT_COMPATIBILITY} occurs earlier in the same unit, on line 91 - I've temporarily wrapped that in {$IFNDEF POSIX} to bypass WindowsNT compatibility routines.  Which gets me further to:

 

[dccosx64 Error] OverbyteIcsSuperObject.pas(1292): E2003 Undeclared identifier: 'PTimeZoneInformation'

function TzSpecificLocalTimeToSystemTime(
  lpTimeZoneInformation: PTimeZoneInformation;
  lpLocalTime, lpUniversalTime: PSystemTime): BOOL; stdcall; external 'kernel32.dll';

...making progress!

Edited August 6, 2020 by Incus J

[Angus Robertson 574]

I've just removed all that old date/time handling code from Superobject, JavaToDelphiDateTime and vice versa, since recent use of Json always stores dates as ISO strings, not unix seconds.  Having hacked it so heavily, I've now adding proper TDateTime support to avoid needing those conversions in all applications.   Ready tomorrow.   It also used InterlockedIncrement just to make life interesting, but different implementation to the other units.

 

Angus

 

[Angus Robertson 574]

SVN has been updated with lots of units with changes to make them happier with DCCOSX64, can not test here so more changes may be needed.  The zip is updated at 11pm each night. Also built this version with Delphi 7, one unit was missing from SVN but only warnings, not errors. 

 

SuperObject is simplified with redundant code removed, and now supports Delphi TDateTime. 

 

Angus

 

[Incus J 10]

Thank you - I've download the updated zip and it looks very promising.  Here are the remaining stream compiler errors:

 

OverbyteIcsStreams.pas

 

[dccosx64 Error] OverbyteIcsStreams.pas(292): E2137 Method 'Read' not found in base class

function Read(var Buffer; Count: Integer): Integer; override;

 

[dccosx64 Error] OverbyteIcsStreams.pas(394): E2137 Method 'Create' not found in base class

constructor Create(const FileName : String; Mode : Word; Rights : Cardinal; BufferSize : Integer); override;

 

[dccosx64 Error] OverbyteIcsStreams.pas(990): E2037 Declaration of 'Read' differs from previous declaration

function TMultiPartFileReader.Read(var Buffer; Count: Integer): Longint;

 

[dccosx64 Error] OverbyteIcsStreams.pas(1030): E2037 Declaration of 'Write' differs from previous declaration

function TMultiPartFileReader.Write(const Buffer; Count: Integer): Longint;

 

[dccosx64 Error] OverbyteIcsStreams.pas(1149): E2037 Declaration of 'Create' differs from previous declaration

constructor TTextStream.Create(AStream : TStream; BufferSize : Integer; Style : TTextLineBreakStyle);

 

[dccosx64 Error] OverbyteIcsStreams.pas(1314): E2037 Declaration of 'Read' differs from previous declaration

function TTextStream.Read(var Buffer; Count: Integer): Longint;

 

[dccosx64 Error] OverbyteIcsStreams.pas(1322): E2037 Declaration of 'Write' differs from previous declaration

function TTextStream.Write(const Buffer; Count: Integer): Longint;

 

[dccosx64 Error] OverbyteIcsStreams.pas(1463): E2037 Declaration of 'Read' differs from previous declaration

function TIcsBufferedStream.Read(var Buffer; Count: Integer): Longint;

 

[dccosx64 Error] OverbyteIcsStreams.pas(1534): E2037 Declaration of 'Seek' differs from previous declaration

function TIcsBufferedStream.Seek(Offset: LongInt; Origin: Word): Integer;   { V8.65 was Integer }

 

[dccosx64 Error] OverbyteIcsStreams.pas(1598): E2037 Declaration of 'Write' differs from previous declaration

function TIcsBufferedStream.Write(const Buffer; Count: Integer): Longint;

 

For each of these errors, changing all occurrences of Integer in the definition to LongInt solves it.

Edited August 10, 2020 by Incus J

[Incus J 10]

OverbyteIcsZlibHigh.pas

 

[dccosx64 Error] OverbyteIcsZlibHigh.pas(385): E2033 Types of actual and formal var parameters must be identical

strm.next_out  := DMAOfStream(OutStream, strm.avail_out);

 

Changing the definition of strm.avail_out and strm.avail_in to Integer in the z_stream record (defined line 182) clears the error.  But I don't know the potential impact of that change on the record structure.

Edited August 10, 2020 by Incus J

[Incus J 10]

OverbyteIcsSuperObject.pas

 

[dccosx64 Error] OverbyteIcsSuperObject.pas(1055): E2065 Unsatisfied forward or external declaration: 'gcvt'

function gcvt(value: Double; ndigit: longint; buf: PAnsiChar): PAnsiChar; cdecl; external {$IFDEF MSWINDOWS} 'msvcrt.dll' name '_gcvt'{$ENDIF};

 

I can bypass the error by (* commenting out *) the function gcvt.  However this function is called later on in the same unit:

 

[dccosx64 Error] OverbyteIcsSuperObject.pas(1806): E2003 Undeclared identifier: 'gcvt'

Result := Append(PSOChar(SOString(gcvt(FO.c_double, 15, fbuffer))));

 

I suspect the missing function gcvt may be required to continue further.

[Angus Robertson 574]

gcvt is a Linux and Windows function to convert a floating point double to a string, it should exist, but could be replaced by Delphi Format.

 

I'll look at OverbyteIcsStreams again, but we can not used 64-bit longint, unless Classes is now also using longint instead of Int64. 

 

Not sure how much further this conversion is going, it seems LongWord is also 64-bit in MacOS64 and there are a lot of those in the OpenSSL units. 

 

Angus

 

[Incus J 10]

Yes, System.Classes.pas seems to use Longint - which could be good news:

TStream = class(TObject)	
...
    function Read(var Buffer; Count: Longint): Longint; overload; virtual;
    function Write(const Buffer; Count: Longint): Longint; overload; virtual;
    function Read(Buffer: TBytes; Offset, Count: Longint): Longint; overload; virtual;
    function Write(const Buffer: TBytes; Offset, Count: Longint): Longint; overload; virtual;

    function Read(var Buffer: TBytes; Count: Longint): Longint; overload;
    function Write(const Buffer: TBytes; Count: Longint): Longint; overload;

Maybe the ICS classes derived from TStream assume old type declarations from a previous Delphi release?  If I've understood, bringing them up to date to reflect the current System Classes TStream definitions makes the macOS compiler happy.  Speculation: Int64 is being deprecated in favour of Longint?

 

 

Edited August 10, 2020 by Incus J

[Angus Robertson 574]

OK, I'll look again, the latest TSteam class is horrible with IFDEF SizeOf, new methods with 32 and 64 extensions and dozens of overloads, out of control.

 

Any changes we make must be compatible back to Delphi 7.

 

Angus

 

[Fr0sT.Brutal 900]

http://docwiki.embarcadero.com/RADStudio/XE8/en/What's_New_in_Delphi_and_C%2B%2BBuilder_XE8#Changes_in_LongInt_and_LongWord_Size_for_64-bit_iOS_Platforms

[Angus Robertson 574]

Except we are not supporting iOS.  DCCOSX64 was introduced in 10.3.2 with brief release notes, but never mentioned in What's New.

 

Angus

 

[Fr0sT.Brutal 900]

I just thought that change would shed some light on what was done for OSX because symptoms seem similar

[Angus Robertson 574]

Indeed, I was not aware of the LongWord problem until I read the Stack Overflow synopsis of changes for 64-bit iOS, given the minimal information for MacOS64.

 

Angus

 

[Angus Robertson 574]

More units in SVN, will be zipped this evening, all the streams, SO and zlib fixes done, also OpenSSL units, wsocket and wsockets, most longword and longints gone.

 

Angus

 

[Incus J 10]

Yes!  Your changes worked!  It built successfully! 🙂

Building IcsCommonD104Run.dproj (Debug, OSX64)
[dccosx64 Warning] OverbyteIcsUtils.pas(1309): W1073 Combining signed type and unsigned 64-bit type - treated as an unsigned type
[dccosx64 Hint] H2596 ld: warning: directory not found for option '-LC:\Users\...\Documents\Embarcadero\Studio\21.0\Imports'
Success
Elapsed time: 00:00:05.8

I made just a couple of adjustments to get it to build:

 

[dccosx64 Error] OverbyteIcsStreams.pas(298): E2137 Method 'Write' not found in base class

function Write(const Buffer; Count: Integer): Integer; override;

To solve, I changed the two Integer to Longint

 

[dccosx64 Fatal Error] OverbyteIcsTicks64.pas(111): F2613 Unit 'Windows' not found.

uses Windows, SysUtils;

This unit seems Windows specific, so in IcsCommonD104Run.dproj I wrapped it in an {$IFDEF} :

{$IFDEF MSWINDOWS}
OverbyteIcsTicks64 in '..\Source\OverbyteIcsTicks64.pas',
{$ENDIF}

I haven't gone any further yet - just wanted to let you know it built successfully.

Edited August 14, 2020 by Incus J

[Angus Robertson 574]

Excellent, I'll be even happier when you manage to make an SSL connection somewhere, although I've no idea if any the FMX samples still work, never looked at them. 

 

Just about to put more stuff into SVN so will do these changes.   GetTickCount64 is only used in samples at the moment, system seems to provide 32-bit versions for Posix but not 64-bit.

 

Angus

 

[Incus J 10]

In D104InstallVclFmx.groupproj the Design packages (e.g. IcsCommonD104Design.bpl IcsFmxD104Design.bpl) have a single Windows 32-bit Target Platform.  That makes sense I think because the Delphi IDE is 32-bit only (?)

 

In contrast the Common Runtime package IcsCommonD104Run.bpl has three Target Platforms available: Windows 32-bit, Windows 64-bit and macOS 64-bit.

 

The other Runtime packages (IcsVclD104Run.bpl IcsFmxD104Run.bpl) have two Target Platforms: Windows 32-bit and Windows 64-bit.  Should IcsFmxD104Run also have a third macOS 64-bit Target Platform assigned?  If yes, I can add it.

 

Almost all the units in IcsFmxD104Run, except two, seem to simply include other common units, like this:

unit Ics.Fmx.OverbyteIcsFtpCli;
{$DEFINE FMX}
{$DEFINE ICS_INCLUDE_MODE}
{$I OverbyteIcsFtpCli.pas}

So perhaps it doesn't matter, since those common units are already built for macOS via IcsCommonD104Run.bpl.  The two exceptions are Ics.Fmx.OverbyteIcsCharsetComboBox and Ics.Posix.Messages - at present these two units may not be being built for macOS when installing, and Ics.Posix.Messages is probably important for macOS.

Edited August 14, 2020 by Incus J

[Angus Robertson 574]

My live 10.4 design packages only have Win32 target, I'll have to double check if master is the same, it should be, 

 

I can not add Mac platforms from the IDE,  despite having the compiler installed, I'll try hacking the XML. Still can not build since I can not create a connection profile.  Though we had MacOS targets before because others have used it okay, so perhaps Delphi deletes them if I modify the package. 

 

Angus

 

[Angus Robertson 574]

All now in SVN, last for this week, OSX32 targets seem to disappear in 10.4 so I guess are now dead. 

 

Angus

 

[Incus J 10]

Thanks Angus.

 

macOS went 64-bit in 2005, but still continued to support 32-bit software until recently.  I guess since Macs from the last 15 years support 64-bit, introduction of the macOS 64-bit compiler makes the OSX32 compiler redundant.

 

I've had a try building one of the ICS FMX samples relating to HTTP.  At the moment I'm seeing a couple of compiler errors in Ics.Posix.Messages relating to a missing InterlockedExchange function - will post if I can't resolve.

[Angus Robertson 574]

I changed all the old InterlockedIncrement to AtomicIncrement, but seems I missed InterlockedExchange which has now gone, Not sure of the modern replacement for InterlockedExchang, hopefully someone watching will know immediately. 

 

I've not done the GetTickCount64 stuff yet, the 10.4 runtime has various ticks functions for different platforms, just lots of new conditionals so it works on all platforms. 

 

Angus

 

[Angus Robertson 574]

Change InterlockedExchangePointer to TInterlocked.Exchange, and InterlockedExchangeAdd to TInterlocked.Add, then add System.SyncObjs,to Uses and you should get a little further.

 

Angus

 

[Incus J 10]

Thank you, that helped!

 

There were also a couple of InterlockedExchangeDecrement calls that I’ve swapped for TInterlocked.Decrement

System.SyncObjs is already declared in the main uses clause, so I didn’t have to add that one.

 

I’ve also changed line 56 of Ics.Posix.Messages from IFNDEF to IFDEF:

{$IFDEF MSWINDOWS }
  {$MESSAGE Fatal 'This unit should not be included in a Windows project. Make sure you use Winapi.Messages instead'}
{$ENDIF}

 

[dccosx64 Fatal Error] OverbyteIcsWndControl.pas(153): F2613 Unit 'Vcl.Forms' not found.

{$IFNDEF NOFORMS}
  {$IFDEF FMX}
    FMX.Forms,
  {$ELSE}
    {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF},
  {$ENDIF}
{$ENDIF}

I’m a little unsure here.  IcsHttpsTst1 appears to be an FMX project.  But the compiler is trying to add Vcl.Forms, so I suspect ‘FMX’ is not a predefined conditional, at least I haven’t spotted it here:

 

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Conditional_compilation_(Delphi)#Predefined_Constants

 

Does Delphi have a mechanism to conditionally compile VCL vs FMX?  I guess it must have one, but I haven’t found it yet.