Re: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...
Hi Ge, On Wednesday 07 September 2005 01:05, you wrote:
I'm working on importing the changes between Wine-20050725 and Wine-20050830 into ReactOS. This also includes your patch below. I'm not sure if you realized it, but shell32 now wastes a lot of memory. The problem is the initialization of the icon cache. Previously, icons with indexes 1-39 would be loaded. Since IDI_SHELL_MY_DOCUMENTS has such a high number, now icons with indexes 1-235 are loaded. Most of those ofcourse don't exist and will be replaced with index 1, but they still take up a lot of space in the ImageList bitmaps. I've found that, for ReactOS running on a 32bpp display, memory usage of shell32 increased by 17Mb. This may in part be a problem in ReactOS (it's much higher than I expected), but even for Wine the increase in mem usage should be considerable. The ImageLists get expanded to 494 entries, taking up 494 (entries) * 2 (color + mask) * 32 (sizex) * 32 (sizey) * 4 (32bpp) = 4Mb per ImageList. We're keeping 2 ImageLists, plus 2 16*16 ImageLists, all in all we're talking about 10Mb minimum. And this for every process that loads shell32.
I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it: http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls?
For the moment I'm limiting the ReactOS icon cache to the lower 39 entries, but I think we need to figure out a way to include the My Documents icon without wasting so much space.
As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de
Michael,
I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it:
http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html
I actually read the discussion but didn't make the connection when looking at this problem.
The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls?
Yes, you're right on both counts, we do have real PE dlls and it turns out we don't actually need the pre-init. Thanks for solving my problem :-)
As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months.
To fix the memory waste, maybe Wine could stop substituting icon with index 0 for non-existent icons in SIC_Initialize? PidlToSicIndex() will try to find the icon and when it doesn't exist will return index 0 anyway. This doesn't solve the general problem of loading resources from Wine dlls ofcourse. Gé van Geldorp.
participants (2)
-
Ge van Geldorp -
Michael Jung