* Re: New Xconq Windows Executable
@ 2003-08-27 18:04 Bill Macon
0 siblings, 0 replies; 15+ messages in thread
From: Bill Macon @ 2003-08-27 18:04 UTC (permalink / raw)
To: xconq7
This would be much more convenient, especially for new users with no Linux
or Cygwin experience. If the new version of Xconq could package ALL
required files/directories into a Windows installation program, that would
be ideal. Download one file, hit "Install," and then play. Future updates
to binaries or game modules could be made available as a patch file. The
idea should be to keep this as simple as possible to bring in new players -
hence new ideas and game mods.
Bill
>From: Eric McDonald <mcdonald@phy.cmich.edu>
>As far as the AS licensing is concerned, it looks like all that
>Xconq really needs to do is get written permission to bundle the
>DLL's and Tk Tcl scripts (actually the legalese refers to the
>"Package", which is a superset of what we want/need, I think). AS
>seems to be fairly OpenSource-friendly, so it might be worth a
>shot.
_________________________________________________________________
MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
^ permalink raw reply [flat|nested] 15+ messages in thread
* New Xconq Windows Executable @ 2003-08-27 4:29 Eric McDonald 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 0 siblings, 2 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-27 4:29 UTC (permalink / raw) To: xconq7 Hello all, I have just finished building and briefly testing a fresh Xconq executable for Windows. It was built and ran on Windows XP; hopefully other versions of Windows will not have trouble. I have bundled the Cygwin DLL with Xconq. Hopefully this will eliminate any need for people to install Cygwin. (*fingers crossed*) I linked against Tcl/Tk 8.4.4 so that is probably what you will want to have installed on your system. I cannot include the tcl84 and tk84 DLL's with Xconq due to licensing constraints. You can find the DLL's at: (http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcl). Run the installer program that you download. Install Tcl/Tk anywhere. Then find tcl84.dll and tk84.dll and copy them into the _same_ directory where xconq.exe is located. Then try running xconq.exe. I will try eliminate the DLL copying step someday when I feel more motivated and feel like mucking around in Windows-land again. If you have problems (after following the above instructions), please let me know what version of Windows you are using, and whether you have installed the AS Tcl/Tk package previously, and if so, what version. Also please describe the symptoms (error messages, etc...). The zip file, which includes xconq.exe, the latest games library, etc..., is at: http://eric_mcdonald.home.comcast.net/xconq/xconq20030827.zip Enjoy, Eric P.S. By downloading the above zip file, you agree to be a beta tester for the new Bellum Aeternum game. :) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 4:29 Eric McDonald @ 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 1 sibling, 0 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-27 16:17 UTC (permalink / raw) To: xconq7 On Tue, 26 Aug 2003, Eric McDonald wrote: >Then find tcl84.dll and tk84.dll and copy them into the > _same_ directory where xconq.exe is located. Actually, you can disregard this step unless you are having problems getting Xconq to run. I was thinking about something else when I wrote that. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 4:29 Eric McDonald 2003-08-27 16:17 ` Eric McDonald @ 2003-08-27 16:37 ` Jim Kingdon 2003-08-27 17:20 ` Eric McDonald 1 sibling, 1 reply; 15+ messages in thread From: Jim Kingdon @ 2003-08-27 16:37 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > I cannot include the tcl84 and tk84 DLL's with Xconq due to licensing > constraints. You can find the DLL's at: > (http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcl). Hmm. Anyone tried the tcl which comes with cygwin ( http://www.cygwin.com/packages/tcltk/ )? It would presumably be free of said licensing issue, but I don't know whether it has other issues (for example, maybe it depends on X, which would probably be more trouble than it is worth). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 16:37 ` Jim Kingdon @ 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne 2003-08-28 13:38 ` Juergen Ruehle 0 siblings, 2 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-27 17:20 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 Hi Jim, On Wed, 27 Aug 2003, Jim Kingdon wrote: > Hmm. Anyone tried the tcl which comes with cygwin ( > http://www.cygwin.com/packages/tcltk/ )? > > It would presumably be free of said licensing issue, but I don't know > whether it has other issues (for example, maybe it depends on X, which > would probably be more trouble than it is worth). Yes, it does depend on the Cygwin XFree86 X libraries. We would then need to have people install the Cygwin XFree86 stuff (which, IMO, is much more stable than 2 years ago). And they would essentially be playing Unix Xconq in an X display on their Windows machine. As as side note, building Xconq for the AS Tcl/Tk is slightly hairier when one has the Cygwin XFree and Tcl/Tk stuff installed (as I do). More attention has to be paid to make sure you are pointing at the right sets of headers. As far as the AS licensing is concerned, it looks like all that Xconq really needs to do is get written permission to bundle the DLL's and Tk Tcl scripts (actually the legalese refers to the "Package", which is a superset of what we want/need, I think). AS seems to be fairly OpenSource-friendly, so it might be worth a shot. Regards, Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 17:20 ` Eric McDonald @ 2003-08-27 18:40 ` Hans Ronne 2003-08-27 19:53 ` Eric McDonald 2003-08-28 13:38 ` Juergen Ruehle 1 sibling, 1 reply; 15+ messages in thread From: Hans Ronne @ 2003-08-27 18:40 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >As far as the AS licensing is concerned, it looks like all that >Xconq really needs to do is get written permission to bundle the >DLL's and Tk Tcl scripts (actually the legalese refers to the >"Package", which is a superset of what we want/need, I think). AS >seems to be fairly OpenSource-friendly, so it might be worth a >shot. This restriction only applies to the package distributed by AS. I think the main reason is that they want people to always get the latest package from their web site. The tcl core license goes as follows: "The authors hereby grant permission to use, copy, modify, distribute, and license this software and its documentation for any purpose, provided that existing copyright notices are retained in all copies and that this notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for any of the authorized uses. Modifications to this software may be copyrighted by their authors and need not follow the licensing terms described here, provided that the new terms are clearly indicated on the first page of each file where they apply." So you are free to distribute tcltk for any purpose. You can also hack the files and impose your own license variant. This is in effect what AS has done. However, if you get the sources from sourceforge and build your own DLLs, or use the binaries at sourceforge (currently available only for the Mac) there are no restrictions on redistribution. The same applies to the tcl script files. Anyway, getting tcltk from AS (for Windows users) is a good idea for several reasons. First, the AS installer makes sure that all files are put in the right places. Second, you always get the latest version that way. Third, tcltk is a huge package, much bigger than Xconq. Hans ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 18:40 ` Hans Ronne @ 2003-08-27 19:53 ` Eric McDonald 2003-08-28 3:26 ` Hans Ronne 0 siblings, 1 reply; 15+ messages in thread From: Eric McDonald @ 2003-08-27 19:53 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 Hi Hans, On Wed, 27 Aug 2003, Hans Ronne wrote: > Anyway, getting tcltk from AS (for Windows users) is a good idea for > several reasons. First, the AS installer makes sure that all files are put > in the right places. Second, you always get the latest version that way. > Third, tcltk is a huge package, much bigger than Xconq. Not that I care too much about marketing, but I do think that this extra step of going out and getting the AS Tcl/Tk reflects poorly on Xconq's perceived level of "sophistication." If we want to release our own Tcl/Tk bundle, I really only think a few things would be necessary: (1) The Tcl and Tk DLL's. (2) The Tcl scripts for Tk et al. (3) A .reg file with the appropriate registry entries. (Harcoded paths will have to be assumed, I think. Probably something like "C:\Program Files\Xconq\ASTcl".) (4) A simple install.bat to create the official Xconq install directory and populate it. Things could be even smoother and more dynamic if we can find a free installer program. I haven't checked the licensing of things like InstallShield (Lite?). But maybe it is not worth the effort.... I have not given SDL serious consideration. Are there any bundling issues with that? Regards, Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 19:53 ` Eric McDonald @ 2003-08-28 3:26 ` Hans Ronne 0 siblings, 0 replies; 15+ messages in thread From: Hans Ronne @ 2003-08-28 3:26 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >If we want to release our own Tcl/Tk bundle, I really only think a >few things would be necessary: >(1) The Tcl and Tk DLL's. >(2) The Tcl scripts for Tk et al. >(3) A .reg file with the appropriate registry entries. (Harcoded >paths will have to be assumed, I think. Probably something like >"C:\Program Files\Xconq\ASTcl".) >(4) A simple install.bat to create the official Xconq install >directory and populate it. > >Things could be even smoother and more dynamic if we can find a >free installer program. I haven't checked the licensing of things >like InstallShield (Lite?). >But maybe it is not worth the effort.... Well, I would put it like this: why do the job when AS has already done it for us. Sure, we might be able to prune down tcltk to a lot less than the 80 MB in the AS package, and then bundle it with Xconq. However, consider what happens if somebody installs a partial tcltk that comes with Xconq and then finds out he/she needs the full install for some other program. If there is one thing that can mess upp a system it is installing a full version of something on top of a partial version or vice versa. I fear that xconq would be blamed in the end and get a bad rep. I am not dogmatic about this, however. If it turns out that all you need is the DLLs and a few script files, it might be worthwhile. We already included BWidget in Xconq. I haven't checked how many of the tcltk script files that are really needed to run Xconq. Everything should be installed in the Xconq directory in that case, in order not to mess up things for other programs. >I have not given SDL serious consideration. Are there any >bundling issues with that? Not that I am aware of. SDL is under LGPL. In any case, I have been building the DLLs myself from the SDL sources, since the DLLs from the official distribution were built with Visual C++ and therefore are incompatible with apps built by CodeWarrior (which I am using). Hans ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne @ 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald ` (2 more replies) 1 sibling, 3 replies; 15+ messages in thread From: Juergen Ruehle @ 2003-08-28 13:38 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 Eric McDonald writes: > On Wed, 27 Aug 2003, Jim Kingdon wrote: > > Hmm. Anyone tried the tcl which comes with cygwin ( > > http://www.cygwin.com/packages/tcltk/ )? > > > > It would presumably be free of said licensing issue, but I don't know > > whether it has other issues (for example, maybe it depends on X, which > > would probably be more trouble than it is worth). > > Yes, it does depend on the Cygwin XFree86 X libraries. We would > then need to have people install the Cygwin XFree86 stuff (which, > IMO, is much more stable than 2 years ago). And they would > essentially be playing Unix Xconq in an X display on their Windows > machine. Actually no: the cygwin tk does not depend on X, but it doesn't contain the right headers either. You have to download the source to the tcl/tk package, extract the headers, and configure using --x-includes=<<tk's xlib header directory, e.g. /usr/include/tk/xlib>> (Probably the same you are doing to compile with the AS package). Otherwise configure will find the standard X11 headers which are incompatible and the resulting application will crash on startup. Also it seems there is still some tweaking of at least win/Makefile.in neccessary. it would be nice if somebody could commit something along the lines of (one still has to muck with TCLTKLIB, but I see no way to autodetect this): =================================================================== RCS file: /cvs/xconq/xconq/win/Makefile.in,v retrieving revision 1.7 diff -b -B -d -u -I\$$ -r1.7 Makefile.in --- win/Makefile.in 28 Aug 2003 04:04:00 -0000 1.7 +++ win/Makefile.in 28 Aug 2003 10:55:40 -0000 @@ -56,6 +55,8 @@ TKIAPP_LIB = ../tcltk/libtkiapp.a +MAIN = ../tcltk/tkwin32.o + # Host and target-dependent makefile fragments come in here. #### # End of host and target-dependent makefile fragments. @@ -94,20 +95,18 @@ WIN_CFLAGS = -mwindows -ALL_CFLAGS = $(CFLAGS) $(HFLAGS) $(REQD_CFLAGS) $(WIN_CFLAGS) -I$(srcdir) -I$(srcdir)/.. -I$(krnsrcdir) -I$(srcdir)/../tcl/generic -I$(srcdir)/../tk/generic - -.c.o: - $(CC) -c $(ALL_CFLAGS) $< - # Do it all. all: xconq # The game itself. -xconq: wconq.o $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) - rm -f xconq - $(CC) -o xconq $(ALL_CFLAGS) $(LDFLAGS) wconq.o $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) $(WITH_LIBS) $(TCLTK_LIB) $(NET_EXTRA_LIBS) +xconq: $(MAIN) $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) + rm -f xconq.exe + $(CC) -o xconq $(WIN_CFLAGS) $(LDFLAGS) $(MAIN) $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) $(WITH_LIBS) $(TCLTK_LIB) $(NET_EXTRA_LIBS) + +$(MAIN): + (cd ../tcltk; make tkwin32.o) $(KERNEL_LIB): (cd ../kernel; make libconq.a) @@ -134,7 +133,7 @@ clean: rm -f *.o lint.out core - rm -f xconq xconq.6 *.conq *.xconq + rm -f xconq.exe xconq.6 *.conq *.xconq distclean: clean rm -f Makefile config.status =================================================================== Regards, jr ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle @ 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald 2003-08-29 9:06 ` Hans Ronne 2 siblings, 0 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-29 0:44 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 On Thu, 28 Aug 2003, Juergen Ruehle wrote: > Eric McDonald writes: > > Yes, it does depend on the Cygwin XFree86 X libraries. We would > > then need to have people install the Cygwin XFree86 stuff (which, > > IMO, is much more stable than 2 years ago). And they would > > essentially be playing Unix Xconq in an X display on their Windows > > machine. > > Actually no: the cygwin tk does not depend on X, but it doesn't > contain the right headers either. You have to download the source to > the tcl/tk package, extract the headers, and configure using OK, "depend" was too strong of a word. During my earliest build attempt, I was picking up the wrong Tcl/Tk (I forgot that I had the Cygwin version of it installed, and its headers were in /usr/include which was earlier in the search path than the AS headers), and when compiling tkwin32.c, I was getting conflicts with what I _assumed_ were the actual X headers that Tcl/Tk "depended" on. I'll eat my words for now, until I can verify what X headers were actually being used (next time I boot into Windows). Sorry for possibly dispensing misinformation based on an assumption.... > --x-includes=<<tk's xlib header directory, e.g. /usr/include/tk/xlib>> > (Probably the same you are doing to compile with the AS package). Yes. > Otherwise configure will find the standard X11 headers which are > incompatible and the resulting application will crash on startup. Actually, you probably won't make it past linking, because of the overridden definitions at the bottom of tkwin32.c. > Also it seems there is still some tweaking of at least win/Makefile.in > neccessary. it would be nice if somebody could commit something along > the lines of (one still has to muck with TCLTKLIB, but I see no way to > autodetect this): I had some similar tweaks in mind, based on my experience with that mess. I will look at your patch more closely tonight (US Mountain time), unless someone has already committed it by then. Thanks. Best regards, Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald @ 2003-08-29 8:35 ` Eric McDonald 2003-08-29 15:22 ` Juergen Ruehle 2003-08-29 9:06 ` Hans Ronne 2 siblings, 1 reply; 15+ messages in thread From: Eric McDonald @ 2003-08-29 8:35 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 On Thu, 28 Aug 2003, Juergen Ruehle wrote: > Eric McDonald writes: > > Yes, it does depend on the Cygwin XFree86 X libraries. We would > > then need to have people install the Cygwin XFree86 stuff (which, > > IMO, is much more stable than 2 years ago). And they would > > essentially be playing Unix Xconq in an X display on their Windows > > machine. > > Actually no: the cygwin tk does not depend on X, but it doesn't > contain the right headers either. Ok, I mounted my NTFS partition that has Cygwin. I looked at tk.h and it says: #ifndef _XLIB_H # ifdef MAC_TCL # include <Xlib.h> # include <X.h> # else # include <X11/Xlib.h> # endif #endif And the only X11/Xlib.h in my entire Cygwin filespace is under /usr/X11R6/include, which, of course, is the real thing, not a Tcl/Tk imitation. So, if anyone was to build a Tcl/Tk-based app under this setup (and it is a relatively recent and fairly standard one), he/she would, in fact, end up depending on the real X11 stuff. From this standpoint, any Cygwin app built thusly would be a true X11 client in need of a true X11 server. But, I suppose this a wasted point, since what you prescribe seems like a good idea (it also devalues the AS Tcl/Tk in my eyes). It would be nice to build Tcl/Tk for Windows natively under Cygwin, and then statically link it into Xconq, removing the need of Tcl and Tk DLL's and whatnot. I'll look into it. Thanks. > Also it seems there is still some tweaking of at least win/Makefile.in > neccessary. it would be nice if somebody could commit something along > the lines of (one still has to muck with TCLTKLIB, but I see no way to > autodetect this): Your patch looks fine. I was going to commit it later this evening, but I suppose I should boot into Windows first and actually test it.... I'll take care of it soon, but maybe not today. Thanks, Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 8:35 ` Eric McDonald @ 2003-08-29 15:22 ` Juergen Ruehle 2003-08-30 5:47 ` Eric McDonald 0 siblings, 1 reply; 15+ messages in thread From: Juergen Ruehle @ 2003-08-29 15:22 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 Eric McDonald writes: > On Thu, 28 Aug 2003, Juergen Ruehle wrote: > > Eric McDonald writes: > > > Yes, it does depend on the Cygwin XFree86 X libraries. We would > > > then need to have people install the Cygwin XFree86 stuff (which, > > > IMO, is much more stable than 2 years ago). And they would > > > essentially be playing Unix Xconq in an X display on their Windows > > > machine. > > > > Actually no: the cygwin tk does not depend on X, but it doesn't > > contain the right headers either. First: sorry for the tone of my mail. I had the suspicion it might sound patronizing, but English isn't my first language and I had no better wording available. I very much appreciate the time and effort you and others (especially Hans) are putting into xconq. I did not intend to offend anybody. > Ok, I mounted my NTFS partition that has Cygwin. > I looked at tk.h and it says: > #ifndef _XLIB_H > # ifdef MAC_TCL > # include <Xlib.h> > # include <X.h> > # else > # include <X11/Xlib.h> > # endif > #endif > And the only X11/Xlib.h in my entire Cygwin filespace is under > /usr/X11R6/include, which, of course, is the real thing, not a > Tcl/Tk imitation. > > So, if anyone was to build a Tcl/Tk-based app under this setup > (and it is a relatively recent and fairly standard one), he/she > would, in fact, end up depending on the real X11 stuff. From this > standpoint, any Cygwin app built thusly would be a true X11 client > in need of a true X11 server. 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. Now, X based Tk uses the X structures directly while on Windows (and probably Mac OS) the layout is slightly different. Linking code with different 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 (I learned this the hard way:-). It would be nice if Win dows Tk had some deliberate incompatibility with the X11 headers so this could be detected at compile time. Langer Rede kurzer Sinn:-) When compiling a Tk application for X11 nothing can go wrong, but if compiling a Tk app for windows or Mac Tk you have to make sure that the compiler doesn't accidently pick up original X11 headers. > But, I suppose this a wasted point, since what you prescribe seems > like a good idea (it also devalues the AS Tcl/Tk in my eyes). > It would be nice to build Tcl/Tk for Windows natively under > Cygwin, and then statically link it into Xconq, removing the > need of Tcl and Tk DLL's and whatnot. I'll look into it. Thanks. There are two alternatives: - 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) - a non-cygwin xconq (either compiled using -mno-cygwin - which I've never attempted myself - or using VC++ - which works - or using CodeWarrior - which is what Hans is doing AFAIK): this will probably have no choice but to use AS Tk > > Also it seems there is still some tweaking of at least win/Makefile.in > > neccessary. it would be nice if somebody could commit something along > > the lines of (one still has to muck with TCLTKLIB, but I see no way to > > autodetect this): > > Your patch looks fine. I was going to commit it later this > evening, but I suppose I should boot into Windows first and > actually test it.... I'll take care of it soon, but maybe not > today. It's not really a priority, there are few of us that actually build it on windows. BTW I think I have posted this earlier, but I'll include it again: my attempt at an INSTALL-win file. This is probably slightly outdated by now. It would be nice, if you could review it and perhaps commit it too. The major part missing is building with Visual C++, since I currently don't have it installed. ===================================================== BUILDING XCONQ ON WINDOWS FROM SOURCE The xconq Tcl/Tk interface should run on most win32 based Systems (95, NT4.0 and up). Currently (as of 02/08/16) it doesn't build right out of the box but needs some minor tweaking. The following assumes you have downloaded and extracted the source on your system and are familiar with building software. Since the windows port isn't fully maintained, you might have to fix some problems yourself. If you need further help, please contact the xconq mailing list on 'sources.redhat.com'. NOTE: This document contains forward slashes as directory separators. 1. Building with cygwin (Net Release) 1.1 Install Cygwin Install cygwin from http://sources.redhat.com/cygwin/ if you haven't done so already. You will at least need the 'cygwin', 'ash', 'gcc', 'binutils', and 'make' packages. You also need a Tcl/Tk package as explained in the next section. 1.2 Install Tcl/Tk Headers and Libraries IMPORTANT: read this carefully to improve the chance the xconq will actually build and run. There are currently three cygwin packages containing Tcl/Tk libraries: - 'tcltk' (Version 20001125-1) contains Tcl/Tk Version 8.0 - 'gdb' (Version 20010428-3) also contains Tcl/Tk Version 8.0 - 'gdb' (Version 20020718-1) contains Tcl/Tk Version 8.3 If you don't want gdb grab the 'tcltk' package, otherwise install one of the 'gdb' packages. NOTE: 'gdb' (20010428-3) contains exactly the same Tcl/Tk files as the 'tcltk' package. So - due to a quirk in the cygwin setup - if you install both and later deinstall one, it will delete the files, therefore you have to reinstall the remaining package. Unfortunately the binary packages do not contain all required header files, namely Xlib.h and friends. These are only contained in the corresponding source packages. So download and install (or simply extract it somewhere) the appropriate source package. It is important to use the header files that have been used to build the libraries since crucial functions are implemented as macros. Especially DO NOT use X11 headers (e.g. from one of the X11 packages). While the compile may succeed the resulting executable will most probably crash (within expanded macro code). That said, it seems that the headers included in the 'tcltk' source package actually work with all three binary packages (even so the Tcl/Tk versions differ). This can significantly reduce download time, but YMMV. 1.3 Configure Make sure that there are no directories named 'tcl' or 'tk' in the xconq source directory. These are for the old cygwin beta releases. If they exist remove or rename them. You just need the directory named 'tcltk'. Start a cygwin shell (e.g. /bin/sh.exe), cd to the directory where you extracted the source, and type ./configure --x-includes=<directory of the modified Tcl/Tk X includes> This will try to guess the correct settings for your systems, select the Tcl/Tk X headers, and create Makefiles in the appropriate directories. The correct X include directory is the one from the Tcl/Tk source containing an X11 sub directory that contains Xlib.h. 1.4 Make Run 'make' (in the xconq source directory). Fix any errors that might occur. This should produce 'win/xconq.exe'. 2. Building xconq using MS Visual C++ 2.1 Get and install Tcl/Tk ... 2.2 Setup the project Create a new project containing the following files: ... Change the settings as follows: ... 2.3 Compile Start the compile. Fix any errors that occur. 3. Running xconq 'xconq.exe' should be runnable when copied to the top level xconq source directory. If it complains that it cannot find 'init.tcl' you have to set the 'TCL_LIBRARY' environment variable to the directory of the 'init.tcl' file (i.e. '/usr/share/tcl8.0'). If it cannot find other tcl scripts you should try to add them to the 'TCLLIBPATH' environment variable. 4. Installing xconq Currently not supported by the build system, but you can copy the executable and library directories to any directory you like and create a shortcut. You then probably have to provide the directory of the game library using command line parameter '-L <game library directory>'and possibly set TCLLIBPATH to the directory of the 'tkconq.tcl' script. ===================================================== ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 15:22 ` Juergen Ruehle @ 2003-08-30 5:47 ` Eric McDonald 0 siblings, 0 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-30 5:47 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald @ 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald 2 siblings, 1 reply; 15+ messages in thread From: Hans Ronne @ 2003-08-29 9:06 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 >Also it seems there is still some tweaking of at least win/Makefile.in >neccessary. it would be nice if somebody could commit something along >the lines of (one still has to muck with TCLTKLIB, but I see no way to >autodetect this): This seems OK to me. However, what I really would like to do is to get rid of the win directory, and make the Windows app build in the tcltk directory, where the Windows tcltk code now lives. The point of this is an attempt to organize the sources in a way that makes sense, so that new users know where to find the files. We also have a Windows SDL app, furthermore, we have a Mac tcltk app, and the latter does not live in the mac directory, which instead contains the mac interface. So the idea was to have all tcltk stuff (sources, resources, Makefiles) in the tcltk directory, all SDL stuff in the sdl directory etc. One directory for each interface. This was discussed on the list earlier, and I already moved the relevant source and resource files from the win to the tcltk directory. I think Stanley Sutton started to look at moving the relevant stuff from the win Makefile.in to the tcltk Makefile.in, but unfortunately he was not able to complete that work. Perhaps we should do this now? Hans ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 9:06 ` Hans Ronne @ 2003-08-29 15:57 ` Eric McDonald 0 siblings, 0 replies; 15+ messages in thread From: Eric McDonald @ 2003-08-29 15:57 UTC (permalink / raw) To: Hans Ronne; +Cc: Juergen Ruehle, xconq7 On Fri, 29 Aug 2003, Hans Ronne wrote: > This was discussed on the list earlier, and I already moved the relevant > source and resource files from the win to the tcltk directory. I think > Stanley Sutton started to look at moving the relevant stuff from the win > Makefile.in to the tcltk Makefile.in, but unfortunately he was not able to > complete that work. Perhaps we should do this now? Doesn't seem too difficult. I will attempt to take care of it tonight, and modify/crossover/integrate Juergen's patch accordingly. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-08-29 15:57 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-27 18:04 New Xconq Windows Executable Bill Macon -- strict thread matches above, loose matches on Subject: below -- 2003-08-27 4:29 Eric McDonald 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne 2003-08-27 19:53 ` Eric McDonald 2003-08-28 3:26 ` Hans Ronne 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald 2003-08-29 15:22 ` Juergen Ruehle 2003-08-30 5:47 ` Eric McDonald 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).