November 2010 - Wine-Devel - list.winehq.org

Stopping Win9x testing

by Greg Geldorp

> From: Paul Vriens > > On 11/30/2010 04:41 PM, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly questionable. > > We don't try to emulate the Win9x behavior anyway, except in a very few > > cases (which most likely don't have tests...) so it only serves to > > document historical behavior that nobody cares about any longer. > > > > I wouldn't be opposed to switching off win9x test runs and getting rid > > of the corresponding broken(). > > So the first thing is a patch to winetest.exe and the winetest website > and at the same time tell Greg to exclude it from 'patchwatcher' and the > batch running of the (almost) daily winetests. I'll mark the Win9x VMs offline when there's nothing queued to run on them. Then in a weeks time I can delete them after all jobs referring to them have been retired/deleted (referential integrity in the database). So for the next week you'll see a red dot with "One or more VMs are offline" on the testbot main page, don't be alarmed by this. Greg.

Nov. 30, 2010

Re: Death to win9x?

by Paul Vriens

On 11/30/2010 08:53 PM, Eric Durbin wrote: > On Tue, Nov 30, 2010 at 12:17 PM, Dan Kegel <dank(a)kegel.com > <mailto:dank(a)kegel.com>> wrote: > > I'm all for removing stuff that nobody needs anymore. I imagine there > are still a few popular older apps that will force us to keep some old > win9x behaviors around, though, so we probably won't be able > to remove the 'emulate win98' choice from winecfg any time soon. > > > > Windows 7 still offers a compatibility mode back to Windows 95 in a > program/shortcut's properties. I don't think wine should remove this. > > > > I think the first (only?) thing we should discuss right now is whether we should stop running our test-suite on Win9x/WinME. The little bits and pieces we have in our code should stay as we probably need that to cope with old apps that expect a different behavior. -- Cheers, Paul.

Nov. 30, 2010

Re: Death to win9x?

by Eric Durbin

On Tue, Nov 30, 2010 at 12:17 PM, Dan Kegel <dank(a)kegel.com> wrote: > I'm all for removing stuff that nobody needs anymore. I imagine there > are still a few popular older apps that will force us to keep some old > win9x behaviors around, though, so we probably won't be able > to remove the 'emulate win98' choice from winecfg any time soon. > > > Windows 7 still offers a compatibility mode back to Windows 95 in a program/shortcut's properties. I don't think wine should remove this.

Nov. 30, 2010

Death to win9x?

by Dan Kegel

I'm all for removing stuff that nobody needs anymore. I imagine there are still a few popular older apps that will force us to keep some old win9x behaviors around, though, so we probably won't be able to remove the 'emulate win98' choice from winecfg any time soon.

Nov. 30, 2010

Re: mshtml: Added beginning ActiveX tests.

by Paul Vriens

On 11/30/2010 04:41 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> I can see that these tests may be useful sometimes, eg. if someone is >> interested in old apps that don't run on new Windows. But the honest >> true is that it's not what happens with our tests. All we usually do >> with old Windows or old IEs is blindly (well, not always, you do >> better than that) marking them as broken. The result is that our tests >> have more complicated code and are less strict. Thus my personal >> strategy is different: leave win9x (or old IEs for that matter) alone >> as long as they don't cause troubles. As soon as there is a trouble >> with a test on a platform that I don't care about, I just disable the >> whole file. This way I don't waste my time on uninteresting platforms, >> the code stays cleaner and tests remain stricter, giving win9x tests a >> chance to prove itself. I've already sent quite a few patches applying >> this strategy to different tests. > > The value of running tests on Win9x these days is certainly questionable. > We don't try to emulate the Win9x behavior anyway, except in a very few > cases (which most likely don't have tests...) so it only serves to > document historical behavior that nobody cares about any longer. > > I wouldn't be opposed to switching off win9x test runs and getting rid > of the corresponding broken(). > So the first thing is a patch to winetest.exe and the winetest website and at the same time tell Greg to exclude it from 'patchwatcher' and the batch running of the (almost) daily winetests. Cleaning up the tests will come after that and will certainly be a nice long janitorial task. -- Cheers, Paul.

Nov. 30, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by Aric Stewart

Sent a revised patch using the ICMDecompression apis just before seeing your e-mail. So I figured out that part. I will have to look into the pixel buffer copying improvement once the base framework is in place. thanks! -aric On 11/30/10 10:33 AM, Ken Thomases wrote: > On Nov 30, 2010, at 6:52 AM, Alexandre Julliard wrote: > >> Aric Stewart<aric(a)codeweavers.com> writes: >> >>> --- >>> configure | 8 +- >>> configure.ac | 5 + >>> dlls/wineqtdecoder/Makefile.in | 11 + >>> dlls/wineqtdecoder/main.c | 135 +++++++++ >>> dlls/wineqtdecoder/qtvdecoder.c | 536 >>> +++++++++++++++++++++++++++++++++ >>> dlls/wineqtdecoder/version.rc | 26 ++ >>> dlls/wineqtdecoder/wineqtdecoder.spec | 4 + >>> 7 files changed, 724 insertions(+), 1 deletions(-) >>> create mode 100644 dlls/wineqtdecoder/Makefile.in >>> create mode 100644 dlls/wineqtdecoder/main.c >>> create mode 100644 dlls/wineqtdecoder/qtvdecoder.c >>> create mode 100644 dlls/wineqtdecoder/version.rc >>> create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec >> >> This is showing many deprecated function warnings even on Leopard. We >> should try to avoid that in new code. > > Aric, > > The DecompressSequenceBeginS takes a CGrafPort or GWorld. These are QuickDraw concepts and are very, very obsolete. DecompressSequenceBeginS should be deprecated, itself, since it depends on them, but doesn't appear to be. The documentation on this whole area is terrible. Apple seems to have blackholed even the documentation of the more modern APIs. (You can still get it from within Xcode 3.2.x if you go into preferences and subscribe to the Leopard docset. But it seems largely gone from their website.) > > As is often the case, the headers provide what documentation there is. According to the headers (/System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h), the replacement is ICMDecompressionSessionCreate() and friends, also in that header. (That header has both old APIs and new. You want the ones introduced with Mac OS X 10.4 or later, or QuickTime 7 or later.) > > The ICMDecompression... functions feed you CVPixelBuffer objects through a callback. Those are documented here<http://developer.apple.com/library/mac/#documentation/QuartzCore/Reference/…>. (Take note of the "Derived from" info at the top of that page. If you feel that CVPixelBuffer is missing some important API, it may be provided by the base classes.) > > The ICMDecompression... API seems kind of asynchronous in nature, but I think you can force it to fully decompress frames immediately via the frameTime parameter to ICMDecompressionSessionDecodeFrame(). The flags field of ICMFrameTimeRecord can include icmFrameTimeDecodeImmediately. > > The next thing that might be useful are some techniques to avoid doing the pixel copying manually. Depending on the output format you require (This->outputDepth and This->rowBytes), you may be able to create a CGBitmapContext to wrap the output buffer. Then, you can create a CGImage from the CVPixelBuffer, and draw the image into the context. (The modern Mac APIs don't really have blit operations, they copy and/or convert images by drawing.) Some of these techniques are illustrated in this sample code:<http://developer.apple.com/library/mac/#samplecode/CaptureAndCompressIPBMov…>. Actually, it sort of does the reverse. It wraps the CVPixelBuffer in the bitmap context and draws onto it, but the principle is similar. > > I hope that helps. > > -Ken >

Nov. 30, 2010

Re: [1/4] winmm/tests: Add tests for mmioOpen for the file name of the form EXAMPLE.EXT+ABC.

by Dmitry Timoshkov

Alexander Puzankov <alxpnv(a)gmail.com> wrote: > Ok, I missed that MSDN says that the first parameter of the custom I/O procedure > is of type LPSTR instead of LPMMIOINFO (could be this an error in the > documentation?). Both PSDK and Wine headers use the same definition for MMIOPROC. > I can make cast in mmio_test_IOProc instead, something like: > > static LRESULT CALLBACK mmio_test_IOProc(LPSTR lpMMIOInfo, UINT > uMessage, LPARAM lParam1, LPARAM lParam2) > { > LPMMIOINFO lpmmioinfo = (LPMMIOINFO) lpMMIOInfo; > ... > } > > So should I remove these casts and resend the entire patchset in the right > order? Yes please. -- Dmitry.

Nov. 30, 2010

Re: wineqtdecoder: initial commit of the video decoder using Mac OS/X QuickTime Framework

by Ken Thomases

On Nov 30, 2010, at 6:52 AM, Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> --- >> configure | 8 +- >> configure.ac | 5 + >> dlls/wineqtdecoder/Makefile.in | 11 + >> dlls/wineqtdecoder/main.c | 135 +++++++++ >> dlls/wineqtdecoder/qtvdecoder.c | 536 >> +++++++++++++++++++++++++++++++++ >> dlls/wineqtdecoder/version.rc | 26 ++ >> dlls/wineqtdecoder/wineqtdecoder.spec | 4 + >> 7 files changed, 724 insertions(+), 1 deletions(-) >> create mode 100644 dlls/wineqtdecoder/Makefile.in >> create mode 100644 dlls/wineqtdecoder/main.c >> create mode 100644 dlls/wineqtdecoder/qtvdecoder.c >> create mode 100644 dlls/wineqtdecoder/version.rc >> create mode 100644 dlls/wineqtdecoder/wineqtdecoder.spec > > This is showing many deprecated function warnings even on Leopard. We > should try to avoid that in new code. Aric, The DecompressSequenceBeginS takes a CGrafPort or GWorld. These are QuickDraw concepts and are very, very obsolete. DecompressSequenceBeginS should be deprecated, itself, since it depends on them, but doesn't appear to be. The documentation on this whole area is terrible. Apple seems to have blackholed even the documentation of the more modern APIs. (You can still get it from within Xcode 3.2.x if you go into preferences and subscribe to the Leopard docset. But it seems largely gone from their website.) As is often the case, the headers provide what documentation there is. According to the headers (/System/Library/Frameworks/QuickTime.framework/Headers/ImageCompression.h), the replacement is ICMDecompressionSessionCreate() and friends, also in that header. (That header has both old APIs and new. You want the ones introduced with Mac OS X 10.4 or later, or QuickTime 7 or later.) The ICMDecompression... functions feed you CVPixelBuffer objects through a callback. Those are documented here <http://developer.apple.com/library/mac/#documentation/QuartzCore/Reference/…>. (Take note of the "Derived from" info at the top of that page. If you feel that CVPixelBuffer is missing some important API, it may be provided by the base classes.) The ICMDecompression... API seems kind of asynchronous in nature, but I think you can force it to fully decompress frames immediately via the frameTime parameter to ICMDecompressionSessionDecodeFrame(). The flags field of ICMFrameTimeRecord can include icmFrameTimeDecodeImmediately. The next thing that might be useful are some techniques to avoid doing the pixel copying manually. Depending on the output format you require (This->outputDepth and This->rowBytes), you may be able to create a CGBitmapContext to wrap the output buffer. Then, you can create a CGImage from the CVPixelBuffer, and draw the image into the context. (The modern Mac APIs don't really have blit operations, they copy and/or convert images by drawing.) Some of these techniques are illustrated in this sample code: <http://developer.apple.com/library/mac/#samplecode/CaptureAndCompressIPBMov…>. Actually, it sort of does the reverse. It wraps the CVPixelBuffer in the bitmap context and draws onto it, but the principle is similar. I hope that helps. -Ken

Nov. 30, 2010

Re: mshtml: Added beginning ActiveX tests.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > I can see that these tests may be useful sometimes, eg. if someone is > interested in old apps that don't run on new Windows. But the honest > true is that it's not what happens with our tests. All we usually do > with old Windows or old IEs is blindly (well, not always, you do > better than that) marking them as broken. The result is that our tests > have more complicated code and are less strict. Thus my personal > strategy is different: leave win9x (or old IEs for that matter) alone > as long as they don't cause troubles. As soon as there is a trouble > with a test on a platform that I don't care about, I just disable the > whole file. This way I don't waste my time on uninteresting platforms, > the code stays cleaner and tests remain stricter, giving win9x tests a > chance to prove itself. I've already sent quite a few patches applying > this strategy to different tests. The value of running tests on Win9x these days is certainly questionable. We don't try to emulate the Win9x behavior anyway, except in a very few cases (which most likely don't have tests...) so it only serves to document historical behavior that nobody cares about any longer. I wouldn't be opposed to switching off win9x test runs and getting rid of the corresponding broken(). -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2010

Re: mshtml: Added beginning ActiveX tests.

by Jacek Caban

On 11/30/10 3:49 PM, Paul Vriens wrote: > On 11/30/2010 03:42 PM, Jacek Caban wrote: >> Hi Paul, >> >> On 11/30/10 2:46 PM, Paul Vriens wrote: >>> Changing the lstrcmpW and using A-functions to create the window makes >>> the tests succeed on my win98 box (changed activex.c attached). >> >> Thanks for catching it. How about this version: >> http://source.winehq.org/patches/data/68936 >> I would prefer to forget about win9x when writing tests, so I've skipped >> as much as possible on them. >> > > I guess that's AJ's call? Taking this approach is fine with me but we > could then start considering whether we still want to test on Win9x. > Microsoft has abandoned those old versions already so maybe we are the > only solution for old programs (and we thus need tests?). > > Or are you only talking about stuff like mshtml/shdocvw ....? I was mostly talking about stuff I work on, but since you brought the topic here is my opinion: I can see that these tests may be useful sometimes, eg. if someone is interested in old apps that don't run on new Windows. But the honest true is that it's not what happens with our tests. All we usually do with old Windows or old IEs is blindly (well, not always, you do better than that) marking them as broken. The result is that our tests have more complicated code and are less strict. Thus my personal strategy is different: leave win9x (or old IEs for that matter) alone as long as they don't cause troubles. As soon as there is a trouble with a test on a platform that I don't care about, I just disable the whole file. This way I don't waste my time on uninteresting platforms, the code stays cleaner and tests remain stricter, giving win9x tests a chance to prove itself. I've already sent quite a few patches applying this strategy to different tests. Jacek

Nov. 30, 2010