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

[Harald O. <har...@el...>]

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