windowscodecs questions.

[Max TenEyck Woodbury]

Background: I am trying to improve the performance/reliability of
 GuildWars2 under wine.  In particular, PNG handling seems very
 slow, so I am looking at windowscodecs and I seem to be
 misunderstanding some things.  I have read the PNG spec.

First: The CRC check.  The spec says that a 'chunk' contains a four
 byte size of data field, a four byte 'chunk identifier', the data
 and a CRC32 of the data.

 I found some code that reads a generic chunk.  I see where the size
 and type are read, where a correctly sized record is allocated and
 where the data is read into the record.

 There is a 'FIXME' that asks about checking the CRC, but no code to
 actually read or check the CRC.

 I added code to read and check the CRC to my working copy of the git
 tree.  That threw off the block synchronization, so I think there is
 code someplace else that either checks or skips the CRC, but I have
 not found it after a few hours searching for it.  An indication on
 where to look and other advice would be very helpful at this time.

Second: At least two of the methods GuildWars2 wants to use are stubbed.
 To implement those methods, the frame section of the WIC object should
 contain an array (or something with similar properties) of pointers to
 chunks.  From what I have read about WIC, other formats could use a
 similar array.  Some could even use an array of pointers to frames.
 Before I go messing with that level of change, I think I should listen
 to other peoples opinions of the subject.

Third: On a very broad level, the whole OLE implementation seems to be
 very messed up.  In particular, the usual practice for doing
 inheritance in C does not seem to be being used.  That practice is to
 have the elements common to the base and extending object be placed at
 the beginning of the implementing data structures.  While the member
 names need not be the same in all instances, the function, type and
 order of the common elements must be the same for economical
 implementation.

 This has been done for the basic object; all start with a pointer to
 the 'vtable'.  What I think should follow is the critical section lock
 structure and, for 'IUnknown', the reference count.  What I see is that
 these common elements are placed more or less at random in each
 extended object.

 Is there any reason, other than inertia, that at least these two
 fields should not be moved to the beginning of implementing objects.
 This can be done one object at a time and would allow the changed
 objects to use a common implementation of 'AddRef' at least, and
 another common routine or macro that handles the critical part of
 'Release'.