mcastle@mcs213c.cs.umr.edu (Mike Castle {Nexus}) (04/24/91)
Well, I've managed to get nearly the entire PBMPlus packaged compiled for DOS.
I used DJ Delorie's port of GCC to do it. Therefore, it requires a 386 and,
for parts, a 387.
The complete binaries take up over 3 Megs (and it would take more if I built
the dos extender into the executables rather than the stub driver that calls
the dos extender).
I doubt that I'll post the binaries any time soon (though I will send them to
Bill Davidsen, moderator of comp.binaries.ibm.pc if he requests them).
Instead, I'll probably post patches instead (most likely to alt.sources). I'll
describe here, though, how I did my port.
The pbm library has a couple of routines call pm_openr and pm_openw that open
files in the standard unix method. Since DOS can't always handle binary files
like that, I added 2 called pm_openrb/openwb that open them as binary files.
I used the binary opens for all the non-p?m files. (This may not work formats
such as the x-windows bitmaps, but I have no way of testing these).
I then went through all the sources and changed all the i/o statements.
Printf's became fprintf, putchar became fputc, etc.
Actually, it went something like this:
printf(headerstuff);
became
#ifdef GNUDOS /* GNUDOS is automatically declared by dj's gcc compiler */
fprintf( ofp, headerstuff );
#else /* GNUDOS */
printf( headerstuff );
#endif /* GNUDOS */
I also added the appropriate statements to assign appropriate names to output
files (the name is taken from the input p?m file, then appended a .xxx where,
in general, xxx is taken from the name of the p?mtoxxx program). I think I've
done a good enough job putting #ifdef's around everything so that it will
still compile on a unix system (theoretically, you could run my source as
well as the real version, through just the compilers preprocessor and get the
exact same output, on a unix system, of course). Oh, and all piping of
p?m files work (although slow and space consuming with dos having to make the
temporary files to hold the info since it can't do all at the same time), and
piped files get a name of noname.xxx
I then editted the makefiles and removed certain things in the dependencies
(such as rm and cp, which would be unnecessary if you have a set of unix-like
utilities such as MKS or PICNIX, I suppose). I used the DOS version of
GNU MAKE (available on simte20 et al in the gnuish directory).
That's all there was to it. I used a version of dj's gcc that's about 2 weeks
old, and the beta version of pbmplus dated (I *think*) 04 feb 1991.
Oh, I did make a few batch files that prepend the dos extender stub to each
of the resulting files.
There are only a few programs I didn't get to work:
* pbmtogem: I got gemtopbm to work once I set a define to change it to use
little-endian byte ordering (at least it worked with the .img
file that came with graphics workshop), but pbmtoimg doesn't
have any such option. A quick attempt at a patch failed and I
don't have the time right now to work on it (see below).
* giftoppm: It chokes when it tries to malloc() an array. I believe this
might be a problem with djgcc (I get the exact same protection
violation with a malloc in DKBTrace 2.10, but all the other
malloc()s in pbmplus work fine), but I haven't had a chance to
delve into this further.
* pnmgamma: For some reason, all values of 0 in a ppm file end up as 255's
in the output (even with a gamma correction of 1.0!!). A quick
fix is ppmake #010101 x y then ppmarith (or pnm??) -add to add
1 to everything.
I won't have much time to work on this anymore until after finals.
Unfortunately, after finals, I won't have net access again (or any computer
access outside of my pc, not even a BBS within a local phone call where I
live!!) until september.
If anyone who will have net access over the summer would like to help me with
this, drop me a line. I would like to keep up with all the updates to both
pbmplus (such as when it gets out of beta) and djgcc.
Interested parties should contact me at:
mcastle@cs.umr.edu
or s087891@umrvma.umr.edu (or s087891@umrvma.bitnet)
or snailmail: Mike Castle
R 2 Bx 69
Troy, MO 63379
I suppose I should admit that I'm not positive everything else works (at least
as far as going between formats are concerned). I'm pretty sure most of the
p?mtoxxx works (such as pcx, gif, whatever cshow can handle). I only have
samples for xxxtop?m for gem(.img) and targa (.tga) files (well, rawtoppm
worked with the .tga file with -headerskip 18 :-). Most of the work station
graphics (X-windows type stuff) I can't test. If someone who knows they have
a working copy of PBMPlus would like to make some sample with p?mtoxxx that I
could compare mine with, I would appreciate it. Please just send a message
saying that you would help, not samples!! Disk space here is a premium and I
don't want my mailbox to explode with samples. What I'm looking for will be
small samples (25x25). Most like tarring and compressing the whole lot of
samples and uuencoding and mailing to me (or set them up for ftp access).
This summer, I may try creating the binaries using the pbmmerge method. While
ms-dos doesn't support file links, it might be possible to keep around one
executable, and just copy it to the filenames that you need (comp430d.zip,
the official port of compress to dos does this. Just copy the same executable
to compress or uncomp or zcat, and it does the obvious).
I may also *try* writing a dos specific version of pbmplus. It would have to
include a method similiar to PICLAB's of keeping the stuff on disk rather than
in memory. Slower than anything without a good drive and cache, but it works.
This last is to Jef, but I'd like to hear from any one else who has written
a pbmplus program.
Would you be interested in a major change to pbmplus?? Basically, my dos
port, with all the #ifdef's around all those printf() statements, looks a
mess!! Except for the couple of programs (I think pbmtomacp is one) that
used all fprintf( fdout,... ) and fputc( byte, fdout) instead. Those still
look nice and clean. If you would like, I could generate patches that would
change all the printfs and putchars and such to the obvious file i/o statements.
And, of course, a ofp = stdout near the beginning of the program.
Then, for the DOS port, I'd only have to have a couple #ifdef's near the
beginning like:
#ifdef GNUDOS
/* insert filename creation here */
#else /* GNUDOS */
ofp = stdout
#endif /* GNUDOS */
Be a lot nicer for me. :->
Just a thought.
Sorry for all this pixutils stuff on comp.graphics, but with all the posts I
read here about the subject, I thought I'd let this let people know it is
being done. I've cross-posted this to alt.graphics.pixutils, with followups
directed there as well.
Regards,
Mike Castle
--
Mike Castle (Nexus) s087891@umrvma.umr.edu or mcastle@mcs213k.cs.umr.edu
Feel lonely? Want someone to send you e-mail? Just post to *.test with a
Reply-To: field, and watch your mailbox explode!!