Re: [stella] Dasm for Linux

Subject: Re: [stella] Dasm for Linux
From: Julian Squires <tek@xxxxxxx>
Date: Mon, 29 Mar 2004 12:05:05 -0500
Hi Andrew.

On Tue, Mar 30, 2004 at 02:01:24AM +1000, Andrew Davie wrote:
> There's really nobody who totally understands the program.  Large areas of
> it I haven't looked at nor played with.  What I have done is fixed bugs when
> they appear, and add new capabilities when they seem to make sense.  Having
> *a* maintainer is better than having none at all.  Slowly, as I find the
> time, I update the coding style to try and get some consistency into it all.

And, I appreciate your maintenance of it.  I know from experience how
thankless a job it often is.

> > 1) the aforementioned ulong typedef (for obvious reasons).
> As it happens, some weeks ago I distributed new source to various parties
> who have volunteered to be official 'builders' of the binary for various
> platforms.  These typedef statements were totally removed in that latest
> source, and would have been released as a matter of course when the next
> release came about.  I may very well have broken something in making an
> assumption that the code did not NEED unsigned variables;  I'll have to
> double-check that to find out WHY your Linux build wasn't working.

Well, ulong implies ``unsigned long'' not ``long'', and since there's
already a typedef elsewhere in the system headers that ulong is an
unsigned long, it causes an error.  The redefinition (to a compatible
type) only causes a warning.  Getting rid of those typedefs is good,
anyway.  Better still might be using the ISO C99 integer types in
stdint.h/stddef.h (uint32_t, int16_t, etc).

> > Also, having a make clean rule in the Makefile, and not including
> > exp.obj (exp.obj: 80386 COFF executable not stripped - version 25970) in
> > the distribution, would be other suggestions I have.
> I don't understand the above.  I can't find "exp.obj" in the makefile I
> have.  Perhaps another thing I've removed.  Where's that version control
> when I really need it.

Ah, it was just floating around in the zip file, probably just a
left-over from a build.

> > A few comments in the Makefile about what to uncomment for various
> > platforms might be helpful, too.  I can make a more comprehensive patch
> > that addresses all these issues and submit it, if you'd like.  I've been
> > meaning to write debian build rules for dasm, anyway.
> Thanks, any help is welcome -- and I do appreciate your comments and
> suggestions.  A patch file isn't much good for me, as I don't have the tools
> to apply the patch -- and in any case I'd like to understand what changes
> are being made before they're actually implemented.

Well, patch is the defacto means of contributing to open source projects
without direct access to the version control system, so I'm hoping you
won't be too bent out of shape if I submit another one. :-)  Most of my
work with win32 is done with a cross-compile environment under UNIX, so
I'm not sure what the best choice for patch/diff under windows is (aside
from cygwin --

Usually when I'm deciding whether to integrate a submitted patch, I'll
skim the patch first (with patch syntax highlighting enabled in my
editor), then check out a fresh copy of the project from version
control, apply the patch, and then use annotation or similar to browse
the changes within the context of the rest of the source.

I'm at work at the moment, but when I get home, it shouldn't take me too
long to produce a patch as I'd like to see it, including proper debian
build rules (so debian users can just ``cd DASM && dpkg-buildpackage
-rfakeroot'' and end up with a nice binary package that plays well with
the rest of the system).


Julian Squires
Archives (includes files) at
Unsub & more at

Current Thread