Re: Check Server Version From Client Dlls

[Andreas Mohr]

Hi,

On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote:
> Changelog:
> Check server version from x11drv, kernel32 and user32 to prevent 
> mismatches of installed dlls.

Slight overkill, I'd say.

Why not do:

if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ...

if (ver != SERVER_PROTOCOL_VERSION)
        	MESSAGE( "Error: server version mismatch.\n"
                	 "Your %s binary was not upgraded correctly\n"
                	 "or the wrong wineserver is still running.\n", dll_name );
    return (ver == SERVER_PROTOCOL_VERSION);

Greetings,

Andreas Mohr

Check Server Version From Client Dlls

[Robert Shearman]

Andreas Mohr wrote:
> Hi,
>
> On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote:
> > Changelog:
> > Check server version from x11drv, kernel32 and user32 to prevent 
> > mismatches of installed dlls.
>
> Slight overkill, I'd say.
>
> Why not do:
>
> if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ...
>
> if (ver != SERVER_PROTOCOL_VERSION)
>        	MESSAGE( "Error: server version mismatch.\n"
>                	 "Your %s binary was not upgraded correctly\n"
>                	 "or the wrong wineserver is still running.\n", dll_name );
>    return (ver == SERVER_PROTOCOL_VERSION);

Ok, I'll send an updated patch.

Rob

Check Server Version From Client Dlls

[Alexandre Julliard]

Robert Shearman  writes:
> > if (ver != SERVER_PROTOCOL_VERSION)
> >        	MESSAGE( "Error: server version mismatch.\n"
> >                	 "Your %s binary was not upgraded correctly\n"
> >                	 "or the wrong wineserver is still running.\n", dll_name );
> >    return (ver == SERVER_PROTOCOL_VERSION);
>
> Ok, I'll send an updated patch.

Actually I don't think we want to add this kind of check at all. The
whole point of dll separation is to make sure we don't need that sort
of thing; while we are not 100% there yet, adding more version checks
is going in the wrong direction.

Check Server Version From Client Dlls

[Robert Shearman]

Alexandre Julliard wrote:
> Robert Shearman  writes:
> > > if (ver != SERVER_PROTOCOL_VERSION)
> > >       	MESSAGE( "Error: server version mismatch.\n"
> > >               	 "Your %s binary was not upgraded correctly\n"
> > >               	 "or the wrong wineserver is still running.\n", dll_name );
> > >    return (ver == SERVER_PROTOCOL_VERSION);
> >
> > Ok, I'll send an updated patch.
>
> Actually I don't think we want to add this kind of check at all. The
> whole point of dll separation is to make sure we don't need that sort
> of thing; while we are not 100% there yet, adding more version checks
> is going in the wrong direction.

DLL separation is not going to help when a function in user32 calls the 
server and fails due to mismatched server interfaces. You just get a 
very cryptic error message:
err:msg:QUEUE_CreateMsgQueue Cannot get thread queue

Note that I only added it to the DLLs that will always need server calls 
(i.e. not advapi32), but I was very surprised that gdi32 didn't call the 
server.

Rob

Check Server Version From Client Dlls

[Alexandre Julliard]

Robert Shearman  writes:
> DLL separation is not going to help when a function in user32 calls
> the server and fails due to mismatched server interfaces.

Yes it will, because part of that task is also to ensure that the
server protocol is backwards compatible. This isn't fully the case yet
but it should be soon. And really I don't think upgrading a single dll
is a case common enough to justify exporting new APIs for a check that
will need to be removed later anyway.

Check Server Version From Client Dlls

[Robert Shearman]

Alexandre Julliard wrote:
> Robert Shearman  writes:
> > DLL separation is not going to help when a function in user32 calls
> > the server and fails due to mismatched server interfaces.
>
> Yes it will, because part of that task is also to ensure that the
> server protocol is backwards compatible. This isn't fully the case yet
> but it should be soon. And really I don't think upgrading a single dll
> is a case common enough to justify exporting new APIs for a check that
> will need to be removed later anyway.

Fair enough.

Rob