Delphi 10.4 PATCH 2 experiences

[PeterPanettone 157]

Get It offers the new Delphi 10.4 PATCH 2:

 

 

Unfortunately, the installer (= downloader) does not explicitly mention the information that the installation has to be done MANUALLY. So, if you have not by chance visited the Embarcadero blog:

 

https://community.idera.com/developer-tools/b/blog/posts/patch-2-for-rad-studio-10-4-now-available

 

...you would believe that PATCH 2 has been installed while it has not. OK, this file has to be executed:

 

\Embarcadero\Studio\21.0\CatalogRepository\10.4Patch2pro-10\R104_Patch2Pro\patch2.bat

 

Since the readme file says: "-The installation will require elevation...", I tried to execute the patch2.bat file with Administrator rights:

 

 

But it seems that nothing happened after doing this.

 

So I simply double-clicked the patch2.bat file. But no console window was shown to give me visual feedback of the executing patch. The only visual feedback was the HOURGLASS mouse-cursor which remained for over a minute.

 

So I restarted the Delphi 10.4 IDE.

 

In the About dialog, there was no mention of the installed patches 1 and 2.

 

And since the readme file also says the AV bug in the License Manager would be fixed with this Patch 2, I opened the License Manager and ... had the same AV as before the Patch 2:

 

 

I haven't also found any installation log file.

 

Can anyone confirm this?

Edited July 25, 2020 by PeterPanettone

[Achim Kalwa 61]

Hello Peter,

 

yes, the downloaded update/patch needs to be installed manually. Close the IDE and doubleclick "patch2.bat". This will trigger the User Account Control (UAC) to give the patch app admin credentials. It will open a black console window, with quickly scrolling messages from the patch progress.

 

I've installed that patch a few days ago; and I can confirm that

- no information about the patch is in the About dialog.

- the Access Violation in the LicenseManager.exe is fixed.

 

You can verify if the patch was installed successfully by checking the timestamp of some files in the "C:\Program Files (x86)\Embarcadero\Studio\21.0\bin" folder; it should be 2020-07-15 (using ISO date format):

- LicenseManager.exe:

- dcc32.exe

- getit270.bpl

 

If the files are still older (e.g. 2020-05-16), the patch has NOT been installed. Just try again 🙂

 

[Rollo62 536]

The backup files are there, in a separate folder, and also the file dates were changed as described in Marco Cantu's Blog.

Only verifying the file dates has to be so ne manual, which is a little unprofessional  .

[pyscripter 689]

I had the same problem.  I though I had installed the patch through Getit but it was not actually installed.  After reading this thread I installed by the command prompt.  It appears that just clicking on the bat file via the File Explorer did not work despite getting the elevation prompt.

[PeterPanettone 157]

It really seems the patch was made in an unprofessional way:

 

Since I am running Windows 10 in a Parallels VM (in COHERENCE mode), the patch was saved in this directory:

 

\\Mac\Home\Documents\Embarcadero\Studio\21.0\CatalogRepository\10.4Patch2pro-10\R104_Patch2Pro

 

It seems the Patch Tool cannot handle this network path.

 

But the above same network path is also accessible via a normalized path:

 

Y:\Documents\Embarcadero\Studio\21.0\CatalogRepository\10.4Patch2pro-10\R104_Patch2Pro

 

So I double-clicked the patch2.bat file in this new normalized path inside my default file-manager (Directory Opus). This made the UAC prompt appear and then this console window:

 

 

...and when pressing any key, the console window closed. (Obviously, PatchTool.exe had been started without parameters).

 

So I opened my ultimate weapon: Windows File Explorer!

 

In Windows File Explorer, I opened the normalized path and double-clicked the patch2.bat file. This not only showed the UAC prompt, but also gave me that beautiful scrolling lines in the console window, showing me that the patch was executing.

 

However, the created install.log file contains only one line:

 

C:\Program Files (x86)\Embarcadero\Studio\21.0\_patch-backup\2020-07-25 21.02.44

 

Not very talkative.

 

Then I restarted the Delphi 10.4 IDE and checked the License Manager: The AV bug has gone!

 

So I consider this patch a success, although it could have been built in a more compatible way.

[Anders Melander 1782]

6 hours ago, PeterPanettone said:

Unfortunately, the installer (= downloader) does not explicitly mention the information that the installation has to be done MANUALLY.

It actually does but since the installation process is a bit confusing it's easy to miss. After the patch has been downloaded patch2-readme.txt is opened in notepad. The readme states:

Quote

Installation Steps (via GetIt)
-Use GetIt to download the patch
-The patch executable is copied along with a ZIP file in a folder like: C:\Users\<name>\Documents\Embarcadero\Studio\21.0\CatalogRepository\10.4Patch2-10xx\R104_Patch2
-Close the RAD Studio 10.4 IDE (and also any other earlier versions of RAD Studio IDE)
-From the folder, run the batch file patch2.bat
-The installation will require elevation and proceed adding a detailed log file to the catalog repository folder
-When completed, restart the IDE

 

32 minutes ago, PeterPanettone said:

It really seems the patch was made in an unprofessional way:

Yeah. How difficult would it have been to create a simple InnoSetup installer that automated the process completely? Including registering the fact that the patch had been installed:

[HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\InstalledUpdates]
"Patch 1"="Patch1 for RAD Studio 10.4 (build 9797)"
"Patch 2"="Patch2 for RAD Studio 10.4"

Not impressed

[PeterPanettone 157]

It seems that PatchTool.exe is HARD-WIRED to Windows File Explorer since it works only in Windows File Explorer. Such HARD-WIRING is not recommended for install tools (nor for any other programs).

Edited July 25, 2020 by PeterPanettone

[aehimself 396]

There is no such thing as hardwired to File Explorer; it is just an application which requires elevated privileges due to it unzips files to the Program Files folder. I suggest you to take a look at how UAC works on Vista+ and how you can auto-elevate everything if it disturbs you that much.

While I completely admit that this "patch tool" is utterly useless, don't blame Emba because of how UAC works.

[PeterPanettone 157]

19 minutes ago, aehimself said:

There is no such thing as hardwired to File Explorer; it is just an application which requires elevated privileges due to it unzips files to the Program Files folder. I suggest you to take a look at how UAC works on Vista+ and how you can auto-elevate everything if it disturbs you that much.

While I completely admit that this "patch tool" is utterly useless, don't blame Emba because of how UAC works.

Obviously you don't know what you are saying. This has nothing to do with UAC (although UAC is involved). I suggest that you re-read what I have written. If you don't understand any particular topic then please ask me.

Edited July 26, 2020 by PeterPanettone

[aehimself 396]

38 minutes ago, PeterPanettone said:

Obviously you don't know what you are saying. This has nothing to do with UAC (although UAC is involved). I suggest that you re-read what I have written. If you don't understand any particular topic then please ask me.

Obviously. I forgot that the one and only way to start a batch file is Windows Explorer.

Why are we paying sysadmins, if the answer is always so easy...? 

[PeterPanettone 157]

29 minutes ago, aehimself said:

Obviously. I forgot that the one and only way to start a batch file is Windows Explorer.

Internally, a batch file is being started by a CommandLine. Windows File Explorer (but also other shell-programs) can provide that CommandLine, e.g. by double-clicking on a batch file e.g. in Windows File Explorer.

 

BTW, it would be interesting to inspect the source code of PatchTool.exe...

Edited July 26, 2020 by PeterPanettone

[aehimself 396]

15 minutes ago, PeterPanettone said:

Internally, a batch file is being started by a CommandLine. Windows File Explorer (but also other shell-programs) can provide that CommandLine, e.g. by double-clicking on a batch file e.g. in Windows File Explorer.

And here I though, that the CommandLine is internally using a ConHost process (Windows Console Host) which is provided by the operating system with AllocConsole for example. I must be wrong.

 

 

16 minutes ago, PeterPanettone said:

BTW, it would be interesting to inspect the source code of PatchTool.exe...

In that, we definitely agree.

[Anders Melander 1782]

[PeterPanettone 157]

49 minutes ago, Anders Melander said: