[1/3] Make mac driver the default on OS X
duboisj at codeweavers.com
Wed Mar 6 07:20:57 CST 2013
On 3/6/13 12:24 AM, Ken Thomases wrote:
> 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?
I figured it was that way for a reason, so I was trying to reduce noise
in the case that fall-through drivers fail. Even with making mac the
first thing we try to load, it seemed that a valid use was setting by
hand to, e.g., x11,mac, with working X11 libraries and DISPLAY unset.
But yes, it's more complicated: I don't care where they're printed.
(The same is true for the ERR->TRACE bits in the third chunk - I
certainly don't mind them both staying ERRs, or WARNs. I had
interpreted the failure of those things differently until the point at
which a window creation was attempted, but maybe that's wrong.)
>> + 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;
> Probably it's just best to say that the Mac driver is running in a non-GUI session such as a remote login.
Well, if something in Apple's code fails, it's still likely they'll
print to the console, yes? At any rate, I'm not attached to the error
message. As for whether to print errors in gdi32 or user32, I don't
feel strongly about that personally, either, but I'm curious what others
More information about the wine-devel