As I mentioned on IRC, I don't see any reason why you *must* use /drawsave.
If you're adding functionality via a dll to extend picwins, it seems reasonable to have an extra save functionality to save those extended picwin buffers.
/mydll.drawsave { dll MYDLL DrawSave }
As far as managing WM_PAINT calls, it's feasible to overlay a window and still handle the calls coming from mIRC's native /draw commands. It's not trivial, but it's possible, and that's what you should be focused on. How? Well, there are plenty of docs on subclassing and hooking in MSDN.
I'm not too sure what you're trying to get out of this thread. You seem to know pretty much all there is to know about how the windows work. I doubt Khaled can add much to this-- there's no magic repository of information that would make subclassing the window any simpler. As you have probably figured out on your own (and as I mentioned on IRC as well), the buffer mIRC uses to store the actual image data is probably some internal data structure that you do not have access to. It's unlikely you'll get access to this data structure, so you have to treat it as a black box and deal with the WINAPI interface as any extension code would. This means subclassing the static control or hooking into its MessageProc, handling the WM_PAINT calls and injecting your own logic there.
