Invalid Compiler Directive: 'MESSAGES'

[Lars Fosdal 1792]

If you need VCL/FMX conditions in your own code, this works:
 

{$DEFINE HAS_VCL}
{$IF DECLARED(FireMonkeyVersion) and (FireMonkeyVersion >= 16.0)}
  {$UNDEF HAS_VCL}
  {$DEFINE HAS_FMX}
{$IFEND}

 

[Incus J 10]

Thanks Lars - I've tried this approach but haven't got it to work as yet.  FireMonkeyVersion does not seem to be defined at present - perhaps it is defined in a unit that is not currently used in the project?

{$IFNDEF NOFORMS}
  {$IF DECLARED(FireMonkeyVersion) and (FireMonkeyVersion >= 16.0)}
    FMX.Forms,
  {$ELSE}
    {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF},
  {$ENDIF}
{$ENDIF}

When I build the project in Delphi 10.4, the compiler ends up at Vcl.Forms which seems a bit odd:

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

 

I've found the following in the FMX.Types unit:

{$HPPEMIT '#define FireMonkeyVersion 270'}
  FireMonkeyVersion = 270;
{$EXTERNALSYM FireMonkeyVersion}

FMX.Types is present in the uses clause of both the project .dpr file, and the main form .pas file.  I must be doing something wrong here.

Edited August 19, 2020 by Incus J

[Angus Robertson 574]

I built all the ICS FMX sample projects OK yesterday using the XSamples group, for Windows only, IcsHttpsTst worked fine with SSL once I copied the latest DLLs into that directory.  Two server samples need minor fixes that were made to VCL ages ago but forgot FMX, and StrokeThickness has disappeared from Bitmap.Canvas,

 

IcsHttpsTst is a little basic compared to the VCL version, need to add more SSL stuff. 

 

I'll look at the other Interlocked stuff, one problem is these are also Windows APIs so removing them from the ICS unit does not stop units building if they also include Winapi.Windows.

 

Angus

 

[Incus J 10]

Thanks Angus - I can also confirm IcsHttpsTst builds successfully here for Win32.

 

Since I know that the project IcsHttpsTst really is FMX, I have defined 'FMX' manually in the Project Options > Delphi Compiler > Conditional defines.  A workaround just so {$IFDEF FMX} code compiles - to progress a bit further on macOS 64-bit.

[Lars Fosdal 1792]

22 minutes ago, Incus J said:

Thanks Lars - I've tried this approach but haven't got it to work as yet.  FireMonkeyVersion does not seem to be defined at present - perhaps it is defined in a unit that is not currently used in the project?

It was based on this: https://stackoverflow.com/questions/12788870/conditionally-compile-units-for-fmx-or-vcl

I never mix VCL and FMX form code in projects myself, but I guess the problem here is that the "defined" depends on FMX.Types already being in scope. 

My approach would probably be to use an interface or a proxy class to hide the actual VCL/FMX accesses.

[Angus Robertson 574]

ICS defines FMX at the top of all Ics.Fmx.xx units, which are built by the FMX runtime package.  But I guess should also be in any FMX projects that include other units that are VCL/FMX.  

 

Angus

 

[Incus J 10]

Thanks Lars and Angus.  That makes sense.  So if I've understood, defining 'FMX' manually in the Project Options Conditional Defines is likely a reasonable way to go here (for IcsHttpsTst).

 

(Side note: Interesting that OverbyteIcsWndControl.pas compiled OK for FMX Win32, presumably even without 'FMX' defined.  Maybe it pulled in Vcl.Forms too but being a Windows platform was able to continue compiling without FMX.Forms in this particular case:)

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

 

Edited August 19, 2020 by Incus J

[Angus Robertson 574]

The magic is:

 

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

which is how FMX gets defined and all the units get then built for FMX or VCL.   Not sure how VCL.Forms is being dragged in. 

 

Angus

 

[Incus J 10]

Quote

Not sure how VCL.Forms is being dragged in

I'm not sure either - maybe the sample app references the OverbyteIcsWndControl unit directly somehow (instead of via Ics.Fmx.OverbyteIcsWndControl) - skipping the magic {$DEFINE FMX}.  OK I've got a little further:

 

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

Count := f_BIO_read_ex(FSslbio, @Dummy, 0, ReadBytes);     { V8.51 new in 1.1.1 }

 

ReadBytes is a var parameter, of type size_t on line 21668.

ReadBytes         : size_t;  { V8.51 }

    

OverbyteIcsTypes size_t is likely a UInt64:

{ V8.65 MacOS64 seems to be missing size_t }
{$IFDEF POSIX}
  {$IFDEF CPUX64}
    size_t                    = UInt64;
  {$ELSE}
    size_t                    = LongWord;
  {$ENDIF}
    Psize_t                   = ^size_t;
{$ENDIF POSIX}

However OverbyteIcsLibEAY f_BIO_read_ex references size_t in Posix.SysTypes:

size_t = Posix.StdDef.size_t;

…which is LongWord not UInt64.

 

To progress I’ve changed CPUX64 size_t to LongWord in OverbyteIcsTypes.

[Incus J 10]

Next up is:

 

[dccosx64 Error] OverbyteIcsHttpProt.pas(847): E2003 Undeclared identifier: 'TNtlmAuthSession'

{$IFDEF UseNTLMAuthentication}  FAuthNtlmSession : TNtlmAuthSession;  // V8.61 OAS

 

TNtlmAuthSession is defined in unit OverbyteIcsNtlmSsp - but it is wrapped in {$IFDEF MSWINDOWS} and a quick Google search suggests NT LAN Manager authentication, perhaps intended for Windows only (?).  Though it is in THttpCli rather than a server component.

[Angus Robertson 574]

OK, did not know about Posix.SysTypes which is what should have included rather than adding size_t to our types unit.  Can you please remove that block of Posix code from OverbyteIcsTypes and see how manu units need Posix.SysType adding?  

 

NTLM is used in both clients and servers, but should not used for Posix, I'll look at it.  

 

BTW, I've just got a need VCL.Forms unit error building the FMX package, did not see that last time I built it so must have added something horrible in the last day or two. 

 

Angus

[Fr0sT.Brutal 900]

Btw, most of non-Windows code could be checked for buildability with Linux target (unless it's Mac-specific of course). This will require only a running instance of any Linux.

[Angus Robertson 574]

Yes, when Delphi first got Linux as a target I did try to create a Linux VM, but I've at this stuff so long I really do not have the energy to learn much new, and in particular another command line language, so I never got Linux working.  At the time it did not support AnsiString so would not have got very far anyway.  You'd have thought a Hyper-V disk of a working Linux OS would be easy to find, but no, they wanted you to start from scratch. 

 

Angus

 

[Angus Robertson 574]

SVN is updated again with (I hope) all the MacOS fixes reported here, including fixing some FMX samples so they build again.  Will be zipped overnight. 

 

Angus

[Fr0sT.Brutal 900]

1 hour ago, Angus Robertson said:

Yes, when Delphi first got Linux as a target I did try to create a Linux VM, but I've at this stuff so long I really do not have the energy to learn much new, and in particular another command line language, so I never got Linux working.  At the time it did not support AnsiString so would not have got very far anyway.  You'd have thought a Hyper-V disk of a working Linux OS would be easy to find, but no, they wanted you to start from scratch. 

Things got much easier since then, I recently successfully compiled my DLL on Linux with Rio. Almost no command line, just copy PAServer and launch it. Emba even has Docker image with PAServer for those who are familiar with it

[Incus J 10]

On 8/21/2020 at 3:40 PM, Angus Robertson said:

SVN is updated again with (I hope) all the MacOS fixes reported here, including fixing some FMX samples

Thanks Angus - I've downloaded the overnight zip and will give it a try.

 

I have Linux Mint in a VM, but only the Pro version of Delphi 10.4 which (I think) lacks the Linux target.

Edited August 25, 2020 by Incus J

[Incus J 10]

Yes, I can confirm the macOS fixes are present.  Just a couple of minor tweaks before moving forward:

 

Line 89 of IcsCommonD104Run project file, I've included the ticks64 unit for Windows only:

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

 

[dccosx64 Error] Ics.Posix.Messages.pas(73): E2004 Identifier redeclared: 'System.SyncObjs'

System.SyncObjs,  { V8.65 }

No problem - I just comment out the second declaration.

 

[dccosx64 Error] Ics.Posix.Messages.pas(1965): E2003 Undeclared identifier: 'InterlockedDecrement'

InterlockedDecrement(FSentinel);

Solved by changing to TInterlocked.Decrement(FSentinel).

 

With those in place the package builds successfully.

Edited August 27, 2020 by Incus J

[Incus J 10]

Moving on to the FMX IcsHttpsTst sample application.

 

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

{$IFNDEF NOFORMS}

  {$IFDEF FMX}

    FMX.Forms,

  {$ELSE}

    {$IFDEF RTL_NAMESPACES}Vcl.Forms{$ELSE}Forms{$ENDIF},

  {$ENDIF}

{$ENDIF}

 

Although this is an FMX project, it is pulling in Vcl units.  The magic {$DEFINE FMX} is bypassed, maybe because the main form currently references OverbyteIcs--- internal units directly, like this (IcsHttpsTst1.pas, line 95):

  OverbyteIcsWndControl,
  OverbyteIcsWSocket,
  OverbyteIcsLIBEAY,
  OverbyteIcsSsLeay,
  OverbyteIcsSslSessionCache,
  OverbyteIcsLogger,
  OverbyteIcsIniFiles,
  OverbyteIcsUtils,
{$IFDEF USE_MODEZ}              { V2.102 }
  OverbyteIcsHttpCCodZLib,
{$ENDIF}
  OverbyteIcsHttpProt, OverbyteIcsCookies, FMX.Memo.Types,

Perhaps this list of units should be prefixed for FMX? e.g. Ics.Fmx.OverbyteIcsWndControl

Would that allow {$DEFINE FMX} to be parsed, so Vcl units are not included?  This is speculation, as I don't have in depth knowledge of the project.

 

[dccosx64 Error] IcsHttpsTst1.pas(884): E2010 Incompatible types: 'OverbyteIcsWSocket.TX509List' and 'Ics.Fmx.OverbyteIcsWSocket.TX509List'

{ Property SslCertChain contains all certificates in current verify chain }

    CertChain := HttpCli.CtrlSocket.SslCertChain;

Edited August 27, 2020 by Incus J

[Incus J 10]

Good news:  If I edit the list of units in IcsHttpsTst1.pas as follows, the application builds successfully for macOS 64-bit 🙂

  Ics.Fmx.OverbyteIcsWndControl,
  Ics.Fmx.OverbyteIcsWSocket,
  OverbyteIcsLIBEAY,
  OverbyteIcsSsLeay,
  Ics.Fmx.OverbyteIcsSslSessionCache,
  OverbyteIcsLogger,
  OverbyteIcsIniFiles,
  OverbyteIcsUtils,
{$IFDEF USE_MODEZ}              { V2.102 }
  OverbyteIcsHttpCCodZLib,
{$ENDIF}
  OverbyteIcsHttpProt, OverbyteIcsCookies, FMX.Memo.Types,
  FMX.Controls.Presentation, FMX.ScrollBox;

Basically I just added a few Ics.Fmx prefixes, which seems to avoid Vcl conflicts.

Building IcsHttpsTst.dproj (Debug, OSX64)
[dccosx64 Warning] OverbyteIcsUtils.pas(1309): W1073 Combining signed type and unsigned 64-bit type - treated as an unsigned type
[dccosx64 Hint] OverbyteIcsWSocket.pas(10705): H2164 Variable 'phe' is declared but never used in 'LocalIPList'
[dccosx64 Hint] OverbyteIcsWSocket.pas(24464): H2077 Value assigned to 'TIcsEventQueue.HandleEvents' never used
[dccosx64 Hint] OverbyteIcsWSocket.pas(24491): H2077 Value assigned to 'TIcsEventQueue.HandleEvents' never used
[dccosx64 Warning] OverbyteIcsWSocket.pas(24703): W1057 Implicit string cast from 'AnsiString' to 'string'
[dccosx64 Hint] OverbyteIcsCookies.pas(669): H2443 Inline function 'DeleteFile' has not been expanded because unit 'Posix.Unistd' is not specified in USES list
[dccosx64 Hint] H2596 ld: warning: directory not found for option '-LC:\Users\(User)\Documents\Embarcadero\Studio\21.0\Imports'
Success
Elapsed time: 00:00:10.0

 

Edited August 27, 2020 by Incus J

[Angus Robertson 574]

If you have seen the more recent topic on Linux here, I've managed to get a Linux VM running so can now build packages for Linux 64 bit. which is closer to MacOS than Windows. 

 

Making some changes today, I've managed to build the IcsCommonD104Run package for Linux, including OverbyteIcsTicks64. But am now stuck building IcsFmxD104 for Linux, with 'Required package 'fmx' not found'.  Attempting to check paths in Project Options quickly gets 'invalid value for CFBundleVersion' which seems to relate to Apple platforms which I'm not building, nor can I set MacOS version information.

 

I was wondering about those missing Ics.Fmx prefixes, but all this MacOS stuff was written by another developer who is no longer with us,  so can not ask.  I assume it all worked many years when he tested it, but we are now many Delphi versions later and it seems we do need to change all those uses names. 

 

Angus

[Incus J 10]

2 hours ago, Angus Robertson said:

Attempting to check paths in Project Options quickly gets 'invalid value for CFBundleVersion'

I encountered this small issue with Project Options too.  I don't know the cause, but I worked around it by switching the Platform Target to Win32 temporarily, before opening the Project Options dialog.  Then afterwards switched the Target Platform back to macOS 64-bit after closing the Options dialog.  There is a CFBundleVersion field in the options 'Version Info' section, which looks to be set to a value of 1.0.0 (that sounds a reasonable value).

 

I am really encouraged that the IcsCommonD104Run package now builds successfully, and the FMX IcsHttpsTst sample application also builds successfully.  Getting these two to build successfully feels like a significant step forward - thank you.

[Angus Robertson 574]

SVN is up to date with my changes yesterday, but won't be doing any more until middle of next week.   I did try changing the platform to Win32 but still got the Options error, not having  MacOS PAServer might be a problem. 

 

Angus

[Angus Robertson 574]

Seems 'Required package 'fmx' not found' really means that Delphi for Linux does not support FMX, no GUI applications.  Or at least until you install FMXLinux using Getit. 

 

Angus

 

[Fr0sT.Brutal 900]

21 hours ago, Angus Robertson said:

Seems 'Required package 'fmx' not found' really means that Delphi for Linux does not support FMX, no GUI applications.  Or at least until you install FMXLinux using Getit.

It seems so

Quote

Enterprise and Architect Edition customers can take advantage of FMXLinux integration for building Linux GUI applications.

http://docwiki.embarcadero.com/RADStudio/Sydney/en/What's_New#Key_FireMonkey_Platform_Enhancements

[Angus Robertson 574]

SVN and the overnight zip have many updated units with Posix support, most of the changes are in new units I've added or things I'd changed over the years.  Some Posix is TODO, particularly ICMP/ping, ShellExec and some Windows specific file operations in OverbyteIcsFileCopy.

 

But these changes allow the ICS FMX packages to build for the Linux 64-bit platform, and hopefully the MacOS64 platform.

 

There is a new package IcsLinuxD104 that I'm able to build without errors, just a few hints and TODOs although final compile fails probably because I'm using an unsupported Ubuntu version.   This all needs FMXLinux
installed first and you will get 79 FMX units implicitly imported into the package, because FMXLinux does not have a package, or I can not find it. 

The main work needed is the message pump and timer support, the current implementation is MacOS specific using Apple libraries. I believe FMXLinux probably includes replacements, but it is undocumented and little source code, and without being able to build Linux applications not going to try. We have an ancient ICS version built for Kylix with a message handler that could be used, but my knowledge of Linux is zero so someone else will need to make a decision and finish the Linux implementation.  Hopefully not too much effort.

 

Angus