Mail Archives: djgpp/1992/08/21/23:03:19
I've not been active on the net for a little over a year now (took some
time off from school), and have a LOT of catching up to do. I did ftp and
read the entire archive of posts to this list, and I would like to address
a few points (WARNING: much of the archive was read between 3-6am, so I may
have missed a few things :-).
First, about my original port of PBMPlus to DOS.
I really thought that the setmode() stuff worked in the earlier versions of
go32. If it wasn't still working completely, that may have explained why
I could never get the TIFF stuff to work properly. (BTW, would anyone who
is working/has worked on pbmplus, utah-rle, and rayshade please get in touch,
I would like to compare notes).
When I originally decided to post the binaries for pbmplus, I was indecisive
about how to do it. I choose to post the merged executable with go32 attached
based on the following reasons:
I was going to post to comp.binaries.ibm.pc on usenet. The merged executables
were much smaller than the entire package compiled into each separate program.
I figured most people would only use 3 to 6 programs (at the time, I rarely
used anything more than tgatoppm, ppmquant, and ppmtogif), and it would not
be difficult to copy ppmmerge.exe to tgatoppm.exe. If you needed the disk
space, you only had to keep one executable and restore the whole package from
that.
My post did include complete diffs to the makefile as well as the source, so
anyone who wanted to could build the separate exectuable and/or the merged
exectuables with no problem. I felt this was a fair trade off.
I chose to prepend go32 rather than stub.exe for simplicity. I could not
be sure if the end-user would understand why go32 would have to be available
in the path, and I new I wouldn't be around for support for a while. I know
knew this might pose a problem with upgrading go32 (I had this problem with
the first diff.exe posted that used a go32 that couldn't handle VCPI. I had
to use a binary editor to strip off the old go32), but again, I felt it was a
justified decision. Of course, now that we have aout2exe.exe and exe2aout.exe,
this is much less of a problem.
In short, I felt the patches I has posted along with the package provided
enough of a starting ground for others to rebuild the package with minimal
effort.
Enough explanations of my actions, on to something new.
I used GNU-Make from the very beginning, but I would have spurious problems
with it hanging my system. I beleive it was the swapping spawn routine
gnumake uses conflicting with something on my system. Whether is was go32,
qemm, the flakey disk cache i was using, I don't know. I eventually
switched over to using borland's make (that came with tc++ 1.0), though this
resulted in a LOT more hacking of the make files. Oh well. BTW, has any one
else noticed how borland's makes have approached the similarity of gnumake??
I seem to remember that the new boland makes (i've seen it on the campus
network, but I don't have tc++ 3.0) has 1 or 2 dot-directives that are
particular to gnu-make (that is, I don't *think* other unix makes has the
same feature, just gnu's). Then again, I haven't had that much experience
with unix makes, and may just be imagining things. :-)
Has anyone else had any problems with gnu-make and it's swapping algorithm??
Has anyone recompiled it using a later version of the gnuish progect library
that (I *think*) allows one to turn OFF the swapping?? just curious.
DJ: What version of binutils are you making from??? The ChangeLog that comes
with you distribution has a last entry of june 20, 1990, while the version on
prep.ai.mit.edu (1.9) has a last entry of apr 17, 1991. The reason I would
like to know it, the a.out.gnu.h file in the later version has an entry
like this:
#if !defined (N_BSS)
#define N_BSS 8
#endif
#if !defined (N_COMM)
#define N_COMM 18
#endif
#if !defined (N_FN)
#define N_FN 15
#endif
The aout.h that comes with djdev108.zip does NOT have the entry referring to
N_COMM. I am trying to compile dld3.23 (dynamic link/unlink editor, dynamic
link library support, addons to programs, etc), but I hate hacking aout.h to
add N_COMM to it. Also, the aoutgnu.h that comes with you binutils.zip does
not have N_COMM in it. I was wondering if you are using an older version.
Will it mess anything up for me to add that entry there, or can you update
to the newer version of binutils???
Oops... look before you leap... I just read diffs/versions, and it says
binutils 1.0 ... are there any problem with the newer versions, wrt porting
to dos??? I'd better finish there other 2 projects I'm working on before I
attack that problem, though....
I am currently also trying to compile zoo210 with djgpp. Anyone else done
this?? My major problem is lack of library support. 1.08 seems to have
some of the missing functions though (utime is my current stumbling back).
I've found the function in libc.a, but I couldn't find it in a header file
any where (but, I'm in the process of unpacking it at the moment anyway, so
I may find it yet). I'm wondering if I'll get more or less speed out of zoo210
under djgpp (my initial guess is a lot less speed, but it's worth the try).
Since it's a lot of file i/o, that means lots of switches between real and
protected more, and I doubt that zoo use much 32 bit stuff, except for maybe
some hashing functions. Most of the lzw and huffman stuff is at the bit level,
I assume, and unless 386 code for shifts is much faster than 8086 code on the
same machine, I don't expect much speed up there. But, it's a fun project,
none-the-less.
Has anyone tried a shell for desqview call, I think, dshell. The main feature
I read about it is the ability to spawn off other process when doing pipes so
that i/o goes straght from one process to another, with out dos's normal disk
accesses. That is a command line like:
tgatoppm test.tga | ppmquant 256 | ppmtogif > test.gif
would only have disk accesses to read in test.tga and write out test.gif, just
like a unix system would. Has anyone tried this shell with go32 programs??
Well, this is interesting. I just checked the source for utime[s] and
discovered it was stubbed out, rechecked the maillist archive, and discovered
that someone had mailed in a uuencoded version of utime.
Eric Backus: Was that zoo you were working on? Please contact me.
Told you all I probable missed some stuff when I read it :->
Anyway, enough long-winded babbling.... I'm about out of hard disk space, and
have to take some time to clear some out :-/
regards,
Mike Castle
- Raw text -