Hi,
Maybe you know, I hope to submit several fixes and tests for avifile soon. Vitaliy Margolen pointed out I should be create proper temporary files in the system's tmp directory so I implemented this. This actually showed a new bug in Wine's avifile:
Wine's avifile does not handle normal avi files with an filename extension different than avi (f.e. tmp), while Windows XP's avifile has no problems with those at all.
The problem is in this part of the code: http://source.winehq.org/source/dlls/avifil32/api.c#L244
I discussed it with Roderick a bit on IRC and he said the whole registry check is flawed and there should be detection for AVI files based on the content of the file. I then did some tests and replaced line 247 (return AVIERR_UNSUPPORTED;) with "clsidHandler = CLSID_AVIFile;" which always forces the correct handler for AVI files. With that change I get the exact same behaviour as on Windows: Proper AVI files always work, irregardless of their filename extension. Files in which I replaced "AVI LIST" (the magic with which AVI files can be detected) with "AV2 LIST" in a hex editor fail on both Windows and Wine. On both they immediately fail with the error that my file is not an AVI file.
So this means that there already is proper detection in Wine based on the content of the file! There is just one extra obstacle in front now.
I'm not very familiar (yet) with COM, CLASS IDs and how files are generally handled in Wine. Also I don't really know much about VFW, I especially cannot imagine what other files than AVI files would need to be read using avifile (but from the code I except this is possible). So my question is: What do you think would be an appropriate way to solve this? Should I just remove the obstacle or add my change? Or do something completely different? Also if anyone can shed more light on the current idea behind the code, this would be welcome!
Thanks a lot in advance, Julius
On Fri, Jan 8, 2010 at 12:40 PM, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Hi,
Maybe you know, I hope to submit several fixes and tests for avifile soon. Vitaliy Margolen pointed out I should be create proper temporary files in the system's tmp directory so I implemented this. This actually showed a new bug in Wine's avifile:
Wine's avifile does not handle normal avi files with an filename extension different than avi (f.e. tmp), while Windows XP's avifile has no problems with those at all.
The problem is in this part of the code: http://source.winehq.org/source/dlls/avifil32/api.c#L244
I discussed it with Roderick a bit on IRC and he said the whole registry check is flawed and there should be detection for AVI files based on the content of the file. I then did some tests and replaced line 247 (return AVIERR_UNSUPPORTED;) with "clsidHandler = CLSID_AVIFile;" which always forces the correct handler for AVI files. With that change I get the exact same behaviour as on Windows: Proper AVI files always work, irregardless of their filename extension. Files in which I replaced "AVI LIST" (the magic with which AVI files can be detected) with "AV2 LIST" in a hex editor fail on both Windows and Wine. On both they immediately fail with the error that my file is not an AVI file.
So this means that there already is proper detection in Wine based on the content of the file! There is just one extra obstacle in front now.
I'm not very familiar (yet) with COM, CLASS IDs and how files are generally handled in Wine. Also I don't really know much about VFW, I especially cannot imagine what other files than AVI files would need to be read using avifile (but from the code I except this is possible). So my question is: What do you think would be an appropriate way to solve this? Should I just remove the obstacle or add my change? Or do something completely different? Also if anyone can shed more light on the current idea behind the code, this would be welcome!
Thanks a lot in advance, Julius
Write and submit tests that show the correct behavior, then submit a patch that makes Wine match that behavior. In general, questions like "What's the right fix?" can be answered by thorough, well-thought out tests.
James Hawkins wrote:
Write and submit tests that show the correct behavior, then submit a patch that makes Wine match that behavior. In general, questions like "What's the right fix?" can be answered by thorough, well-thought out tests.
I can write tests for the cases I just described and my fix would work, but I don't think it'd be the right way. I'm not sure what a better way would be though, I think also because I do not fully understand the COM architecture.
-
James Hawkins -
Julius Schwartzenberg