Well, it's a more general problem, namely that the spec files can reference functions that are not implemented directly in the dll.

You also have for instance:

@ cdecl strcpy(ptr str) strcpy

You'll need a file somewhere that specifies all the entries that cannot be determined automatically from the source. You simply cannot build a 100% correct spec file based only on the function comments. And you definitely do not want to need to parse KERNEL source files (like the ones in memory/) to build the USER spec file.

IMO, this is true if we can make the generator work purely on the source code, so that you can give it the unmodified source of a Windows dll and it spits out the spec file. If you need to add comments before each and every exported function, then I don't see much advantage to parsing the source. You might as well put all the information in the comment (or leave it in the current spec file for that matter).

Basically, if the source parsing allows doing more than we do now (like build spec files for new dlls) it's worthwhile; if all it does is generate the existing spec files some other way I don't think there's much point. After all, we have the spec files already, and they are not going to change much.

Another use of the source parser could be to generate more detailed debugging information for +relay; but in this case I'd say it should go to a completely different file, used by some external relay dumping program. I don't want all the extra debug information to clutter up the spec files.

When discussing with Ove yesterday on #WineHQ about the handling of X errors, he told me about an idea of his : using exceptions to handle X errors.

This way, when we have to explicitely handle X errors (as we will need to do for XVidmode and XDGA2 due to some (stupidly done IMHO :-) ) security fixes in XFree 4.x), we could do that using exceptions.

The main problem with that is that I don't think you can jump out of Xlib without corrupting its state. Also you'd need to properly unlock the tsx11 lock in case of exception, which will probably require an finally handler around each X call.

My idea was to have the following two functions:
void X11DRV_expect_error( unsigned char request, unsigned char error, XID id );
int X11DRV_check_error(void);

You'd call X11DRV_expect_error before doing an X call that can fail; then if an X error happens that matches what you expect, the X error handler will simply set a flag and ignore the error (if it doesn't match you get the standard error handling). Then after the call you use X11DRV_check_error to see if your error happened or not. Would this work for what you need?

I spent most of the day tracking an 'abort' in SYSMETRICS_Init due to the fact that the "DISPLAY" driver was not loaded.

I tracked this down to the fact that OpenGL32.DLL was the first library loaded by the application.

The problem is that when the loading of OpenGL32 happens, it first loads 'USER32'. When attaching 'USER32', it tries to reload 'X11DRV' (and fails as the 'recursion' lock is in place).

This means that when it calls SYSMETRICS_Init, the 'DISPLAY' driver was not registered yet (as we did not yet attach to the X11 driver) => we get the abort.

This is more a problem of inter-dependencies of X11DRV and USER32 (as the former should NEVER be loaded before the latter)... But as I could not fix this problem, I prefered going 'around' the problem :-)

And thus the attached patch (I see it was already done for DDraw) :

• one that is 'GDI' specific with the 'dc->funcs->pFUNC_NAME' sort of calls
• the other for 'USER' with 'USER_Driver.pFUNC_NAME'

I was planning on implementing ChangeDisplaySettingsA soon but I'm not certain on how to do it.

I have been browsing the source tree and was following the methods used by DirectDraw and was considering a similar approach. While I was browsing the source, I was eventually lead to dlls/x11drv/xvidmode.c which contains most of the functions that I will probably need. But I still have a few concerns:

1. Is the x11drv used for ddraw AND the gdi or just one?
2. what is the best way to query if the video exists? without knowing syncs?
3. and if i need to know syncs how do I find them?

Another question I have is about pixel depth. From what I understand, it is imposible to change the pixel format of the screen while X is running. However, it is possible to start more than one X server with different configs (and depth) which we could use if we have to but probably not a good idea. Of course another posibility is to emulate the pixel depth, but that would probably cause performance problems, especially when used by games. Anyone have any suggestions or should we just leave changing depths as unimplemented?

My first question was : why implement it ? I would personnaly find VERY annoying to have any Windows app. change the size of my desktop window when I prefer running my applications 'windowed'.

Moreover, I would prefer you to handle first the 'Desktop' case :-) In that case, no need to use any X extension, you just have to resize the desktop window.

Depth changing is part of the new X extension called 'RandR' (Rotate and Resize). I do not know at all though when it will be available on 'normal' X servers (as it was mostly developped now for the iPAQ handheld to rotate the screen).

Keith Packard (the Render author (BTW how is the support of this extension progressing :-) ? )) and Jim Gettys are the main developpers of this extension.

So I would probably wait for this extension to be available before starting any code on ChangeDisplaySettings... And please consider having it optional :-)