DelphiUdIT

That project was done with Delphi 2007. This is a note of developer:

If you want to play with security, build a Https server (from Indy demo with a little effort). After that you can test it with https://www.ssllabs.com/ssltest/ or with https://testtls.com/ To test, the servers should be public available (firewall NAT is enough). You can play with the project attached, old demo (is ready to compile and run with cert and SSL dll 32 bit (1.02u)). This is the partial result with test, with default (no chiperlist). https-server.zip

You use sslvSSLv23; Instead try to stay on sslvTLSv1_2. If you want to use the sslmServer way, you'd better set the "chiperlist" to a way like this (it's for better security and to avoid known bugs): //THIS BEFORE SERVER ACTIVATION FIOHandlerSSLOpenSLL.SSLOptions.CipherList := '!EXPORT:!LOW:!aNULL:!eNULL:!RC4:!ADK:!3DES:!DES:!MD5:!PSK:!SRP:!CAMELLIA'+ ':ECDHE-RSA-AES128-GCM-SHA256'+ ':ECDHE-RSA-AES256-GCM-SHA384'+ ':ECDHE-RSA-CHACHA20-POLY1305'+ //to use this two you must create a dhparam.pem file with openssl in this way //openssl dhparam -out dhparam.pem 4096 //':DHE-RSA-AES128-GCM-SHA256'+ //':DHE-RSA-AES256-GCM-SHA384'+ ''; ////This is to use DHE encoding (see above) //DHParamsFile := '.\dhparam.pem'; Then, if you use openssl 1.02, and you want the "client" to attempt connection according to your chiperlist you should also set the context with a general command: //THIS AFTER SERVER ACTIVATION (EVERY TIME YOU DISABLE AND ENABLE THE SERVER) type TMyIdSSLContext = class(TIdSSLContext) end; var FSSLContext1: TMyIdSSLContext; FSSLContext1 := TMyIdSSLContext(FIOHandlerSSLOpenSLL.SSLContext); SSL_CTX_set_ecdh_auto(FSSLContext1.fContext, 1); SSL_CTX_set_options(FSSLContext1.fContext, SSL_OP_CIPHER_SERVER_PREFERENCE); You can check also OPENSSL REF PAGE: https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

In the server connect event you must add: procedure TFTPServer.ServerConnect(AContext: TIdContext); begin If AContext.Connection.IOHandler is TIdSSLIOHandlerSocketBase then TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough := (UseTLS = utNoTLSSupport); //This function must be set to false for it to handle SSL/TLS functionality. end;

These are the differences between two builds ( near 30 seconds between): Like I told every builds produce different executables (release profile).

When you build a project, every build (exe) is different (may be some fuzzy data ? or some timestamp inside ?). I think that should be some $DEF or some magic setting to send to compiler or linker to produce the same "exe".

Something wrong with .dproj files ? These files maintain the project settings regarding compilation, environment, path, etc.

May be you can try with: //I think these two lines resolve you problems SSL.SSLOptions.Mode := sslmUnassigned; SMTPServer.UseTLS := utUseImplicitTLS; //look also for SSL.Port setting like 465 // SMTPServer.AuthType := satDefault; SMTPServer.ValidateAuthLoginCapability := True; SMTPServer.Connect; SMTPServer.Authenticate; if SMTPServer.DidAuthenticate then begin //Make message SmtpServer.Send(message); end; If you search in the Forum there are others discussion about that. Bye

My experience: Laptop PC less than two years old, 32GB and SSD. Win 11 and WSL / VirtualBox Rad Studio 11.3 Enterprise, MIcrosoft Studio, etc ... A VCL project with 50 personal units and 30 Forms with Styles, TChart, Indy, FastReport. Manual TThread implementation, various third-party libraries with "self-produced" wrappers including a computer vision library. The "project group" has several other projects including C++ for hardware support DLL libraries Compilation, for one project, of about 400 thousand lines (I don't use BPL). Memory occupation during work (including compilations): - Delphi approximately 450 Mbytes, - LSP approximately 300 Mbytes. I've never had problems with LSP (or at least I've never noticed), codeinsight is set automatically and responds correctly (you rarely have to use the keyboard shortcut to give it a "boost"). The "Help Insight tooltip" always works well too. I use Parnassus Debugger, and I must say that every now and then the debugger "crashes" and it is better to restart the IDE. But when I debug I normally have something like 50 instantiated manual threads, many that interact with the hardware and others that instantiate very heavy third-party libraries. I must say that as an experience it is certainly positive. Bye

Sorry, but what are you talking about? You said you don't know Lazarus but you say you want a Delphi like Lazarus, you decline a series of features without knowing them or having tried them. Try using Lazarus with your project, install Lazarus on Linux and work from there and then try to "distribute" your work to other Linux PCs: X11 and Wayland, Linux 4.xx, Linux 5.xx, Linux 6.xx , GTK2, GTK3, GTK3.2 GTK+, GTK4, QT5, QT5Moded, QT6, etc .... I won't continue to mention all the libraries otherwise .... Let's not talk about the distros (Debian, Fedora, Ubuntu just to name a few some common). Are you sure you want a Delphi like this? Fmx runs in a few OS (Linux, Mac, Android and IOS, as well as Windows) but at least the environment is unique. Use third-party libraries and see if they also run in all operating systems supported by Lazarus. FastReport for example on Lazarus only runs on Windows and Linux. Lazarus really doesn't have "skins". And, just to be clear, "skins" also exist in FMX, not just in VCLs. Etc... As others have said, it is better to have the IDE that is there now and most of the engineering resources dedicated to this IDE rather than splitting efforts and finding ourselves with new IDEs with new problems and the old one with old unsolved problems. The time will also come for a Delphi on "Mars", but only when the time is ripe. Bye

I've been using this technique for years (in Windows) because I use external graphical controls that don't have the POPUP function and so I simulate POPUP this way. Especially with Touch screens, where there is no mouse and it is simulated with touch. Bye

RTTI is an experimental stage. Lacks some generics support also. Anonymous methods and function reference are still not supported (may be in the next stable release will be), there are no styles or themes in the LCL, and since they are used to be compatible with a lot of OS they don't "use" some functions for current OS (for example, they lack full support for drag and drop operations). Not all Windows Messages are supported ... In the standard distribution there are not many components and most of the components are third party and must be installed (there is an online repository also accessible from the IDE). When the version changes it very often happens that support for old components is not available, and since many components have links to each other this blocks several components. Support (via forum) is active and is normally quite fast. Every time you install a component you need to recompile the IDE, There is no company behind Lazarus and FPC and therefore what guarantee can there be regarding a product that must generate production software? These are only some questions about ....

I think the new syntax is simply an opportunity, not an obligation. And I see no reason to include IFDEF... just don't use it.

Except for a library for Android ARM64-V8 (64 bit) which is present in Indy and which is not present in Fulgan.

You can look to Indy repository too: https://github.com/IndySockets/OpenSSL-Binaries

I use these (it's for Delphi 11.3 and Indy from github).

I've tried again several times and it actually works 1 time in a while. Saying that there aren't many ways: do you use what @Remy Lebeau told you or do you use a simple timer i.e. you set "enable = false" for all the controls and then call a timer (with a 50 ms interval) and perform your processing in the timer event. At the end of the timer you reactivate the controls.

As documentation says: So, is better to use directly Update for each control after every "enabled = false". I tried and for me is working, but I really don't know if it's OK in all situation (i.e. under heavy load).

I don't use c++ to build interfaces, only for device interfacing. I normally use Delphi instead, but the principle is the same: when you use any property of a component (but also functions, procedures, methods, etc ...) especially graphical components, i.e. which is executed "behind" the property it can be synchronous or asynchronous. So you cannot in any way expect that your action will have an immediate response, especially with graphics. Normally the graphics have a lower priority level (let's call it that) than the standard code and it is still unlikely that the graphics will be able to follow the code in real time (and it doesn't even make sense normally). To clarify the situation better, I present the use of the "SendMessage" and the "PostMessage". Both perform the same function, i.e. send messages to the queue.... but while SendMessage "makes sure" that the message is deposited and returns to the caller only after the message has been deposited in the queue (synchronous operation with your code), PostMessage instead sends it to the queue and returns immediately, without making sure that it is actually in the queue (the message will arrive in the queue asynchronously with respect to your code). With SendMessage at the next line of your code it is certain that the message is present in the queue, with PostMessage it is not certain (and no time prediction can be made) that the message is present at the queue of the next line of your code.

You can start from here: https://github.com/IndySockets/Indy/wiki/Updating-Indy

Even if you disable Windows Update policies, the updates imposed by Microsoft will still be carried out. This is certain in the latest version of Windows 11 Pro. I have lot of PC with the policies disabled and all of them do sometimes some upgrades.

Which operating system are you using? For TCP/IP connections, there are limits on the number of available IP ports and the number of concurrent connections. If you have a high connection/disconnection speed, you may run out of available ports as they may all be in the TIME_WAIT state. But it could also be that the "used" and released ports are not reused "immediately" and therefore the server "stops" when the range of available ports has run out. Look this https://learn.microsoft.com/en-us/answers/questions/482793/tcp-ip-concurrent-connections

You can try PasLibVlc, is a wrapper around VLC made in Pascal. https://prog.olsztyn.pl/paslibvlc/

If I'm not mistaken, nothing can be publicly distributed that is developed with the Beta stage environment. And on the other hand, until it becomes public (ie sold publicly by Embarcadero) it doesn't make much sense to do anything. Any features could change at the last moment and therefore frustrate the work done (as well as producing unusable libraries).