Re: Text version of Windows error messages in small_printf considered harmful

[Mumit Khan <khan@xraylith.wisc.EDU>]

Corinna Vinschen <corinna@vinschen.de> 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.

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.

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.

Over time, we can keep on expanding the error translation table.

> 
> > Because of this, I have conditionalized this code in recent snapshots.
> > It's off by default.
> > I'm thinking that an alternative is to add the
> > possibility to create text messages as an STRACE option.  I have always
> > wanted to write an strace program rather than using the kludgey environment
> > variable method.  If we did this, we could do something like
> > 'strace --text file.exe' to produce error message logs with text error
> > messages.
> 
> IMHO, the environment variable method is ok. It allows, to debug an
> application, that is started from the service manager.
> The `strace' program would nevertheless be a convenient method. I
> like this idea, too, and I think, this program can be very easy:
> It only has to control the setting of the environment variable.
> 

I do like the strace option, but please keep users in mind. 

Regards,
Mumit