Cygwin Upgrade/Integration nightmare with TCL

[Gerhard Reithofer]

Hi,
I'm using Cygwin as "Integration" tool to write platform independent
software, GUI tools and scripts which can be used on Windows and Unix,
integrate Unix tools into "normal" administration tasks, etc. for ca. 2
years.

Unhappy about the relatively old Tcl version 8.4 I upgraded to newest
Cygwin version 1.7.20, because I know that it has already 8.5 as
standard Tcl version on board.

After upgrading to 3.1.17 I was surprised, that many of my TCL scripts
do not work anymore.
After some investigation I found out, that this version does not load
TWAPI (a very frequently used module), which worked on older
version well.

The reason, why it does not load is, that new Tcl uses IMHO real strange
platform variables:
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = i686
tcl_platform(os) = CYGWIN_NT-5.2-WOW64
tcl_platform(osVersion) = 1.7.20(0.266/5/3)
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 4
tcl_platform(user) = rg018104
tcl_platform(wordSize) = 4

That does not nearly correspond to anything on the list on the Wiki:
http://wiki.tcl.tk/1649

Of course this never will load the Windows extension "TWAPI.
TWAP uses the following code for initializing (pkgIndex.tcl):
if {$::tcl_platform(os) eq "Windows NT" &&
($::tcl_platform(machine) eq "intel" ||
$::tcl_platform(machine) eq "amd64") &&
[string index $::tcl_platform(osVersion) 0] >= 5} {
source [file join $dir twapi_version.tcl]
source [file join $dir twapi_buildid.tcl]
package ifneeded $::twapi::package_name $twapi::patchlevel [list source [file join $dir twapi.tcl]]
}

I'm surpised!
Does it really make sense to report the Windows extension
(basically dll-redirects) as Opertating System CYGWIN_xxx?
What does the "osVersion" 1.7.20(0.266/5/3) mean, it's just a "library"
version?
Also the tcl_platform(machine) was reported as "intel" earlier, the
older version was a "normal" windows version "Windows NT" with version
"5.2".

In my desperation I tried a hack and I set the platform variables
hardcoded to the old version values in the pkgIndex file. The result
was, that the load function was called, but it fails on next error:
can't find package registry.
I. e. also the Windows specific funtion "registry" seems to be missing
and therfore it is absolutely unusable as "Intergration platform" which
it used before.
And finally the "Wigdet" style looks like 8.4 under Unix. I know that
this is "themeable" in the meantime, but it is definitely not a piece of
Windows software.

Another topic is, that the menus behave rather different, as it is
(almost) not possible to select a cascaded submenu, because after
leaving the cursor from the main menu window, the menu is unposted. But
this may be my fault, I will investigate this more - at least in old TCL
8.4 on Cygwin the same script works well, but this was a "Windows NT"
with version "5.2".

Or did I miss any important information, which brings back the Windows
compatibility into this version?

I'm really hoping this will be possible, to come back to my seamless
integrated Unix/Windows world, now it cannot be used for my work :(

--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at

[tcltk-d]

Hi, Gerhard

First of all,why you are strugging with so cumbersome cygwin?
Is tclsh(or wish on microsoft-OS) itself isn't a nice and simple command-shell?

proc ls {args} {exec cmd /C dir $args}
or
proc ls {args} {exec bash -e ls $args}

may show you files list on tcl-STDOUT,


2013-6-28 Gerhard Reithofer:

[Gerhard Reithofer]

Hi

On Thu, 27 Jun 2013, tcltk-d wrote:

> Hi, Gerhard
>
> First of all,why you are strugging with so cumbersome cygwin?

Because any environment is more productive than Windows standard tools.
The unix'ish Cygwin is much more produchtive!

> Is tclsh(or wish on microsoft-OS) itself isn't a nice and simple command-shell?

Maybe, but "nice and simple" is not enough for my work.
Tclsh is only a part from my working environment and there are also
different unixes where I'm working on and I use a larger amount of
existing (often self develped) tools.

> proc ls {args} {exec cmd /C dir $args}
> or
> proc ls {args} {exec bash -e ls $args}
>
> may show you files list on tcl-STDOUT,

Sorry, but that is not how I'm working. A file listing inside tcl will
always be generated via the tcl function [glob] ;)

I'm more thinking of such a situation.

I have a proc:
Debug obj [dbglevel]

The oneliner:
grep -wn "Debug" */*.tcl *.tcl|grep -v '[0-9]$'|cut -d: -f1,2

gives me a list with all TCL files (incl. the directory name) in the
current directory and all directories exact one level below and the
corresponing line numbers, where I used my TCL function "Debug"
*without* the optional parameter dbglevel.

Any similar function in Windows? Not even expecting that this works on
another platform!

Thank you for your freedback.

> 2013-6-28 Gerhard Reithofer:
> > Hi,
> > I'm using Cygwin as "Integration" tool to write platform independent
> > software, GUI tools and scripts which can be used on Windows and Unix,
> > integrate Unix tools into "normal" administration tasks, etc. for ca. 2
> > years.