If you work with Win2K/XP, you can use NTobjects a free tool from www.smidgeonsoft.com. It shows you for each process the number of each type of GDI objects, compare that with the number that you observe in your wine logs.
That's a nice page, interesting looking tools. I tried it out and if the app is running it has 39 fonts and the other items (Pen, Brush, Bitmap) even less. So this looks like wine reserves unnecessarily too many fonts. I'll see if I find something more.
After fiddling around and creating some test programs I found that in wine a font is created for every control. Even a simple dialog with just four labels or textboxes in it will have 4 times a MS Sans Serif font. So this looks like another problem concerning wine and VB (Man, I hate this VB...). On Windows it uses only one font MS Sans Serif. As my original application which I want to make work uses many dialogs and controls it's now obvious why it runs out of GDI memory.
I'm now trying to find out who decides if a new font has to be created or if an old one can be used. If anyone knows about this (in VB) please let me know.
I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW a bit. Instead of always allocating a new gdi object it has a list of already allocated font objects and first tests if there was already a font allocated with the same logical properties (LOGFONTW). If so it just returns the existing HFONT and doesn't allocate a new one. With this change my VB app with the many controls comes up and is almost usable. Some fonts on the registers of the tab control look quite strange. But besides that it works.
Now is this a reasonable change (apart from its hacky implementation now :) ? Is the function CreateFontIndirect allowed to do something like this? Are there more things I should test than just the ones in the LOGFONTW struct? If anybody is interested in a screenshot (the funny fonts go down by about 20 degrees :) just raise your hand.
Maybe the caching needs to be done at another place. I have already seen the GdiFontList in freetype.c. But then it's already too late (and only works for ttf I guess). Another possibility may be to create the font but then free it again if a similar is found.
Thanks
bye Fabi