Re: Cygwin, tcl/tk, and "native" [Was: Re: Interest in "native" Tcl/Tk/Expect/Itcl/... packages?]

[Jean-Sebastien Trottier <jst1 at email dot com>]

On Fri, Oct 15, 2004 at 01:35:16PM -0400, Charles Wilson wrote:
> In the interests of clarity, let's agree on some terminology:
> 
> a "cygwin" version --
>   uses the cygwin1.dll for runtime services (like printf etc)
> 
> a "native windows" version
>   uses msvcrt.dll for runtime services
> 
> an "X" version
>   uses xlib calls to draw stuff on a display
>   this requires a xserver of some kind
> 
> And here's the tricky one:
> 
> a "GDI" version
>   uses the Windows Graphics Device Interface calls to draw
>      stuff on a display -- WITHOUT using an Xlib emulator.
>   no Xserver needed.

I'm OK with these... thanks for clarifying.

> ------------------
> 
> Using these terms, what we already have is
>   cygwin, GDI
>
> ActiveState provides a
>   native, GDI
> 
> What is being proposed is
>   cygwin, X

I would say that what we already have is:
    Tcl/Tk: half-Windows/half-Cygwin, GDI
    Expect: Cygwin, no GUI

Putting aside the GUI part, let me explain the Tcl/Tk case with an
example:

    [jst@mc (0) ~/test]> ln -s /non-existant bad-link
    [jst@mc (0) ~/test]> ln -s /home/jst/ good-link

--> what we already have: half-Windows/half-Cygwin

    [jst@mc (0) ~/test]> /usr/bin/tclsh84
    % parray tcl_platform
    tcl_platform(byteOrder) = littleEndian
    tcl_platform(machine)   = intel
    tcl_platform(os)        = Windows NT
    tcl_platform(osVersion) = 5.1
    tcl_platform(platform)  = windows
    tcl_platform(user)      = jst
    tcl_platform(wordSize)  = 4
    % pwd
    C:/cygwin/home/jst/test
    % file type bad-link
    could not read "bad-link": no such file or directory
    % file type good-link
    directory
    % file readlink bad-link
    could not readlink "bad-link": no such file or directory
    % file readlink good-link
    could not readlink "good-link": invalid argument

--> what I'm proposing: Cygwin

    [jst@mc (1) ~/test]> /home/jst/test/bin/tclsh8.4.exe 
    % parray tcl_platform
    tcl_platform(byteOrder) = littleEndian
    tcl_platform(machine)   = i686
    tcl_platform(os)        = CYGWIN_NT-5.1
    tcl_platform(osVersion) = 1.5.11(0.116/4/2)
    tcl_platform(platform)  = unix
    tcl_platform(user)      = jst
    tcl_platform(wordSize)  = 4
    % pwd
    /home/jst/test
    % file type bad-link
    link
    % file type good-link
    link
    % file readlink bad-link
    /non-existant
    % file readlink good-link
    /home/jst/

--> For comparison: linux

    [jst@gw (0) ~/test]> tclsh8.4.4.0 
    % parray tcl_platform
    tcl_platform(byteOrder) = littleEndian
    tcl_platform(machine)   = i686
    tcl_platform(os)        = Linux
    tcl_platform(osVersion) = 2.4.27-rc3-smp-gw
    tcl_platform(platform)  = unix
    tcl_platform(user)      = jst
    tcl_platform(wordSize)  = 4
    % pwd
    /home/jst/test
    % file type bad-link
    link
    % file type good-link
    link
    % file readlink bad-link
    /non-existant
    % file readlink good-link
    /home/jst

As you can see above, the current Tcl version uses windows APIs to
access the filesystem. So, I would consider it as a mixed
half-Windows/half-Cygwin version...

Thus, I would say the Tk GUI is not the only problem in the current
version...

> Contrary to Jean-Sebastien Trottier's assertion, replacing the current 
> "cygwin, GDI" implementation with the "native, GDI" ActiveState version 
> will NOT satisfy the current requirements of insight/gdb and other 
> existing cygwin packages.

I never (did|meant to) "assert" that people should switch to using
ActiveState's Tcl.

Thanks to the list, the requirements are getting clearer now...
Read on...

> Somehow, a way must be found to have both a "cygwin, GDI" version of 
> tcl/tk/etc and a "cygwin, X" version -- where both can coexist on the 
> same machine seamlessly, making it easy to use for the end user and 
> develop against for the developer.
> 
> This is a hard problem, since it requires proper installation and 
> handling of DLLs, import libs, configure scripts (/usr/lib/tclConfig.sh 
> and /usr/lib/tkConfig.sh), and include files.  I am overjoyed to see 
> someone interested in tackling the issue.

Although (I think) it would be possible to have 2 Tk DLL's ("Cygwin, X"
vs "Cygwin, GDI"), I like Charles Wilson's idea to try and use W11:

    On Fri, 15 Oct 2004 14:22:02 -0400 (EDT), Charles Wilson wrote:
    > Rxvt already does this.  Do tk/itk make GDI calls that aren't
    > covered by rxvt's W11 library?  If so, wouldn't a more worthwhile
    > investment of effort be to extend the W11 library with the
    > implementation of the appropriate X11 calls (by plundering the
    > tk/itk GDI implementation as needed), and then use the W11 library
    > in the same way as rxvt does.

So, let's extend the terminology:

a "Cygwin, W11" version
    uses xlib calls to draw stuff on a display using the W11 library
    this works with or without a xserver running

With this "Cygwin, W11" Tk version, this would cover the insight/gdb
requirements without the need for 2 distinct Tk DLL's or majorly hacking
the code.

I will try and have a proof of concept working ASAP...


Thanks Charles, Chris, Corinna, Gerrit and all for your comments,
Sebastien