Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Mon, 7 Jun 1999 13:15:22 -0400 To: Mumit Khan Cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: Text version of Windows error messages in small_printf considered harmful Message-ID: <19990607131522.A1738@cygnus.com> References: <37579252 DOT 34EB714E AT vinschen DOT de> <199906071552 DOT KAA02703 AT mercury DOT xraylith DOT wisc DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199906071552.KAA02703@mercury.xraylith.wisc.edu>; from Mumit Khan on Mon, Jun 07, 1999 at 10:52:55AM -0500 On Mon, Jun 07, 1999 at 10:52:55AM -0500, Mumit Khan wrote: >Corinna Vinschen writes: >> Chris Faylor wrote: >> > Now that I've had the chance to use the extended error messages that >> > Mumit recently added to smallprint.c, I have to say that I'm not thrilled. >> > The error messages extend the length of the line so that things wrap >> > in a way that makes it hard to read. Worse, I've received a couple of >> > strace logs from non-US users and the error messages are incomprehensible >> > to me. Another problem is that it is not easy to figure out exactly >> > which error *code* is being displayed even when the error is in English. >> >> I agree. I'm native german and it's easier for me to work with error >> codes than with german or english error messages. It's definitely >> easier to find related information with the error code instead of with >> the error message. > >I on the other hand find it *very* cumbersome to look up error messages >when given just numbers; eg., 'dlopen: win32 error 113' or something >similar means nothing to a user, when something like 'dlopen: can't find >shared library' means a lot more. Sure it does. But when it is a slightly more obscure error message the correspondence to an ERROR_* define might be more useful. In the Win32 API documentation they do mention ERROR_* defines from time to time, although not as often as they should. The definitions in include/winerror.h do not contain the text of the message so, when you're displaying messages, you have to guess what message corresponds to what ERROR_* define. Of course, we could clutter up the strace output even more by including the error number along with the error text but one of the problems is that the strace files are a lot larger and a lot harder to read with the addition of error messages. Adding more text doesn't seem like the way to go to me. >However, since the code is problematic, it should be taken out or turned >on via a env variable as Chris suggests. > >The language issue is trivial -- just force the language to be US English >instead of native in the FormatMessage. How does this work with "keeping the users in mind", then? This helps only US users. >IMO One way to do this correctly is the following: > >- tag a set of these error codes as something we would like to display > using a human-readable message. >- have a associative translation table using the error code as the key; > the table will have error messages formatted like sys_errlist to > provide Unix-like consistency (eg., short and no embedded newlines!). >- display only these messages as text. I don't see any reason for this logic to be inside cygwin, actually. The translation could easily be provided by some sort of strace file filter or, eventually, by an strace program itself. cgf