w0wbagger

It appears that creating a TStringStream from my postData and setting client->SendStream to this may have worked in the past (8.7), but now I just needed to directly set rawParams = postData, and it worked. Hope I'm doing it correctly now.

Angus, my app seems to be working fine with the 32-bit release build. Other than the emits and the backwards compatibility issue with having to change overbyteicsftpcli::ftpRead to TFtpState::ftpReady, I've tested the modules that use the ICScomponents and they're working. Thank you for all your work on this. I'll try to see based on your release builds if I can build a debug group and build with the modern C++ 32-bit compiler. At minimum, the modern 32-bit compiler should be the default builder in the options, I'd imagine. I didn't realize D12.2 can't import C++ packages. So that Embarcadero video from yesterday saying the modern 64-bit toolchain "just works" wasn't *quite* accurate. Which would be the simplest C++ samples to update, do you think, Angus? I can maybe take a crack at one or two, at least. Update: I spoke too soon. *Most* of it seems to work, but same code, doing an httpPOST is resulting in an error from the destination ("Premature end of file."). Will check to see what's changed from 8.7 - 9.3 that I need to accommodate. It's almost like it isn't transmitting the entire XML stream that I've queued up. Maybe something to do with the new way that TRestParams work in 9.x? In my old code, I was setting client->SendStream = myTStringStream->get() before calling client->RestRequest. Can I still do that in 9.x?

Thanks, François! The only other thing I had to change in my app (that was using 8.70 prior to this) was to change my check of FtpClient->State from Overbyteicsftpcli::ftpReady to TFtpState::ftpReady in a couple of places. Haven't tried my app yet, but am hoping it will work - it seems to be compiling fine. Will let it finish compiling overnight and test it in the morning.

Okay! I reinstalled 12.2, and built the entire release group after removing the 64-bit compiles, and it worked! Installed my other component sets and while attempting to compile our app, got the same errors with the overnight that HTMLValidator did. [bcc32c Error] OverbyteIcsTypes.hpp(74): unknown type name '_TRANSMIT_FILE_BUFFERS' [bcc32c Error] OverbyteIcsTypes.hpp(76): unknown type name '_TRANSMIT_FILE_BUFFERS' [bcc32c Error] OverbyteIcsTypes.hpp(78): unknown type name 'ip_mreq' [bcc32c Error] OverbyteIcsTypes.hpp(80): unknown type name 'ip_mreq' [bcc32c Error] OverbyteIcsTypes.hpp(94): unknown type name 'sockaddr_in6' [bcc32c Error] OverbyteIcsTypes.hpp(96): unknown type name 'sockaddr_in6' [bcc32c Error] OverbyteIcsTypes.hpp(98): unknown type name 'ipv6_mreq' [bcc32c Error] OverbyteIcsTypes.hpp(100): unknown type name 'PIPV6_MREQ' [bcc32c Error] OverbyteIcsUtils.hpp(624): unknown type name 'sockaddr_in6' [bcc32c Error] OverbyteIcsUtils.hpp(624): expected unqualified-id These did *not* show up when compiling the components, only when attempting to use them in my app. I did as he said: and it seems to have worked - it's at least compiling my app with no errors. If there's a way to get Delphi to create the .hpp file with those two lines, then this should fix the issue for anyone else. It's not the 64-bit version I'd love to get working, but at least this might mean we can start developing on 12.2. Thank you, Angus! I *think* it might have been set to use the classic bcc32 compiler, and the dynamic RTL, so I may need to recompile the whole thing with the modern compiler and static libs, but hopefully it will still work.

Angus, I tried building and installing the C++ Win32 Release packages, and it didn't work at all. Were you using build groups, or did you build/install them separately? I'm currently completely uninstalling my 12.2 installation and reinstalling from scratch to eliminate that as the issue. Thanks, Ian

I don't know if we should start a new thread specifically to discuss compiling the overnights in C++ Builder 12.2? I tried both the groupproj and the individual .cbproj files. groupproj was not working at all, but I have traditionally had better luck compiling and installing each of the cbproj file separately. However, just trying to compile ICSCommonCBNewRun failed when compiling the 32-bit version. I got this error from ilink32 [ilink32 Error] Error: Unresolved external '__InitVCL' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\23.0\LIB\WIN32C\RELEASE\CP32MT.LIB|crtlvcl [ilink32 Error] Error: Unresolved external '__ExitVCL' referenced from C:\PROGRAM FILES (X86)\EMBARCADERO\STUDIO\23.0\LIB\WIN32C\RELEASE\CP32MT.LIB|crtlvcl I was not having this issue in previous attempts. I was able at one point to compile and install all 32-bit packages, although could never get my program working. @HTMLvalidator, were you able to get the groupproj to compile without changing many options? Can you try whatever you did with the overnights, per Angus' request? It would be nice to have a stable, easily installable C++ version upon which future builds could be made that includes all of Angus' significant improvements. thanks.

Just downloaded the overnights and trying this weekend, Angus. Sorry it's taken so long, but I'm being smashed with my current project.

Thank you! This is the only thing keeping me from moving to 12.2 (I couldn't get 9.x to compile on it), so I'll try this soon! Did you have to use the 'classic' borland compiler for the 32-bit?

Thanks, Angus. Until I can get the new version working with C++ Builder (Been crushed at work and haven't had time to get at it), I have to use 8.x, where someone else might have this issue. Sorry, I should have mentioned that I had this issue with 8.x, not 9.x

Just FYI in case anyone else has a similar problem, My app was working fine on my development machine, but stopped when I put it on a client machine. I was having this problem (didn't load Libcrypto-1_1.dll), and put LoadLibrary into my app at startup, but it still wasn't working (although it wasn't failing on LoadLibrary) Error was *still* reported as that it couldn't load Libcrypto-1_1.dll. However, the issue was that I was missing libssl-1_1.dll, Once I copied that into the directory, it worked well. Was still getting the Application Exception error instead of a clean exception, but didn't seem to affect performance.

Thanks, Angus. I'll give 'em a try this week.

Have to give up on this for now. TFTPServer and TSslFTPServer do not seem to work for me in C++ Builder. I can compile and run the .dproj demo (it works correctly), but cannot create the simplest native C++ Builder app with either component. It connects (triggers OnClientConnect), but then hangs. I can't seem to debug into the .pas source, so can't figure out why. The fact I can run the .dproj sample program okay would indicate to me that the .lib file is correct, and it must be something about how the .hpp files are generated that somehow screw it up? Anyway, if there's anyone else using C++ out there, I've sent Angus some updates for the package directory .proj files that make the library compilable. Maybe the other components work, but T(Ssl)FTPServer doesn't seem to, unfortunately. Here's what the ICSLogger captured: 21:54:04:484 054684F0 Listening 21:54:04:499 SslFtpServer1 started 21:54:13:060 054684F0 Do_FD_ACCEPT handle=1632 21:54:13:063 08B427E0 Client Connect Error - No Error (#0) -1 21:54:35:908 054684F0 SocketCloseCalled handle=1632 21:54:35:910 054684F0 TCustomWSocket.Shutdown 1 handle=1632 21:54:35:913 054684F0 ResetSslSession starting handle=-1 21:54:35:921 ResetSslSession SetShutDown FSsl handle=0 21:54:35:927 ResetSslSession FSslBio handle=0 21:54:35:928 ResetSslSession FNBio handle=0 21:54:35:929 ResetSslSession Fibio handle=0 21:54:35:929 ResetSslSession Close FSsl handle=0 21:54:35:940 054684F0 ResetSslSession Done 21:54:35:940 SslFtpServer1 stopped and here's the client side log: . 2024-10-13 21:54:13.059 Session upkeep . 2024-10-13 21:54:13.099 Connecting to 127.0.0.1 ... . 2024-10-13 21:54:13.099 Connection pending . 2024-10-13 21:54:13.099 Connected with 127.0.0.1. Waiting for welcome message... . 2024-10-13 21:54:28.748 Timeout detected. (control connection) . 2024-10-13 21:54:28.748 Connection closed . 2024-10-13 21:54:28.748 Connection failed. . 2024-10-13 21:54:28.748 Got reply 1004 to the command 1 * 2024-10-13 21:54:28.809 (EFatal) Connection failed. * 2024-10-13 21:54:28.809 Timeout detected. (control connection) * 2024-10-13 21:54:28.809 Connection failed.

Thanks Angus, I'll try your suggestions now. The server never responds with the "Welcome" lines. it does trigger a "ConnectClient" event, (I can log this okay), but then never returns control to my ftp session to allow me to enter a USER command. Will let you know how I get on with your suggestions, thanks.

It calls OnClientConnect, and I am able to enter some log entries there (although as I mentioned, Client->GetPeerAddr() returns '' in it). But then, nothing. My understanding of the component is it should then send a request for User/Pass, but it doesn't seem to get to this point. Is there some other trigger between connect and the Banner/request for User that I might trap to log? Here's what inspecting the Client * looks like in OnClientConnect. It looks...incomplete? ftpState is ftpcWaitingUserCode, but on the client side, control hasn't returned to me to enter USER or PASS. Does this suggest an issue at a lower-level function?

I'll try. It's strange. I wrote two apps, one with the TFtpClient component, one with the TFtpServer component. If I use the *updated* client app with the *old* TFtpServer app (the one written with 8.7, the last time I was able to compile ICS in C++ Builder), it works fine. As soon as I try replacing the old TFtpServer App with the new one, it stops. I was logging ClientConnect in the new version, and noticed that when it's called, the PeerAddr is NULL. Something must have changed. I'll check the changelogs to see if I can pinpoint what's happened, but as of now, I'd say TFtpServer is not backwards compatible in C++ Builder, while TFtpClient still works correctly (8.7->9.3).. I'll try using an sslFTPServer component and see if I have any better luck, too. Just writing these in case anyone else is trying to get this working in C++ Builder.