Angus Robertson

Followed up in the correct ICS group. Angus

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

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

That would make sense, except the 10.4 help says System.AtomicIncrement is only in mobile compilers, AtomicIncrement on it's own is not mentioned. In which version was it added? Angus

A lot of that SuperObject date handling code, like time zones and system time, duplicates stuff elsewhere in ICS and can be probably be removed to save space and simplicity. I was adding new functions to SuperObject last month, so may as well remove some as well. Probably not today, like to test SO properly. Angus

Lets worry about warnings once all the errors have gone, I changed dozens of integers to longint in streams so there may be more warnings to come. I'll put my changed units in SVN later today. Not touched zlib for many years, keep meaning to update to a newer version. I'll have a look later. Angus

For the InterlockedIncrement asm issue, add this to the top of Ics.InterlockedApi.inc: {$IFDEF COMPILER23_UP} function InterlockedIncrement(var Addend: LongInt): LongInt; begin Result := TInterlocked.Increment(Addend); end; {$ELSE} (and a closing endif at the end). OverbyteIcsWSocket and OverbyteIcsUtils both need the suppressed PUREPASCAL define replaced with: {$IFDEF MACOS} {$DEFINE PUREPASCAL} {$ENDIF} These should get your compile a little further. Angus

For the missing size_t, try adding this to types: {$IFDEF POSIX} {$IFDEF CPUX64} size_t = UInt64; {$ELSE} size_t = LongWord; {$ENDIF} Psize_t = ^size_t; {$ENDIF POSIX} Not sure if the 32-bit line is necessary, seems strange MacOS did not give an error if it was missing. Angus

Thanks, done most of your changes, don't worry about MacOS32 if it is now dead. The Wang Z80 development environment was luxury compared to CP/M PCs at the time, it originally had CDC 14in platter disk drives with 75 or 300 megs of storage and used the Intel PL/M language (which CP/M was also written in). Angus

Side tracking slightly, what was the last ICS version you successfully built with MacOS32? I believe V8.62 at least was successful for MacOS from reports here. While I understand the ASM problems, not sure why all these LongInt problems are happening when Win64 is happy. In CRC, function Endian can be killed, no longer used, don't think it worked anyway. Might be better to wait until you have found all the compiler errors before sending anything, but I'm quite happy to update as you report them. Angus

Sorry, can not help with InterlockedIncrement, that code was written by a developer that is no longer with us, and appears to be using some CPU feature for a few functions like Posix.Messages, TIcsThreadTimer and web sessions, The last assembler I wrote was Z80 for Wang Word Processing, over 30 years ago. Hopefully some watching here might have a clue what this interlocking is all about? Angus

Have you built and installed the three packages for FMX without any more errors. That is the most important and useful test. Ideally from the overnight zip, but there will be more changes before the next release. Angus

I've fixed the $MESSAGE issue, I added that but it is not tested by building FMX packages. PUREPASCAL was defined OverbyteIcsUtils.pas for CPUX64 but is currently suppressed since we now have the necessary assembler. I'll set it for MacOS64 I've fixed the AddSorted mismatch, does not show up under Win64. Please let me know of any other MacOS errors you find, I can not test this since I don't have any Mac hardware. Won't be in SVN for a few days. Angus

There are several httperr constants in OverbyteIcsHttpProt,pas that reflect the operation result, httperrNoError = 0 being the most common result. There are no literals for these constants. Angus

My main problem with .net and D2007 is that every time I install a new version of Windows (twice a year with 10), Microsoft deletes the four Borland.x.Targets files it installs under \Microsoft.Net\, but learnt my lesson a long time ago and keep copies to restore. Angus

In general, ICS servers will support a few hundred clients doing simple downloads or uploads, before threads are needed to use multiple CPUs. That may change if ARM based server chips appear with dozens of lower spec cores than current Xeon chips with just a few cores (unless you pay silly money). Only think about threads when it slows down. Angus

I've never looked at the OverbyteIcsThrdSrvV2 sample so can not comment on, I'd only say don't use a thread unless you really need it. Making HTTP requests with GET and POST are asynchronous so are not blocking your client unless you need many milliseconds of processor time to read through hundreds of megs of response. Threads are sometimes needed for database access to process large query results, but my own database driven web server does not yet need threads for it's load, SQL queries usually only take 50ms or less. Angus

Beware that TWSocketThrdServer has not been updated or tested for over 10 years, and specifically not with the latest OpenSSL which changed the way thread locking works. Nor does it have any of the many new features in TWSocketServer. You may be better off retaining TWSocketServer and only starting a thread if you expect a long query, which is how TFtpServer works, look at Client.ProcessingThread which is used for processor heavy functions. Really do need to bring TWSocketThrdServer up to date, but very few people need it. Angus

The ICS version of superobject now reports 'Error teDepth at line 1 column 6067 at depth 31' for the Json block, little more useful than nil result. The information is all there internally, just not reported. Not in SVN yet. Angus

Thanks, I shall update the superobject included with ICS appropriately. I did try the Json file on two web site parsers yesterday, one worked, one failed with an error but did not mention object depth, ran out of time to look further. Angus

Did you see any downside to increasing SUPER_TOKENER_MAX_DEPTH. does it require more memory for every parse or something? Really need a way for tok.err to be exposed on failure, it's frustrating when superobject just fails for no obvious reason, although usually badly formatted json. Angus

Look in the TIcsFtpMulti component to see how it logs using the OnResponse and OnDisplayFile. events. As Francois suggests, you can build the OverbyteIcsXferTst sample that uses that component, check it yourself, then get your client to transfer the same file on their system with it, to see if it fails. How large or small is this file? The sample creates a log file. Angus

Someone else mentioned a similar bug recently, but can not find the message. I fixed a bug calculating the speed of zero second FTP transfers 15 years ago that resulted in a similar error, but this would not happen with more recent releases. ICS does have a n TicsLogger component that developers can add to their applications, but it is primarily for internal debugging of SSL applications, older components needed to be updated to log events and that was never done consistently. Newer components like TIcsFtpMulti and TSslHttpRest have ProgressEvent or OnHttpRestProg events, and LogLevel or DebugLevel properties that can be used for screen display and file logging. If you continue using the older TFtpCli component you will need to add logging the onFtpClientDisplay and OnFtpResponse events to log the FTP protocol commands and responses so you can see at which point the error is happening. Angus

If you mean you only want to accept LAN connections on port 80 or something, you can can do as you suggest, but this is irrelevant to SSL/TLS. It is quite normal nowadays to respond with a redirection to the correct HTTPS URL. Angus

Try building and running the sample OverbyteIcsMailQuTst.dpr in .\Samples\delphi\sslinternet\ and see if you get an error sending emails. This is now the recommended way for sending SMTP emails, it tries multiple SMTP servers with attempts over several days to ensure email is sent. Angus