Incus J

I think FMX renders its UI to a surface/canvas, rather than having the OS render the controls (?) - so yes, it could be different. This is where the IcsHttpsTst seems to get stuck at startup: Line 1962 of Ics.Posix.Messages function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean; var Thread: PThreadInfo; HasReadLock: Boolean; ThreadID: Cardinal; Test: Integer; OldRevisionLevel: Cardinal; begin ... ThreadID := GetCurrentThreadID; The top of the call stack looks like this : :000000010001D0F0 System::_DbgExcNotify(int, void*, System::SmallString<(unsigned char)255>*, void*, void*) :000000010001D12E System::NotifyReRaise(System::TObject*, void*) :000000010001D1CA System::_RaiseAtExcept(System::TObject*, void*) :0000000100056AB8 System::Sysutils::ErrorHandler(unsigned char, void*) :0000000100015F30 System::ErrorAt(unsigned char, void*) :000000010001B252 System::_BoundErr() Ics.Posix.Messages.TMultiReadExclusiveWriteSynchronizer.BeginWrite()(0x0000000102521120) Ics.Posix.Messages.TIcsMessagePump.AfterConstruction()(0x000000020245bd80) :0000000100016B45 System::_AfterConstruction(System::TObject*) :0000000100011443 System::TObject::TObject() Ics.Fmx.Overbyteicswndcontrol.TIcsWndControl.AllocateHWnd()(0x0000000203080ff0) Ics.Fmx.Overbyteicshttpprot.THttpCli.THttpCli(System.Classes.TComponent*)(0x0000000203080ff0,true,0x000000020801e5f0) ... Maybe that contains useful information. On Posix, the System unit defines: TThreadID = NativeUInt; But local var ThreadID is Cardinal. Maybe Cardinal and NativeUInt are not compatible. If I redefine ThreadID as a NativeUInt too, then the ERangeError disappears, and the app is "[Running]" - but the UI does not appear. I think Thread #1 might be waiting for something.

I remember back in Delphi 10.2 Tokyo FMX ProcessMessages seemed to behave differently to VCL ProcessMessages. With VCL I can call ProcessMessages and any queued mouse clicks are processed. With FMX I found that a call to ProcessMessages did not process queued mouse clicks. It was as though FMX UI events were handled separately. I don't know whether this is still the case.

That sounds good. I've just tested the latest overnight zip, and D104InstallVclFmx builds successfully for macOS 64-bit. The sample app IcsHttpsTst builds successfully by adding the Ics.Fmx. prefix to a few IcsHttpTst1.pas uses units. When the sample app deploys and runs on macOS 64-bit I get an ERangeError "Range check error" at runtime. I think it occurs in Ics.Posix.Messages.pas but the IDE debugger can't find that unit, so I'm not sure. I must need to tell the IDE/Debugger the path to the ICS source units so it can step into them - but I'm not sure how to do this. The Delphi compiler already knows where the source units are, because the app builds and deploys OK, but the IDE itself seems unaware at the moment.

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.

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

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;

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.

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.

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.

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.

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}

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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!

Sounds good. In z_stream I've redefined strm.avail_out (and also strm.avail_in) from LongInt to Integer to get a bit further. Good news is your InterlockedIncrement suggestion worked, with a small adjustment: function InterlockedIncrement(var Addend: Integer): LongInt; I defined Addend as Integer, because routines that call this function pass in an Integer parameter. Integer seems a better fit here, TInterlocked.Increment has overloaded versions for Integer and Int64, but not LongInt. [dccosx64 Error] OverbyteIcsSuperObject.pas(278): E2100 Data type too large: exceeds 2 GB TSuperObjectArray = array[0..(high(PtrInt) div sizeof(TSuperObject))-1] of ISuperObject; [dccosx64 Fatal Error] OverbyteIcsSuperObject.pas(859): F2613 Unit 'Winapi.Windows' not found. uses {$IFDEF RTL_NAMESPACES}System.SysUtils,{$ELSE}SysUtils,{$ENDIF} {$IFDEF UNIX} baseunix, unix, DateUtils {$ELSE} {$IFDEF RTL_NAMESPACES}Winapi.Windows{$ELSE}Windows{$ENDIF} {$ENDIF} {$IFDEF FPC} ,sockets {$ELSE} ,{$IFDEF RTL_NAMESPACES}Winapi.WinSock{$ELSE}WinSock{$ENDIF} {$ENDIF} ; I have bypassed the two Winapi statements using {$IFDEF MSWINDOWS}. This unit performs calculations with dates and times, and seems to use Winapi to do this: [dccosx64 Error] OverbyteIcsSuperObject.pas(1074): E2003 Undeclared identifier: 'PSystemTime' [dccosx64 Error] OverbyteIcsSuperObject.pas(1075): E2005 'PSystemTime' is not a type identifier [dccosx64 Error] OverbyteIcsSuperObject.pas(1080): E2017 Pointer type required [dccosx64 Error] OverbyteIcsSuperObject.pas(1122): E2003 Undeclared identifier: 'PTimeZoneInformation' [dccosx64 Error] OverbyteIcsSuperObject.pas(1123): E2003 Undeclared identifier: 'PFileTime' [dccosx64 Error] OverbyteIcsSuperObject.pas(1128): E2003 Undeclared identifier: 'TSystemTime' [dccosx64 Error] OverbyteIcsSuperObject.pas(1129): E2003 Undeclared identifier: 'TFileTime' [dccosx64 Error] OverbyteIcsSuperObject.pas(1146): E2003 Undeclared identifier: 'TIME_ZONE_ID_INVALID' [dccosx64 Error] OverbyteIcsSuperObject.pas(1158): E2003 Undeclared identifier: 'FileTimeToSystemTime'

Thanks Angus, David That solved size_t OK. [dccosx64 Warning] OverbyteIcsUtils.pas(1304): W1073 Combining signed type and unsigned 64-bit type - treated as an unsigned type Result := Int64(Buf.f_bfree) * Buf.f_frsize I’ve ignored this warning for now, but I could cast to Int64(Buf.f_frsize) ? [dccosx64 Error] OverbyteIcsZlibHigh.pas(385): E2033 Types of actual and formal var parameters must be identical strm.next_out := DMAOfStream(OutStream, strm.avail_out); DMAOfStream defines parameter out Available as Integer. However strm.avail_out, part of a record, z_stream, is LongInt. To continue I redefine DMAOfStream to use a LongInt parameter, rather than mess with the size of the z_stream record structure that might be populated from a disk buffer (?) …but doing that causes: [dccosx64 Error] OverbyteIcsZlibHigh.pas(309): E2033 Types of actual and formal var parameters must be identical BackObj.InMem := DMAOfStream(InStream, BackObj.InMemSize); Again, DMAOfStream, but now the situation is reversed, InMemSize is defined as Integer, and the redefined DMAOfStream requires LongInt. So I might try redefining strm.avail_out from LongInt to Integer instead, and hope that doesn't damage the size of the z_stream record structure.

OK - I've removed the unused Endian function. Next up is: [dccosx64 Error] OverbyteIcsSSLEAY.pas(2105): E2003 Undeclared identifier: 'size_t' f_SSL_bytes_to_cipher_list : function(s: PSSL; cbytes: PAnsiChar; len: size_t; isv2format: Boolean; var sk: PSTACK_OF_SSL_CIPHER; var scvsvs: PSTACK_OF_SSL_CIPHER): LongInt; cdecl = nil; { V8.64 } size_t is defined as a UInt64 or LongWord on line 85 and 87 of OverbyteIcsTypes.pas - but only for MSWINDOWS. There are quite a few nested IFDEFs here, so I need to be careful making any modification. 75 megs does sound like luxury, compared to 48K of RAM and compact cassette for storage.