dmocsny@uceng.UC.EDU (daniel mocsny) (03/03/90)
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@uceng.uc.edu