On Mar 5, 2013, at 6:32 PM, Josh DuBois wrote:
dlls/gdi32/driver.c | 102 +++++++++++++++++++++++++++++++++++++++++++-- dlls/gdi32/gdi32.spec | 1 + dlls/gdi32/gdi_private.h | 2 + dlls/user32/driver.c | 27 ++++++------ include/wine/gdi_driver.h | 11 +++++ 5 files changed, 125 insertions(+), 18 deletions(-)
<0001-Track-and-report-multiple-errors-loading-display-drive.txt>
As I believe you're aware, I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. So, maybe this was just submitted in preparation for that time, but there should probably have been a note to that effect.
Also, this patch seems exceedingly complex for a relatively simple problem. Just because it has historically been user32 that reported failure to load the driver doesn't mean it must remain so, at least to my way of thinking. Why not just print out the diagnostics directly in gdi32 as each attempt to load a driver fails? In user32, there can be a secondary, driver-agnostic message about failure to create a window.
case ERROR_DLL_INIT_FAILED:load_err->err_msg = "Make sure you have permission to create \na window or check for errors with Console.app. \n(The Mac driver cannot do remote display: try X11 if you need that.)";break;
"Make sure you have permission to create a window" doesn't mean anything to me. Checking Console.app isn't very useful either. If the user sees this message, then they're already looking at wherever the process's output is going. Running Wine from a shell won't write anything to the console logs. As of Mountain Lion, running it from a GUI app won't either; Apple changed things so that stdout and stderr of GUI apps go to /dev/null rather than console logs. (Only things like NSLog() or asl_log() go to the console log.)
Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login.
-Ken