Xref: utzoo comp.sys.ibm.pc:45168 comp.lang.c:26283 comp.sys.ibm.pc.programmer:112 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!psuvm!cmh117 From: CMH117@psuvm.psu.edu (Charles Hannum) Newsgroups: comp.sys.ibm.pc,comp.lang.c,comp.sys.ibm.pc.programmer Subject: Re: Sticky IBM C programming problems (summary of replies) Message-ID: <90055.142524CMH117@psuvm.psu.edu> Date: 24 Feb 90 19:25:24 GMT References: <498@bilver.UUCP> Distribution: usa Organization: Penn State University Lines: 124 I seem to have missed your original posting, so I'll take this opportunity to respond. In article <498@bilver.UUCP>, alex@bilver.UUCP (Alex Matulich) says: > > ... the MSC manuals do NOT answer my questions, which > is why I asked them; the Turbo C manuals do, however the ones I had > were from version 1.5 or earlier and I didn't know it! > > I have been using primarily MSC. Almost every single respondent is a > Turbo C user, so many of the responses didn't apply to MSC -- I didn't > realize Turbo C was so popular. Anybody know anything about Lattice? Probably because Turbo C is *fast*, the integrated environment in one *hell* of a lot better than M*crosoft's, and the manuals are superb! >COMMENT: I was hoping to preserve portability in my programs by using > cprintf() everywhere, and, in porting it to a non-IBM computer, using > #define cprintf printf, but cprintf() doesn't translate the \n character > properly, nor does it work with ANSI escape codes. But I do have uses. > cprintf() in Microsoft C is just as SLOW as printf()! Turbo C is much > faster, but the text doesn't inherit the current stdout text colors. > As far as I can tell, _write() needs a file handle, and I don't know how > to get a file handle to the video memory. Lemme explain ... cprintf(), et al., are specified to write directly to the CON: device (or /dev/ttyxx, or whatever), rather than to stdout or stderr. They are *supposed* to do the same translations as printf() (et al.); I suspect this is why the MSC library routines seem to offer no improvement in speed over the normal printf() routines; this is not what they were meant for. In Turbo C 1.0 (I've had it since the beginning!) the output was sent directly to the MS-DOS console I/O functions (rather than the file I/O functions, which are normally used). However, this didn't follow the definition either, as they could be redirected. Starting with Turbo C 1.5, the console library has forced it to write directly to the screen (literally!!! B-), but it still doesn't do proper translations; you still have to use "\n\r" rather than "\n". If you just want to speed up output, and you're displaying line-by-line, use setvbuf(stdout,... _IOLBF ...) (not exactly; fill in the missing arguments!). I don't know about MSC, but this DRAMATICALLY improves performance in Turbo C. (The reason, for those interested, is that Turbo C says "Hey! It's a character device!" and proceeds to write ONE STINKING CHARACTER at a time. With MS-LOSS this is horrendously slow. By using _IOLBF, a whole line is output on each MS-LOSS call. [Note: _IOFBF on an output file is the same in TC as _IOLBF.]) >COMMENT: gettext(), etc. is only available on Turbo C. > My current project is too big to convert to curses, but I'll look for > it next time. I have yet to see a decent (read: REASONABLY FAST) version of Curses! on the PC. If someone actually has a copy, I'd appreciate it, as I don't generally make a habit of porting brain-dead software. >COMMENT: textbackground() and textcolor() aren't available with MSC. > Escape sequences don't work with cputs(), cprintf(), etc. but it's not > a real problem to use escape sequences with stdout functions when speed > doesn't matter. In your portability quest, you are not considering the problem of porting to an entirely different *architecture*. What if you're using a Tektronix terminal on a *nix machine? The escape sequences will be completely different! Your best option, if you want total portability, is to use a *nix-like "termcap" file. >COMMENT: Hmmm, that's right -- if I wait LONNNG enough, the critical error > handler does indeed get invoked with a "device not ready" message. From > the responses I got, I gather that there's not really any good way to do > this. And how do I access "the print spooler"?? Is it a part of MS-DOS? The "print spooler" is PRINT.COM. It's documented in the MS-DOS manual. >COMMENT: Sure enough, there it is in the MSC manual! The MSC index listed > nothing useful under "directory", "directory control", "files", and other > obvious headings. _dos_findfirst(), indeed! I never looked at that one > long enough to realize what it was. Also, implementation differences > between these functions in Turbo C and MSC make for difficult porting. These functions are not derived for any type of standard, and therefore cannot be expected to be portable. Tough. >Look in argv[0], it contains the path of the program. Then use fnsplit() > and fnmerge() to manipulate the path. Works under DOS 3.x. >Use searchpath(). Note: This was in reference to the statement below, which indicates that in DOS -3.00, argv[0] doesn't contain the complete path. >In version 1.x and 2.x, your best bet is to search the current directory, > and then the path, yourself, which is a pain. Note: Version 1.x doesn't use paths. [B-)] >[What books do you recommend?] >The manuals that came with Turbo C You'll get no argument on that one! They're excellent! (Herbert Schildt's?) "Turbo C Pocket Reference". I'm not sure it's ever been updated since version 1.5, but it's still an incredibly useful book. >Many thanks to all the people who contributed (did I leave anyone out?): > > ... >CMH117@psuvm.psu.edu (Charles Hannum) I'm at the bottom of the list! B-) Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."