ANNOUNCE: freeWrap 6.1 released 
Author Message
 ANNOUNCE: freeWrap 6.1 released

This message announces the release of freeWrap version 6.1

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.1 is based on TCL/TK 8.4.11

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://www.*-*-*.com/

Changes implemented in version 6.1
------------------------------------
   1. FreeWrap 6.1 is based on TCL/TK 8.4.11.

   2. FreeWrapPlus can now load BLT into slave interpreters. The necessary
patch has been applied to the BLT code.

   3. FreeWrap 6.0 did not recognize UNC file paths properly. This problem
has been corrected. FILE and GLOB commands that use UNC file paths will now
work correctly.

   4. Corrected operation of the (-i) icon change option.

   5. Added -forcewrap command line option to force freeWrap to act as a
wrapping program even if it has been renamed.

   6. Added a -debug command line option which opens a console window so the
user can see debug messages while wrapping.

   7. Corrected formatting of makeZIP command description in the HTML
documentation.

   8. The freeWrap program is compressed with the UPX utility only for the
Linux version. This will enable modification (under Windows) of the wrapped
application file's resources with third part utilities.



Fri, 15 Feb 2008 09:59:50 GMT  
 ANNOUNCE: freeWrap 6.1 released
freeWrap seems to serve much the same purpose as Starkits.
Would anyone care to comment on what the differences are?

--
Bill Poser, Linguistics, University of Pennsylvania



Fri, 15 Feb 2008 12:55:27 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:

> freeWrap seems to serve much the same purpose as Starkits.
> Would anyone care to comment on what the differences are?

One of the most important differences, at least for me, is the fact
that freewrap also comes in a form with BLT included. It is not
possible to use BLT together with starkits (because BLT is not yet
stubs-enabled).

Torsten



Fri, 15 Feb 2008 14:31:55 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:
> freeWrap seems to serve much the same purpose as Starkits.
> Would anyone care to comment on what the differences are?

If you need to support a Mac, you have to use Starkits.  I don't think the
Mac lets you modify the program if it is running so I don't think this
can be fixed.  :-(

I'd love to be proven wrong though! :-)

joey



Fri, 15 Feb 2008 23:14:12 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:


>>freeWrap seems to serve much the same purpose as Starkits.
>>Would anyone care to comment on what the differences are?

> One of the most important differences, at least for me, is the fact
> that freewrap also comes in a form with BLT included. It is not
> possible to use BLT together with starkits (because BLT is not yet
> stubs-enabled).

The BLT in CVS (v3.0alpha) is stubs enabled.  I can't tell you
much about it other than that as George is close-lipped about
its current development.

--
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos



Thu, 21 Feb 2008 10:58:09 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:



>>> freeWrap seems to serve much the same purpose as Starkits.
>>> Would anyone care to comment on what the differences are?

>> One of the most important differences, at least for me, is the fact
>> that freewrap also comes in a form with BLT included. It is not
>> possible to use BLT together with starkits (because BLT is not yet
>> stubs-enabled).

> The BLT in CVS (v3.0alpha) is stubs enabled.  I can't tell you
> much about it other than that as George is close-lipped about
> its current development.

Interesting, thanks. Would you know if it is compatible with Tk 8.5 at this time?


Thu, 21 Feb 2008 17:49:55 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:
>  Would you know if it (BLT 3.0) is compatible with Tk 8.5 at this time?

I would very much doubt it.  George has stated on several occasions that it
is too much trouble to try to track alpha and beta Tcl releases with BLT.

Bob
--

Mayo Foundation                                 (507) 538-5495
200 First St. SW                            FAX (507) 284-9171
Rochester MN, 55901  USA            http://www.mayo.edu/sppdg/



Sun, 24 Feb 2008 04:22:19 GMT  
 ANNOUNCE: freeWrap 6.1 released
Freewrap is simpler to use. Just one command and BAM you have an
executable.
It doesn't depend on special directory structures etc.
I tried using Starkits but then gave up. I only need to support Windows
anyway so the multi-platform nature of Starkits don't give me much.
Plus, it's actually Starkits that's serving the same purpose as
Freewrap. They may be roughly the same age but I was delivering
Freewrapped binaries to clients long before Starkits were on Google's
radar. I found freewrap first because it was on Google at least one
year before starkits.
I much prefer freewrap's way of doing things. Now.. if only someone
would port freewrap to the Mac...


Mon, 25 Feb 2008 11:04:04 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:

> Freewrap is simpler to use. Just one command and BAM you have an
> executable.
> It doesn't depend on special directory structures etc.
> I tried using Starkits but then gave up. I only need to support Windows
> anyway so the multi-platform nature of Starkits don't give me much.
> Plus, it's actually Starkits that's serving the same purpose as
> Freewrap. They may be roughly the same age but I was delivering
> Freewrapped binaries to clients long before Starkits were on Google's
> radar. I found freewrap first because it was on Google at least one
> year before starkits.

Here, hear!  I think the same thing.  Currently, I am using Starpacks,
but only because I need to support the Mac.  Starpacks are really complex
and for us have actually caused some problems because of the wrapping
mechanism and the fact that certain commands no longer work under a
starpack with no workarounds.

Starpacks only advantage is if you need to support multiple platforms
in a SINGLE executable, rather than having different executables for
each platform.  

Quote:
> I much prefer freewrap's way of doing things. Now.. if only someone
> would port freewrap to the Mac...

I tried doing it once.  The problem was that freeWrap needs to write to
the end of an open executable to make its own executable.  This is
verboten on the Mac so I don't think it is possible.

<THINKING OUT LOUD>

Starpacks seem to be what everyone is working on so it might be possible
to make starpacks as simple as freeWrap.  What we did was make our
build system create the directory structure required by starkit and
then copy all our Tcl files into it.  Then, the build system does the
starpack wrapping commands.  

What could be done would be to add another command to the starpack
sdx.kit that does this step or even better, finds all the dependencies,
puts them in whatever directory structure it deems necessary, and then
does the wrap.  Maybe if that were to happen, more people would be
on the starpack bandwagon?

</THINKING OUT LOUD>

Joey



Mon, 25 Feb 2008 22:51:38 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:

> Here, hear!  I think the same thing.  Currently, I am using Starpacks,
> but only because I need to support the Mac.  Starpacks are really complex
> and for us have actually caused some problems because of the wrapping
> mechanism and the fact that certain commands no longer work under a
> starpack with no workarounds.

Out of curiosity (I don't use starkits much, as I keep landing at jobs
that use other techniques) what commands no longer work that are causing
you problems?


Mon, 25 Feb 2008 23:54:15 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:


> > Here, hear!  I think the same thing.  Currently, I am using Starpacks,
> > but only because I need to support the Mac.  Starpacks are really complex
> > and for us have actually caused some problems because of the wrapping
> > mechanism and the fact that certain commands no longer work under a
> > starpack with no workarounds.

> Out of curiosity (I don't use starkits much, as I keep landing at jobs
> that use other techniques) what commands no longer work that are causing
> you problems?

The ones I have found are auto_execok, file, and glob.  The problem is
the name of the executable is now a directory so commands which would
normally work for the starpack as a file now no longer work from within the
starpack on the starpack itself.  Does that make sense?

For example, if you have a starpack named "PROG": "file mtime PROG" from
within the starpack PROG returns 0.  "auto_execok PROG" returns false from
within PROG even though PROG is a perfectly fine executable in the path.

The reason is so you can use the file, glob, and auto_execok (maybe?)
on files within the starpack itself.  This is great if that's what you need
to do; however, it will not work as before if you were expecting to use any
of these commands on your new starpack.  As far as I know, there are no
workarounds either.  :-(

Joey



Wed, 27 Feb 2008 00:03:54 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:



>>>Here, hear!  I think the same thing.  Currently, I am using Starpacks,
>>>but only because I need to support the Mac.  Starpacks are really complex
>>>and for us have actually caused some problems because of the wrapping
>>>mechanism and the fact that certain commands no longer work under a
>>>starpack with no workarounds.

>>Out of curiosity (I don't use starkits much, as I keep landing at jobs
>>that use other techniques) what commands no longer work that are causing
>>you problems?

> The ones I have found are auto_execok, file, and glob.  The problem is
> the name of the executable is now a directory so commands which would
> normally work for the starpack as a file now no longer work from within the
> starpack on the starpack itself.  Does that make sense?

Yes. I knew about that restriction. I guess it never occured to me that
a program would want use a filesystem command on itself. Can you not
simply special-case the starkit itself? That is, put a wrapper around
glob so that if you're globbing something that should return the
startkit, you append [info nameofexecutable] to the result? Likewise for
auto_execok and the file commands.

I can understand though, how this would be problematic if you're writing
something like a file manager.



Wed, 27 Feb 2008 01:47:46 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:


>> The ones I have found are auto_execok, file, and glob.  The problem is
>> the name of the executable is now a directory so commands which would
>> normally work for the starpack as a file now no longer work from within the
>> starpack on the starpack itself.  Does that make sense?

>Yes. I knew about that restriction. I guess it never occured to me that
>a program would want use a filesystem command on itself. Can you not
>simply special-case the starkit itself? That is, put a wrapper around
>glob so that if you're globbing something that should return the
>startkit, you append [info nameofexecutable] to the result? Likewise for
>auto_execok and the file commands.

What I usually do is to mount the starkit's VFS at someplace
like "/kit", instead of at [info nameofexecutable].

Of course this causes similar problems if there's a directory
named "/kit" in the real filesystem.  But that directory usually
doesn't exist whereas [info nameofexecutable] always does :-)

--Joe English



Wed, 27 Feb 2008 03:38:59 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:

> >>>mechanism and the fact that certain commands no longer work under a
> >>>starpack with no workarounds.

> > The ones I have found are auto_execok, file, and glob.  The problem is
> > the name of the executable is now a directory so commands which would
> > normally work for the starpack as a file now no longer work from within
> > the starpack on the starpack itself.  Does that make sense?

> Yes. I knew about that restriction. I guess it never occured to me that
> a program would want use a filesystem command on itself. Can you not
> simply special-case the starkit itself? That is, put a wrapper around
> glob so that if you're globbing something that should return the
> startkit, you append [info nameofexecutable] to the result? Likewise for
> auto_execok and the file commands.

> I can understand though, how this would be problematic if you're writing
> something like a file manager.

In fact this program is a file manager type of program!  I was able to work
around everything but the "file mtime" command.  

What I don't understand is why this restriction must exist.  Why couldn't
the filesystem/starpack name be given some other temp name which is
retrievable from info or something rather than making a reserved word for
the file.  All the other commands would work and if someone wanted to do
something within a starpack, they have a new [info starpackname] to work
with.

Joey



Fri, 29 Feb 2008 22:35:59 GMT  
 ANNOUNCE: freeWrap 6.1 released

Quote:



> >> The ones I have found are auto_execok, file, and glob.  The problem is
> >> the name of the executable is now a directory so commands which would
> >> normally work for the starpack as a file now no longer work from within
> >> the starpack on the starpack itself.  Does that make sense?

> >Yes. I knew about that restriction. I guess it never occured to me that
> >a program would want use a filesystem command on itself. Can you not
> >simply special-case the starkit itself? That is, put a wrapper around
> >glob so that if you're globbing something that should return the
> >startkit, you append [info nameofexecutable] to the result? Likewise for
> >auto_execok and the file commands.

> What I usually do is to mount the starkit's VFS at someplace
> like "/kit", instead of at [info nameofexecutable].

> Of course this causes similar problems if there's a directory
> named "/kit" in the real filesystem.  But that directory usually
> doesn't exist whereas [info nameofexecutable] always does :-)

This is interesting.  Do you do this when you are building the starkit or
is this something you do within your code?  Can you give me a simple
example/walkthrough?

Couldn't the starpack do this itself?

Thanks,
Joey



Fri, 29 Feb 2008 22:39:30 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ANNOUNCE: freeWrap 6.2 released - Now with encryption

2. ANNOUNCE: freeWrap 6.0 released

3. ANNOUNCE: freeWrap 5.61 released

4. ANNOUNCE: freeWrap 5.6 released

5. ANNOUNCE: Release of freeWrap version 5.5

6. ANNOUNCE: freeWrap version 5.4 released

7. ANNOUNCE: freeWrap version 5.3 released

8. ANNOUNCE: freeWrap 5.2 released

9. ANNOUNCE: freeWrap 5.1 released

10. ANNOUNCE: freeWrap 5.0 released

11. ANNOUNCE: freeWrap 4.4 released

12. ANNOUNCE: freeWrap 4.3 released

 

 
Powered by phpBB® Forum Software