[ros-kernel] Enhanced error messages

[Martin Fuchs]

Hello,

> If I understand your proposal correctly, my app running under
> ros would give me:
> 
> Could not open C:\Documents and Settings\galb.mydomain\Application 
> Data\Xyzzy\foo.txt: "C:\Documents and Settings\galb.mydomain\Application 
> Data\Xyzzy\foo.txt" not found
> 
> which seems a little bit obnoxious (I deliberately choose a long file
> name to make it more obnoxious :-)

Of course this is a very simple example - your application tries to open
a file explicitly, and can print its name in the error message.
There may be more complex scenarios when calling other functions
that create file names internally and then pass them to CreateFile().
In this cases you can't simply print out the file name from the application.

> Really, if we wanted to support this, maybe an extra
> flag to SetErrorMode() could swap out the message tables
> used in the system dlls, with ones containing inserts
> ("%1" not found, for example) and then an application
> would be required to either pass in the results of
> ROS_GetLastErrorInfo() as the Arguments parameter
> of FormatMessage(), or pass the flag to ignore inserts.
> 
> ROS native applications could SetErrorMode(SMART_MESSAGE_TABLES)
> 
> But windows native applications would continue to get the original
> error messages (that don't have the inserts.)

This would of course be a possibility. But then we could also just export
the new enhanced functions. The apps have to know about the new
features - this way or the other.

I would prefer to set the enhanced error messages as default handling.
We could introduce some compatibility mode for apps such as your example
above. Do you know the "Compatibility" property sheet of XP for EXE-files?
I'm thinking along this line. Default execution mode would be "ROS". If there
is a program, which has difficulties with this, one could run it in NT4/XP or
even an WIN98 mode. This would also be a possibility to introduce some
other enhancements without the danger of too many compatibility problems.

But since it seems no one other really likes my idea, I will drop it.

Regards,

   Martin