Tcl Source Code

Command "package require registry" allocates a temporary subfolder of user's %TEMP% folder containing 1 single file "tcl9registry13.dll". Temporary folder and file remain after "exit".
Test case:
- Open new tcl 9.0 shell
- execute commands:
  package require registry
  exit
- Open user's folder %TEMP% in explorer
- Each run of test case allocates 1 additional subfolder "TCL*" with random suffix containing file "tcl9registry13.dll"

Dup of [a8e4f76ce4].

> It would be great to find a smart solution here

Let's go for the smart solution: use the CRC of the dll (which is already calculated, it's in the zip-file) in the directoryname, in stead of the "random suffix".

I added this bug to the "Known bugs" section of 9.0

Independent from the question whether the registry dll should be statically linked or not, users should be able to include their own dll's in the executable without recompiling the executable.

Idea: why not use the CRC of the dll in the temporary folder name in stead of some random number? Then, if the dll has the same content (what it should have) it will be unpacked in the same directory, and if unpacking fails (which will happen if the dll is already loaded and locked) it means the file is already there. Two dll's with the same name and the same CRC but which really are different is extremely unlikely.

There is also no reason that those are DLL's. They may just be in the core.

+1 to always link them static.

Harald

No, the proper solution is not to put registry dll to the (zipped) library at all, but link it statically (in case of --enable-zipfs) and then load it by package require with `load {} registry`.

I suppose, this is the same issue, as in starkits.
TCL can not clean-up the file, as the dll is loaded by the executable and thus locked until exit.
My personal solution (for starkits) is to search the temp folder for any TCL* and delete them. You can not remove the one of the current running program, as it is locked.
It would be great to find a smart solution here.
One not so smart solution is to not put any dll's into the included zip folder, but locate them beside the executable.

Sorry,
Harald