Re: New Xconq Windows Executable

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

On Fri, 29 Aug 2003, Juergen Ruehle wrote:

> intend to offend anybody.

No offense taken. If I am wrong about something, then I want to 
know.

> Sorry that I worded my explanation poorly. It is slightly more
> complicated. You can compile it this way and with some fiddling you
> can even link it to the X11 libraries, but it won't run. Tk's internal
> structures unfortunately are directly derived from the corresponding
> X11 structures. Access to these structures is through macros which are
> (mostly) inherited from X and defined in X11/* headers.

Yes, I know. When I was developing the BadDrawable fix a couple 
months ago (my first serious experience with Tcl/Tk) I saw that, 
in a number of cases, there was essentially a 1:1 correspondance 
between the Tk function and the X11 function.

> Tk uses the X structures directly while on Windows (and probably Mac
> OS) the layout is slightly different.

Obviously. On Windows, Tcl/Tk must at some level map its calls to 
GDI/DirectDraw calls. And on the Mac, it must map to QuickDraw (if 
Apple still calls it that; I have not programmed for the Mac in a 
long time). Naturally, there will be different underlying 
structures as well, since we are talking about different API's.

> opinions on the layout of structures (in this case cygwin tk84.dll
> using the windows layout and xconq compiled with X11 headers using the
> X11 layout) will result in a segmentation fault rather sooner than
> later 

Not surprising. I was not advocating this approach, btw.
I was suggesting that if one built it with the real X11 headers 
(and libraries) then one should be running it on the Cygwin 
XFree86 server (which is quite stable these days, IMO). However, 
we obviously should not be asking Xconq Windows users to do this.

After you mentioned (or I thought you mentioned) that the full 
Tcl/Tk source (not the AS flavor) could be built under Cygwin and 
that it could use the special Tcl/Tk X headers for Windows, __then 
I stated that I liked that approach better than the existing one 
of using the AS stuff.

> had some deliberate incompatibility with the X11 headers so this could
> be detected at compile time.

I thought the 3 dummy X functions at the end of tkwin32.c were a 
result of this incompatibility.

> Langer Rede kurzer Sinn:-)

I don't know any Deutsch, unless the words are cognate with 
the Anglo-Saxon inheritance of English. If it is a famous saying, 
please pardon my ignorance.

>  - a cygwin based xconq: and the I think it is The Right Thing(TM) to
>    use cygwin Tk in this case (because the installer is already in
>    place; actually we could host it using a setup file for the net
>    installer)

I agree. I am going to try this approach. With one twist: I will 
try to statically link the Cygwin Tcl/Tk stuff into Xconq, and 
include the necessary Tcl scripts as part of the end product. This 
will remove the need (if it works) of the end user needing to get 
the Cygwin Tk (which is even worse than having him/her get the AS 
stuff, IMO).

> outdated by now. It would be nice, if you could review it and perhaps
> commit it too.

OK, I will look it over. I may need to modify it to account for 
the fact that the win stuff is getting transplanted to the tcltk 
and sdl directories.

  Thanks,
   Eric