FPiette

Maybe there is a conditional compilation ($IF...) which hide the declaration? When you Ctrl-Right-Click on the offending FList, the IDE should move the caret to FList declaration, if he can find it. The error about FList is not the first error. Maybe the compiler is confused by PREVIOUS error. Always resolve the errors in the order the compiler encounter them. Another check you can do: create a manifest syntax error in TIcsIntegerList = class(TObject) and recompile. If the error is not seen, that means the compiler don't see the declaration, probably because of some conditional compilation. Another check you can do: move all TIcsIntegerList class code to a new unit, use that unit in a trivial test program and compile.

The error comes from the post build commands (A kind of batch file). Maybe some Windows permission issue ?

Show the declaration.

This is very clear: FList is not defined in TIcsIntegerList. So look FList at your class declaration, it is missing. Why ? I don't know because I don't have your modified code. Don't take offense, but if you can solve such a simple error, I doubt you can port ICS to mobile platform. Those symbols are defined in Posix.SysStatvfs.pas unit. Check that. By the way, which platform do you use? Android or Apple?

Those line numbers are useless for me. As I already said, publish the code around the error you get. That's where you have to start. I gave the URL for TWSocket, but there are already a bunch of files. Did you had a look at everything? The last thing to do is to take the whole ICS and try to rebuilt it. You'll need YEARS to to that. Start with the basis: TWSocket and then higher level components. Embarcadero wants you to use latest feature. Generics are wonderful, but don't spend time on converting perfectly working code. You'll do that at the last stage. That is perfect. The path to the port is the inheritance chain for the components you need. At the lowest level, there is TWSocket. Start by TWSocket I made for Linux (Work in progress anyway) and write some basic application to test your code. This is a bottom to top way of programming.

It takes some time to scan all files and folders recursively but 15 minutes is way to much. One thing that slow down the process is the display on the user interface for each fil found, one by one. You'd better load the list in a TStringList or other structure suitable to your application without displaying anything. And then if required display all files. If you display in a TMemo, use TMemo BeginUpdate/EndUpdate so that the UI is not updated while the lines are added. And note that it is not useful to fill any screen with hundreds of filename but that is another discussion.

To help help for command prompt (There is no more DOS and all), type this: dir /? If you want to do it with Delphi code, look at Delphi documentation about finding files.

IMO, you don't need to change TIcsIntegerList to work on another platform. TList exists on all platforms, isn't it? You should publish what you have on the lines around the error because we don't necessarily have the exact same source code as you have. Here on line 5933, I have the closing end of constructor TIcsFileStreamW.Create. The real difficulty in porting ICS to mobile platform is to replace Windows stuff that is used in ICS code. Mainly everything related to messages. ICS make heavily use of Windows messaging system (https://learn.microsoft.com/en-us/windows/win32/winmsg/windowing) which doesn't exists at all on the mobile platform and must be replaced by something else. Probably the code I wrote for Linux will help you as mobile platforms (Android, iOS share most of Linux API). Look at http://svn.overbyte.be/svn/icsv10/Source/

I use the PCAN-BASIC API with several PCAN-USB devices and there is no problem at all. Sorry but I don't agree with you : this API is easy to use whatever number of interfaces you use. My use is controlling motors using digital positioning controllers in an industrial environment.

I'm using Peak System PCAN-USB interfaces with great success. In their PCAN-BASIC API, they have a Lazarus folder which contains PCANBasic.pas files you can use with Delphi. Those hardware and software are very reliable, I recommend it.

You probably need to call Embarcadero to solve this.

Put a breakpoint in the client destructor and also on the line where the AV occurs (client.free). And run the application. If the destructor brekpoint is hit before the one on client.free, then try to understand why the client is destroyed before the call to free.

I don't know which processing you need to do with the data. I guess it is a simple lookup. Instead of loading the data into a TDictionary, you could use a SQLite table and use SQL request to do the lookup. With SQLite, the SQL engine is linked with your executable and there is zero installation. It is also very fast.

Are those components compatible with the standard VCL component? I mean does they has same methods, properties and events. If they do, you can just substitute TTNTListBox by TListBox etc... It is easier to use an interposer class : TTNTListBox = class(TListBox) end; On the long term, once it works, do a global search and replace is .pas and .dfm to get rid of TTNTListBox and similars.

Low-level experienced, I'm still learning. Android has a layer of complexity above Linux kernel. Socket API on Android is the same a socket API on Linux. Before entering to TWSocket port, you should begin with the simplest program which open a TCP client socket with pure API, and send any string and wait for the answer, display it on a TMemo and then close. A simple TForm with a TButton and a TMemo will be enough. Use one of the server samples in ICS for Windows to connect to. You can find simple C-code for Linux that you can start with. If you are able to port this C-code to Delphi/FMX for Android, then you are probably ready to start porting ICS. If you want to discuss further, please open a new topic with proper subject to catch attention of interested peoples. Maybe some will help.

Sure, i'll try. Seriously? What experience do you have with Linux API level programming? (Android is Linux at the low level).

I converted a lot of code, most without any issue. I you have done like me, that is using each data type for what it really is, there will be no issue. But if you used, for example, a string as a general buffer instead of an array of byte, then you'll have to change your code. Another example is of you use Windows messages (PostMessage and other API function in the same category), if you used LPARM and WPARAM, then no issue. If you used other data types as integer of unsigned, then you have to change your code. There are other similar cases. The biggest issue can come from 3rd party components which may not exists anymore and for which you don't have full source code. If you have full source code, you can recompile (with the same issues as you own code). If you don't have source code, even if the component still exists, you may be faced with their evolution over the years: properties, events, function may now differ. I can't be more precise with seeing your code...

Sure ! Why don't you do it and give it away for free to ICS community? That would be great as well.

You are wrong there. Your application can't start. And most ICS sample do load OpenSSL automatically at startup. Here how to stop loading OpenSSL before really needed: 1) Take OverbyteIcsHttpsTest.dproj sample program. 2) Locate THttpsTstForm.FormShow event handle in OverbyteIcsHttpsTst1.pas source code. 3) At the end of that handler, you'll find this code: OverbyteIcsWSocket.LoadSsl; 4) Comment out form that line (including it) to the end of the event hanlder. Recompile, copy the exe to a folder when OpenSSL is not there. Run the executable. It starts nicely. Enter an http URL (not https) and click "Get" button. You'll see the document downloaded. Enter a https URL and click "Get" button. This time you should get an error because OpenSSL DLL are not found. Copy OpenSSL and retry. Https link will work. Using ProcessMonitor you can see when the OpenSSL are loaded. I hope you understand I demonstrated the ICS application can start without OpenSSL DLL present and the SAME application can do https once the DLL are in place.

How do you distribute/deploy your application? Why don't you deploy all dependencies along with the executable? Think about a setup program. Using a setup application (There are plenty) or write one yourself using Delphi. You can also embed the OpenSSL into your executable and extract it on the first run. As long as you don't request any SSL related function, OpenSSL will no be required (ICS use dynamic load).

Look better. And explain clearly what problem you have! Up to know you are very confusing. Sometimes you want SSL and sometimes you don't. That's not a problem at all if this is for different applications. Did you see my previous reply mentioning USE_SSL define?

If you don't need SSL, your don't need OpenSSL DLL. But, you have to tell ICS to compile without SSL code and that is done by undefining USE_SSL. You'll find this define in source/include/OverbyteIcsDefs.inc just comment out the line and recompile EVERYTHING.

Is it a VCL or FMX application ?

Then you have been very lucky. Every single GExperts release for the last few years has been flagged as malware. That probably result of the use of some library or component that your software (GExperts) use and that some viruses are using as well. Or some virus took part of GExperts source code. I use almost NO external library in my software, I use nearly only my own code. And when using something for elsewhere (VirtualTreeView for example), I never use pre-built dcu nor any runtime package nor any pre-built DLL. I always recompile EVERYTHING. There are also bad anti-virus software that has a lot of false positive because of their poor detection mechanism or their bugs.

I never had any of my Delphi generated application flagged as malware. I use Delphi since version 1. I used all versions.