March 2008 - Wine-devel - list.winehq.org

Re: quartz: Set a default sync source on the filtergraph
by Chris Robinson 14 Mar '08

14 Mar '08

On Friday 14 March 2008 04:25:02 pm Maarten Lankhorst wrote: > Use the fallback system IReferenceClock, unless the app comes up with > its own clock. This doesn't look right. According to MSDN, the clock used when Run is called is chosen by the following algorithm: 1- The app called IMediaFilter::SetSyncSource 2- A live filter source is connected to the graph and supports the IReferenceClock interface 3- Any filters support IReferenceClock, starting with renderers and going "upstream" (following pin connections to the source), and falling back to disconnected filters if still nothing. Normally, an audio renderer would be selected here. 4- If still nothing, use the system reference clock. I don't think SetDefaultSyncSource should should just jump right to the system clock. As far as I can tell, you need to hold a reference to a clock, and a bool saying if it's custom set (as even NULL can be a valid custom override). When Run is called, if no custom override is set, it would release the current set clock (if any) and check as steps 2, 3, and 4 describe. So really what the function needs to do is release the current set reference clock (if non-NULL), clear a custom-override flag (while SetSyncSource sets the custom-override flag and holds a reference for non-NULL filters), and check steps 2, 3, and 4. So something like: SetSyncSource(clock) { if(this->ref_clock) this->ref_clock->Release(); this->ref_clock = clock; if(clock) clock->AddRef(); this->custom_clock = TRUE; } SetDefaultSyncSource() { SetSyncSource(NULL); this->custom_clock = FALSE; ...do steps 2, 3, and 4... this->ref_clock = selected_clock; } Run() { if(!this->custom_clock) SetDefaultSyncSource(); ...run... }

2 1

Wine Security Disclosure
by TheBlunderbuss 14 Mar '08

14 Mar '08

3 2

Re: Google Summer of code
by Maarten Lankhorst 14 Mar '08

14 Mar '08

Hi Luis, 2008/3/13, "Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com>: > Proposing another thing if implementing d3dx9_36.dll is too much I > propose to implement: > 1 D3DXAssembleShader > 2 D3DXAssembleShaderFromFileA > 3 D3DXCompileShader > 4 D3DXCompileShaderFromFileA > 5 D3DXCreateCubeTextureFromFileExA > 6 D3DXCreateCubeTextureFromFileInMemory > 7 D3DXCreateEffectCompilerFromFileA > 8 D3DXCreateEffectFromFileA > 9 D3DXCreateTextureFromFileExA > 10 D3DXCreateTextureFromFileInMemory > 11 D3DXCreateVolumeTextureFromFileExA > 12 D3DXCreateVolumeTextureFromFileInMemory > 13 D3DXGetImageInfoFromFileInMemory > 14 D3DXGetPixelShaderProfile > 15 D3DXGetShaderConstantTable > 16 D3DXGetShaderInputSemantics > 17 D3DXGetShaderVersion > 18 D3DXGetVertexShaderProfile > 19 D3DXLoadSurfaceFromSurface > 20 D3DXSaveSurfaceToFileA > 21 D3DXSaveTextureToFileA > > Which are the functions that Sid Meier's Civilization 4 calls and are > not yet implemented from d3dx9_32 (36) Your best bet for the A function is to forward them to the W versions. These do basically the same thing. Call the W version from the A version and convert any wide strings to ansi strings, this is what happens all throughout wine. Also, do you have any plans for adding conformance tests so you can compare it with windows behavior? Cheers, Maarten.

1 0

new winetricks 20080314: added vcrun2003, improved dotnet, fixed gui multiple selections
by Dan Kegel 14 Mar '08

14 Mar '08

Another day, another winetricks :-) This version finally adds a way to get Visual C++ 2003 runtime libraries (msvcp71, mfc71). It also finally adds in all the twisty little workarounds needed to run trivial .net 1.1 apps. Also, it looks like enough people are using the gui to send in bug reports for it, which is great; as a result, multiple selections should actually work now. As always, you can grab the latest crosstool from http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Remember, don't use winetricks while operating heavy machinery... - Dan

1 0

Re: Google Summer of code
by Stefan Dösinger 14 Mar '08

14 Mar '08

Am Donnerstag, 13. März 2008 18:26:17 schrieb Luis C. Busquets Pérez: > Proposing another thing if implementing d3dx9_36.dll is too much I > propose to implement: > 1 D3DXAssembleShader > 2 D3DXAssembleShaderFromFileA > 3 D3DXCompileShader > 4 D3DXCompileShaderFromFileA I plan to implement those as a university project now(I already got the general approval for it, just need to sort out the details) > 5 D3DXCreateCubeTextureFromFileExA > 6 D3DXCreateCubeTextureFromFileInMemory > 7 D3DXCreateEffectCompilerFromFileA > 8 D3DXCreateEffectFromFileA > 9 D3DXCreateTextureFromFileExA > 10 D3DXCreateTextureFromFileInMemory > 11 D3DXCreateVolumeTextureFromFileExA > 12 D3DXCreateVolumeTextureFromFileInMemory > 13 D3DXGetImageInfoFromFileInMemory > 14 D3DXGetPixelShaderProfile > 15 D3DXGetShaderConstantTable > 16 D3DXGetShaderInputSemantics > 17 D3DXGetShaderVersion > 18 D3DXGetVertexShaderProfile > 19 D3DXLoadSurfaceFromSurface > 20 D3DXSaveSurfaceToFileA > 21 D3DXSaveTextureToFileA That's a long enough list in itself I think. You shouldn't cap it off at specifically the functions CIV4 calls, but rather look for blocks of functionality.

1 0

Re: quartz: Detect and skip id3v2 header in mpeg splitter
by Chris Robinson 14 Mar '08

14 Mar '08

On Thursday 13 March 2008 09:01:53 pm Maarten Lankhorst wrote: > If read from a file source, ID3 v2 tags might be incorrectly parsed by > the head_check. This patch skips the whole tag altogether. I'm not sure this is completely correct. The main splitter function detects the presense of an MP3 header at the start of a sample it's sending to set the sample's sync point attribute. Since the ID3 tag is not a sync point, this causes the first sample to not be set as a sync point, and it would be unlikely that a following sample would, under normal circumstances, contain an MP3 header at the start either. This could cause sensitive codecs to never find a sync point. ACMWrapper wouldn't be affected as it doesn't handle sync points, but other native codecs (which do work in Wine) could. Additionally, winemp3.acm may be affected by the ID3 tag as it doesn't seem to have code to handle it either.

2 3

wine virus story
by Dan Kegel 14 Mar '08

14 Mar '08

http://wearenixed.blogspot.com/2008/03/you-only-know-good-when-youve-seen-b… "I had set her up with a perfect Wine install. She had a bit of software that needed to run under wine and I had shown her how to install within that environment. Apparently, I wasn't specific enough. It never occurred to Paula that the .exe programs she had used on her XP machine were the vehicles for many of her present viruses. To her, it was perfectly fine to use those same .exe's...after all, she was in Linux, right? I got there within the same hour and checked her machine. Yep...Windows viruses will reside and create the same havoc within a Wine environment. Now, I've seen it with my own eyes. This time I reinstalled for her and made sure I found all the infected .exe's on the Windows side and deleted them."

10 18

Re: [PATCH] gdiplus: Fix test crash in GdipSaveImageToStream.
by Lei Zhang 14 Mar '08

14 Mar '08

On Tue, Mar 11, 2008 at 10:26 PM, Nathan Beckmann <nathan.beckmann(a)gmail.com> wrote: > Correctly initialized parameters to GetDIBits. (Based on > GdipLockBitmapBits.) > > Testing seems to indicate that the error doesn't occur on Debian, but > shows up in Slackware. Valgrind also complains. > --- > dlls/gdiplus/image.c | 28 ++++++++++++++++++++++------ > 1 files changed, 22 insertions(+), 6 deletions(-) > > diff --git a/dlls/gdiplus/image.c b/dlls/gdiplus/image.c > index 8307938..ad15148 100644 > --- a/dlls/gdiplus/image.c > +++ b/dlls/gdiplus/image.c > @@ -908,7 +908,9 @@ GpStatus WINGDIPAPI GdipSaveImageToStream(GpImage *image, IStream* stream, > HRESULT hr; > short type; > HBITMAP hbmp; > + HBITMAP old_hbmp; > HDC hdc; > + int bm_is_selected; > BITMAPINFO bmp_info; > LPVOID bmp_bits; > encode_image_func* encode_image; > @@ -917,6 +919,7 @@ GpStatus WINGDIPAPI GdipSaveImageToStream(GpImage *image, IStream* stream, > unsigned int dummy; > int i; > > + old_hbmp = 0; > output = NULL; > output_size = 0; > > @@ -943,18 +946,32 @@ GpStatus WINGDIPAPI GdipSaveImageToStream(GpImage *image, IStream* stream, > hr = IPicture_get_Handle(image->picture, (OLE_HANDLE*)&hbmp); > if (FAILED(hr) || !hbmp) > return GenericError; > + hr = IPicture_get_CurDC(image->picture, &hdc); > + if (FAILED(hr)) > + return GenericError; > + bm_is_selected = (hdc != 0); > + if (!bm_is_selected) { > + hdc = CreateCompatibleDC(0); > + old_hbmp = SelectObject(hdc, hbmp); > + } > > /* get bits from HBITMAP */ > - hdc = GetDC(0); > bmp_info.bmiHeader.biSize = sizeof(bmp_info.bmiHeader); > + bmp_info.bmiHeader.biBitCount = 0; > GetDIBits(hdc, hbmp, 0, 0, NULL, &bmp_info, DIB_RGB_COLORS); > > bmp_bits = GdipAlloc(bmp_info.bmiHeader.biSizeImage); > - if (!bmp_bits) { > - ReleaseDC(0, hdc); > - return OutOfMemory; > + > + if (bmp_bits) > + GetDIBits(hdc, hbmp, 0, abs(bmp_info.bmiHeader.biHeight), bmp_bits, &bmp_info, DIB_RGB_COLORS); > + > + if (!bm_is_selected) { > + SelectObject(hdc, old_hbmp); > + DeleteDC(hdc); > } > - GetDIBits(hdc, hbmp, 0, bmp_info.bmiHeader.biHeight, bmp_bits, &bmp_info, DIB_RGB_COLORS); > + > + if (!bmp_bits) > + return OutOfMemory; > > stat = encode_image(bmp_bits, &bmp_info, &output, &output_size); > if (stat == Ok) > @@ -962,7 +979,6 @@ GpStatus WINGDIPAPI GdipSaveImageToStream(GpImage *image, IStream* stream, > > GdipFree(output); > GdipFree(bmp_bits); > - ReleaseDC(0, hdc); > > return stat; > } > -- > 1.5.4.2 > > > > FYI, here's the valgrind log: http://www.kegel.com/wine/valgrind/logs-2008-03-11/vg-gdiplus_image-diff.txt We're passing an uninitialized bmp_info into GetDIBits(), but somehow it magically works on Debian.

1 0

Clipping regions on windows and Expose Xevents issue
by Ann & Jason Edmeades 14 Mar '08

14 Mar '08

Hello, I've been investigating defect 11562, and would appreciate some thoughts on how to move forward... Basically the application creates a new visible window (eg at 0,0 - 200,50) and then draws in it by: 1. BeginPaint - This sets up the cliprgn to the whole window 2. Works out some sizes... 3. MoveWindow - This moves the window to an appropriate place on the screen 4. FillRect (DrawText, EndPaint) to empty the window... From this call (and all follow on ones) nothing is written to the window because although the visible region is correctly calculated, the clip region was not updated by the MoveWindow call. This highlights 2 problems.. 1. MoveWindow doesn't update the DCEx clip_region region, and hence when the visible region changes, it is merged with the clip region and since there is no overlap the visible region is empty so all subsequent processing ends. Q: Whats the best way to handle that - I was tempted to reset the clip_region to the visible_region (as MSDN sort of implies - you cant really query them so tests don't help much here) in a movewindow call 2. I then hacked MoveWindow to do nothing, so I could progress... What I see then is the popup is drawn, emptied and framed etc, and THEN overwritten with grey. Debugging this shows the application does not respond to WM_PAINT calls for the popup window - ie its drawn once and once only. You can see this on windows if you alt+tab to a covering window, and then back again. HOWEVER, on windows the popup does display correctly the once Investigating the cause, all is ok until the trace:event:process_events Expose for hwnd/window 0xd50026/220002c This drives the trace:win:RedrawWindow 0xd50026 rect (0,0)-(250,50) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and *bang*, all the drawing which has been done is lost Q: This is getting way outside my understanding of X events, but shouldn't the Expose event for the child (popup) window be processed before returning from CreateWindow with style WS_VISIBLE? All suggestions welcome - I don't mind writing tests etc but would like to try to come up with a solution for the problem as well! Jason

2 3

Re: regedit: stdin is not seekable so do not try to seek the input file if it is not seekable
by Alexandre Julliard 14 Mar '08

14 Mar '08

Aric Stewart <aric(a)codeweavers.com> writes: > --- > programs/regedit/regedit.c | 2 +- > programs/regedit/regproc.c | 19 +++++++++++-------- > programs/regedit/regproc.h | 2 +- > 3 files changed, 13 insertions(+), 10 deletions(-) We shouldn't need to seek at all, instead it should be easy to test the first two bytes of the first line before processing it. -- Alexandre Julliard julliard(a)winehq.org

2 2