Bug in dosput?

[daniel mocsny]

Hello Net.

Well, I'm finally actually far enough into messing around with UNIX
to be crossing that evanescent threshold into the real of...useful
work! Yes, I find this as surprising as anyone else, but it can
happen! Just hang in there, and RTFM, and (as Winston Churchill
would growl) "Nevah give up!"

Seriously, I've written some C code using curses under Interactive
386/ix 2.0.something, and now I'm porting it to the ugly, but
unfortunately ubiquitous, world of MS-DOS. I'm using Bjorn Larsson's
PCcurses under Turbo C v. 2.0. I ran into an interesting little hitch
building the PCcurses library under TC, which turned out to follow
from an interesting glitch in dosput, the Interactive utility for
converting UNIX files to MS-DOS.

The PCcurses package comes in a set of shar files which you unpack
under UNIX and then must put on your PC. One way to do this is to use
dosput to write UNIX files to a DOS floppy. Among other things,
dosput needs to convert the UNIX newline end-of-line character to the
carriage-return/linefeed sequence MS-DOS wants to see. This dosput
usually does, with one slight problem. In the middle of the PCcurses
sources the file make.exe appears, a DOS binary executable file.
(Actually, PCcurses supplies make.uu, a uuencoded version, which you
uudecode either under UNIX or MS-DOS, depending on where you have
your uudecode program. Since I only have uudecode on UNIX, I created
make.exe there.)

Typing the line:

dosput * a:

seems to work without a problem. However, dosput seems to give up the
good fight after it copies make.exe. All test files after that have
only the UNIX newline character at the end of each line, not the
DOS sequence. Hmmm.

Of course, I wasn't aware of this when I set about to build PCcurses.
After the usual mucking about with the makefiles and directories and
such, I got my PCcurses libraries together. Turbo C wasn't reporting
any errors. But when I tried to link the libraries with my compiled
program sources, the Turbo linker kept complaining about not being
able to find a whole bunch (but not all) of the curses library
functions I was calling. Since I hardly knew my way around in Turbo
C, I had no idea what the problem was. 

After several workdays (yes, I'm embarrassed) of reading manuals and
trying everything, (every time I looked at the sources, everything
looked perfect, since I was using Vernon Buerg's list.com program
under MS-DOS, which is smart enough to accept UNIX newlines) I
eventually got around to generating a Turbo Librarian listing file,
when I read about how to do that. And lo, the missing curses functions
really were missing. Much work is necessary to overcome incorrect
initial assumptions during debugging...since I believed that
perfectly-good looking code would either compile or give me errors, I
interpreted the absence of errors to mean that the code actually was
compiling.

So I got the idea of trying to run the Turbo C stand-alone
preprocessor, a tactic I was familiar with under UNIX. CPP.EXE was
producing some pretty weird output. In the improperly compiling
PCcurses sources (all of which started with the letter 'M' or higher,
which did look suspicious, all right), the output of CPP.EXE consisted
only of the <curses.h> header file and nothing else. Since the only
thing in all those sources before the line #include <curses.h> was a
section of comments, I decided to try hex dumping the source files
with list.com and checking to see what could be wrong with the code
right at that point. That is where I saw the problem with the
end-of-line sequences.

Duh. When I then tried popping one of the UNIX-style files into the
Turbo C editor, the editor informed me that it had a file with ONE
very long line. Evidently the preprocessor/compiler was parsing
through this "line" until it reached the first #include preprocessor
directive, after which it silently ignored everything else on the
"line." So if I had been using the Turbo C environment to examine
files, I would have seen the problem right away. But I hadn't done
this, since I was more comfortable using list.com, and the PCcurses
stuff was all set up to use the Turbo C command line stuff.

I tried reproducing the error with dosput. It was reproducible.
Everytime I copied a set of files with wildcards, everything up to and
including the binary file would copy correctly, and everything
thereafter did not have proper MS-DOS end-of-line sequences.
So that gets me to my question: is this a known bug in dosput?
If so, do any of the Interactive updates fix it?

Oh and one more thing---the Turbo C built-in debugger works nicely
with PCcurses functions under straight MS-DOS, but apparently not
under vpix. I guess things get a little crowded with three different
programs competing to see who gets to control the display.

Dan Mocsny
dmocsny at uceng.uc.edu