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

Re: [PATCH 1/5] qedit: Mostly stubbed out implementation of SampleGrabber filter

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Ok, I did so - although it will take a while to rebuild all 5 patches. > > What about calling AddRef() in QueryInterface() vs. calling > InterlockedIncrement directly on the counter? AddRef is definitely better. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2010

re: msi: copy InstallerImpl_LastErrorRecord to use it for DatabaseImpl (resend)

by Dan Kegel

André Hentschel wrote > makes the installer in http://tinyurl.com/y9gy6c4 run farther Thanks for including the link. (For the curious, see http://www.boschrexroth.com/business_units/brc/de/information_de/software_d… http://www.boschrexroth.com/country_units/america/united_states/en/products… It looks like a pretty cool CAD simulation package.)

Feb. 3, 2010

Re: [PATCH 1/5] qedit: Mostly stubbed out implementation of SampleGrabber filter

by Paul Chitescu

On Wednesday 03 February 2010 11:57:37 am Alexandre Julliard wrote: > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > +/* Macro to get the SampleGrabber This pointer from interface pointer */ > > +#define GET_THIS(ptr,iface) ((SG_Impl *)((char *)(ptr) - FIELD_OFFSET(SG_Impl,iface ## _Vtbl))) > > Please define an inline function for that sort of thing. Look at > shelllink.c for examples. > > -- > Alexandre Julliard > julliard(a)winehq.org Ok, I did so - although it will take a while to rebuild all 5 patches. What about calling AddRef() in QueryInterface() vs. calling InterlockedIncrement directly on the counter? Paul

Feb. 3, 2010

CJK default fonts for packagers to set

by Scott Ritchie

My notes from Wineconf remind me that I need to create some manual links in the registry to whatever default CJK fonts are on the system. Can someone tell me what these are supposed to look like? Thanks, Scott Ritchie

Feb. 3, 2010

Re: [PATCH 4/5] wined3d: Remove the unused device type parameter from the fragment pipe's get_caps() function.

by Stefan Dösinger

Am 03.02.2010 um 18:17 schrieb Henri Verbeet: > On the subject of actually supporting software devices, we should probably > implement those by creating a software or reference adapter with appropriate > gl_info and pipe implementations and creating a device based on that. Wouldn't that conflict with how adapters work in the d3d8/9 API? There an adapter identifies the display hardware, not necessarily the rendering device. Or, to phrase it in API terms: > static HRESULT WINAPI IWineD3DImpl_CreateDevice(IWineD3D *iface, UINT adapter_idx, > WINED3DDEVTYPE device_type, HWND focus_window, DWORD flags, IUnknown *parent, > IWineD3DDeviceParent *device_parent, IWineD3DDevice **device) You'd want to remove device_type from here as well if we merge it into the adapter(and then deal with splitting up wined3d adapters into d3d8/9 adapters and device types in the client libs)

Feb. 3, 2010

Re: [PATCH] mdi: fix drawing the MDI client area when creating children.

by Reece Dunn

On 3 February 2010 15:17, Alexandre Julliard <julliard(a)winehq.org> wrote: > Reece Dunn <msclrhd(a)googlemail.com> writes: > >> diff --git a/dlls/user32/mdi.c b/dlls/user32/mdi.c >> index 631d477..0850282 100644 >> --- a/dlls/user32/mdi.c >> +++ b/dlls/user32/mdi.c >> @@ -1132,6 +1132,7 @@ LRESULT MDIClientWndProc_common( HWND hwnd, UINT message, WPARAM wParam, LPARAM >> hwnd, 0, csA->hOwner, >> (LPVOID)csA->lParam); >> } >> + InvalidateRect(hwnd, NULL, TRUE); >> return (LRESULT)child; > > The window should have been exposed and repainted when the children got > resized. If this doesn't happen it's a bug, but invalidating by hand is > only hiding the problem. The MDI Client window is not getting painted when the maximised child window is restored. That is the core problem identified by that bug. There are some message trail tests in dlls/user32/tests/msg.c, but not for the above scenario. I will extend the tests to investigate what is going on in this specific case. - Reece

Feb. 3, 2010

Re: [PATCH] mdi: fix drawing the MDI client area when creating children.

by Alexandre Julliard

Reece Dunn <msclrhd(a)googlemail.com> writes: > diff --git a/dlls/user32/mdi.c b/dlls/user32/mdi.c > index 631d477..0850282 100644 > --- a/dlls/user32/mdi.c > +++ b/dlls/user32/mdi.c > @@ -1132,6 +1132,7 @@ LRESULT MDIClientWndProc_common( HWND hwnd, UINT message, WPARAM wParam, LPARAM > hwnd, 0, csA->hOwner, > (LPVOID)csA->lParam); > } > + InvalidateRect(hwnd, NULL, TRUE); > return (LRESULT)child; The window should have been exposed and repainted when the children got resized. If this doesn't happen it's a bug, but invalidating by hand is only hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2010

Re: libpng dependency issue

by Luca Bennati

2010/2/3 Roderick Colenbrander <thunderbird2k(a)gmail.com> > We are loading png dynamically and we want to keep doing that. Figure > out where the longjmp call comes from (perhaps it is some macro or so > in the png code). We might have to dynamically load the function.. > > Regarding that gray conversion function. The only thing that changed > is the name of the function the prototype and its behavior looks > similar. I'm not sure how we want to fix it. For instance it can be > fixed at compile time by checking the png version (I believe png.h > defines it) or it can be done at runtime by checking if the old > function is around and if it isn't try to load the new function. > > Roderick > Ok, i will investigate more on libpng loading As for the gray conversion functions, the ones used by windowscodecs were deprecated since long time (it seems from their readme), so changing their name shouldn't break builds with libpng 1.2.x

Feb. 3, 2010

Re: libpng dependency issue

by Roderick Colenbrander

On Wed, Feb 3, 2010 at 11:57 AM, Luca Bennati <lucak3(a)gmail.com> wrote: > > > 2010/2/3 Luca Bennati <lucak3(a)gmail.com> > >> >> LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc >> --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ >> -foversion.res version.rc >> ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. >> -shared ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o >> converter.o gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o >> palette.o pngformat.o propertybag.o regsvr.o stream.o ungif.o >> version.res -o windowscodecs.dll.so -luuid -lole32 -ladvapi32 >> -lkernel32 ../../libs/port/libwine_port.a >> pngformat.o: In function `PngFrameEncode_Commit': >> /home/luca/wine-git/dlls/windowscodecs/pngformat.c:987: undefined >> reference to `png_set_longjmp_fn' >> pngformat.o: In function `PngEncoder_Initialize': >> /home/luca/wine-git/dlls/windowscodecs/pngformat.c:1119: undefined >> reference to `png_set_longjmp_fn' >> pngformat.o: In function `PngFrameEncode_WritePixels': >> /home/luca/wine-git/dlls/windowscodecs/pngformat.c:861: undefined >> reference to `png_set_longjmp_fn' >> pngformat.o: In function `PngDecoder_Initialize': >> /home/luca/wine-git/dlls/windowscodecs/pngformat.c:252: undefined >> reference to `png_set_longjmp_fn' >> collect2: ld returned 1 exit status >> >> I will now investigate this new one > > I didn't find a clear answer as code seemed ok, so i tried to issue the > command: > ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared > ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o converter.o > gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o palette.o > pngformat.o propertybag.o regsvr.o stream.o ungif.o version.res -o > windowscodecs.dll.so -luuid -lole32 -ladvapi32 -lkernel32 > ../../libs/port/libwine_port.a > adding a simple -lpng: > ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared > ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o converter.o > gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o palette.o > pngformat.o propertybag.o regsvr.o stream.o ungif.o version.res -o > windowscodecs.dll.so -luuid -lole32 -ladvapi32 -lkernel32 -lpng > ../../libs/port/libwine_port.a > and it magically works ok > > so the previous patch just has to add png to the imports in Makefile.in to > make it work > Should i send the now correct patch? > We are loading png dynamically and we want to keep doing that. Figure out where the longjmp call comes from (perhaps it is some macro or so in the png code). We might have to dynamically load the function.. Regarding that gray conversion function. The only thing that changed is the name of the function the prototype and its behavior looks similar. I'm not sure how we want to fix it. For instance it can be fixed at compile time by checking the png version (I believe png.h defines it) or it can be done at runtime by checking if the old function is around and if it isn't try to load the new function. Roderick

Feb. 3, 2010

Re: libpng dependency issue

by Luca Bennati

2010/2/3 Luca Bennati <lucak3(a)gmail.com> > LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc > --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ > -foversion.res version.rc > ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. > -shared ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o > converter.o gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o > palette.o pngformat.o propertybag.o regsvr.o stream.o ungif.o > version.res -o windowscodecs.dll.so -luuid -lole32 -ladvapi32 > -lkernel32 ../../libs/port/libwine_port.a > pngformat.o: In function `PngFrameEncode_Commit': > /home/luca/wine-git/dlls/windowscodecs/pngformat.c:987: undefined reference > to `png_set_longjmp_fn' > pngformat.o: In function `PngEncoder_Initialize': > /home/luca/wine-git/dlls/windowscodecs/pngformat.c:1119: undefined > reference to `png_set_longjmp_fn' > pngformat.o: In function `PngFrameEncode_WritePixels': > /home/luca/wine-git/dlls/windowscodecs/pngformat.c:861: undefined reference > to `png_set_longjmp_fn' > pngformat.o: In function `PngDecoder_Initialize': > /home/luca/wine-git/dlls/windowscodecs/pngformat.c:252: undefined reference > to `png_set_longjmp_fn' > collect2: ld returned 1 exit status > > I will now investigate this new one > I didn't find a clear answer as code seemed ok, so i tried to issue the command: ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o converter.o gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o palette.o pngformat.o propertybag.o regsvr.o stream.o ungif.o version.res -o windowscodecs.dll.so -luuid -lole32 -ladvapi32 -lkernel32 ../../libs/port/libwine_port.a adding a simple -lpng: ../../tools/winegcc/winegcc -B../../tools/winebuild --sysroot=../.. -shared ./windowscodecs.spec bmpdecode.o bmpencode.o clsfactory.o converter.o gifformat.o icoformat.o imgfactory.o info.o jpegformat.o main.o palette.o pngformat.o propertybag.o regsvr.o stream.o ungif.o version.res -o windowscodecs.dll.so -luuid -lole32 -ladvapi32 -lkernel32 -lpng ../../libs/port/libwine_port.a and it magically works ok so the previous patch just has to add png to the imports in Makefile.in to make it work Should i send the now correct patch?

Feb. 3, 2010