Menu
▾
▴
tcl-core
|
From: Jan N. <jan...@gm...> - 2025-01-08 15:54:38
|
This is a CFV warning for TIP #699:
MPL Licence for MemoryModule
<https://core.tcl-lang.org/tips/doc/trunk/tip/709.md>
This is - most likely - the last TIP targeting 8.6 as well.
MemoryModule is already used in androwish (more precisely,
in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is
still based on 8.6.
The TIP implementation is based on 9.0, but
backporting to 8.7 and 8.6 is trivial. Since this is an
opt-in feature, default Tcl builds are not affected.
The vote process for TIP #705: "Affirm Tcl License" will
(most likely) start soon as well. This TIP can be
seen as an example how to request inclusion
of differently-licensed code in a repository supplied
by the Tcl consortium (anything ending with tcl-lang.org).
@Nathan Coulter <com...@po...> If you have any
spelling/wording
suggestions, please supply them now, not after
the voting finishes!
If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.
Regards,
Jan Nijtmans
|
|
From: <apn...@ya...> - 2025-01-10 01:30:12
|
I am torn about this TIP. On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation. But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence. For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. /Ashok From: Jan Nijtmans <jan...@gm...> Sent: Wednesday, January 8, 2025 9:24 PM To: Tcl Core List <tcl...@li...>; Nathan Coulter <com...@po...> Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule This is a CFV warning for TIP #699: MPL Licence for MemoryModule <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> This is - most likely - the last TIP targeting 8.6 as well. MemoryModule is already used in androwish (more precisely, in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is still based on 8.6. The TIP implementation is based on 9.0, but backporting to 8.7 and 8.6 is trivial. Since this is an opt-in feature, default Tcl builds are not affected. The vote process for TIP #705: "Affirm Tcl License" will (most likely) start soon as well. This TIP can be seen as an example how to request inclusion of differently-licensed code in a repository supplied by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ). @Nathan Coulter <mailto:com...@po...> If you have any spelling/wording suggestions, please supply them now, not after the voting finishes! If you think this is a bad idea, speak up now. If not, I'll start the vote in a few days. Regards, Jan Nijtmans |
|
From: Marc C. <cul...@gm...> - 2025-01-10 02:13:13
|
I am getting the impression that deciding on this TIP will require more experience with Windows APIs than I possess. I will probably have to leave this decision to the Windows experts. - Marc On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core < tcl...@li...> wrote: > I am torn about this TIP. > > > > On the one hand, it is a very nice feature. On the other hand, it uses > undocumented Windows behaviour / API’s which has already changed once > (though it was a while ago for Vista). Jan has spent considerable effort on > merging patches for MemoryModule and making it robust. Nevertheless, the > fact remains it is susceptible to internal design changes in Windows which > would cause applications making use this in-memory loading to fail (not > fail to load, which would result in an external copy of the DLL to be made > but fail at some later point in mysterious ways). If I understood Christian > correctly, this does not work in Wine either which points to the dependency > on the exact loader implementation. > > > > But I appreciate the usefulness and the fact that it is not the default > build behaviour mitigates my concerns to some extent. Thus my ambivalence. > > > > For anyone who has not followed earlier discussion, please see ticket > https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. > > > > /Ashok > > > > > > *From:* Jan Nijtmans <jan...@gm...> > *Sent:* Wednesday, January 8, 2025 9:24 PM > *To:* Tcl Core List <tcl...@li...>; Nathan Coulter < > com...@po...> > *Subject:* [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > This is a CFV warning for TIP #699: > MPL Licence for MemoryModule > <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> > > This is - most likely - the last TIP targeting 8.6 as well. > > MemoryModule is already used in androwish (more precisely, > > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is > still based on 8.6. > > The TIP implementation is based on 9.0, but > > backporting to 8.7 and 8.6 is trivial. Since this is an > > opt-in feature, default Tcl builds are not affected. > > > The vote process for TIP #705: "Affirm Tcl License" will > > (most likely) start soon as well. This TIP can be > > seen as an example how to request inclusion > > of differently-licensed code in a repository supplied > > by the Tcl consortium (anything ending with tcl-lang.org). > > @Nathan Coulter <com...@po...> If you have > any spelling/wording > > suggestions, please supply them now, not after > > the voting finishes! > > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. > > Regards, > Jan Nijtmans > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: <apn...@ya...> - 2025-01-10 16:29:57
|
FWIW I would not say understanding Windows API’s is the crux of the issue. It really has to do with whether Tcl should rely on undocumented behaviour and implementation (not just API’s) that might change between OS versions. From: Marc Culler <cul...@gm...> Sent: Friday, January 10, 2025 7:43 AM To: apn...@ya... Cc: Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule I am getting the impression that deciding on this TIP will require more experience with Windows APIs than I possess. I will probably have to leave this decision to the Windows experts. - Marc On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote: I am torn about this TIP. On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation. But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence. For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. /Ashok From: Jan Nijtmans <jan...@gm... <mailto:jan...@gm...> > Sent: Wednesday, January 8, 2025 9:24 PM To: Tcl Core List <tcl...@li... <mailto:tcl...@li...> >; Nathan Coulter <com...@po... <mailto:com...@po...> > Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule This is a CFV warning for TIP #699: MPL Licence for MemoryModule <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> This is - most likely - the last TIP targeting 8.6 as well. MemoryModule is already used in androwish (more precisely, in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is still based on 8.6. The TIP implementation is based on 9.0, but backporting to 8.7 and 8.6 is trivial. Since this is an opt-in feature, default Tcl builds are not affected. The vote process for TIP #705: "Affirm Tcl License" will (most likely) start soon as well. This TIP can be seen as an example how to request inclusion of differently-licensed code in a repository supplied by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ). @Nathan Coulter <mailto:com...@po...> If you have any spelling/wording suggestions, please supply them now, not after the voting finishes! If you think this is a bad idea, speak up now. If not, I'll start the vote in a few days. Regards, Jan Nijtmans _______________________________________________ Tcl-Core mailing list Tcl...@li... <mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Kevin W. <kw...@co...> - 2025-01-10 18:58:00
|
I'd caution against relying on undocumented/private API's unless there is a GREAT reason to do so. Windows has been remarkably stable for Tcl/Tk, and it would be shame for API churn (typical of Apple) to make its way into that source tree. On 1/10/25 11:29 AM, apnmbx-public--- via Tcl-Core wrote: > > FWIW I would not say understanding Windows API’s is the crux of the > issue. It really has to do with whether Tcl should rely on > undocumented behaviour and implementation (not just API’s) that might > change between OS versions. > > *From:*Marc Culler <cul...@gm...> > *Sent:* Friday, January 10, 2025 7:43 AM > *To:* apn...@ya... > *Cc:* Tcl Core List <tcl...@li...> > *Subject:* Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for > MemoryModule > > I am getting the impression that deciding on this TIP will require > more experience with Windows APIs than I possess. I will probably > have to leave this decision to the Windows experts. > > - Marc > > On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core > <tcl...@li...> wrote: > > I am torn about this TIP. > > On the one hand, it is a very nice feature. On the other hand, it > uses undocumented Windows behaviour / API’s which has already > changed once (though it was a while ago for Vista). Jan has spent > considerable effort on merging patches for MemoryModule and making > it robust. Nevertheless, the fact remains it is susceptible to > internal design changes in Windows which would cause applications > making use this in-memory loading to fail (not fail to load, which > would result in an external copy of the DLL to be made but fail at > some later point in mysterious ways). If I understood Christian > correctly, this does not work in Wine either which points to the > dependency on the exact loader implementation. > > But I appreciate the usefulness and the fact that it is not the > default build behaviour mitigates my concerns to some extent. Thus > my ambivalence. > > For anyone who has not followed earlier discussion, please see > ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. > > /Ashok > > *From:*Jan Nijtmans <jan...@gm...> > *Sent:* Wednesday, January 8, 2025 9:24 PM > *To:* Tcl Core List <tcl...@li...>; Nathan > Coulter <com...@po...> > *Subject:* [TCLCORE] CFV warning: TIP #709: MPL Licence for > MemoryModule > > This is a CFV warning for TIP #699: > MPL Licence for MemoryModule > <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> > > This is - most likely - the last TIP targeting 8.6 as well. > > MemoryModule is already used in androwish (more precisely, > > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), > which is still based on 8.6. > > The TIP implementation is based on 9.0, but > > backporting to 8.7 and 8.6 is trivial. Since this is an > > opt-in feature, default Tcl builds are not affected. > > > The vote process for TIP #705: "Affirm Tcl License" will > > (most likely) start soon as well. This TIP can be > > seen as an example how to request inclusion > > of differently-licensed code in a repository supplied > > by the Tcl consortium (anything ending with tcl-lang.org > <http://tcl-lang.org>). > > @Nathan Coulter > <mailto:com...@po...> If you have any > spelling/wording > > suggestions, please supply them now, not after > > the voting finishes! > > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. > > Regards, > Jan Nijtmans > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Jan N. <jan...@gm...> - 2025-01-10 19:49:22
|
Op vr 10 jan 2025 om 19:58 schreef Kevin Walzer:
> I'd caution against relying on undocumented/private API's unless there is a GREAT reason to do so. Windows has been remarkably stable for Tcl/Tk, and it would be shame for API churn (typical of Apple) to make its way into that source tree.
That's part of the point here. I think, being able to load dll's in memory is
such a GREAT reason. Ashok is IMHO exaggerating on how bad
MemoryModule is, looking at the code it is - actually - programmed
quite well. Well enough that it is picked up by other projects, and
other people were contributing back their fixes. I wrote testcases
for various situations Ashok pointed out to be problematic: All of
those worked fine! A "great" reason would be enough for me,
it doesn't even need to be GREAT.
Since I was not able to convince Ashok, it's now on our plate to
decide.
Part of the question is also non-technical. Should the quality
of code be a reason to accept or decline it in one of our
repositories? If TIP #705 "Affirm Tcl License" wouldn't be
there, TIP #709 wouldn't have been written at all. It also
means that - if TIP #709 is declined, I have to close the
branch and cannot even work on it any more, trying to
make it even more GREAT than it already is ;-)
Hope this helps,
Jan Nijtmans
|
|
From: Poor Y. <org...@po...> - 2025-01-10 21:06:58
|
On 2025-01-10 21:48, Jan Nijtmans wrote: [SNIP] > > Part of the question is also non-technical. Should the quality > of code be a reason to accept or decline it in one of our > repositories? If TIP #705 "Affirm Tcl License" wouldn't be > there, TIP #709 wouldn't have been written at all. It also > means that - if TIP #709 is declined, I have to close the > branch and cannot even work on it any more, trying to > make it even more GREAT than it already is ;-) > Right. TIP 705 just makes development of Tcl more difficult for no real benefit to anyone. The whole point of branches is to allow people to work in their own corner where they don't affect any other branch until a decision to merge is made. -- Yorick |
|
From: Rolf A. <tcl...@po...> - 2025-01-11 00:04:12
|
apnmbx-public--- via Tcl-Core writes: > FWIW I would not say understanding Windows API’s is the crux of the > issue. It really has to do with whether Tcl should rely on > undocumented behaviour and implementation (not just API’s) that might > change between OS versions. Not sure if this frames the decision problem at hand right. Without other context relying "on undocumented behaviour and implementation (not just API’s) that might change between OS versions" sounds at best peculiar. >From what I read the proposal fixes real, reported problems of some people. I do not know how likely it is, that the "fix" stops to work with some random windows update. I also don't know how likely other problems are (beside the most tested registry and dde). This points back to the knowledge and experience of the windows experts. rolf > > > From: Marc Culler <cul...@pu...> > Sent: Friday, January 10, 2025 7:43 AM > To: apnmbx-public-/E15...@pu... > Cc: Tcl Core List <tcl...@pu...> > Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > I am getting the impression that deciding on this TIP will require more experience with Windows APIs than I possess. I will probably have to leave this decision to the Windows experts. > > > > - Marc > > > > > > > > > > > > On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@pu... <mailto:tcl...@pu...> > wrote: > > I am torn about this TIP. > > > > On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation. > > > > But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence. > > > > For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. > > > > /Ashok > > > > > > From: Jan Nijtmans <jan...@pu... <mailto:jan...@pu...> > > Sent: Wednesday, January 8, 2025 9:24 PM > To: Tcl Core List <tcl...@pu... <mailto:tcl...@pu...> >; Nathan Coulter <com...@pu... <mailto:com...@pu...> > > Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > This is a CFV warning for TIP #699: > MPL Licence for MemoryModule > <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> > > This is - most likely - the last TIP targeting 8.6 as well. > > MemoryModule is already used in androwish (more precisely, > > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is still based on 8.6. > > The TIP implementation is based on 9.0, but > > backporting to 8.7 and 8.6 is trivial. Since this is an > > opt-in feature, default Tcl builds are not affected. > > > The vote process for TIP #705: "Affirm Tcl License" will > > (most likely) start soon as well. This TIP can be > > seen as an example how to request inclusion > > of differently-licensed code in a repository supplied > > by the Tcl consortium (anything ending with tcl-lang.org <http://tcl-lang.org> ). > > @Nathan Coulter <mailto:com...@pu...> If you have any spelling/wording > > suggestions, please supply them now, not after > > the voting finishes! > > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. > > Regards, > Jan Nijtmans > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@pu... <mailto:Tcl...@pu...> > https://lists.sourceforge.net/lists/listinfo/tcl-core > > _______________________________________________ > Tcl-Core mailing list > Tcl...@pu... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Marc C. <cul...@gm...> - 2025-01-11 16:08:30
|
I think that the licensing issue is a red herring, in spite of being named as the main point of the TIP. I think the core issue is whether to rely on undocumented operating system features. The TIP addresses this by saying "In Tcl 8.6 and 9.0 it is only enabled when the build is configured with --enable-memorymodule". So, even though this feature may be dangerous, you have to explicitly request it in order to be exposed to the dangers. Perhaps that is adequate protection - I am not sure. I do not understand the problem which this optional feature is solving. The TIP says that the problem (which involves failing to delete temporary files) only arises when Tcl loads a DLL with the "Windows VFS loader". I don't really know what "Windows VFS" means and the internet was not much help when I tried to read about "Windows VFS". Does "Windows VFS" have another name that might be more familiar? Does "Windows VFS" mean SAMBA? What are the common, problematic, use cases in which people need Tcl to load a DLL from "Windows VFS"? How common are they? Where do the orphaned temporary files which get created in the problematic situation end up? The fact that they do not get cleaned up is being attributed to "a longstanding bug in the implementation of the VFS loader for Windows". But I don't really know what that means. I can't really tell how serious this problem is, how prevalent it is, or where it comes from. - Marc On Fri, Jan 10, 2025 at 6:04 PM Rolf Ade <tcl...@po...> wrote: > > apnmbx-public--- via Tcl-Core writes: > > FWIW I would not say understanding Windows API’s is the crux of the > > issue. It really has to do with whether Tcl should rely on > > undocumented behaviour and implementation (not just API’s) that might > > change between OS versions. > > Not sure if this frames the decision problem at hand right. Without > other context relying "on undocumented behaviour and implementation (not > just API’s) that might change between OS versions" sounds at best > peculiar. > > From what I read the proposal fixes real, reported problems of some > people. > > I do not know how likely it is, that the "fix" stops to work with some > random windows update. I also don't know how likely other problems are > (beside the most tested registry and dde). > > This points back to the knowledge and experience of the windows experts. > > rolf > > > > > > > From: Marc Culler <cul...@pu...> > > Sent: Friday, January 10, 2025 7:43 AM > > To: apnmbx-public-/E15...@pu... > > Cc: Tcl Core List < > tcl...@pu...> > > Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for > MemoryModule > > > > > > > > I am getting the impression that deciding on this TIP will require more > experience with Windows APIs than I possess. I will probably have to leave > this decision to the Windows experts. > > > > > > > > - Marc > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core < > tcl...@pu... <mailto: > tcl...@pu...> > wrote: > > > > I am torn about this TIP. > > > > > > > > On the one hand, it is a very nice feature. On the other hand, it uses > undocumented Windows behaviour / API’s which has already changed once > (though it was a while ago for Vista). Jan has spent considerable effort on > merging patches for MemoryModule and making it robust. Nevertheless, the > fact remains it is susceptible to internal design changes in Windows which > would cause applications making use this in-memory loading to fail (not > fail to load, which would result in an external copy of the DLL to be made > but fail at some later point in mysterious ways). If I understood Christian > correctly, this does not work in Wine either which points to the dependency > on the exact loader implementation. > > > > > > > > But I appreciate the usefulness and the fact that it is not the default > build behaviour mitigates my concerns to some extent. Thus my ambivalence. > > > > > > > > For anyone who has not followed earlier discussion, please see ticket > https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. > > > > > > > > /Ashok > > > > > > > > > > > > From: Jan Nijtmans <jan...@pu... > <mailto:jan...@pu...> > > > Sent: Wednesday, January 8, 2025 9:24 PM > > To: Tcl Core List < > tcl...@pu... <mailto: > tcl...@pu...> >; Nathan > Coulter <com...@pu... > <mailto:com...@pu...> > > > > Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > > > > > This is a CFV warning for TIP #699: > > MPL Licence for MemoryModule > > <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> > > > > This is - most likely - the last TIP targeting 8.6 as well. > > > > MemoryModule is already used in androwish (more precisely, > > > > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which > is still based on 8.6. > > > > The TIP implementation is based on 9.0, but > > > > backporting to 8.7 and 8.6 is trivial. Since this is an > > > > opt-in feature, default Tcl builds are not affected. > > > > > > The vote process for TIP #705: "Affirm Tcl License" will > > > > (most likely) start soon as well. This TIP can be > > > > seen as an example how to request inclusion > > > > of differently-licensed code in a repository supplied > > > > by the Tcl consortium (anything ending with tcl-lang.org < > http://tcl-lang.org> ). > > > > @Nathan Coulter <mailto: > com...@pu...> If > you have any spelling/wording > > > > suggestions, please supply them now, not after > > > > the voting finishes! > > > > > > If you think this is a bad idea, speak up now. If not, > > I'll start the vote in a few days. > > > > Regards, > > Jan Nijtmans > > > > > > > > _______________________________________________ > > Tcl-Core mailing list > > Tcl...@pu... <mailto: > Tcl...@pu...> > > https://lists.sourceforge.net/lists/listinfo/tcl-core > > > > _______________________________________________ > > Tcl-Core mailing list > > Tcl...@pu... > > https://lists.sourceforge.net/lists/listinfo/tcl-core > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Brian G. <bri...@ea...> - 2025-01-11 17:05:50
|
On Jan 11, 2025, at 08:09, Marc Culler <cul...@gm...> wrote: I think that the licensing issue is a red herring, in spite of being named as the main point of the TIP. I think the core issue is whether to rely on undocumented operating system features. The TIP addresses this by saying "In Tcl 8.6 and 9.0 it is only enabled when the build is configured with --enable-memorymodule". So, even though this feature may be dangerous, you have to explicitly request it in order to be exposed to the dangers. Perhaps that is adequate protection - I am not sure. I do not understand the problem which this optional feature is solving. The TIP says that the problem (which involves failing to delete temporary files) only arises when Tcl loads a DLL with the "Windows VFS loader". I don't really know what "Windows VFS" means and the internet was not much help when I tried to read about "Windows VFS". VFS: Virtual File System Does "Windows VFS" have another name that might be more familiar? Does "Windows VFS" mean SAMBA? What are the common, problematic, use cases in which people need Tcl to load a DLL from "Windows VFS"? Tcl includes support for a zip based VFS. It is used internally when tcl is built with -disable-shared. The result is a single file tclsh.exe that contains the executable and an attached zip file containing the tcl library of scripts and packages, which may include dll files. At runtime, the dll files are copied out to a temporary location so that the os can load them. It’s these copies that need to be cleaned up. -Brian How common are they? Where do the orphaned temporary files which get created in the problematic situation end up? The fact that they do not get cleaned up is being attributed to "a longstanding bug in the implementation of the VFS loader for Windows". But I don't really know what that means. I can't really tell how serious this problem is, how prevalent it is, or where it comes from. - Marc On Fri, Jan 10, 2025 at 6:04 PM Rolf Ade <tcl...@po...<mailto:tcl...@po...>> wrote: apnmbx-public--- via Tcl-Core writes: > FWIW I would not say understanding Windows API’s is the crux of the > issue. It really has to do with whether Tcl should rely on > undocumented behaviour and implementation (not just API’s) that might > change between OS versions. Not sure if this frames the decision problem at hand right. Without other context relying "on undocumented behaviour and implementation (not just API’s) that might change between OS versions" sounds at best peculiar. From what I read the proposal fixes real, reported problems of some people. I do not know how likely it is, that the "fix" stops to work with some random windows update. I also don't know how likely other problems are (beside the most tested registry and dde). This points back to the knowledge and experience of the windows experts. rolf > > > From: Marc Culler <cul...@pu...<mailto:cul...@pu...>> > Sent: Friday, January 10, 2025 7:43 AM > To: apnmbx-public-/E15...@pu...<mailto:E15...@pu...> > Cc: Tcl Core List <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>> > Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > I am getting the impression that deciding on this TIP will require more experience with Windows APIs than I possess. I will probably have to leave this decision to the Windows experts. > > > > - Marc > > > > > > > > > > > > On Thu, Jan 9, 2025 at 7:30 PM apnmbx-public--- via Tcl-Core <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...> <mailto:tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>> > wrote: > > I am torn about this TIP. > > > > On the one hand, it is a very nice feature. On the other hand, it uses undocumented Windows behaviour / API’s which has already changed once (though it was a while ago for Vista). Jan has spent considerable effort on merging patches for MemoryModule and making it robust. Nevertheless, the fact remains it is susceptible to internal design changes in Windows which would cause applications making use this in-memory loading to fail (not fail to load, which would result in an external copy of the DLL to be made but fail at some later point in mysterious ways). If I understood Christian correctly, this does not work in Wine either which points to the dependency on the exact loader implementation. > > > > But I appreciate the usefulness and the fact that it is not the default build behaviour mitigates my concerns to some extent. Thus my ambivalence. > > > > For anyone who has not followed earlier discussion, please see ticket https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4. > > > > /Ashok > > > > > > From: Jan Nijtmans <jan...@pu...<mailto:jan...@pu...> <mailto:jan...@pu...<mailto:jan...@pu...>> > > Sent: Wednesday, January 8, 2025 9:24 PM > To: Tcl Core List <tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...> <mailto:tcl...@pu...<mailto:tcl-core-5NWGOfrQmneRv%2BL...@pu...>> >; Nathan Coulter <com...@pu...<mailto:com...@pu...> <mailto:com...@pu...<mailto:com...@pu...>> > > Subject: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > > > > This is a CFV warning for TIP #699: > MPL Licence for MemoryModule > <https://core.tcl-lang.org/tips/doc/trunk/tip/709.md> > > This is - most likely - the last TIP targeting 8.6 as well. > > MemoryModule is already used in androwish (more precisely, > > in the LUCK <https://wiki.tcl-lang.org/page/LUCK)> framework), which is still based on 8.6. > > The TIP implementation is based on 9.0, but > > backporting to 8.7 and 8.6 is trivial. Since this is an > > opt-in feature, default Tcl builds are not affected. > > > The vote process for TIP #705: "Affirm Tcl License" will > > (most likely) start soon as well. This TIP can be > > seen as an example how to request inclusion > > of differently-licensed code in a repository supplied > > by the Tcl consortium (anything ending with tcl-lang.org<http://tcl-lang.org> <http://tcl-lang.org> ). > > @Nathan Coulter <mailto:com...@pu...<mailto:com...@pu...>> If you have any spelling/wording > > suggestions, please supply them now, not after > > the voting finishes! > > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. > > Regards, > Jan Nijtmans > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...> <mailto:Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...>> > https://lists.sourceforge.net/lists/listinfo/tcl-core > > _______________________________________________ > Tcl-Core mailing list > Tcl...@pu...<mailto:Tcl-Core-5NWGOfrQmneRv%2BL...@pu...> > https://lists.sourceforge.net/lists/listinfo/tcl-core _______________________________________________ Tcl-Core mailing list Tcl...@li...<mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Marc C. <cul...@gm...> - 2025-01-11 17:47:47
|
On Sat, Jan 11, 2025 at 11:05 AM Brian Griffin <bri...@ea...> wrote: > Tcl includes support for a zip based VFS. It is used internally when tcl > is built with -disable-shared. The result is a single file tclsh.exe that > contains the executable and an attached zip file containing the tcl library > of scripts and packages, which may include dll files. > Thank you. That makes sense. I knew that VFS stands for "Virtual File System", but I had no idea that we were talking about a zip filesystem. I was assuming that the issue was with SMB filesystems. - Marc |
|
From: Christian G. <aur...@gm...> - 2025-01-11 17:58:09
|
Am 11.01.25 um 18:47 schrieb Marc Culler:
> On Sat, Jan 11, 2025 at 11:05 AM Brian Griffin <bri...@ea...
> <mailto:bri...@ea...>> wrote:
>
> Tcl includes support for a zip based VFS. It is used internally when
> tcl is built with -disable-shared. The result is a single file
> tclsh.exe that contains the executable and an attached zip file
> containing the tcl library of scripts and packages, which may
> include dll files.
>
>
> Thank you. That makes sense. I knew that VFS stands for "Virtual File
> System", but I had no idea that we were talking about a zip filesystem.
> I was assuming that the issue was with SMB filesystems.
The use case of a DLL in a ZIP file sounds exotic, until you think of
distributing your software to end users. Previously starkits have been
used based on MetaKit, and the ZIP file is now an alternative. If you
include any binary extension in the starkit/zipkit, the contained code
must be loaded upon "package require". So far, it is done by a modified
"load" command, which copies the DLL to a temporary file and then loads
this file. Upon exit, these DLLs cannot be deleted, because on Windows
you can't change an executable or DLL that is running. This creates a
lot of debris. A solution to load the DLL from memory instead would be
really great.
Under Linux, you can simply unlink the .so file directly after loading
it, so there is no real problem.
Christian
|
|
From: Marc C. <cul...@gm...> - 2025-01-11 19:51:53
|
Here is a naive question. Is it possible to specify the path that the DLL file will be copied to? If the answer is yes, here is a naive suggestion: Why not always use the same, known, path for each DLL that needs to be loaded from a zip file? This would seem to mean: * There would be at most one copy of the DLL on the user's disk. * The user would know or could find out where it is, so it could be deleted by hand. * The copy-to-disk operation could be skipped if the file were already there. - Marc On Sat, Jan 11, 2025 at 11:58 AM Christian Gollwitzer via Tcl-Core < tcl...@li...> wrote: > Am 11.01.25 um 18:47 schrieb Marc Culler: > > On Sat, Jan 11, 2025 at 11:05 AM Brian Griffin <bri...@ea... > > <mailto:bri...@ea...>> wrote: > > > > Tcl includes support for a zip based VFS. It is used internally when > > tcl is built with -disable-shared. The result is a single file > > tclsh.exe that contains the executable and an attached zip file > > containing the tcl library of scripts and packages, which may > > include dll files. > > > > > > Thank you. That makes sense. I knew that VFS stands for "Virtual File > > System", but I had no idea that we were talking about a zip filesystem. > > I was assuming that the issue was with SMB filesystems. > > The use case of a DLL in a ZIP file sounds exotic, until you think of > distributing your software to end users. Previously starkits have been > used based on MetaKit, and the ZIP file is now an alternative. If you > include any binary extension in the starkit/zipkit, the contained code > must be loaded upon "package require". So far, it is done by a modified > "load" command, which copies the DLL to a temporary file and then loads > this file. Upon exit, these DLLs cannot be deleted, because on Windows > you can't change an executable or DLL that is running. This creates a > lot of debris. A solution to load the DLL from memory instead would be > really great. > > Under Linux, you can simply unlink the .so file directly after loading > it, so there is no real problem. > > > Christian > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Brian G. <bri...@ea...> - 2025-01-11 20:45:36
|
On Jan 11, 2025, at 11:52, Marc Culler <cul...@gm...> wrote:
Here is a naive question. Is it possible to specify the path that the DLL file will be copied to?
If the answer is yes, here is a naive suggestion:
Why not always use the same, known, path for each DLL that needs to be loaded from a zip file?
This would seem to mean:
* There would be at most one copy of the DLL on the user's disk.
* The user would know or could find out where it is, so it could be deleted by hand.
* The copy-to-disk operation could be skipped if the file were already there.
This would turn a “single file” program into a “self installer” kind of application.
There would be other things to deal with, like clean up when updating to a newer versions, or Trojan horse attacks.
These are my immediate thoughts.
-Brian
- Marc
On Sat, Jan 11, 2025 at 11:58 AM Christian Gollwitzer via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Am 11.01.25 um 18:47 schrieb Marc Culler:
> On Sat, Jan 11, 2025 at 11:05 AM Brian Griffin <bri...@ea...<mailto:bri...@ea...>
> <mailto:bri...@ea...<mailto:bri...@ea...>>> wrote:
>
> Tcl includes support for a zip based VFS. It is used internally when
> tcl is built with -disable-shared. The result is a single file
> tclsh.exe that contains the executable and an attached zip file
> containing the tcl library of scripts and packages, which may
> include dll files.
>
>
> Thank you. That makes sense. I knew that VFS stands for "Virtual File
> System", but I had no idea that we were talking about a zip filesystem.
> I was assuming that the issue was with SMB filesystems.
The use case of a DLL in a ZIP file sounds exotic, until you think of
distributing your software to end users. Previously starkits have been
used based on MetaKit, and the ZIP file is now an alternative. If you
include any binary extension in the starkit/zipkit, the contained code
must be loaded upon "package require". So far, it is done by a modified
"load" command, which copies the DLL to a temporary file and then loads
this file. Upon exit, these DLLs cannot be deleted, because on Windows
you can't change an executable or DLL that is running. This creates a
lot of debris. A solution to load the DLL from memory instead would be
really great.
Under Linux, you can simply unlink the .so file directly after loading
it, so there is no real problem.
Christian
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Marc C. <cul...@gm...> - 2025-01-11 20:57:08
|
On Sat, Jan 11, 2025 at 2:30 PM Brian Griffin <bri...@ea...> wrote: > This would turn a “single file” program into a “self installer” kind of > application. > I don't get that. You still download a single file. When you run that file as an executable, it writes a file to your disk. That is true with the current setup too. If memory loading is required for a 'single file' program then there have never been any 'single file' programs, if I understand the situation correctly. > There would be other things to deal with, like clean up when updating to a > newer versions, or Trojan horse attacks. > The clean up for new versions seems minimal but I agree that a fixed path would make Trojan horse attacks easier. - Marc |
|
From: Brian G. <bri...@ea...> - 2025-01-11 21:46:08
|
On Jan 11, 2025, at 12:56, Marc Culler <cul...@gm...> wrote: On Sat, Jan 11, 2025 at 2:30 PM Brian Griffin <bri...@ea...<mailto:bri...@ea...>> wrote: This would turn a “single file” program into a “self installer” kind of application. I don't get that. You still download a single file. When you run that file as an executable, it writes a file to your disk. That is true with the current setup too. Yes, but, the current problem is that a temp folder is created and used once to hold the dll's for the current invocation. Then it is abandoned, never to be used again. Using a fixed path allows for reuse, but there's no mechanism to clean it up once it's no longer relevant. In that sense, it is as if the application went through an install process, installing stuff only known to the application. A new version of the application could provide an "uninstall" section to cleanup older versions detritus. The beauty of a single file application is that simply deleting that file should be all that is necessary to "uninstall" the application. I'm just spitballing here. -Brian If memory loading is required for a 'single file' program then there have never been any 'single file' programs, if I understand the situation correctly. There would be other things to deal with, like clean up when updating to a newer versions, or Trojan horse attacks. The clean up for new versions seems minimal but I agree that a fixed path would make Trojan horse attacks easier. - Marc |
|
From: Kevin W. <kw...@co...> - 2025-01-12 05:01:05
|
<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/46upqMQYxyWjcJWDnhDWKvKiciMSdTh8Ku-VjaZ-WlcFCUWx6eQtwJhKWVHIC9eHX9VirfvOMDE6wk-VrqU_vQsx8YlXy6WHQUEd1a3tZNDkMW-hSH4ySTTeABJEL0hS6XAD1t5DmM6hYW1RqKrNwxUGSTMY2kgFILHGZBStlIYG09sHTOucHOVXaTDy0qctzYcZRhP7sYvu_IUE5R9h-ffCpH3n' /></div><br/><br/>> On Jan 11, 2025, at 4:46 PM, Brian Griffin <bri...@ea...> wrote:<br/>> <br/>> The beauty of a single file application is that simply deleting that file should be all that is necessary to "uninstall" the application<br/><br/>Is that really even possible on Windows? Perl’s pp module also makes a mess in the temp dir, but deletes everything on app shutdown. Perhaps we should look to see how they do it?<br/><br/>I’m still waiting to see a robust example of a standalone Tcl/Tk app on Windows, with its own icon and name, deployed as a zip kit/exe with everything bundled. Are we there yet? |
|
From: <apn...@ya...> - 2025-01-12 11:06:45
Attachments:
~WRD0000.jpg
|
Kevin, Thanks for pointing me to pp. I’d looked at py2exe but not pp for perl. Pp and PyInstaller are both implemented the same way. They are wrap the actual interpreter executable and extensions. At runtime these are written out to disk and invoked. When they exit the parent process (wrapper) cleans up the temporary directory. I have implemented a similar (though directly in Tcl core, not a wrapper) scheme that cleans up the temporary files using a separate process after the Tcl process exits. See branch https://core.tcl-lang.org/tcl/timeline?r=apn-bug-a8e4f76ce4. It’s currently in cold storage as TIP 709 would be more elegant if it could be robustly implemented. Your question regarding a Windows standalone app is a bit difficult to answer. If it contains “support” DLL’s that are not directly loaded via Tcl_LoadFile, they will still need to be explicitly written to disk first (Tcl_LoadFile will not load DLL’s that are dependencies of the primary extension DLL). I believe this limitation applies to Unix as well, not just Windows. I have not tried icons or signing. I should check that and add it to the https://wiki.tcl-lang.org/page/Single+file+applications+in+Tcl+9 page. /Ashok From: Kevin Walzer <kw...@co...> Sent: Sunday, January 12, 2025 10:31 AM To: Brian Griffin <bri...@ea...> Cc: Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule > On Jan 11, 2025, at 4:46 PM, Brian Griffin wrote: > > The beauty of a single file application is that simply deleting that file should be all that is necessary to "uninstall" the application Is that really even possible on Windows? Perl’s pp module also makes a mess in the temp dir, but deletes everything on app shutdown. Perhaps we should look to see how they do it? I’m still waiting to see a robust example of a standalone Tcl/Tk app on Windows, with its own icon and name, deployed as a zip kit/exe with everything bundled. Are we there yet? |
|
From: Marc C. <cul...@gm...> - 2025-01-13 15:45:27
|
Here is my suggestion for TIP #709: * The TIP should be modified to only address the licensing issue, and not include the implementation of memory-mapped DLL files. * The TIP rationale should explicitly mention the real problem at hand - namely, creating single file Tcl applications as zip files without making a mess in a temp directory. I also think it would be helpful to make it clear that the virtual file systems being discussed are Zip filesystems. The rationale for my suggestion is: * The licensing issue seems straightforward * The implementation seems to still be a work in progress. There are multiple approaches being tested right now. Why not wait until the various strategies have been implemented, tested and compared before finalizing a TIP for the implementation? - Marc |
|
From: da S. P. J <pet...@fl...> - 2025-01-13 16:38:09
|
Since Windows doesn’t have a hierarchy of processes the same way UNIX does, couldn’t you start a cleanup program, exit, and have the cleanup program delete the libraries? |
|
From: Harald O. <har...@el...> - 2025-01-13 16:54:56
Attachments:
OpenPGP_signature.asc
|
Am 13.01.2025 um 17:15 schrieb da Silva, Peter J: > Since Windows doesn’t have a hierarchy of processes the same way UNIX > does, couldn’t you start a cleanup program, exit, and have the cleanup > program delete the libraries? Hi Peter, thank you for the great suggestion. That would work. The currently best solution is to clean-up all TCL temps on the next startup. By this strategy, there is only one old temp folder. To all: this problem is not so important. Solutions and strategies exist for this since around 20 years, when this was developed with the starkit technology by PC Wippler. A fix would be nice but is not at all mandatory. Thank you all for your great thinking ! Harald |
|
From: <apn...@ya...> - 2025-01-13 17:29:20
|
That was what I was referring to when I referenced branch https://core.tcl-lang.org/tcl/timeline?r=apn-bug-a8e4f76ce4. From: da Silva, Peter J <pet...@fl...> Sent: Monday, January 13, 2025 9:45 PM To: Kevin Walzer <kw...@co...>; Brian Griffin <bri...@ea...> Cc: Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] [External] Re: CFV warning: TIP #709: MPL Licence for MemoryModule Since Windows doesn't have a hierarchy of processes the same way UNIX does, couldn't you start a cleanup program, exit, and have the cleanup program delete the libraries? |
|
From: Jan N. <jan...@gm...> - 2025-01-13 17:44:22
|
Op ma 13 jan 2025 om 16:45 schreef Marc Culler:
> * The TIP should be modified to only address the licensing issue, and not include the implementation of memory-mapped DLL files.
If there is a desire for a separate licensing-TIP, that's OK with me. But then
I prefer TIP #709 to address the MemoryModule solution.
> * The TIP rationale should explicitly mention the real problem at hand - namely, creating single file Tcl applications as zip files without making a mess in a temp directory. I also think it would be helpful to make it clear that the virtual file systems being discussed are Zip filesystems.
I'm still open to suggestions for TIP text improvements. (Nathan
already took care of the Spelling/Wording!)
> * The implementation seems to still be a work in progress. There are multiple approaches being tested right now. Why not wait until the various strategies have been implemented, tested and compared before finalizing a TIP for the implementation?
I think your impression is wrong. The implementation is not a work in
progress, not any more than Tcl is a work in progress ;-). My
milestone was to pack tcl9tk90.dll into a zip-file and make Tk work from there.
Tk uses Windows manifests and Windows resources, both were brought
up by Ashok as not-working. It simply worked. Because of Ashok's feedback
I did additional testing with TLS (thread-local storage). That worked too.
So, the milestone is reached.
I am not aware of any other approaches being tested now, nor of any of
the various
strategies implemented. So, if you want to wait for that, we can wait forever.
Ashok's cleanup proposal has commit message "Proof of concept cleaning
up temp DLLs". That should tell enough ....
Thanks!
Regards,
Jan Nijtmans
|
|
From: Marc C. <cul...@gm...> - 2025-01-13 18:30:56
|
On Mon, Jan 13, 2025 at 11:44 AM Jan Nijtmans <jan...@gm...> wrote: > > I am not aware of any other approaches being tested now, nor of any of > the various strategies implemeted. You may not consider Ashok's cleanup proposal to be a strategy or to have an implementation, but that seems to contradict what he was saying earlier in this thread. My impressions just come from what I am reading here. As I said, I do not feel that I have enough Windows experience to judge. And I certainly could not (and would not try to) predict how long we would have to wait for Ashok's implementation to be finished. I do think we could quickly discuss and pass a TIP which was limited to declaring the MPL license to be Tcl-compatible. - Marc |
|
From: <apn...@ya...> - 2025-01-15 10:43:43
|
Jan wrote:
Tk uses Windows manifests and Windows resources, both were brought
up by Ashok as not-working. It simply worked. Because of Ashok's feedback
I did additional testing with TLS (thread-local storage). That worked too.
I mentioned TLS, manifests, exception handling and resources in the general
case. Not the very simple uses (or no uses) within Tk. Your test DLL (for
TLS) when I last saw it did not either for reasons I reiterated in my
previous post (single scalar TLS int which will be indistinguishable from a
normal static when the test is run).
Jan wrote:
Ashok's cleanup proposal has commit message "Proof of concept cleaning
up temp DLLs". That should tell enough ....
I am not sure what you think it is telling! Afair the code is complete but
still needs a review. It is indeed not a proposal because before TIP'ing or
writing a test suite, I was waiting for 709 to come to a conclusion one way
or another. If a robust 709 comes into being, there is no need for it.
I do wish Jan, assuming he has read the references I posted previously,
would address at least the two points I specifically asked about in my post.
To quote,
Per my reading of just the TLS-related portions,
. It does not allocate slots for the *implicit* TLS entries and
initialize them in the loading thread.
. It does not update the TLS map for existing threads by
reallocating (if necessary) the TLS storage and updating the in-use slot
map.
If the intent is to have memory loading work for a restricted set of
extensions (say no exception handling or implicit TLS) because that is
useful enough to accept current risk and future risk in case of Windows
changes, folks can by all means vote yes. Please do add test cases though to
avoid a repetition of the zipfs situation before 9.0.
/Ashok
-----Original Message-----
From: Jan Nijtmans <jan...@gm...>
Sent: Monday, January 13, 2025 11:14 PM
To: Marc Culler <cul...@gm...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #709: MPL Licence for MemoryModule
Op ma 13 jan 2025 om 16:45 schreef Marc Culler:
> * The TIP should be modified to only address the licensing issue, and not
include the implementation of memory-mapped DLL files.
If there is a desire for a separate licensing-TIP, that's OK with me. But
then
I prefer TIP #709 to address the MemoryModule solution.
> * The TIP rationale should explicitly mention the real problem at hand -
namely, creating single file Tcl applications as zip files without making a
mess in a temp directory. I also think it would be helpful to make it clear
that the virtual file systems being discussed are Zip filesystems.
I'm still open to suggestions for TIP text improvements. (Nathan
already took care of the Spelling/Wording!)
> * The implementation seems to still be a work in progress. There are
multiple approaches being tested right now. Why not wait until the various
strategies have been implemented, tested and compared before finalizing a
TIP for the implementation?
I think your impression is wrong. The implementation is not a work in
progress, not any more than Tcl is a work in progress ;-). My
milestone was to pack tcl9tk90.dll into a zip-file and make Tk work from
there.
Tk uses Windows manifests and Windows resources, both were brought
up by Ashok as not-working. It simply worked. Because of Ashok's feedback
I did additional testing with TLS (thread-local storage). That worked too.
So, the milestone is reached.
I am not aware of any other approaches being tested now, nor of any of
the various
strategies implemented. So, if you want to wait for that, we can wait
forever.
Ashok's cleanup proposal has commit message "Proof of concept cleaning
up temp DLLs". That should tell enough ....
Thanks!
Regards,
Jan Nijtmans
_______________________________________________
Tcl-Core mailing list
<mailto:Tcl...@li...> Tcl...@li...
<https://lists.sourceforge.net/lists/listinfo/tcl-core>
https://lists.sourceforge.net/lists/listinfo/tcl-core
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X