gmane.comp.lang.tcl.starkit

Re: Re: my kitgen kits drop the modified date from embedded files (windows)

Neil Bryant — 2012-05-20T04:58:23

Pat,

I want to thank you. Your instructions were exactly what I needed, and very
precise. I followed them, and have everything working properly.

As somebody who had just finished a project by deadline when this issue
popped up, I can't tell you how much stress you've saved me.

Thanks again,
Neil

On Mon, May 14, 2012 at 2:49 PM, Pat Thoyts <patthoyts< at >gmail.com> wrote:

Re: Re: my kitgen kits drop the modified date from embedded files (windows)

Pat Thoyts — 2012-05-14T21:49:11

You should not need to rebuild tclkit to update the manifest resource.
However, you need to peform
a couple of steps. The tclkit executable is a Windows PE executable
compressed with upx and
has a metakit database appended to the end. To change the resources
the safest method is to
split the file and decompress:
 sdx mksplit tclkit.exe  # this yields tclkit.head (the exe) and
tclkit.tail (the database)
then
  upx -d tclkit.head
Now you can use the mt tool to merge the manifest update with the
embedded manifest resource;
  mt -inputresource:tclkit.head;#1 -manifest:admin.manifest
-outputresource:tclkit.head;#1
then rejoin the pieces into a tclkit again:
   copy /b tclkit.head + tclkit.tail tclkit-admin.exe
(you could re-compress tclkit.head again here if you want a small exe)

Where admin.manifest contains just the new parts of the manifest required:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

The above steps give me a tclkit executable that requests elevation as
soon as I run it. However, if you are doing this you will
probably need to sign such an executable using a valid authenticode
certificate. You can't do that to a metakit based tclkit but
you can do that using the vlerq based executables. So re-do the steps
above using tclkit-gui.exe if you want to sign the exe.

Re: my kitgen kits drop the modified date from embedded files (windows)

Neil Bryant — 2012-05-13T21:31:50

Nope. For what it's worth, it seems if I add any type of manifest to the 
file, it mucks up file extractions.

If I use the files from the tclkit goolecode site (eg, 
tclkitsh-8.5.9-win32.upx.exe<https://code.google.com/p/tclkit/downloads/detail?name=tclkitsh-8.5.9-win32.upx.exe&can=2&q=>), 
file copies are correct. These exe's have no manifest, and appear to have 
been built without need of one.

I've been trying to compile with VC8, which needs a manifest, or it 
complains it can't find the runtimes. With the manifest, it breaks the copy 
datestamps. I can't (I don't think) compile without a manfest, since the 
exe just won't run.

I've been trying to compile in VC6, for comparison--to see if adding the 
manifest changes things--but I'm not having luck getting it to compile at 
all.

Right now, I've stared at this too long, so I'm putting it down while I can 
still form a sentence. I will pick it up later, or look into alternate 
forms of extraction.

If anybody has any thoughts, I would appreciate hearing them. If they are 
simple enough for me to follow, I will attempt them =]

Re: my kitgen kits drop the modified date from embedded files (windows)

Neil Bryant — 2012-05-13T17:01:42

FYI: I seem to have sorted it. A bit more testing, and I'll post where I'm 
at.

my kitgen kits drop the modified date from embedded files (windows)

Neil Bryant — 2012-05-13T00:16:36

Hoping somebody can tell me what I'm doing wrong.

I need tclkits with a manifest for 
requestedExecutionLevel=="requireAdministrator", so I downloaded kitgen, 
and the source code for tcl 8.5.11 and 8.6.b2.

I'm compiling with VS2005, which chokes on a warning embedding the 
manifest, but I got around that, and it looks like everything compiles 
correctly.

If I build a starkit with either of these binaries, and use it to copy a 
file to the computer, the file has no 'modified date' in Explorer. In file 
properties, all the files show a modified date of 1/1/1970 (Windows Epoch) 
leading me to presume that the actual value is null.

If I do a local copy (from the file system to the file system) all of the 
dates populate properly. It's only when I copy one out of the starkit onto 
the file system.

I've looked at the googlecode-starkit pages, and don't see anything 
relevant (closest: metakit gets confused with embedded certificates), nor 
do I find anything at the tcl wiki.

I'm going to try some other things--metakit-based kits for example, and 
eliminate machine-based causes--but I'm hoping somebody might have an idea 
what's going on or ideally have fixed it before =]

aTdHvAaNnKcSe

Ann: kbs 0.4.2

Rene Zaumseil — 2012-01-16T22:53:49

 kbs -- kitgen build system (version 0.4.2 for tcl/tk 8.5.11 and 8.6b2) 
 
 The system can generate [Tclkit] and [Tclkit Lite] executables,
 Tcl packages, starkits and starpacks for different operating systems.
 Additional documentation can be found under <http://wiki.tcl.tk/18146> 
 
 Sources and pre compiled binary interpreters are available from
   <http://sourceforge.net/projects/kbskit> 

 News

 * changed versions: tcl/tk 8.5.11, tcl/tk 8.6b2,
   bwidget 1.9.5, img 1.4 (svn #332), mentry 3.5, sqlite 3.7.9,
   tablelist 5.5, tcllib 1.14, tdom 0.8.3, thread 2.6.7, wcb 3.4,
   xotcl 1.6.7
 * Windows, Linux and Solaris binaries

 Regards, Rene

Re: critcl 64bit on MacOSX not working

Zbigniew Diaczyszyn — 2011-12-19T18:52:56

Am 17.12.2011 12:09, schrieb Zbigniew Diaczyszyn:

Cross-compiling a 64bit extension on a 32bit MacOSX host worked finally with the critcl2.kit from the digitalsmarties' site. Fortunately Snow Leopard 10.6.2 has already all the necessary 64bit libraries:

$ ./base-tcl8.5-thread-macosx10.5-i386-x86_64 critcl2.kit -pkg -target macosx-ix86 sha256c.tcl
Target:   macosx-ix86
Source:   sha256c.tcl 
Library:  sha256c.dylib
Package:  lib/sha256c

$ file lib/sha256c/macosx-ix86/sha256c.dylib 
lib/sha256c/macosx-ix86/sha256c.dylib: Mach-O universal binary with 2 architectures
lib/sha256c/macosx-ix86/sha256c.dylib (for architecture i386):Mach-O bundle i386
lib/sha256c/macosx-ix86/sha256c.dylib (for architecture x86_64):  Mach-O 64-bit bundle x86_64

Great work, this kit!

Sure, I will investigate the new critcl v3 ...

Re: Re: critcl 64bit on MacOSX not working

Steve Landers — 2011-12-17T12:02:20

Check out Andreas Kupries critcl3 http://wiki.tcl.tk/2523

Re: critcl 64bit on MacOSX not working

Zbigniew Diaczyszyn — 2011-12-17T11:09:44

Am 16.12.2011 22:37, schrieb Zbigniew Diaczyszyn:

I had chosen the Tk-basekit version.

My new trial was:

$ ./base-tcl8.5-thread-macosx10.5-i386-x86_64 critcl.kit -I macosx-86_64 -lib sha256c.tcl 
Source: sha256c.tcl 
Library: sha256c.dylib

Alas:

$ file sha256c.dylib 
sha256c.dylib: Mach-O dynamically linked shared library i386

So this is the way I should call critcl?

critcl 64bit on MacOSX not working

Zbigniew Diaczyszyn — 2011-12-16T21:37:03

I tried to compile a 64 bit sha256 C extension from the tcllib package with AS ./tclkit-8.5.11-macosx-universal and a critcl.kit from digitalsmarties.com (1. April 2010). MacOSX is Snow Leopard 10.6.2.

Compiling failed with this mysterious error message:

$ ./tclkit-8.5.11-macosx-universal critcl.kit -target macosx-x86_64 -pkg sha256c.tcl 
cannot load gbutton
cannot load Wikit::Gui

Can anybody help?

Zbigniew

Re: Have starkits ever been reported as viruses?

Steve Landers — 2011-10-09T23:04:11

On 10/10/2011, at 6:50 AM, jemptymethod wrote:


I have only seen it happen when using UPX compression (one reason why I don't bother with UPX these days).

Steve

Have starkits ever been reported as viruses?

jemptymethod — 2011-10-09T22:50:18

I'm asking this question because I've been told that an .exe I created
using a tool similar to Starkit but for another scripting language,
specifically the "One Click Ruby Application" (or OCRA for short), but
I've been told by some that the resultant .exe has been falsely
reported by McAfee as being a virus.

I'm wondering if anybody has ever had a similar experience with
Starkits? (Am hoping *not* :)

Starkit - Hard coded Path issue

ebeezee — 2011-09-30T15:10:12

I am trying to create a starkit/starpack for a bunch of TCL scripts that
someone else has written.  Throughout their code the path is hard coded.

In the first file they do this....

**myapp.tcl**
global path 
set path "C:/myapp"

source $path/common/gui.tcl

Then throughout their scripts they call source $path test/etc/etc.tcl all
over the place.

When I create the starkit the hard coded paths do not work anymore (for
obvious reasons).

How do I get the script to look within the VFS of the exe?

**main.tcl**

  package require starkit
  starkit::startup
  package require app-myapp


I tried adding something like this(below) in main.tcl  but it does not work.
(should it be in myapp.tcl?)

set home [file dirname [info script]]
source [file join $path myapp.tcl]

I also tried the following in main.tcl (which also does not work)

if {[info exist starkit::startup]} {
set path [file join starkit::topdir ... app-myapp]
} else {
set path{C:\Myapp}
}
source [file join $path smartdiag.tcl]

Any help or resources would be appreciated it. :)

Re: Accessing the tclkit executable in a starpack

Neil — 2011-07-20T03:45:57

If I understand you correctly, you can launch both of those using the
starpack.

Make a folder structure (mine has main.tcl in the root, with a /lib
below that).

---- main.tcl ----
package require starkit

if {[llength $::argv]==1 && [string length [lindex $::argv 0]] &&
[file exist [lindex $::argv 0]]} {
source [lindex $::argv 0]
exit
}

puts "Running remainder of script"
---- /main.tcl ----

Then put a 'hello world' script in the lib directory (i named it
int.tcl, and made a copy outside the whole thing called ext.tcl).

Pack it all up into an exe. If I run that as follows, I get this:

  C:\dev\tcl\template>extlaunch.exe ext.tcl
  hello

  C:\dev\tcl\template>extlaunch.exe extlaunch.exe/lib/int.tcl
  hello

Note, to run the internal file, you use the exe name as the base
directory...

Next, if you want to open a new process from your exe running one of
the scripts, you just change the 'Running remainder of script' line
with:
 exec [info nameofexecutable] ext.tcl
or
 exec [info nameofexecutable] [file join [info nameofexecutable] lib
int.tcl]

You'd probably be best off using cmdline for the options, and
accepting a -source option, or similar, and obviously you want to
merge this with a proper main.tcl; but essentially, all you do is
source/exec the script *if it's passed*, then exit; or go on with your
app otherwise.

On Jul 18, 12:17 pm, Paul <pault...< at >googlemail.com> wrote:

Accessing the tclkit executable in a starpack

Paul — 2011-07-18T18:17:49

Hi,

I want to distribute a Tcl app as a starpack. The computer that it
will be used on won't have Tcl installed on it, but of course, Tcl
will be in the starpack.

What I want to do is, from a tcl script within the starpack, kick off
another tcl process, using the tcl interpreter contained within the
starpack.

If I could do something like [open "|internal_tclkit external.tcl" r
+], that would be great, where internal_tclkit is the tclkit contained
within the starpack, and external.tcl is a tcl script that resides
outside the starpack.

Is something like this possible?

Thanks,

Paul.

(Actually, I would prefer to be able to kick off another process using
the internal tclkit and also an internal tcl script, but I've already
found out that's not posiible.)

Re: Cross-compiling 64bit library sha256 for Windows 7 64bit with critcl

Zbigniew Diaczyszyn — 2011-07-02T06:10:08

Richard Ellis offered a workaround:

* Get the latest file from:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-linux_20110627.tar.bz2/download

* Unpack it to <my-mingw64-path>

* remove machine and cpu description from the binaries' name: 

   cd <my-mingw64-path>/mingw/bin
   for name in * ; do mv -v $name ${name:19} ; done

* Add to PATH: export PATH=<my-mingw64-path>/mingw/bin:$PATH

* Run: tclkit critcl.kit -pkg sha256c.tcl

Cross compiling for Windows using Xmingwin
Source: sha256c.tcl 
Library: sha256c.dll
Package: /home/dia/Projekte/gorilla/lib/sha256c

As I have seen there is a version 2 for critcl.kit at http://www.digitalsmarties.com/pub/
dated 01-Apr-2010. It is offering a configuration file for comfortable setting of Cflags and Ldflags.
So the best will be to set there a working win64 configuration including the "-m64" option.

Cross-compiling 64bit library sha256 for Windows 7 64bit with critcl

Zbigniew Diaczyszyn — 2011-07-01T13:46:56

I hit a snag when trying to compile on a Linux (32bit) host a Windows 
64bit library version of sha256 from tcllib with critcl:

I have downloaded from the ming64 download site the version for a Linux 
host, set the PATH for critcl:

export PATH=/home/dia/mingw64/x86_64-w64-mingw32/bin/:$PATH

and started compiling:

$ tclkit critcl.kit -lib sha256c.tcl
Cross compiling for Windows using Xmingwin
Source: sha256c.tcl

Fri Jul 01 09:51:42 +0200 2011 - /home/dia/Projekte/gorilla/sha256c.tcl
gcc -r -nostdlib -DUSE_TCL_STUBS -I/home/dia/.critcl/Windows-x86 
-DTCL_BYTE_ORDER=1234 -o 
/home/dia/.critcl/Windows-x86/v035_7bf64913e94cd555e881b5a952aaab81_pic.o /home/dia/.critcl/Windows-x86/v035_7bf64913e94cd555e881b5a952aaab81.c 
/home/dia/Projekte/gorilla/sha256.c

In file included from 
/home/dia/.critcl/Windows-x86/v035_7bf64913e94cd555e881b5a952aaab81.c:5:0:
/home/dia/.critcl/Windows-x86/tcl.h:162:22: fatal error: stdio.h: Datei 
oder Verzeichnis nicht gefunden
compilation terminated.
/home/dia/Projekte/gorilla/sha256.c:52:20: fatal error: string.h: Datei 
oder Verzeichnis nicht gefunden
compilation terminated.
ERROR while compiling code in /home/dia/Projekte/gorilla/sha256c.tcl:

Error: Did not find: stdio.h and string.h

When doing the job for a 32bit Win library with the 32bit development 
environment of xmingw there is no problem at all.

So I don't understand what causes the problems. My stdio.h and string.h 
are in the default Linux path /usr/include ... A workaround would be to 
create some symlinks but I would like to know why critcl doesn't find 
the system libraries. Do I have to set some GCC environment variables or 
TCL variables?

Has anyone tried to compile a 64bit library for Win64?

By the way:

As for Linux my application is downloaded 100 times for 64bit and for 
32bit 114 times. I suppose for Windows it is the same meanwhile.

Re: Trying to test starsync

Kyle Bateman — 2011-06-22T20:03:52

I have gone through that tutorial trying to get a server set up with 
both apache and tclhttpd.  I think in each case, I'm probably having 
some technical issues with the web server setup.  In short, I haven't 
gotten it running yet but I'm' still fiddling with it.

In the mean time, I'm really more interested in getting it to run 
stand-alone (without a web server involved).  Any hints on getting that 
going?

I tried running: sdx starsync

Is that supposed to open up a socket that I can direct the "sdx update" 
to talk to using the -from switch?

Kyle

Re: Trying to test starsync

keb — 2011-06-21T21:36:42


Thanks for the pointers.  Is there one to show how to do it stand-
alone (without a web server)?

Re: Trying to test starsync

Steve Landers — 2011-06-19T23:53:41

On 20/06/2011, at 2:25 AM, Kyle Bateman wrote:


Yes


Both are possible


I suggest you take a look at the Starkit paper at hhttp://equi4.com/papers/skpaper1.html and in particular the section on Starsync at http://equi4.com/papers/skpaper7_2.html and also Setting up a Starsync Server at http://equi4.com/papers/skpaper7_3.html

Steve

Trying to test starsync

Kyle Bateman — 2011-06-19T18:25:07

Yup, no problem.
So after your pointer to the mailing lists, I have read a little more 
and it it looks like to me that I should probably do something like:

On the client side: sdx update
And on the server side: sdx starsync

So presumably, I could embed the equivalent of those commands into my 
server and client applications to do the automatic updating I want.

This week has been busy and I haven't gotten back to try a test on this 
yet but I will.  A few questions to help me get started:
- Am I on the right track?
- Is the server side meant to stand alone?  Or is it supposed to be set 
up as a cgi script under a web server?
- Is there already a reference example or tutorial somewhere for this?

Kyle