ANNOUNCE: freeWrap 6.2 released - Now with encryption
Dennis LaBelle
The freeWrap program turns TCL/TK scripts into single-file binary executable
programs. freeWrap can wrap TCL/TK applications that consist of multiple
script and binary files. freeWrap combines all the files together into a
single executable file.
freeWrap 6.2 is based on TCL/TK 8.4.12
freeWrap 6.2 now includes encryption for wrapped applications.
freeWrap executables are freely available for both Linux and Windows.
Instructions and source code for building freeWrap on both Windows and UNIX
platforms is also freely available.
The following additional variations of freeWrap are also available for
download:
freewrapPLUS a windowing application that includes TCL/TK along
with the BLT and TkTable extensions
freewrapTCLSH a console-only application which includes only TCL.
Please visit the freeWrap home page:
http://freewrap.sourceforge.net
Changes implemented in version 6.2
------------------------------------
1. FreeWrap 6.2 is based on TCL/TK 8.4.12.
2. The freeWrap::getStubSize procedure has been corrected to return the
proper stub size. It was returning too small a value.
3. A new encryption mechanism has been incorporated into freeWrap. All
wrapped files are encrypted by default.
4. The freeWrap documentation has been converted to PDF format.
5. Expanded the instructions for building freeWrap. See the new PDF
documentation file.
Robert Hicks
to know the pros and cons of each as compared with each other.
Robert
sleb...@gmail.com
> This message announces the release of freeWrap version 6.2
>
> The freeWrap program turns TCL/TK scripts into single-file binary executable
> programs. freeWrap can wrap TCL/TK applications that consist of multiple
> script and binary files. freeWrap combines all the files together into a
> single executable file.
>
> freeWrap 6.2 is based on TCL/TK 8.4.12
> freeWrap 6.2 now includes encryption for wrapped applications.
>
Thank you. I'm one of those who missed the encryption ability of the
old freewrap.
sleb...@gmail.com
> Is there a Starkit/Starpack vs. FreeWrap somewhere? I would be curious
> to know the pros and cons of each as compared with each other.
>
Not sure. For me it's just a matter of preference/taste. I personally
'hate' Starkits (hate is a strong word, I know, but my feelings for it
is that strong) and prefer FreeWrap.
Here's a short list of pros and cons in my experience:
Starkit/Starpack:
PRO - Supports a large number of platforms.
PRO - Is used by more people.
CON - Your Tcl code must fit in to the Starkit universe.
CON - Starpacking is a multi-step process (once you've made you code
Starkitable)
FreeWrap:
PRO - Simple, single-step wrapping.
PRO - FreeWrap will wrap YOUR CODE (instead of having to make your code
wrapable).
PRO - Built-in access to the Zip Virtual FileSystem so you can process
Zip files.
PRO - A version is available compiled with BLT and TkTable.
PRO - Supports generating executable with customised icon.
CON - Only supports Windows and Linux.
I used FreeWrap mainly because Starkits did not exist back then when I
wanted to wrap my project. Later when Starkits arrived I tried to
migrate my code to it but got frustrated because Starkits expects the
directory structure of my code to comply to its format. So I stuck with
FreeWrap.
Since I haven't used Starkits much feel free to add to the PRO/CON list
so that Robert gets a better picture for comparison.
Victor Wagner
> FreeWrap:
> CON - Only supports Windows and Linux.
I think that it would be no problem porting freewrap to FreeBSD or
Solaris.
--
That should probably be written:
no !@#$%^&*:@!semicolon
-- Larry Wall in <1997101618...@wall.org>
Jeff Hobbs
Uh, mostly that *all* your FreeWrap PROs apply to starkits as
well, and starkit is certainly available on many platforms.
I'm not sure what troubles you had in "porting" code for
starkits, but all you have to do is maintain code that
operates in a "self-relative" manner (like basing all paths
on the main scripts [file dirname]). That is good practice
for general coding anyways though.
As for the wrapping, I do it all in a one-liner. Of course,
I am using TclApp. I can't really say much about FreeWrap, as
I've never used it (never had the need). Starkits have
provided all the flexibility necessary. Furthermore, I even
have stardlls working.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
sleb...@gmail.com
> sleb...@yahoo.com wrote:
> > Robert Hicks wrote:
> >> Is there a Starkit/Starpack vs. FreeWrap somewhere? I would be curious
> >> to know the pros and cons of each as compared with each other.
> >>
> >
> > Not sure. For me it's just a matter of preference/taste. I personally
> > 'hate' Starkits (hate is a strong word, I know, but my feelings for it
> > is that strong) and prefer FreeWrap.
> > I used FreeWrap mainly because Starkits did not exist back then when I
> > wanted to wrap my project. Later when Starkits arrived I tried to
> > migrate my code to it but got frustrated because Starkits expects the
> > directory structure of my code to comply to its format. So I stuck with
> > FreeWrap.
> >
> starkits, but all you have to do is maintain code that
> operates in a "self-relative" manner (like basing all paths
> on the main scripts [file dirname]). That is good practice
> for general coding anyways though.
The trouble is the need to "port". With FreeWrap I didn't need to port
anything. FreeWrap readily took my working script and turned it into an
exe. Maybe it's also because I've gotten so used to FreeWrap's years
before Starkits appeared that I couldn't get myself to work the
'Starkit' way.
Wojciech Kocjan
<sleb...@gmail.com> wrote:
> Not sure. For me it's just a matter of preference/taste. I personally
> 'hate' Starkits (hate is a strong word, I know, but my feelings for it
> is that strong) and prefer FreeWrap.
>
> Here's a short list of pros and cons in my experience:
>
> Starkit/Starpack:
> PRO - Supports a large number of platforms.
> PRO - Is used by more people.
> CON - Your Tcl code must fit in to the Starkit universe.
Have you ever tried 'qwrap' command in sdx?
If you want just a one script file, qwrap will do it for you.
> CON - Starpacking is a multi-step process (once you've made you code
> Starkitable)
You can write a script to starpack everything. Since it's a matter of
vfs::mk4::Mount, you can do anything you like. You're not limited to any
tool :-)
> FreeWrap:
> PRO - Simple, single-step wrapping.
> PRO - FreeWrap will wrap YOUR CODE (instead of having to make your code
> wrapable).
If you don't source other files, it WILL work. otherwise I agree it's a
bit harder, but worth it.
> PRO - Built-in access to the Zip Virtual FileSystem so you can process
> Zip files.
Starkits can do this. There's vfs::zip included.
> PRO - A version is available compiled with BLT and TkTable.
dqkit supports that :-)
> PRO - Supports generating executable with customised icon.
You can do that with newer tclkits.
--
WK
Victor Wagner
: Here's a short list of pros and cons in my experience:
: Starkit/Starpack:
: PRO - Supports a large number of platforms.
: PRO - Is used by more people.
: CON - Your Tcl code must fit in to the Starkit universe.
: CON - Starpacking is a multi-step process (once you've made you code
: Starkitable)
There is additional CON. If you don't just use opaque tool and want to
understand how your code works, you have to learn about metakits - what
is it, how it is used and how it is related to starkit/starpack.
Freewrap uses zip archive instead of metakit. Probably any person who
like to learn how the things work, already knows what zip archive is and
how to operate it.
To be honest, we should add additional PRO - there is metakit filesystem
builtin, and if you want to use metakit as database, you can do it. But
why bother with metakit, if there is SQLite?
: FreeWrap:
: PRO - Simple, single-step wrapping.
: PRO - FreeWrap will wrap YOUR CODE (instead of having to make your code
: wrapable).
: PRO - Built-in access to the Zip Virtual FileSystem so you can process
: Zip files.
: PRO - A version is available compiled with BLT and TkTable.
: PRO - Supports generating executable with customised icon.
: CON - Only supports Windows and Linux.
There is additional PRO - freewrap is designed to be easily rebuild with
neccessary extensions statically compiled in. So, if you need to use
compiled extension, you can just build your own version of freewrap with
this extension statically compiled in. It eliminates security risk of
having to write compiled code into temporary user-writtable files.
I'm thinking to create 'universal' windows-scripting version of freewrap
with following extensions:
1. Tile - to make interface look native
2. Tcom - to operate with ActiveX objects
3. Michael Schwarz printing extension - to do native printing
4. winhelp extension - to be able to use help files in application.
In my opinion this set of extension would cover most needs for simple
system administration automation (with addition of script-only extension
such as tcllib, which can be easilywrapped)
--
Andy
with no source-code protection. Assume this takes of that ..
walto...@gmail.com
>> Zip files.
>Starkits can do this. There's vfs::zip included.
However, it's been my experience that with large files, zvfs is much
faster than vfs::zip.
When I tested them, to decide which to use in my application, it was on
an 800 mhz machine running Windows. The zvfs extension in Freewrap was
somewhere between 5 and 10 times faster than vfs::zip for my
application.
Gerald W. Lester
I've written several apps that I later wrapped as starkits/starpacks --
never had to change a line of code to get it to wrap. Then again I never
had to change a line of code to get my scripts to work on Linux vs Windows
(don't have access to Mac, but would also suspect no changes).
Exactly what are these "porting" issues that Freewrap people belive are
required.
I've seen several threads where people have problems with compiled
extensions and Freewrap, is this an issue? (never have followed the threads)
Gerald W. Lester
You should add in TWAPI.
Victor Wagner
: > In my opinion this set of extension would cover most needs
for simple
: > system administration automation (with addition of
script-only extension
: > such as tcllib, which can be easilywrapped)
: >
: >
: You should add in TWAPI.
Of course. And may be fiddl
--
Jeff Hobbs
> On Mon, 16 Jan 2006 04:06:42 +0100, sleb...@yahoo.com
> <sleb...@gmail.com> wrote:
>> FreeWrap:
>> PRO - Simple, single-step wrapping.
>> PRO - FreeWrap will wrap YOUR CODE (instead of having to make your code
>> wrapable).
>
> If you don't source other files, it WILL work. otherwise I agree it's a
> bit harder, but worth it.
If this is the basis of the "porting" issue with starkits vs.
freewrap, then you simply aren't writing portable code in the
first place. Your Tcl code should be written that you can
move the whole project to a different directory, even to a
different OS, without any code needing to change.
jo...@swri.edu
> On Mon, 16 Jan 2006 04:06:42 +0100, sleb...@yahoo.com
> <sleb...@gmail.com> wrote:
> > Not sure. For me it's just a matter of preference/taste. I personally
> > 'hate' Starkits (hate is a strong word, I know, but my feelings for it
> > is that strong) and prefer FreeWrap.
> >
> > Here's a short list of pros and cons in my experience:
> >
> > Starkit/Starpack:
> > PRO - Supports a large number of platforms.
> > PRO - Is used by more people.
> > CON - Your Tcl code must fit in to the Starkit universe.
>
> Have you ever tried 'qwrap' command in sdx?
>
> If you want just a one script file, qwrap will do it for you.
Unfortunately, this only works for creating starkits and not starpacks.
Comparing freeWrap and starpacks only make sense. Freewrap and
starkits are not really comparable.
> > CON - Starpacking is a multi-step process (once you've made you code
> > Starkitable)
>
> You can write a script to starpack everything. Since it's a matter of
> vfs::mk4::Mount, you can do anything you like. You're not limited to any
> tool :-)
I don't believe any documentation exists on this so you are limited to
what you can hack and find out.
> > FreeWrap:
> > PRO - Simple, single-step wrapping.
> > PRO - FreeWrap will wrap YOUR CODE (instead of having to make your code
> > wrapable).
>
> If you don't source other files, it WILL work. otherwise I agree it's a
> bit harder, but worth it.
I don't know if it was just me, but making everything into libraries was
not a priority until I was forced to go to starpacks. This made the
conversion a lot harder. Was it worth it? Honestly, I just wished
freeWrap worked on a Mac! :-) Starkits/starpacks solved problems I
did not have. It made the problems I did have harder to solve, but solvable
nonetheless.
What both are missing is a program to just wrap an executable and have it
find all the dependencies and bundle those as well. When that occurs, I
bet one of these will disappear since it will be so simple and people
tend to gravitate toward the simpler, working solution. Well, maybe not
totally disappear, just be less recommended.
Joey
Roy Terry
news:fHNyf.289335$0l5.211877@dukeread06...
> I've seen several threads where people have problems with compiled
> extensions and Freewrap, is this an issue? (never have followed the
threads)
No it is not a technical issue. It may be that
freewrap attracts the relative newcomers
and they naturally have more questions and
struggle in grasping generic wrapping issues such
as the need to put binary files where the OS
can see them.
Wojciech Kocjan
wrote:
> There is additional PRO - freewrap is designed to be easily rebuild with
> neccessary extensions statically compiled in. So, if you need to use
> compiled extension, you can just build your own version of freewrap with
> this extension statically compiled in. It eliminates security risk of
> having to write compiled code into temporary user-writtable files.
You can get that with dqkit (which is close to a starpack :-). And there's
even a bunch of extensions that are described so you just
tclsh gen/buildkit build -tcl -tk -itcl -itk -blt -tktable -openssl -tls
And you have an openssl built as well. All you need to do is create i.e.
parts/tktable.tcl.
That's why dqkit was built in the beginning - I wanted to be flexible in
what I compile in.
--
WK
Wojciech Kocjan
> Wojciech Kocjan <hceicjow...@kocjan.org> wrote:
>> On Mon, 16 Jan 2006 04:06:42 +0100, sleb...@yahoo.com
>> <sleb...@gmail.com> wrote:
>> > Not sure. For me it's just a matter of preference/taste. I personally
>> > 'hate' Starkits (hate is a strong word, I know, but my feelings for it
>> > is that strong) and prefer FreeWrap.
>> >
>> > Here's a short list of pros and cons in my experience:
>> >
>> > Starkit/Starpack:
>> > PRO - Supports a large number of platforms.
>> > PRO - Is used by more people.
>> > CON - Your Tcl code must fit in to the Starkit universe.
>>
>> Have you ever tried 'qwrap' command in sdx?
>>
>> If you want just a one script file, qwrap will do it for you.
>
> Unfortunately, this only works for creating starkits and not starpacks.
> Comparing freeWrap and starpacks only make sense. Freewrap and
> starkits are not really comparable.
>
>> > CON - Starpacking is a multi-step process (once you've made you code
>> > Starkitable)
>>
>> You can write a script to starpack everything. Since it's a matter of
>> vfs::mk4::Mount, you can do anything you like. You're not limited to any
>> tool :-)
> I don't believe any documentation exists on this so you are limited to
> what you can hack and find out.
I remember some file stating that [info nameofexe]/main.tcl is sourced.
The elegant way is to call starkit::startup, which initializes everything,
based on what it is. Then you do whatever you want (based on qwrap
generated code, I always do 'package require app').
For me this is quite clear, although as you said, probably not well
documented. It wouldn't take much time to wrap something to quickly wrap
files "on the fly" or maybe even a small GUI. But the most I'll do in this
case is offer help to someone interested in this :-) For all those
complaining about lack of a simple starpack wrapper -
http://wiki.tcl.tk/qstarpack.
>> > FreeWrap:
>> > PRO - Simple, single-step wrapping.
>> > PRO - FreeWrap will wrap YOUR CODE (instead of having to make your
>> code
>> > wrapable).
>>
>> If you don't source other files, it WILL work. otherwise I agree it's a
>> bit harder, but worth it.
> I don't know if it was just me, but making everything into libraries was
> not a priority until I was forced to go to starpacks. This made the
> conversion a lot harder.
> Was it worth it? Honestly, I just wished freeWrap worked on a Mac! :-)
> Starkits/starpacks solved problems I did not have.It made the problems I
> did have harder to solve, but solvable
> nonetheless.
I would say it this way - the set up time to start a new project is higher
(+ cvs overhead to put it all into version control). But you get the
benefit of being able to copy everything w/o any issues. I only lack ZIP's
abilities to be able to copy from/to a VFS from say total
commander/diropus.
> What both are missing is a program to just wrap an executable and have it
> find all the dependencies and bundle those as well.
The easiest way to do this is to wrap all popular extensions :-) But we'll
go Java size then ;-)
--
WK
Victor Wagner
> tclsh gen/buildkit build -tcl -tk -itcl -itk -blt -tktable
> -openssl -tls
What is -openssl extension? I didn't heard about this one.
Or you just mean compiling in openssl libraries, required by tls
extension?
--
Oh yeah. Forgot about those. Getting senile, I guess...
-- Larry Wall in <1997102615...@wall.org>
Gerald W. Lester
> I don't know if it was just me, but making everything into libraries was
> not a priority until I was forced to go to starpacks. This made the
> conversion a lot harder. Was it worth it? Honestly, I just wished
> freeWrap worked on a Mac! :-) Starkits/starpacks solved problems I
> did not have. It made the problems I did have harder to solve, but solvable
> nonetheless.
You don't have to make everything into libraries, just source them relative
to [file dirname [info script]]
> ...
Jim
startkits has stronger encryption built in?
Thanks,
Jim
"sleb...@yahoo.com" <sleb...@gmail.com> wrote in message
news:1137380802.4...@z14g2000cwz.googlegroups.com...
Steve Landers
>>
>> If you want just a one script file, qwrap will do it for you.
>
> Unfortunately, this only works for creating starkits and not starpacks.
> Comparing freeWrap and starpacks only make sense. Freewrap and
> starkits are not really comparable.
sdx qwrap myscript.tcl
sdx unwrap myscript.kit
sdx wrap myscript.exe -runtime tclkit.exe
If three lines is too much, you can easily script sdx to do the above.
> What both are missing is a program to just wrap an executable and have it
> find all the dependencies and bundle those as well. When that occurs, I
> bet one of these will disappear since it will be so simple and people
> tend to gravitate toward the simpler, working solution. Well, maybe not
> totally disappear, just be less recommended.
Look at "sdx fill"
Steve
Victor Wagner
> Does Starkits have encryption function? If yes, which one,
> freewrap or startkits has stronger encryption built in?
Both are weak anyway. Cryptography is not intended to protect data from
legitimate user. Period.
So, if you encrypt you code, you have to provide key somewhere inside
wrapped executable, so intepreter can decrypt it when sourcing.
Attacker wouldn't brute-force encryption, he would just use debugger to
look up this key.
Uwe Klein
What about a 2 stage start? ( well if you want to be really restrictiv about it.)
First get a basic tcl package running and then get a key for further decryption
of the main package ( i.e. the functional payload ) per secure transport
from a keyserver?
one other possibility would be to get (parts? of) the payload on the same way.
uwe
Victor Wagner
: Victor Wagner wrote:
: > Jim <donot...@nowhere.com> wrote:
: >
: >>Does Starkits have encryption function? If yes, which one,
: >>freewrap or startkits has stronger encryption built in?
: >
: >
: > Both are weak anyway. Cryptography is not intended to
protect data from
: > Attacker wouldn't brute-force encryption, he would just use debugger to
: > look up this key.
: What about a 2 stage start? ( well if you want to be really restrictiv about it.)
: First get a basic tcl package running and then get a key for further decryption
: of the main package ( i.e. the functional payload ) per secure transport
: from a keyserver?
First, it doesn't prevent attacker from anything. At some time every
line of code is in the machine memory unencrypted. May be not simultaneously.
Second, it creates too much problems for honest users. They would be
unable to use legally purcashed application if they cannot access your
keyserver for some reason, say drunken bulldozer driver destroyed optic
fiber somewhere between their location and yours.
: one other possibility would be to get (parts? of) the payload on the same way.
It is better. At least you can give your users some arguments for it,
for instance, say that this ensures that they always have latest version
of code with all the bugs fixed.
--
Wojciech Kocjan
> Does Starkits have encryption function? If yes, which one, freewrap or
> startkits has stronger encryption built in?
Starpack do not offer encryption. Anyway, I think tclbytecode is much
better than encryption. So it doesn't really matter much.
And in terms of obscurity, Starpack does not use zip and for me that's
better since some tools automatically recognize and open executables with
zip archives attached to them.
--
WK
MH
Victor Wagner <vi...@45.free.net> wrote:
>Uwe Klein <uwe_klein_...@t-online.de> wrote:
>: Victor Wagner wrote:
>: > Jim <donot...@nowhere.com> wrote:
>: >
>: >>Does Starkits have encryption function? If yes, which one,
>: >>freewrap or startkits has stronger encryption built in?
>: >
>: >
>: > Both are weak anyway. Cryptography is not intended to
>protect data from
>: >
>: > Attacker wouldn't brute-force encryption, he would just use debugger to
>: > look up this key.
>: What about a 2 stage start? ( well if you want to be really restrictiv
>about it.)
>: First get a basic tcl package running and then get a key for further
>decryption
>: of the main package ( i.e. the functional payload ) per secure transport
>: from a keyserver?
>
>First, it doesn't prevent attacker from anything. At some time every
>line of code is in the machine memory unencrypted. May be not simultaneously.
>
>Second, it creates too much problems for honest users. They would be
>unable to use legally purcashed application if they cannot access your
>keyserver for some reason, say drunken bulldozer driver destroyed optic
>fiber somewhere between their location and yours.
Believe it or not, this happened to me (almost this scenario). Backhoe
driver who was flatting ground for a new driveway for the new house being
built next door ripped the cable-tv cable, and thus my cable modem was dead
for a couple of days...
Mattias
Dennis LaBelle
If you read the freeWrap documentation you will realize that I didn't make
it as easy as that.
Victor Wagner
> If you read the freeWrap documentation you will realize that
> I didn't make it as easy as that.
It just takes more determined and qualified attacker. Which would read
freewrap SOURCE before trying to attack, and know exactly where to set
breakpoints.
--
The first is to ensure your partner understands that nature has root
privileges - nature doesn't have to make sense.
-- Telsa Gwynne
sleb...@gmail.com
> Exactly what are these "porting" issues that Freewrap people belive are
> required.
>
This thread have given us joey's post and the following discussion it
generated as an example of porting issues. Joey had to convert his code
to libraries to make it work with Starpacks when it was working fine
with FreeWrap before.
Sometimes, making code self-relative is a hassle. Of course, your own
code is usually always self-relative but packages you required are
located in a specific place in your system and not self-relative to
your code.
FreeWrap does not require the code to be self-relative as it
(semi-)automatically resolves paths for you. So for example if I need
to wrap tcllib into my executable I merely need to specify the relevant
files in my command line and it gets wrapped. Better, the filenames can
be listed in an 'include' file. On dos the 'include' file can easily be
generated by:
dir /B /S c:\tcl\lib\tcllib1.7 > include.txt
or if I just need base64:
dir /B /S c:\tcl\lib\tcllib1.7\base64 > include.txt
Then it just be wrapped by:
freewrap myApp.tcl -f include.txt
The include.txt can of course be edited to remove unneeded files.
I guess it all boils down to FreeWrap not needing the script to be
self-relative.
jo...@swri.edu
> jo...@swri.edu wrote:
> > Wojciech Kocjan <hceicjow...@kocjan.org> wrote:
> >> Have you ever tried 'qwrap' command in sdx?
> >>
> >> If you want just a one script file, qwrap will do it for you.
> >
> > Unfortunately, this only works for creating starkits and not starpacks.
> > Comparing freeWrap and starpacks only make sense. Freewrap and
> > starkits are not really comparable.
>
> sdx qwrap myscript.tcl
> sdx unwrap myscript.kit
> sdx wrap myscript.exe -runtime tclkit.exe
>
> If three lines is too much, you can easily script sdx to do the above.
This is only true on the simplest of Tcl scripts. If the code calls any other
Tcl libraries or files, this three line solution does not work.
> Look at "sdx fill"
This looks really nice and would have been great if I had seen it before I had
to do my conversions! :-)
I think it would be nice if the qwrap would call fill and which would collect
everything needed and just create the starkit. The next step should be to
create the exe. Why should the user have to manually do the unwrap since they
are not changing it in anyway?
The reason I feel this way is "wish <scriptname>.tcl" just works regardless of
library or "source"ing. You can move files around and it still works provided
everything is relative to the script. With starkit/packs, things have to be
in the right place.
Oh well, I already converted to starpacks and am more or less satisfied.
Joey
Robert Hicks
> You can do that with newer tclkits.
If I had a gripe it would be that it should be "easier" to do the
custom icon. That is probably the only thing that really annoys me
about tclkits.
Robert
Robert Hicks
the directory structure where it needs to go and I have an exe ready to
go.
Robert
lvi...@gmail.com
According to Steve Landers <st...@DigitalSmarties.com>:
:Look at "sdx fill"
$ sdx fill
Specify one of the following commands:
addtoc eval fetch ftpd httpd httpdist ls lsk md5sum mkinfo mkpack mkshow mksplit qwrap ratarx rexecd starsync sync tgz2kit treetime unwrap update version wrap
For more information, type: /volws/lwv27/ldatae/bin/sdx help ?command?
$ sdx version
2006/01/13 19:49:30 13067-68121
Is there a newer version of sdx somewhere that has fill?
--
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Steve Landers
> According to Steve Landers <st...@DigitalSmarties.com>:
> :Look at "sdx fill"
>
> $ sdx fill
> Specify one of the following commands:
> addtoc eval fetch ftpd httpd httpdist ls lsk md5sum mkinfo mkpack mkshow mksplit qwrap ratarx rexecd starsync sync tgz2kit treetime unwrap update version wrap
> For more information, type: /volws/lwv27/ldatae/bin/sdx help ?command?
> $ sdx version
> 2006/01/13 19:49:30 13067-68121
>
> Is there a newer version of sdx somewhere that has fill?
$ sdx update sdx.kit
You'll end up with the latest version (or get
http://mini.net/sdarchive/sdx.kit)
Steve
Robert Hicks
include kits needed to run startkits?
Jeff Hobbs
> This is probably an ActiveState question, but I wonder if they could
> include kits needed to run startkits?
ActiveTcl does fully support starkits. The required components
are mk4tcl, memchan, vfs ... and maybe one or two other that
I've forgotten (and Tcl 8.4).