This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


Using these terms, what we already have is
  cygwin, GDI

ActiveState provides a
  native, GDI

What is being proposed is
  cygwin, X

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.

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/ and /usr/lib/, and include files. I am overjoyed to see someone interested in tackling the issue.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]