Author:         Jan Nijtmans <[email protected]>
Author:	        Christian Werner <[email protected]>
State:          Draft
Type:           Project
Tcl-Version:    8.6, 9.0
Tcl-Branch:     tip-709

Abstract

(Draft) Vote expected in January 2025, after Tcl 9.0.1 is released and the TIP #705 vote is completed.

This TIP proposes to accept MemoryModule.[ch] in the Tcl Repository for the Windows build. These files are under the Mozilla Public License as prominently stated at the very top of these files.

In the default Windows build, MemoryModule.[ch] is not used. In Tcl 8.6 and 9.0, it will only be enabled when the configuration is done with the additional option --enable-memorymodule.

Rationale

This TIP is meant to solve a longstanding bug in the implementation of the vfs loader for Windows. On Windows, dll's residing in a vfs are copied to a temporary directory before being loaded. This directory is never cleaned up, resulting in left-over temporary directories with every tclsh/wish run. The bug is present in all Tcl releases (8.6 too), but it became more visible in 9.0 because of the added support for a zipfs. That's why this TIP is targeting 8.6 and 9.0.

Since MemoryModule.[ch] is distributed under a different license, which is compatible with the Tcl license, a TIP is needed.

The Mozilla Public License doesn't impose any restrictions on software linked to it: the whole combined work can still be distributed under any license. But there are some restrictions on the two mentioned files:

Any modification of those 2 files must be done under the MPL license too.
The source code of such a modification must be published.

Tcl is compliant with those restrictions.

The current implementation of MemoryModule.[ch] is derived from MemoryModule master branch, with 4 additional pull-requests added. And it contains a trivial fix, making it work on ARM64 too.

Specification

This is an opt-in feature which must explicitly enabled by the option --enable-memorymodule when using the Windows Makefile build or OPTS=memorymodule when using the makefile.vc build."

When enabling this, dll's inside a vfs are no longer copied to a temporary directory when being loaded. They are loaded directly in memory, using the functionality provided by MemoryModule.

Known limitations

There are 2 known limitations at the moment. If any of those affect you, don't use --enable-memorymodule. Those limitations might be lifted in the future.

Loading a dll which depends on another dll which is also in VFS doesn't work. But that doesn't work without MemoryModule either, so it cannot be seen as a limitation of MemoryModule itself.
DLL's which are protected with WinLicense don't work.

If the loading by MemoryModule fails, a fallback to the copy strategy takes place.

TLS (Thread Local Storage)

Dll's using TLS work fine with MemoryModule. When compiling with MSVC, nothing special needs to be done. When compiling such a dll with gcc, the resulting dll depends on libgcc_s_seh-1.dll, which

in turn - depends on libwinpthread-1.dll. Those two dll's are not normally installed on Windows, so limitation 1) above comes into play. If those 2 dll's are not present, the fallback to dll copying will take place (which doesn't work either in this case).

Implementation

See the tip-709 branch.

A new win/dltest directory with testcases for the MemoryModule functionality is added.

Extensive tests are currently done, using the LUCK (Lean Undroidwish Construction Kit) environment. Allowing some time for that, this TIP will be brought to vote after Tcl 9.0.1 is released, and after the TIP #705 vote is completed, expected in January 2025.

Copyright

This document has been placed in the public domain.