Thread: [TCLCORE] TIP 702 - static linking for registry and dde

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

TIP 702 - Statically link registry and dde extensions on Windows

https://core.tcl-lang.org/tips/doc/trunk/tip/702.md 

is up for review/comments.

I plan a CFV in two weeks.

/Ashok

Excellent idea. I've always considered these to be core commands anyway 
and I'm not quite clear why they are excluded, except for being 
platform-specific. We have AppleEvent support (Mac IPC mechanism that is 
similar to DDE) in the core.

As a tangent, is there any interest in integrating Schelte Bron's dbus 
and dbif libraries in the core as bundled packages? Schelte, what do you 
think? Including these would give Tcl/Tk full platform-native IPC 
support across all three platforms. I'd be glad to sponsor a TIP.

--Kevin

On 10/18/24 10:43 PM, apnmbx-public--- via Tcl-Core wrote:
>
> TIP 702 - Statically link registry and dde extensions on Windows
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/702.md
>
> is up for review/comments.
>
> I plan a CFV in two weeks.
>
> /Ashok
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

On 19/10/2024 17:05, Kevin Walzer wrote:
> As a tangent, is there any interest in integrating Schelte Bron's dbus 
> and dbif libraries in the core as bundled packages? Schelte, what do you 
> think?

I have no objections.

Schelte.

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/WoCvrdYRRyYDZo40c_T2Frl8PM-KLbnlxc4nZ59X2UByqEmGYZI3p3MM_7M_grWZQgKECChE9OPqrWGPTbGP51Kj3kxGQ3L7265Tekln_lm9wNIgteq4SwhYoLgFDR8bqed7JYRHufjoPSQgblzbJjW-DbCDrmHMDL_bimJvI8LLX27t9GZT-xNqs_VgJIjzWNK7z4vJWzXXBOjv-n10iVfuy9JaWiju' /></div>Thanks, Schelte. <br/><br/>One thing I’m not clear on: what’s the difference between bundled packages like dde and http and more loosely coupled ones like todbc that are merely released at the same time?  I don’t see a TIP for either package type, but I see dbus as falling into the same category as dde. How should we proceed?<br/><br/>> On Oct 20, 2024, at 3:38 AM, Schelte Bron <tc...@tc...> wrote:<br/>> <br/>> On 19/10/2024 17:05, Kevin Walzer wrote:<br/>>> As a tangent, is there any interest in integrating Schelte Bron's dbus and dbif libraries in the core as bundled packages? Schelte, what do you think?<br/>> <br/>> I have no objections.<br/>> <br/>> <br/>> Schelte.<br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

On Oct 19 2024, 15:05 +0000, Kevin Walzer <kw...@co...> wrote:
>As a tangent, is there any interest in integrating Schelte Bron's dbus 
>and dbif libraries in the core as bundled packages? Schelte, what do 
>you think? Including these would give Tcl/Tk full platform-native IPC 
>support across all three platforms. I'd be glad to sponsor a TIP.

What would that mean, in practice? I can see different options:

1. dbus' repo moves within Tcl's fossil tree
2. dbus' packages are distributed with Tcl's (same as tdbc and Thread)
3. dbus is built as part of Tcl's build process

Speaking as a downstream packager, 1 and 2 have no impact on my work, 
and probably neither does it on final users.

As per 3, I see several issues.  I don't think dbus is special in any 
way, and - as much as I like it - I don't see it as being the future of 
IPC. Also, this would introduce a dependency on dbus to build Tcl, which 
I also don't favour. If this happened, in the FreeBSD ports, I'd 
probably disable it and provide it as a separate port anyway.

If we want to consider bundling 3rd party extensions, I think there are 
others that are more generally used than dbus and that would better fit 
a more "batteries" approach, e.g., tcllib, tDOM, tls, thread.

YMMV - which is why I'd rather keep the status quo.

Thanks,

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

On Sat, Oct 19, 2024 at 11:06 AM Kevin Walzer <kw...@co...> wrote:

> Excellent idea. I've always considered these to be core commands anyway
> and I'm not quite clear why they are excluded, except for being
> platform-specific. We have AppleEvent support (Mac IPC mechanism that is
> similar to DDE) in the core.
>
> As a tangent, is there any interest in integrating Schelte Bron's dbus and
> dbif libraries in the core as bundled packages? Schelte, what do you think?
> Including these would give Tcl/Tk full platform-native IPC support across
> all three platforms. I'd be glad to sponsor a TIP.
>
> --Kevin
>

For what it's worth, my understanding was that the original reason (which
has fallen by the wayside) was that the Core proper didn't include anything
that couldn't at least in concept be implemented on all three platforms.

Moreover, the extensions were thought to provide relatively simple worked
examples of how to package an extension on Windows.

Sentiment used to favour unbundling: keeping features out of the Core but
having the ones that were expected to be universal published as bundled
extensions. That's one reason why I never proposed tdbc as bundled; a more
important one was that I wasn't sure that the API was quite right and
didn't want to freeze it for years or decades, as would happen if it came
under TIP control and required a major Tcl release to introduce any
incompatibilities.

New leadership will of course have new directions, and if the pendulum is
swinging back toward greater inclusion. I don't object.

-- 
73 de ke9tv/2, Kevin

I actually share Kevin’s sentiments about minimizing core bloat. However, registry and dde are for all practical purposes already in the core (they are part of the static shell unlike tdbc, thread etc.). One could move them out completely a la TDBC but that would be considerably more disruptive to users imo.

With regards to serving as sample extensions, I think there are many examples out there now so that is no longer a factor.

/Ashok

From: Kevin Kenny <kev...@gm...> 
Sent: Sunday, October 20, 2024 6:17 AM
To: Kevin Walzer <kw...@co...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 702 - static linking for registry and dde

On Sat, Oct 19, 2024 at 11:06 AM Kevin Walzer <kw...@co... <mailto:kw...@co...> > wrote:

Excellent idea. I've always considered these to be core commands anyway and I'm not quite clear why they are excluded, except for being platform-specific. We have AppleEvent support (Mac IPC mechanism that is similar to DDE) in the core. 

As a tangent, is there any interest in integrating Schelte Bron's dbus and dbif libraries in the core as bundled packages? Schelte, what do you think? Including these would give Tcl/Tk full platform-native IPC support across all three platforms. I'd be glad to sponsor a TIP. 

--Kevin

For what it's worth, my understanding was that the original reason (which has fallen by the wayside) was that the Core proper didn't include anything that couldn't at least in concept be implemented on all three platforms.

Moreover, the extensions were thought to provide relatively simple worked examples of how to package an extension on Windows.

Sentiment used to favour unbundling: keeping features out of the Core but having the ones that were expected to be universal published as bundled extensions. That's one reason why I never proposed tdbc as bundled; a more important one was that I wasn't sure that the API was quite right and didn't want to freeze it for years or decades, as would happen if it came under TIP control and required a major Tcl release to introduce any incompatibilities. 

New leadership will of course have new directions, and if the pendulum is swinging back toward greater inclusion. I don't object.

-- 

73 de ke9tv/2, Kevin

When faced with three different platform specific solutions to the same
problem, I think one reasonable approach is to start by designing one
abstraction that represents the important aspects of all three solutions
and then to use the platform specific solutions to realize the
abstraction.  An example of this sort of thing, found in a number of
languages, is having one database abstraction that serves as a "frontend"
which can be used with many different database "backends".

The obvious advantage of doing this is that it enables writing platform
independent code.

- Marc

On Sat, Oct 19, 2024 at 10:06 AM Kevin Walzer <kw...@co...> wrote:

> Excellent idea. I've always considered these to be core commands anyway
> and I'm not quite clear why they are excluded, except for being
> platform-specific. We have AppleEvent support (Mac IPC mechanism that is
> similar to DDE) in the core.
>
> As a tangent, is there any interest in integrating Schelte Bron's dbus and
> dbif libraries in the core as bundled packages? Schelte, what do you think?
> Including these would give Tcl/Tk full platform-native IPC support across
> all three platforms. I'd be glad to sponsor a TIP.
>
> --Kevin
> On 10/18/24 10:43 PM, apnmbx-public--- via Tcl-Core wrote:
>
> TIP 702 - Statically link registry and dde extensions on Windows
>
>
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/702.md
> <https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/dpvfbxiDwteuRkOCwwBEoFiYZiTMi3anLCHhAlKw_oOnNzECZgWFcEG0FrNw88GwseyEFjVyXcoDBCdUXmRGuo1EOi8cujkyV6rY4BJQLXZVJPdCCNDeGKROinEYKM3FG4E8rWa12ALRYlvKag6Akw_6tn4mv5Aw35_zPO8UjFJut3tNGBf-qxbg4pGqa6Kxgv0xykqBpcIzw5YiKS7iwNQJ5qOuFgUvYyVJnmLf7my21keR15Vd2fDjGki1CpStBIWrzXcFHlH5KZcxMCAg1yk6X-NyyT-7Zh6IuO4RSkyMApVq5_wev7z_iBbWevaNdM0m>
>
>
>
> is up for review/comments.
>
>
>
> I plan a CFV in two weeks.
>
>
>
> /Ashok
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core <https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/MlB1gVVE1XsVmWESK_OwKVWaSF7WumaXA08YDpJRng5zcII-ljgKXzvnVaOui4SELj7pWA1qrzli4iEb1NkLfOUZCCSRvmWhEmmAjbBIWX5tRpWGOpfs0pATyS0qjEQdY_mBl-i7bGBfKM0DnklwLysxHXDFDbHwPsOBd5OcggkfpN8Z6kZKPjLaOEj8aZKdQZvt41_I8eiP1LgEgCQztBjzK_0JXKcDqjxiVL13K0X3Ac-vd8Q4SSl-txEQ6Pi2T5TsDdk4rwSKFWdo7QunREVWJVPZDrgd4TjSCupRvHEROg8uLoHkRAZGU6fZNzpiXw>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

On Sat, Oct 19, 2024 at 9:27 PM Marc Culler <cul...@gm...> wrote:

> When faced with three different platform specific solutions to the same
> problem, I think one reasonable approach is to start by designing one
> abstraction that represents the important aspects of all three solutions
> and then to use the platform specific solutions to realize the
> abstraction.  An example of this sort of thing, found in a number of
> languages, is having one database abstraction that serves as a "frontend"
> which can be used with many different database "backends".
>

Tcl is among those languages.  TDBC provides native-API interfaces to
MySQL/MariaDB, PostgreSQL, and SQLite3, and the TDBC-to-ODBC bridge covers
numerous other databases, including SQL Server and Jet/MS Access.  All of
these share a common front end.

-- 
73 de ke9tv/2, Kevin

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/AblX6MEdh0k3tBPVdNfSBsA72VOqL5JCPVZCsCRT38g1uY0Fe9J2ZuhbbCc2XCJMa8dXqZt_OXgsmVeYSncJorJCSx6FN15TphXSSvM3k1TpmxWqTAkT3OCuwONRnJISVY_aT1T17hck9EcvXRHHtS7BRJlQF-n_iRHbkAW4S0cL_c7N_-IR8TM8pPKSaevfHz8HryKZH97Oiu9bSrmjJr02tt-hPAz6' /><div dir="ltr"></div><div dir="ltr">For new API’s I agree. For established ones, layering an abstraction over them makes less sense.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Oct 19, 2024, at 9:26 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>When faced with three different platform specific solutions to the same problem, I think one reasonable approach is to start by designing one abstraction that represents the important aspects of all three solutions and then to use the platform specific solutions to realize the abstraction.&nbsp; An example of this sort of thing, found in a number of languages, is having one database abstraction that serves as a "frontend" which can be used with many different database "backends".</div><div><br></div><div>The obvious advantage of doing this is that it enables writing platform independent code.</div><div><br></div><div>- Marc<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2024 at 10:06 AM Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  <div><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/xs-5-haiKBpl-s_C-aYodh_GwLpJ-OQRNSllSt5FyM8_QbMCTkY-VZHQmFv0z7BAAwCxCIIerMAbpWEUBO08joMjSiWW5FfjUjDOnmPBc_PZ4D5L_gSoquy31KsdRZ8GDF6s-lAq00e_8CIZxGzl6ArEmgScRHxjos6fhiF-5Eyj1rTat2fMEbrWxWR0SwXWjb1CfkWozjN4dsnQDOxU-ZUhdsh5pZtF" data-unique-identifier="">
    <p>Excellent idea. I've always considered these to be core commands
      anyway and I'm not quite clear why they are excluded, except for
      being platform-specific. We have AppleEvent support (Mac IPC
      mechanism that is similar to DDE) in the core. <br>
    </p>
    <p>As a tangent, is there any interest in integrating Schelte Bron's
      dbus and dbif libraries in the core as bundled packages? Schelte,
      what do you think? Including these would give Tcl/Tk full
      platform-native IPC support across all three platforms. I'd be
      glad to sponsor a TIP. <br>
    </p>
    <p>--Kevin <br>
    </p>
    <div>On 10/18/24 10:43 PM, apnmbx-public---
      via Tcl-Core wrote:<br>
    </div>
    <blockquote type="cite">

      <div>
        <p class="MsoNormal">TIP 702 - Statically link registry and dde
          extensions on Windows<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal"><a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/dpvfbxiDwteuRkOCwwBEoFiYZiTMi3anLCHhAlKw_oOnNzECZgWFcEG0FrNw88GwseyEFjVyXcoDBCdUXmRGuo1EOi8cujkyV6rY4BJQLXZVJPdCCNDeGKROinEYKM3FG4E8rWa12ALRYlvKag6Akw_6tn4mv5Aw35_zPO8UjFJut3tNGBf-qxbg4pGqa6Kxgv0xykqBpcIzw5YiKS7iwNQJ5qOuFgUvYyVJnmLf7my21keR15Vd2fDjGki1CpStBIWrzXcFHlH5KZcxMCAg1yk6X-NyyT-7Zh6IuO4RSkyMApVq5_wev7z_iBbWevaNdM0m" target="_blank">https://core.tcl-lang.org/tips/doc/trunk/tip/702.md</a>
          <u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">is up for review/comments.<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">I plan a CFV in two weeks.<u></u><u></u></p>
        <p class="MsoNormal"><u></u>&nbsp;<u></u></p>
        <p class="MsoNormal">/Ashok<u></u><u></u></p>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Tcl-Core mailing list
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a>
<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/MlB1gVVE1XsVmWESK_OwKVWaSF7WumaXA08YDpJRng5zcII-ljgKXzvnVaOui4SELj7pWA1qrzli4iEb1NkLfOUZCCSRvmWhEmmAjbBIWX5tRpWGOpfs0pATyS0qjEQdY_mBl-i7bGBfKM0DnklwLysxHXDFDbHwPsOBd5OcggkfpN8Z6kZKPjLaOEj8aZKdQZvt41_I8eiP1LgEgCQztBjzK_0JXKcDqjxiVL13K0X3Ac-vd8Q4SSl-txEQ6Pi2T5TsDdk4rwSKFWdo7QunREVWJVPZDrgd4TjSCupRvHEROg8uLoHkRAZGU6fZNzpiXw" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/NEyju_rOQTCEDlDotW1y6qkdH1b35Qycz1xz_6f13L2o3_memHYSWWzzuBTbfdHvFgnvXENl2s3OMHV7JZlYtw0bUi0lUKYCuPJ2KuneP2RnZnsD3amWdhqbKGTnaRRpJVYVZFr_8JrnZkp9lZ2v499v9MYY6kKHr3h__RW35h5y4NWR3moPf6E_MYDS7J4czQDlMYTq9clQxWgZGv8BliINm7prxe8zFrzXlA6LuWL9hsASlnAzQcLhYz2OF4zRrbQZq1wMkW4JFhLL7_I4y26TozAAIz-lsGQ1YMHHdYD8pcjD_B6JqKB53Ieiz73nfA" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
</blockquote></div>
</div></blockquote></body></html>

Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:

> For what it's worth, my understanding was that the original reason (which
> has fallen by the wayside) was that the Core proper didn't include anything
> that couldn't at least in concept be implemented on all three platforms.
>
> Moreover, the extensions were thought to provide relatively simple worked
> examples of how to package an extension on Windows.
>
> Sentiment used to favour unbundling: keeping features out of the Core but
> having the ones that were expected to be universal published as bundled
> extensions. That's one reason why I never proposed tdbc as bundled; a more
> important one was that I wasn't sure that the API was quite right and
> didn't want to freeze it for years or decades, as would happen if it came
> under TIP control and required a major Tcl release to introduce any
> incompatibilities.
>
> New leadership will of course have new directions, and if the pendulum is
> swinging back toward greater inclusion. I don't object.
>

I hope I will not the only one to be objecting, but here are my reasons:
1) dde and registry are 'dangerous' extensions. Dde has the same
functionality as the "send" command,
    which was disabled due to security concerns. Registry makes it possible
to read and write
    registry settings, which could also make the computer screw up
completely. Separating
    them would make it possible to remove them, if some application doesn't
need it.
2) dde and registry don't have the best API we can think of. dde would best
be integrated in
   a new "send" command. The registry commands should feel more oo-like.
3) Every command should either be included, then no "package require"
should be needed.
   Or it should be a module, activated by "package require". With TIP #702,
"dde" and "registry"
   will be the only modules which are compiled into the Tcl library. Do we
think it's a
   good example to other modules to do that? I don't think so. Either
provide the "dde" and
   "registry" commands as being available always (which I wouldn't do due
to 1) and 2),
  or make them a separate module loadable at wish (which they are now)

That said, I recognise the problem addressed in the TIP. Actually, there
are 4 problems now.
1) Extracting ddl's from the zip-file takes time and is not 100%
full-proof. That's something
which should be addressed (there already is a ticket for that)
2) Even if we can include dde.ddl and registry.ddl in the zip, the question
is if we really
want to do that. We could just install those in C:\Tcl\lib\registry1.3 resp
C:\Tcl\lib\dde1.4
(as is done now in Tcl 8.6), then all current problems are gone.
3) Currently, registry.dll is loaded at startup because the new "clock"
command needs it.
It would be better to have a native clock subcommand, which reads the
timezone
from the registry, in C, without the need to load registry.dll for doing
that.
4) I think Tk also loads "registry.dll" at startup. I'm sure there's a way
to prevent that too.

I'll create a new ticket, proposing to install registry and dde in
C:\Tcl\lib, instead of packing
it into the zip-file. I think that's a better way going forward than TIP
#702.

Sorry, Ashok,

Regards,
     Jan Nijtmans

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/w9RFJy8VY4uLSMR-YeDYGzlisv0asz3HIFlm2pt4DEGz_a-gJxROqJi6MKv_DDqpBpXfy5_cG280hVbS1Qng3fBmk0azaaSSQ5LZ2wIoAZMoH9Trs2qgzQNEcpve7ujD_FUQ0qplkmGTZBTMNEpmSOAfI9b4rg4Dl7mXPqUvFD0PaHyBwz55k6GKKMvoHOCgmnJvzCQjpOUN_1a751ARjZ9bBN0a_NrM' /></div>I have never understood the value of “send”. It’s non-functional on macOS and Windows, and only works with other Tk apps on X11, which is far too limited to be useful.  It’s obsolete and should be removed. <br/><br/>Each platform provides a native API for IPC - AppleEvents on macOS, dde or COM on Windows, and dbus on X11. Robust toolkits like Qt and wxWidgets support these out of the box. Tk should be able to serve data to other applications  over these connections, and also consume it. I make use of this in all my apps. <br/><br/>My thought is not to submerge these under a single new command. The API’s are too different. But bundling all in one form or another makes sense. <br/><br/>> On Oct 20, 2024, at 7:26 AM, Jan Nijtmans <jan...@gm...> wrote:<br/>> <br/>> 1) dde and registry are 'dangerous' extensions. Dde has the same functionality as the "send" command,<br/>>     which was disabled due to security concerns. Registry makes it possible to read and write<br/>>     registry settings, which could also make the computer screw up completely. Separating<br/>>     them would make it possible to remove them, if some application doesn't need it.<br/>> 2) dde and registry don't have the best API we can think of. dde would best be integrated in<br/>>    a new "send" command. The registry commands should feel more oo-like.<br/>

On Sun, Oct 20, 2024 at 7:26 AM Jan Nijtmans <jan...@gm...> wrote:

>
> I hope I will not the only one to be objecting, but here are my reasons:
> 1) dde and registry are 'dangerous' extensions. Dde has the same
> functionality as the "send" command,
>     which was disabled due to security concerns. Registry makes it
> possible to read and write
>     registry settings, which could also make the computer screw up
> completely. Separating
>     them would make it possible to remove them, if some application
> doesn't need it.
>

For what it's worth, I've never used 'dde' to have Tcl accept DDE
transactions. I've used it only to inject commands into foreign
applications. (I seldom need dde for that any more. Tcom and Twapi do what
I need, and do it better.)

'dde' and 'send' did have severe security implications because of the
danger of code injection from another application on the machine.  The same
argument doesn't apply to the use of 'dde' to command foreign applications
or of 'registry' to modify registry settings. Issuing a command to a
foreign app, or querying or adjusting the registry, is under the full
control of the programmer.  It doesn't hand the reins to an unrelated
application.

Registry actions are kind of required.  On Windows, for instance, as you
observe, [clock] needs to query the registry for time zone and locale
information. I don't see why it should be any different whether the query
originates in a Tcl script or a C wrapper function. We've generally
operated on the principle of having the language provide to users
everything that the library can do.

Tcl scripts have access to the filesystem and to [exec], both of which
already provide ample ways to screw up the computer.

-- 
73 de ke9tv/2, Kevin

On 10/20/2024 02:20 PM, Kevin Walzer wrote:

> ... Robust toolkits like Qt and wxWidgets support these out of the box. Tk should be able to serve data to other applications ...

Sorry Kevin, out of the poor fragility of our beloved toolkit I cannot resist to ask about things like ICE, comm, Tcl-DP which
predate many of these other guys. And weren't there many attempts to interface Tcl to something useful. Few days ago I had
a deeper look into tcluno (the bridge to the (Open|Libre)Office world). Tons of code I managed not to do what was advertised.
My impression was not positive, that bridge is broken. I'm afraid, Tcl is a hopeless case. Never be able to follow the cultural
en vogue trends in time. The all time flash in the pan.

Now we discuss about the (in|ex)clusion of those ancient prehistoric "dde" and "registry" things being part or not of the Tcl
binary while the real problem is Win32's unwillingness to LoadLibrary() from memory streams. I bet that chrome, mozilla, and
even edge found ways to more or less safely load native code without problems.

A final rant: what about ditching "dde" and "registry" once and for all and to add CFFI or FFIDL and reimplement those two
guys in plain Tcl? And d(or whatever letter)bus using this infrastructure, too?

BR,
Christian

On 20/10/2024 14:20, Kevin Walzer wrote:
> I have never understood the value of “send”. It’s non-functional on 
> macOS and Windows, and only works with other Tk apps on X11, which is 
> far too limited to be useful. It’s obsolete and should be removed.
> 
The "send" command is very useful for debugging Tcl/Tk programs. I use 
it almost daily. I strongly disagree that it is obsolete. Removing it 
would mean losing a very handy tool.

Schelte.

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/xWvKr2ex9xZkADTfpqxRTBNXkZt21-qSR2rSVj8QWFY1AtNO4tKCQZhlTFXmcQBikDhnDbnjn_qDV4mc2T5aH8L-jsLtpkbyPgJVrT58teqq_Uqo_wBHGXcKgXUVulRCZraLkjyEHSCbaSar-It0AMAbLKutk3P-QrsiIdimUysvUmv1fCFXBo0vpWuxXvJP6SsgCVQjySd4x1DGwFkhxnQDDsHS-hGA' /></div>On 10/20/24 4:46 PM, Schelte Bron wrote:<br/><br/>> The "send" command is very useful for debugging Tcl/Tk programs. I use <br/>> it almost daily. I strongly disagree that it is obsolete. Removing it <br/>> would mean losing a very handy tool. <br/>Well, we missed an opportunity to remove it anyway with 9.0. So it will <br/>stay.<br/>

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/71ywrk27YImvZvlm_LSyQb_-Flhh8kng9TfcZSAlzxOdvE_cYxAizqZjnzOLmXCtMS4AHRnCEV8ipVOLRFEHSbZWSbba0lQUOthfqkrR0XDMckwYzI2Evxy2iOkh7cQ_AAwSzZF1E5ygKBJeYdtLj9TteWqgeGBJ8Ba0nlk6U1MzBC6-TW9Cpzn1Uc3joJZOnQR4HdLtcEWXSIle937fHawtnOd6ozwu' /></div>Hi Christian,<br/><br/>On 10/20/2024 02:20 PM, Kevin Walzer wrote:<br/><br/>><br/>>> ... Robust toolkits like Qt and wxWidgets support these out of the <br/>>> box. Tk should be able to serve data to other applications ...<br/>><br/>> Sorry Kevin, out of the poor fragility of our beloved toolkit I cannot <br/>> resist to ask about things like ICE, comm, Tcl-DP which<br/>> predate many of these other guys. And weren't there many attempts to <br/>> interface Tcl to something useful. Few days ago I had<br/>> a deeper look into tcluno (the bridge to the (Open|Libre)Office <br/>> world). Tons of code I managed not to do what was advertised.<br/>> My impression was not positive, that bridge is broken. I'm afraid, Tcl <br/>> is a hopeless case. Never be able to follow the cultural<br/>> en vogue trends in time. The all time flash in the pan.<br/><br/>I can't speak to any of the examples you cite. What little I know of <br/>them are that they are mostly various separate Tcl-only approaches to <br/>duplicate the "send" command - why that would need to be done is a <br/>mystery to me. Tcluno is a separate thing, obvioulsy, but I don't know <br/>much about it.<br/><br/>I'm referring to something different altogether. I'm referring to <br/>platform-native standard API's for IPC. I think that Tcl/Tk should <br/>support these in some form out of the box in order to be a better app <br/>citizen on each platform. DDE or COM, AppleEvents, and dbus are those <br/>interfaces.<br/><br/>><br/>> Now we discuss about the (in|ex)clusion of those ancient prehistoric <br/>> "dde" and "registry" things being part or not of the Tcl<br/>> binary while the real problem is Win32's unwillingness to <br/>> LoadLibrary() from memory streams. I bet that chrome, mozilla, and<br/>> even edge found ways to more or less safely load native code without <br/>> problems.<br/>><br/>> A final rant: what about ditching "dde" and "registry" once and for <br/>> all and to add CFFI or FFIDL and reimplement those two<br/>> guys in plain Tcl? And d(or whatever letter)bus using this <br/>> infrastructure, too?<br/><br/>Excellent idea  - Python has had "ctypes" for a long time and it allows <br/>full access to any kind of native API that you could ask for. All that <br/>needs to happen is for someone to do the work.<br/><br/>--Kevin<br/>

Am 20.10.24 um 22:56 schrieb Kevin Walzer:
>  > A final rant: what about ditching "dde" and "registry" once and for
>  > all and to add CFFI or FFIDL and reimplement those two
>  > guys in plain Tcl? And d(or whatever letter)bus using this
>  > infrastructure, too?
>
> Excellent idea  - Python has had "ctypes" for a long time and it allows
> full access to any kind of native API that you could ask for. All that
> needs to happen is for someone to do the work.
>

Well at least the hard part is already done by Ashok:

          https://github.com/apnadkarni/tcl-cffi

Now it would be great to add THIS to the core.

           Christian

My few cents inlined below. 

20.10.2024 13:26, Jan Nijtmans wrote: 

> 3) Every command should either be included, then no "package require" should be needed. 
> Or it should be a module, activated by "package require". With TIP #702, "dde" and "registry" will be the only modules which are compiled into the Tcl library.

I though the TIP means that it shall only link it statically (quasi to
include binary stuff directly to tcl-core 
instead of zipped VFS library, what is IMHO a mistake), the `package
require` may remain 
(just would do `load {} registry`)...
The suggestion to remove `package require` in TIP is just an option, I
guess.
Or did I understand your objection wrong?

Anyway, IMHO the `package require` shall be retained for both commands
(just a load-rewrite for pkgIndex). 

> 3) Currently, registry.dll is loaded at startup because the new "clock" command needs it.

No. The "clock" command needed that always, also previously. Nothing
changed there, 
just new handling is more "flexible", because allows to load DLL from
uninstalled state (e. g. direct from build-folder),
where previously clock did not find the registry module, and so system
TZ would fallback to :localtime timezone 
(so has wrong TZ-name and cannot get times before posix-epoch) and
system locale would fallback to C
(so may remain english for different real locale in windows).
Just compare 8.6 vs. 8.7+: 

 % clock format [clock seconds]
- Mon Oct 21 17:08:14 +0200 2024
+ Mon Oct 21 17:08:14 CEST 2024
 % clock scan "01/01/1960"
- TIME VALUE TOO LARGE/SMALL TO REPRESENT
+ -315622800
- % set ::tcl::clock::CachedSystemTimeZone
+ :LOCALTIME
- % tcl::unsupported::clock::configure -setup-tz
+ :CET 

Previously it was only possible correct in the test-suite (it has loaded
registry-package explicitly). 

So new handling only disabled this discrepancy... Also it doesn't load
registry on startup
(it is just an auto-load on demand if clock would need registry package,
e. g. need current TZ on window). 

> It would be better to have a native clock subcommand, which reads the timezone
> 
> from the registry, in C, without the need to load registry.dll for doing that.

Partially agree.
The effort is also not so large, and can be also provided as new
"clock::configure" thing.

But if I remember correctly other packages, e. g. msgcat, need it also,
for instance to get system locale. 

So at least it'd be good to have at least 2 new functions: get system
locale and get (and/or setup) system TZ.
Probably platform-independent (so as same commands for windows/*nix). 

Regards,
Serg. 
Am 20.10.2024 um 13:26 schrieb Jan Nijtmans:
> Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:
> 
>     For what it's worth, my understanding was that the original reason
>     (which has fallen by the wayside) was that the Core proper didn't
>     include anything that couldn't at least in concept be implemented on
>     all three platforms.
> 
>     Moreover, the extensions were thought to provide relatively simple
>     worked examples of how to package an extension on Windows.
> 
>     Sentiment used to favour unbundling: keeping features out of the
>     Core but having the ones that were expected to be universal
>     published as bundled extensions. That's one reason why I never
>     proposed tdbc as bundled; a more important one was that I wasn't
>     sure that the API was quite right and didn't want to freeze it for
>     years or decades, as would happen if it came under TIP control and
>     required a major Tcl release to introduce any incompatibilities.
> 
>     New leadership will of course have new directions, and if the
>     pendulum is swinging back toward greater inclusion. I don't object.
> 
> 
> I hope I will not the only one to be objecting, but here are my reasons:
> 1) dde and registry are 'dangerous' extensions. Dde has the same 
> functionality as the "send" command,
>      which was disabled due to security concerns. Registry makes it 
> possible to read and write
>      registry settings, which could also make the computer screw up 
> completely. Separating
>      them would make it possible to remove them, if some application 
> doesn't need it.
> 2) dde and registry don't have the best API we can think of. dde would 
> best be integrated in
>     a new "send" command. The registry commands should feel more oo-like.
> 3) Every command should either be included, then no "package require" 
> should be needed.
>     Or it should be a module, activated by "package require". With TIP 
> #702, "dde" and "registry"
>     will be the only modules which are compiled into the Tcl library. Do 
> we think it's a
>     good example to other modules to do that? I don't think so. Either 
> provide the "dde" and
>     "registry" commands as being available always (which I wouldn't do 
> due to 1) and 2),
>    or make them a separate module loadable at wish (which they are now)
> 
> That said, I recognise the problem addressed in the TIP. Actually, there 
> are 4 problems now.
> 1) Extracting ddl's from the zip-file takes time and is not 100% full- 
> proof. That's something
> which should be addressed (there already is a ticket for that)
> 2) Even if we can include dde.ddl and registry.ddl in the zip, the 
> question is if we really
> want to do that. We could just install those in C:\Tcl\lib\registry1.3 
> resp C:\Tcl\lib\dde1.4
> (as is done now in Tcl 8.6), then all current problems are gone.
> 3) Currently, registry.dll is loaded at startup because the new "clock" 
> command needs it.
> It would be better to have a native clock subcommand, which reads the 
> timezone
> from the registry, in C, without the need to load registry.dll for doing 
> that.
> 4) I think Tk also loads "registry.dll" at startup. I'm sure there's a 
> way to prevent that too.
> 
> I'll create a new ticket, proposing to install registry and dde in C: 
> \Tcl\lib, instead of packing
> it into the zip-file. I think that's a better way going forward than TIP 
> #702.
> 
> Sorry, Ashok,
> 
> Regards,
>       Jan Nijtmans
My 2 pence:
- msgcat also loads the registry package.
- I am not the opinion, that the registry package is dangerous. Critical 
changes may only be done by administrator priviledges.
- So, I would advocate to move the registry stuff to the core. It is 
central on Windows.
- The dde package is IMHO not so important and may IMHO even move to 
bundled packages
- For me, the single executable facility is of central importance. I 
would love, that the any library may be included and that it does not 
produce a new copy on each start. I would love to have a constant 
temporary path for contained libraries. I would also like, that they 
keep their names (e.g.registry.dll) and not "tcl12345678.dll".
If this is solved, the TIP is of less importance.

Thanks for all,
Harald

This thread is becoming hard to follow,  because some participants are not
replying to the list.  Please try to copy the list on replies.

- Marc

On Sun, Oct 20, 2024 at 2:57 PM Harald Oehlmann <har...@el...>
wrote:

> Am 20.10.2024 um 13:26 schrieb Jan Nijtmans:
> > Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:
> >
> >     For what it's worth, my understanding was that the original reason
> >     (which has fallen by the wayside) was that the Core proper didn't
> >     include anything that couldn't at least in concept be implemented on
> >     all three platforms.
> >
> >     Moreover, the extensions were thought to provide relatively simple
> >     worked examples of how to package an extension on Windows.
> >
> >     Sentiment used to favour unbundling: keeping features out of the
> >     Core but having the ones that were expected to be universal
> >     published as bundled extensions. That's one reason why I never
> >     proposed tdbc as bundled; a more important one was that I wasn't
> >     sure that the API was quite right and didn't want to freeze it for
> >     years or decades, as would happen if it came under TIP control and
> >     required a major Tcl release to introduce any incompatibilities.
> >
> >     New leadership will of course have new directions, and if the
> >     pendulum is swinging back toward greater inclusion. I don't object.
> >
> >
> > I hope I will not the only one to be objecting, but here are my reasons:
> > 1) dde and registry are 'dangerous' extensions. Dde has the same
> > functionality as the "send" command,
> >      which was disabled due to security concerns. Registry makes it
> > possible to read and write
> >      registry settings, which could also make the computer screw up
> > completely. Separating
> >      them would make it possible to remove them, if some application
> > doesn't need it.
> > 2) dde and registry don't have the best API we can think of. dde would
> > best be integrated in
> >     a new "send" command. The registry commands should feel more oo-like.
> > 3) Every command should either be included, then no "package require"
> > should be needed.
> >     Or it should be a module, activated by "package require". With TIP
> > #702, "dde" and "registry"
> >     will be the only modules which are compiled into the Tcl library. Do
> > we think it's a
> >     good example to other modules to do that? I don't think so. Either
> > provide the "dde" and
> >     "registry" commands as being available always (which I wouldn't do
> > due to 1) and 2),
> >    or make them a separate module loadable at wish (which they are now)
> >
> > That said, I recognise the problem addressed in the TIP. Actually, there
> > are 4 problems now.
> > 1) Extracting ddl's from the zip-file takes time and is not 100% full-
> > proof. That's something
> > which should be addressed (there already is a ticket for that)
> > 2) Even if we can include dde.ddl and registry.ddl in the zip, the
> > question is if we really
> > want to do that. We could just install those in C:\Tcl\lib\registry1.3
> > resp C:\Tcl\lib\dde1.4
> > (as is done now in Tcl 8.6), then all current problems are gone.
> > 3) Currently, registry.dll is loaded at startup because the new "clock"
> > command needs it.
> > It would be better to have a native clock subcommand, which reads the
> > timezone
> > from the registry, in C, without the need to load registry.dll for doing
> > that.
> > 4) I think Tk also loads "registry.dll" at startup. I'm sure there's a
> > way to prevent that too.
> >
> > I'll create a new ticket, proposing to install registry and dde in C:
> > \Tcl\lib, instead of packing
> > it into the zip-file. I think that's a better way going forward than TIP
> > #702.
> >
> > Sorry, Ashok,
> >
> > Regards,
> >       Jan Nijtmans
> My 2 pence:
> - msgcat also loads the registry package.
> - I am not the opinion, that the registry package is dangerous. Critical
> changes may only be done by administrator priviledges.
> - So, I would advocate to move the registry stuff to the core. It is
> central on Windows.
> - The dde package is IMHO not so important and may IMHO even move to
> bundled packages
> - For me, the single executable facility is of central importance. I
> would love, that the any library may be included and that it does not
> produce a new copy on each start. I would love to have a constant
> temporary path for contained libraries. I would also like, that they
> keep their names (e.g.registry.dll) and not "tcl12345678.dll".
> If this is solved, the TIP is of less importance.
>
> Thanks for all,
> Harald
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Op zo 20 okt 2024 om 21:57 schreef Harald Oehlmann:

> - msgcat also loads the registry package.
>

Indeed. Wouldn't it be much simpler to have a
   "info locale"
instead of having to do this?:
  Tcl Source Code: msgcat.tcl at [4292513191] (tcl-lang.org)
<https://core.tcl-lang.org/tcl/file?name=library/msgcat/msgcat.tcl&ci=42925131911a8796&ln=1319-1347>

Same with
    "info timezone" (or - maybe - "clock timezone"
for the clock code. On Windows it will use the registry
to find out the current timezone. On UNIX it will
derive this from the TZ (or TCL_TZ) environment
variable.

Yes, "info locale" and "info timezone" deserve a separate
TIP, it will eliminate the need for clock and msgcat to
use the "registry" extension on Windows.

Hope this helps,
       Jan Nijtmans

Jan,

Regarding registry and dde being dangerous…

As Kevin K. pointed out, if writing to the registry is dangerous, so is writing to the file system. For non-privileged applications, the OS should provide protection. For privileged applications, overwriting any number of files will tank the system as much as writing to sensitive registry keys. With respect to DDE, if an application wants to be a server (which is the case with security implications), whether the dde command is statically linked or not is immaterial. It will load it regardless. The same also applies to third party applications.

I am also somewhat skeptical of the rationale of keeping “dangerous” commands out of Tcl, whatever they might be. That’s what safe interpreters are for, aren’t they?

Regarding registry and dde not having the best API…

That’s a red herring and orthogonal to this TIP. Nothing precludes someone implementing a better API in the future.

Regarding the “package require” comment …

While I am ok with always having the commands available, the package require need is for backward compatibility reasons as mentioned in the TIP. Existing applications that do not load Tcl’s registry package but have their own “registry” command (which may not even have anything to do with the Windows registry) will not be affected. If folks think this is not a likely issue, I have no objections to always having the commands available.

Regarding whether modules should not be compiled into the core…

I am not sure I completely understood the point or why it is a bad idea. For example, modules that are expensive to initialize can very well benefit from having to be explicitly loaded. Even ICU, were it to make it into the core in some form at some future point, would be an example. In any case, the static shell has always had these compiled in so not really breaking new ground here.

Regarding the alternative of always installing into C:/Tcl/lib (even in an embedded ZIP build)…

This precludes the ActiveState “basedll” or Roy’s “kitdll” style single file shared library configurations. Maybe that’s ok, maybe not. I do not use that config myself, not sure how many people do but separate DLL’s would make it not an option.

Thanks for the comments. And no need for apologies; soliciting differing opinions is the primary point of a TIP!

/Ashok

From: Jan Nijtmans <jan...@gm...> 
Sent: Sunday, October 20, 2024 4:56 PM
To: Kevin Kenny <kev...@gm...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 702 - static linking for registry and dde

Op zo 20 okt 2024 om 02:47 schreef Kevin Kenny:

For what it's worth, my understanding was that the original reason (which has fallen by the wayside) was that the Core proper didn't include anything that couldn't at least in concept be implemented on all three platforms.

Moreover, the extensions were thought to provide relatively simple worked examples of how to package an extension on Windows.

Sentiment used to favour unbundling: keeping features out of the Core but having the ones that were expected to be universal published as bundled extensions. That's one reason why I never proposed tdbc as bundled; a more important one was that I wasn't sure that the API was quite right and didn't want to freeze it for years or decades, as would happen if it came under TIP control and required a major Tcl release to introduce any incompatibilities. 

New leadership will of course have new directions, and if the pendulum is swinging back toward greater inclusion. I don't object.

I hope I will not the only one to be objecting, but here are my reasons:

1) dde and registry are 'dangerous' extensions. Dde has the same functionality as the "send" command,
    which was disabled due to security concerns. Registry makes it possible to read and write
    registry settings, which could also make the computer screw up completely. Separating
    them would make it possible to remove them, if some application doesn't need it.

2) dde and registry don't have the best API we can think of. dde would best be integrated in

   a new "send" command. The registry commands should feel more oo-like.

3) Every command should either be included, then no "package require" should be needed.

   Or it should be a module, activated by "package require". With TIP #702, "dde" and "registry"

   will be the only modules which are compiled into the Tcl library. Do we think it's a

   good example to other modules to do that? I don't think so. Either provide the "dde" and

   "registry" commands as being available always (which I wouldn't do due to 1) and 2),
  or make them a separate module loadable at wish (which they are now)

That said, I recognise the problem addressed in the TIP. Actually, there are 4 problems now.

1) Extracting ddl's from the zip-file takes time and is not 100% full-proof. That's something

which should be addressed (there already is a ticket for that)

2) Even if we can include dde.ddl and registry.ddl in the zip, the question is if we really
want to do that. We could just install those in C:\Tcl\lib\registry1.3 resp C:\Tcl\lib\dde1.4

(as is done now in Tcl 8.6), then all current problems are gone.

3) Currently, registry.dll is loaded at startup because the new "clock" command needs it.
It would be better to have a native clock subcommand, which reads the timezone
from the registry, in C, without the need to load registry.dll for doing that.

4) I think Tk also loads "registry.dll" at startup. I'm sure there's a way to prevent that too.

I'll create a new ticket, proposing to install registry and dde in C:\Tcl\lib, instead of packing

it into the zip-file. I think that's a better way going forward than TIP #702.

Sorry, Ashok,

Regards,

     Jan Nijtmans

Op ma 21 okt 2024 om 08:13 schreef Ashok:

> Regarding the alternative of always installing into C:/Tcl/lib (even in an
> embedded ZIP build)…
>
>
>
> This precludes the ActiveState “basedll” or Roy’s “kitdll” style single
> file shared library configurations. Maybe that’s ok, maybe not. I do not
> use that config myself, not sure how many people do but separate DLL’s
> would make it not an option.
>

Please read this "C:/Tcl" as : same installation directory as Tcl 8.6.
"nmake -f makefile.vc install" already installs those dll's there.
My counter-proposal is only a very minimal one in makefile.vc:
    Tcl Source Code: Diff (tcl-lang.org)
<https://core.tcl-lang.org/tcl/fdiff?v1=7e901ffe3d7b512f&v2=8c3ccb5be8fb00eb>

We could talk about changing the default Tcl install dir, but
that's another topic.

Hope this helps,
        Jan Nijtmans

Thread: [TCLCORE] TIP 702 - static linking for registry and dde

The Tool Command Language implementation

tcl-core