[crawl] Trapped in the land of Mingw

[Guest]

Archived from groups: rec.games.roguelike.misc (More info?)

Hi all (and especially Darshan),

Because...

a) Darshan's patch was compiled using Mingw and includes the caveat that
compilability has only been checked under gcc, and

b) I definitely want to include Darshan's patches in the patched .exe I'll be
offering,

....I have a few questions/requests.

1) Darshan, is it OK if I put up an executable that incorporates both this
patch and yours?

2) I've decided, as you might guess, to switch from Borland to Mingw for the
compiling. (Environment will be Win2k at home, winXP Pro in the office after
work, and Dev-C++ as my IDE.) In the "Notes for building crawl with mingw,"
there are... well, there are lots of things that utterly fry my brain, and I
desperately need help in comprehending them. Compiling with Borland 5.5 was
sooo much easier for a dummy like me...

Ye mingw building notes proclaim:
* In makefile specify makefile.w32.
// There's no makefile.w32 in the source distribution. There was a discussion
on a makefile.w32 in crawl-dev back in 2001 and something was uploaded to the
group, but that was several versions ago...

- make sure your path includes mingw binaries
// Does this mean my Windows system path variable, or something different?

- set LIB to your mingw lib directory
- set INCLUDE to your mingw include directory
// Ooookay, I think this means two lines in the makefile.w32 that I don't
have; there are similar lines in the existing makefiles. Only mentioning this
just in case I happen to be wrong.

- the makefile defines WIN32CONSOLE like above
// And the current ambiance of teacups is morphologically exploited as above
too, but I don't know what that means either. :-( The worst part is, I have a
funny feeling this is something very basic where admitting that I don't know
what it means means I'm a total programming newbie, or very close to it. So
let me just state this straight out: I am.

However, it may just be saying that the makefile should declare this to be a
console application... but since I don't know the syntax for that, that
doesn't help much.

- -Wall will generate a fair number of warnings

// LARRY WALL IS GONNA SEND ME WARNINGS?? Will he send them as scans at
least, so I have his autograph??

Don't understand this one either.

* Current build is not statically linked.

//The current build is not quintessentially smurfed? What?? I feel like a
dummy here, too, and even more so.

Erik

 

[Stu]

Archived from groups: rec.games.roguelike.misc (More info?)

if you install mingw, it will put an icon into your
desktop|quickstart|menu wherever that is an xterm shell which (iirc)...
already has all the path/lib etc stuff setup and it should be a matter
of just doing 'make'.

the difference between a console + non-console app is one of main() vs
winmain()

it shouldnt be too hard to create a makefile.. or just use an existing
one for linux or cygwin?? (i'm not a crawl dev, i dont know what their
system is like).. since its all gcc it should all (relativly) work.

or you can do things the hard way with gcc -O2 *.c -o crawl (that used
to work a long time ago when I complied it in the crawl v1.xx era ^_^);

-stu

 

[Guest]

Archived from groups: rec.games.roguelike.misc (More info?)

"Erik Piper" <efrniokr@sdky.cz> wrote:
>Ye mingw building notes proclaim:
>* In makefile specify makefile.w32.
>// There's no makefile.w32 in the source distribution. There was a discussion
>on a makefile.w32 in crawl-dev back in 2001 and something was uploaded to the
>group, but that was several versions ago...
>
> - make sure your path includes mingw binaries
>// Does this mean my Windows system path variable, or something different?

Yes, the environment variable PATH.

> - -Wall will generate a fair number of warnings
>
>// LARRY WALL IS GONNA SEND ME WARNINGS?? Will he send them as scans at
>least, so I have his autograph??
>
>Don't understand this one either.

"-Wall" is a command-line switch to the compiler that turns on a
"standard" package of warnings. This package of warnings is intended to
alert the user to many common kinds of bug and misunderstanding.

>* Current build is not statically linked.
>
>//The current build is not quintessentially smurfed? What?? I feel like a
>dummy here, too, and even more so.

Two kinds of linkage exist: static and dynamic. Static linkage picks up
all the object code from the libraries and produces an executable that
includes all the code it needs to run on a given platform. Dynamic
linkage just puts in a bunch of stuff telling the dynamic loader "I'm
using these libraries. Hook me up with them when I run."

Dynamic linkage allows the OS to only load one copy of the common
library code regardless of how many different programs are using them,
and to only have one copy of the common library code on the disk. This
produces smaller executables.
--
Martin Read - my opinions are my own. share them if you wish.
My roguelike games page (including my BSD-licenced roguelike) can be found at:
http://www.chiark.greenend.org.uk/~mpread/roguelikes.html

 

[Guest]

Archived from groups: rec.games.roguelike.misc (More info?)

Erik Piper wrote:
> Hi all (and especially Darshan),
>
> Because...
>
> a) Darshan's patch was compiled using Mingw and includes the caveat
> that compilability has only been checked under gcc, and
>
I tried to compile beta 26 with mingw and succeeded quite easily, just
plenty of warnings generated.

makefile:
- commented out OTHER=-j2 (add # to the beginning of line)
- makefile.lnx selected

makefile.lnx:
- GAME = crawl.exe instead of GAME = crawl
- OBJECT += libw32c.o instead of OBJECT += liblinux.o
- DELETE = del & COPY = copy instead of unix replacements
- OS_TYPE = WIN32CONSOLE
- modified CFLAGS:
CFLAGS = -Wall -Wwrite-strings -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations \
-g -D$(OS_TYPE) -D__IBMCPP__ $(EXTRA_FLAGS) \
-Ic:\gnu\dev-cpp\include -Ic:\gnu\dev-cpp\include\c++ \
-Ic:\gnu\dev-cpp\include\c++\mingw32
- modified INSTALLDIR
- commented out LIB = -lncurses
- commented out INCLUDES
- removed all references to CHMOD & MCHMOD
- commented .h.cc & touch line out:
#.h.cc:
# touch $@

Source code changes:
- many source files use unlink, in mingw it is not available:
- rename unlink calls to _unlink
- add #include <io.h> to modified files

Now make produces quite a lot of warnings, but crawl.exe is created
(around 6 MB), you can use "strip crawl.exe" to make it smaller.

Seems to start. Anyway, it should not take much time to add proper
support for mingw..

 

[Guest]

Archived from groups: rec.games.roguelike.misc (More info?)

"Erik Piper" <efrniokr@sdky.cz> wrote:

> a) Darshan's patch was compiled using Mingw and includes the
> caveat that compilability has only been checked under gcc, and

It's likely that it'll compile on bcc; some months back, Mitsuhiro
Itakura pointed out some code that bcc was barfing on and I fixed
it. It's always possible I broke bcc compilability again afterwards,
but it's worth a try.

Another thing you'll want to note about bcc vs. gcc on Windows is
that bcc is typically twice as fast. If you've already got Crawl
compiling with Borland's compiler, stay with it.

> 1) Darshan, is it OK if I put up an executable that incorporates
> both this patch and yours?

Of course. That's the point of free software. 🙂

> Ye mingw building notes proclaim:
> * In makefile specify makefile.w32.

>// There's no makefile.w32 in the source distribution. There was a
>// discussion on a makefile.w32 in crawl-dev back in 2001 and
>// something was uploaded to the group, but that was several
>// versions ago...

Pekka's suggestion on tweaking makefile.lnx is good. (I usually take
makefile.dos and maul that, but the effort involved is about the
same.)

It's not very hard to get the ball rolling with MinGW, but you've
already downloaded Borland's compiler and got everything working
with it, so don't bother.

Darshan

 

[Guest]

Archived from groups: rec.games.roguelike.misc (More info?)

Darshan Shaligram wrote in message
<Xns96027904E771Ascintillagmailcom@130.133.1.4>:
>
> Of course. That's the point of free software. 🙂

Let me take advantage of free software in another fashion. As there seem
to be quite a few Crawl developers, maintainers and patchers reading this
newsgroup, I'd like to point out a small but rather nasty bug I've hit
upon in the highscore file management code (in the vanilla source tree,
but not corrected in your patch, afaik).

I sent an e-mail to Brent about it earlier, but it may well have failed
to reach its intended destination. Here it goes:

------------------------------------------------------------------------
A recent new entry in the crawl highscore list here at ENS has cluttered
up the highscore management pretty bad. Let me reproduce it here:

:4:2:68760:mt_i:12215:5:12::14:26:17:3:376:250:a centaur warrior:Shot with a bolt of frost by a centaur warrior:17:0:0:-11:68:68:34:6:26:14:6:165:0:0:20050109004329S:20050110220721S:18844:28869:0:0:

The problem could be fixed by replacing the auxkilldata string by just
"bolt of frost", which is slightly incorrect but shorter. This led me to
suspect some sort of buffer overflow, which, upon further investigation,
I seem to have found in the hs_read function (file hiscores.cc, in the
unpatched 4.0b26 sources).

This function starts by reading a line from the highscore file into a
200-character buffer, when these lines can (and apparently do) get
longer, considering the length of the various fields in the
scorefile_entry structure. (Well, the previous example does not really
have length > 200, since it is only 198 chars long + newline, but due to
how the line is read, the newline is not read on the first iteration, and
the next iteration gets an empty line, which is bad).

A quick and dirty fix to the current hiscores.cc could look like :

1293c1293
< char inbuf[200];
---
> char inbuf[1000];

Well, this isn't as robust as one may wish, admittedly, so I'd better
leave the correction to you.

Thanks for all the work you've been investing in maintaining this
marvellous piece of a timewaster!
------------------------------------------------------------------------

--
Mehdi,
Crawl fan and rgrm lurker (not quite any longer...)