program with tsslHttpRest (ICS 9.3) starts up slowly, 30-40 seconds on some Windows 2008

[iddqd345 0]

The program with tsslHttpRest (ICS 9.3) starts up slowly, 30-40 seconds on some Windows 2008 under a user who is not an administrator.

At the same time, it starts up normally under the administrator. If I give administrator rights to another user, it still starts up slowly under this user.

This does not happen on all computers with Windows 2008, there are some on which it starts up quickly under any user. I tried to compare the installed system updates, service pack - everything is the same.

I used Procmon.exe from Sysinternals to log the program startup. When comparing the logs, it is clear that during a long startup there are many requests to the system registry, which are not there if the program starts up quickly.

When I commented out "{$DEFINE OpenSSL_Resource_Files}" - the program started to start up quickly.

This is how I solved the problem for myself - I will download SSL files separately.

I am attaching the Procmon logs of a quick and long startup of the program.

I compared these files using the CompareIt! program.

Admin.CSV

User.CSV

Edited November 12 by iddqd345

[iddqd345 0]

Upd:

When I commented out "{$DEFINE OpenSSL_Resource_Files}" - the program started to start up quickly, because it can't find the DLL and writes an error in the log.

When I also commented out "{$DEFINE OpenSSL_ProgramData}" and put three OpenSSL DLLs into the program directory, the program started to run slowly again.

Probably, I don't understand something

Edited November 12 by iddqd345

[Angus Robertson 574]

I'll look at the logs later, but ICS is not tested on Windows 2008 which is years beyond end of life. 

 

My first public server was Windows 2008, but I closed it down in 2019.  It was based on Vista, which we don't support either.  Windows 2008 R2 was much better, based on Windows 7 which I do still test, since I have a VM with all the old compilers. 

 

The problem might be file paths, c:\ProgramFiles did not exist 20 years ago. 

 

Windows 2008 was the last Win32 server OS Microsoft sold, only Win64 onwards, which is why some people still use it, on ancient hardware.

 

Angus

 

 

[FPiette 383]

Delphi is not even supported on Windows 2008.

https://docwiki.embarcadero.com/RADStudio/Athens/en/Installation_Notes#Operating_System_Requirements

[Angus Robertson 574]

It is not unusual for applications developed on newer versions of Windows to be used on older versions, Windows 2008 did not even support TLSv12 so using OpenSSL was a way to keep it running, that's what I did for some years. 

 

The original problem here loading OpenSSL DLLs can probably be fixed by the method used by all the samples until this year, disable all the new SSL DEFINES and set GSSL_DLL_DIR to the directory for the DLLs, usually that of the application, then load OpenSSL.  This is explained in readme9, search for GSSL_DLL_DIR.

 

Angus

 

 

[iddqd345 0]

1 hour ago, Angus Robertson said:

disable all the new SSL DEFINES and set GSSL_DLL_DIR to the directory for the DLLs, usually that of the application, then load OpenSSL.  This is explained in readme9, search for GSSL_DLL_DIR.

 

 

Yes, I tried that. Dont work.

 

But I commented out {$DEFINE OpenSSL_AutoLoad_CA_Bundle}, and the program started to launch quickly. But now the first call to tsslHttpRest takes a long time. It turns out that the problem is in loading certificates.

I'll think about it..

[iddqd345 0]

2 hours ago, FPiette said:

Delphi is not even supported on Windows 2008.

https://docwiki.embarcadero.com/RADStudio/Athens/en/Installation_Notes#Operating_System_Requirements

Yes, it is, but it is worth a try.

Win 2008 is still in use. And if I have to choose between reinstalling Windows and trying to solve the problem in the program, I will try the second option first.

[iddqd345 0]

It seems that I have found the reason for the slow startup - with {$DEFINE OpenSSL_Check_Signed} commented out, the program starts quickly.

Probably, these computers have something wrong with the Magenta Systems Ltd. certificate chain.

This is a local problem, and there is no need to rush to solve it.

This solution with {$DEFINE OpenSSL_Check_Signed} suits me at the moment.

 

Thanks for your help.

[Angus Robertson 574]

The Code Sign check is probably failing due to Windows 2008 not understanding the cryptography used, specifically the SHA-256 algorithm.  You may have the same problem using other modern signed applications. 

 

I don't plan to change anything, we can not support old compilers and operating systems forever. 

 

Angus