Author:         Jan Nijtmans <[email protected]>
Author:	        Christian Werner <[email protected]>
State:          Rejected
Vote:           Done
Type:           Project
Tcl-Version:    9.1
Tcl-Branch:     tip-709
Vote-Summary:   Rejected 1/5/0
Votes-For:      JN
Votes-Against:  AN, HO, KW, MC, SL
Votes-Present:  none

Abstract

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 used for all dll's not containing a TLS (= Thread Local Storage) section.

Rationale

This TIP is meant to solve a longstanding bug in the implementation of the VFS loader for Windows. On Windows a dynamically-linked library (DLL) residing in a VFS (e.g. a mounted zip-file) is 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.

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

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. Since the TLS implementation in the Windows loader is a lot different in Vista than in XP, and MemoryModule still only implements the XP part, MemoryModule.[ch] contains a small additional patch which lets it refuse to load any dll which contains a TLS section, so any dll which uses at least one __declspec(thread) variable. Most Tcl extensions don't use such variables, so they can safely be loaded in memory.

Specification

DLL's without a TLS section inside a VFS are no longer copied to a temporary directory in order to load it. Such DLL's are loaded directly in memory using the functionality of MemoryModule.

Known limitations

There are three known limitations at the moment. The limitations might be lifted in the future.

Loading a DLL which depends on another DLL that is also in a VFS doesn't work, but that doesn't work without MemoryModule either, so it cannot be seen as a limitation of MemoryModule itself.
A DLL that is protected with WinLicense does not work.
A DLL using TLS (Thread Local Storage)

If the loading by MemoryModule fails, a fallback to the copy strategy takes place. This is not tested for situation 2, but it should work fine.

Compatibility

This change is 100% upwards compatible.

In my view it's overkill to provide a "-memory" option to the load command, because all known dll's work fine with MemoryModule. Extensive tests have been done to assure that.

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.

Copyright

This document has been placed in the public domain.