May 2012 - Wine-Devel - list.winehq.org

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

Re: Web based translation tool
by Michal Čihař June 18, 2013

June 18, 2013

Hi Dne Mon, 12 Mar 2012 12:02:49 +0200 Yaron Shahrabani <sh.yaron(a)gmail.com> napsal(a): > The Wine project is thinking about using Weblate in order to translate > Wine, you can look at the following discussion and see for yourself. That sounds great! > Looking good although a litle immature, not sure about authentication as > wel... For authentication you can basically use anything what can be used in Django. Any specific concerns on this topic? > I'll talk to Michal Cihar and ask him for a roadmap for this project. Well I don't have any real roadmap right now. I urgently needed replacement for Pootle because we got hit by too many bugs there and did not manage to understand the code there to be able to fix them myself. So far I think it is in pretty good shape for day to day work (with today's 0.5 release fixing few annoying bugs). Of course there are some features missing, you can check what I plan for 1.0 release here: https://github.com/nijel/weblate/issues?state=open&milestone=1 I currently hope to have 1.0 in a month or so, but I really don't want to commit to any specific date. PS: I'm not subscribed to mailing list so please CC me on reply. -- Michal Čihař | http://cihar.com | http://blog.cihar.com

7 16

Wine automated testing update
by Jeremy White Aug. 6, 2012

Aug. 6, 2012

Hi Folks, At the last Wine conference, I volunteered to find a home for the WineTestBot that Ge's brother has been hosting, and to take over the Buildbot that Dan and Austin have been so diligently maintaining. This is an update on that project, mostly to help keep my procrastinating self moving it along. First, we have a lovely set of hardware; 4 servers, in a dedicated rack, with a dedicated static ip to the outside world. One server is the gateway, 2 are dedicated Linux test systems (with nice fast processor + gpus), and one is a beefy system capable of running many VMs. The plan was to move the existing VMWare based WineTestBot to this hardware and simply get the existing system up and running on the new hardware. Here we hit our first snag; the VMWare folks are not willing to provide a permanent license for VMWare to us. So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate. I've done a little of this work, and Maarten is hopefully going to help me try converting the existing VMs to see if we can save any hassle by doing a conversion. In parallel, I learned a great deal about buildbot and the buildbot system that Dan has built. There are two especially valuable and useful functions provided by this buildbot: the first is essentially a patch watcher; a process that catches simple mistakes (e.g. build errors on different architectures, and so on). The second is more powerful and is encapsulated by the 'dotests.sh' shell script. The dotests.sh script does a good job of basically running make test and noticing any test failures outside of 'the usual ones'. There is an infrastructure for Buildbot is a good tool, and I invested a lot of energy into it (as have Dan and Austin). However, Alexandre has persuaded me that we should first explore integrating the dotest.sh functionality into the existing WineTestBot, as that would allow us to have a very simple clean web page, and would also allow us to integrate most cleanly with Alexandre's back end tools. Of course, WineTestBot is Perl code, and my Perl fu is low. So I have recently asked Francois to help with that effort as well. So the basic plan is as follows: 1. Test qemu/kvm with a few Windows versions to see if it'll work. 2. If so, modify WineTestBot to use qemu instead of vmware. (This is 'easy' because the WineTestBot code nicely isolates the VM functions, but 'hard', because VMWare provides some APIs that may have to be replicated). 3. Migrate WineTestBot to the new hardware stack 4. Write new code to run 'dotests.sh' as part of WineTestBot Cheers, Jeremy

9 11

Rethinking WineConf
by Jeremy White July 26, 2012

July 26, 2012

Hi All, This past Wine conference, while great fun as always, was not as well attended as Wine conferences in the past. So I would like to stir up trouble by suggesting we rethink WineConf. For those that have not attended, the Wine conference has been a mostly annual affair since 2002. It is open to all, but is advertised as being aimed at Wine developers. About 35 people attend each year. It's been in Minnesota about every 3rd year, and is otherwise 'normally' somewhere in Europe. I see the primary goal as creating human bonds between otherwise anonymous people (aka going to the pub). It's a bonus if it also spurs resolution to tricky issues, or motivates people to get more done. So I'd like to ask folks to brain storm with me. How could Wineconf be different? If you've never been, what would encourage you to come? If you've been to a technical conference recently that you thought was well done, what did they do well? Anything we could emulate? Any other ideas, or suggestions? Cheers, Jeremy

17 25

Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
by Jacek Caban July 18, 2012

July 18, 2012

Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote: > I noticed we return in this case, without initializing this variable. > Visual inspection indicates we do not seem to access the variable in > this error case, but a) better safe than sorry, and b) GCC 4.8 currently > warns about it. > > Not sure URLPOLICY_DISALLOW is the best return value, open for better > alternatives. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek

2 4

winebuild port to ARM?
by Roger Cruz July 7, 2012

July 7, 2012

Has anyone worked or is currently working on porting the x86 specific code in Winebuild to ARM? Specifically the relay.c file? Thanks Roger R. Cruz

2 9

1.4 has dropped off the list for AppDB submissions
by Rosanne DiMesio June 6, 2012

June 6, 2012

As of the release of 1.5.5, 1.4 has dropped off the list of Wine versions for which AppDB test reports can be submitted. Can someone please add it to the list of stable releases that are always available in the dropdown list? Until it's put back, users will not be able to submit new test reports for 1.4. We could avoid having this problem every time there's a new stable release if users were allowed to submit test reports for any version. Bugzilla lists every version, I don't see why the AppDB doesn't. -- Rosanne DiMesio <dimesio(a)earthlink.net>

2 2

Re: [1/3] user32/tests: Comment-out PostQuitMessage (causes tests skip)
by Dmitry Timoshkov May 31, 2012

May 31, 2012

sir-lexa <sir-lexa(a)yandex.ru> wrote: > case WM_DESTROY: > - PostQuitMessage(0); > + /* PostQuitMessage(0); It lets some tests to be skipped */ > return TRUE; This is not acceptable, there is much more behind the scene. You need to figure out the real reason of skipping the tests. -- Dmitry.

2 2

Re: [PATCH 3/5] ddraw/tests: Add test_coop_level_mode_set() for older ddraw versions.
by Marvin May 31, 2012

May 31, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18687 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:2282: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2284: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2310: Test failed: Expected surface width 640, got 800. ddraw2.c:2312: Test failed: Expected surface height 480, got 600. ddraw2.c:2327: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2338: Test failed: Expected surface width 640, got 800. ddraw2.c:2340: Test failed: Expected surface height 480, got 600. ddraw2.c:2406: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2408: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2434: Test failed: Expected surface width 640, got 800. ddraw2.c:2436: Test failed: Expected surface height 480, got 600. ddraw2.c:2451: Test failed: Expected message 0x7e, but didn't receive it. ddraw2.c:2462: Test failed: Expected surface width 640, got 800. ddraw2.c:2464: Test failed: Expected surface height 480, got 600. === WNT4WSSP6 (32 bit ddraw1) === ddraw1.c:2145: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2147: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2173: Test failed: Expected surface width 640, got 800. ddraw1.c:2175: Test failed: Expected surface height 480, got 600. ddraw1.c:2190: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2201: Test failed: Expected surface width 640, got 800. ddraw1.c:2203: Test failed: Expected surface height 480, got 600. ddraw1.c:2269: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2271: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2297: Test failed: Expected surface width 640, got 800. ddraw1.c:2299: Test failed: Expected surface height 480, got 600. ddraw1.c:2314: Test failed: Expected message 0x7e, but didn't receive it. ddraw1.c:2325: Test failed: Expected surface width 640, got 800. ddraw1.c:2327: Test failed: Expected surface height 480, got 600.

1 0

Re: [PATCH 3/3] ntdll/tests: Add tests for RtlGetProductInfo [resend]
by Alexandre Julliard May 31, 2012

May 31, 2012

Detlef Riekenberg <wine.dev(a)web.de> writes: > Clone the kernel32 tests to verify, that the NULL pointer > check is present in ntdll.dll That's not useful, it's clearly the same function, it doesn't need to be tested twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] win16/int21: make found filename uppercase.
by Alexandre Julliard May 31, 2012

May 31, 2012

Oleksij Rempel <bug-track(a)fisher-privat.net> writes: > @@ -3961,6 +3962,8 @@ static int INT21_FindNext( CONTEXT *context ) > INT21_FindPath = dta->fullPath = NULL; > } > dta->count = n; > + p = dta->filename; > + for ( ; *p; p++) *p = toupper(*p); Using toupper is probably not a good idea on OEM codepage strings. Which app depends on this? -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [4/4] windowscodecs: Add stub IWICMetadataBlockReader to PNG decoder.
by Marvin May 30, 2012

May 30, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18675 Your paranoid android. === WXPPROSP3 (32 bit metadata) === metadata: unhandled exception c0000005 at 4CCA826D === W2K8SE (32 bit metadata) === metadata: unhandled exception c0000005 at 72C28045

1 0

Re: [3/4] windowscodecs: Add test for IWICMetadataBlockReader interface.
by Marvin May 30, 2012

May 30, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18674 Your paranoid android. === WXPPROSP3 (32 bit metadata) === metadata: unhandled exception c0000005 at 4CCA826D === W2K8SE (32 bit metadata) === metadata: unhandled exception c0000005 at 72C28045

1 0

crypt32/tests(1/6): Don't shadow a variable with a variable of a different type
by Juan Lang May 30, 2012

May 30, 2012

--Juan

1 0

Re: [2/2]kernel32/test: added test for OutputDebugStringA called with NULL pointer
by Marvin May 30, 2012

May 30, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18671 Your paranoid android. === WXPPROSP3 (32 bit debugger) === Timeout === W2K3R2SESP2 (32 bit debugger) === Timeout

1 0

Re: [1/5] windowscodecs: Implement IWICStream::InitializeFromIStream. (try 2)
by Dmitry Timoshkov May 30, 2012

May 30, 2012

Józef Kucia <joseph.kucia(a)gmail.com> wrote: > + offset.QuadPart = 0; > + size.u.LowPart = 0xffffffff; > + size.u.HighPart = 0xffffffff; > + return IWICStream_InitializeFromIStreamRegion(iface, pIStream, offset, size); What prevents you from discovering correct stream size? -- Dmitry.

3 5

Re: [1/2] mscoree: Install Wine Mono on prefix update.
by Alexandre Julliard May 30, 2012

May 30, 2012

Vincent Povirk <madewokherd(a)gmail.com> writes: > From d271ba591f6afb4e0b2356da24841f54d5f11b9b Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue, 29 May 2012 10:35:36 -0500 > Subject: [PATCH 1/2] mscoree: Install Wine Mono on prefix update. > > --- > dlls/mscoree/mscoree_main.c | 120 +++++++++++++++++++++++++++++++++++++++++++ > tools/wine.inf.in | 1 + > 2 files changed, 121 insertions(+) This is breaking 64-bit prefixes, because things are not done in the correct order. It also looks like the package is not creating the 64-bit registry keys. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/4] jscript: Added VT_I2 tests
by Marvin May 30, 2012

May 30, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18657 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/3] jscript: Get rid of ret_nan hack
by Ruslan Kabatsayev May 30, 2012

May 30, 2012

Hello, This patch (committed as d0a719a79dae001df341db907fcae54118691d35) leads to compilation error: make[1]: Entering directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/fastdocs/programmer/wine-git/dlls/msadp32.acm' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -I/opt/Xorg-7.5/include -L/opt/Xorg-7.5/lib -o string.o string.c lex.c: In function ‘cc_token’: lex.c:936:71: error: ‘NAN’ undeclared (first use in this function) lex.c:936:71: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [lex.o] Error 1 I've tried doing git clean -xdf, but this still doesn't compile. Regards, Ruslan On Tue, May 29, 2012 at 2:53 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/jscript/date.c | 28 ++++++++++++++-------------- > dlls/jscript/error.c | 3 ++- > dlls/jscript/global.c | 2 +- > dlls/jscript/jscript.h | 7 ------- > dlls/jscript/jsutils.c | 6 +++--- > dlls/jscript/lex.c | 2 +- > 6 files changed, 21 insertions(+), 27 deletions(-) > > > > >

2 1

ru.po: improved an Russian translation
by Oleg Yarigin May 30, 2012

May 30, 2012

There are some improvements of a style (now it is more official) and non-translated empty lines. To avoid an character encoding interruption, I send the diff file as a packed text file attachment (ru_diff.txt.bz2, 22.3 KB).

3 2

stub for SetThreadStackGuarantee
by Daniel Jelinski May 29, 2012

May 29, 2012

Hello, SQL Server Management Studio 2005 needs SetThreadStackGuarantee to either be absent or return TRUE - otherwise it refuses to run at all. Is there a reason for this stub to return FALSE? Regards, Daniel

1 0

Re: kernel32/volume: Don't modify the last error in GetVolumeInformation
by Alexandre Julliard May 29, 2012

May 29, 2012

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -729,6 +731,8 @@ BOOL WINAPI GetVolumeInformationW( LPCWSTR root, LPWSTR label, DWORD label_len, > } > else > { > + /* At this point, last error is ERROR_NOT_SUPPORTED. Restoring the previous one */ > + SetLastError(lastError); You should never need to do that sort of thing, there are no guarantees about last error on success. -- Alexandre Julliard julliard(a)winehq.org

2 1

Implementing joystick ids in DirectInput
by Lucas Zawacki May 29, 2012

May 29, 2012

Hey guys, asking for a little code review here... I was looking at the solution for this bug http://bugs.winehq.org/show_bug.cgi?id=30705 and it comes down to implementing the DIPROP_JOYSTICKSID property for joystick devices. After some research on what this is I know it's always a number between (0,n), where n is the number of joysticks connected, and is analogous to the winmm driver joystick id. The solution I came up is in the attached patch, it's a little weird but I found it hard to give a unique ID to each joystick on Linux when they can come from different drivers. This solution uses the order which dinput puts the joysticks on it's device list and will work regardless. If someone has a better way to do it I'd like to know. Cheers,

2 2

Re: [PATCH 1/3] ntdll: Implement RtlGetProductInfo and use it for GetProductInfo
by Alexandre Julliard May 29, 2012

May 29, 2012

Detlef Riekenberg <wine.dev(a)web.de> writes: > The wrapper in kernel32 is not needed. > RtlGetProductInfo and GetProductInfo have the same signature and > tests show the same results. No they don't have the same signature, look closer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] d3dx9: Implement D3DXSaveSurfaceToFileInMemory.
by Vincent Povirk May 28, 2012

May 28, 2012

> - hr = IWICImagingFactory_CreateStream(factory, &stream); > + hr = IWICImagingFactory_CreateStream(factory, &wic_stream); > IWICImagingFactory_Release(factory); > if (FAILED(hr)) goto cleanup_err; > > - hr = IWICStream_InitializeFromFilename(stream, dst_filename, GENERIC_WRITE); > + hr = CreateStreamOnHGlobal(NULL, TRUE, &stream); > if (FAILED(hr)) goto cleanup_err; > > + hr = IWICStream_InitializeFromIStream(wic_stream, stream); Why bother creating an IWICStream here? Just use your HGLOBAL stream to initialize the encoder.

1 0

Re: [1/5] windowscodecs: Implement IWICStream::InitializeFromIStream.
by Vincent Povirk May 28, 2012

May 28, 2012

> +static HRESULT WINAPI StreamOnStream_Seek(IStream *iface, > + LARGE_INTEGER dlibMove, DWORD dwOrigin, ULARGE_INTEGER *plibNewPosition) > +{ > + StreamOnStream *This = StreamOnStream_from_IStream(iface); > + HRESULT hr=S_OK; > + TRACE("(%p)\n", This); > + > + EnterCriticalSection(&This->lock); > + hr = IStream_Seek(This->stream, dlibMove, dwOrigin, plibNewPosition); > + LeaveCriticalSection(&This->lock); > + > + return hr; > +} The IWICStream needs to have an independent position from the underlying stream. Also, why not just forward to InitializeFromIStreamRegion?

1 0

Re: [1/3] user32/tests: Comment-out PostQuitMessage (causes tests skip)
by Marvin May 28, 2012

May 28, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18630 Your paranoid android. === W7PROX64 (32 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === TEST64_W7SP1 (32 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === W7PROX64 (64 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === TEST64_W7SP1 (64 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible.

1 0

Re: d3dx9_36/tests: Add tests for D3DXCreatePolygon
by Marvin May 27, 2012

May 27, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18615 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

func or pFunc in tests ?
by GOUJON Alexandre May 27, 2012

May 27, 2012

Hi, I'm planning to add a test in the wine test suite and I noticed a difference. Some tests call directly the function by its name (i.e. GetWindowsDirectory, CreateFileA, CloseHandle...) while others declare a pointer to the function (prefixing its name by 'p' and followed by a capital letter) retrieved via GetProcAddress. I know that tests have been written by lots of different people at different times and the general rule is "follow the style of the test file to be consistent" but here, both styles exist in the same file (kernel32/tests/volume.c). Is there any rule concerning using func over pFunc ? Is it related to the module it comes from ? Thanks

2 2

[website] Logo license? Usable in a propritary App?
by André Hentschel May 25, 2012

May 25, 2012

Hey, they use the "old" WineHQ Logo in this 99 Cent App: https://play.google.com/store/apps/details?id=com.appdevandroid.framework.w… Is that ok? If not, could the creater please contact them. The Icon could be misleading. -- Best Regards, André Hentschel

1 0

Fwd: [Freerdp-devel] WinPR: Windows Portable Runtime
by Pau Garcia i Quiles May 25, 2012

May 25, 2012

FYI ---------- Forwarded message ---------- From: Marc-André Moreau <marcandre.moreau(a)gmail.com> Date: Fri, May 25, 2012 at 3:04 AM Subject: [Freerdp-devel] WinPR: Windows Portable Runtime To: freerdp-devel <freerdp-devel(a)lists.sourceforge.net> Dear FreeRDP community, I have an announcement to make regarding a new spin-off project which I've been preparing for a while. Please read as this will set the tone of future development :) You can find most current WinPR development work on the winpr branch: https://github.com/FreeRDP/FreeRDP/tree/winpr WinPR is a spin-off project of FreeRDP which aims at providing a portable implementation of important portions of the Windows API. Just like FreeRDP, WinPR is released under the Apache license. Unlike Wine, WinPR does not provide binary compatibility, and does not require applications to be built for Windows. Instead, WinPR provides API compatibility for applications targeting non-Windows environments. When on Windows, the original native API is being used instead of the equivalent WinPR implementation, without having to modify the code using it. WinPR is the result of long and thoughtful process that came up after years of FreeRDP development. RDP, as you know, is a protocol designed by Microsoft and is primarily “Windows to Windows”. In many instances, protocol messages rely heavily on Windows-specific APIs which have no direct equivalent on other operating systems. For instance, core graphical messages are based on GDI, network level authentication makes use of the Microsoft SSPI authentication modules (CredSSP, NTLM), and terminal server gateway makes use of both SSPI and MSRPC. That’s not even mentioning all the effort that went into mapping keyboard systems and time zones. Developing FreeRDP is in many ways all about implementing Windows APIs outside of Windows. Immense efforts have gone into the implementation of such features, to the point where they begin having value outside of FreeRDP itself. At this point, one of the most valuable part of WinPR is the set of SSPI modules. Various NTLM implementations exist, all with different interfaces, but the WinPR implementation is a direct replacement of the original. This is an advantage because the API is already well documented, with expected inputs and outputs. FreeRDP can also optionally build against the native SSPI modules when on Windows. Making this code easily reusable to any one means that application developers now have an easy way of porting their applications to make use of the Windows authentication architecture. WinPR is also a response to a recurrent problem in FreeRDP development: the proliferation of custom helpers and utility functions. While those are useful, they often need to be modified and updated to meet new requirements, causing frequent API changes. Breaking the API regularly obviously makes a lot of developers unhappy. By choosing to implement an existing and mature API, we can effectively get rid of the core of the problem. If a certain API has been used for years and it fits the needs of most people, you are less likely to need to break it yourself. Besides the argument of API stability, there is another huge advantage in using the Windows API over custom utility functions: the ability to easily share code with other projects that aim at implementing the same API. For instance, the SSPI modules currently developed in WinPR are of high interest to the ReactOS project. If the code was filled with custom utility functions, it would be much harder to use outside of FreeRDP, hindering such collaboration opportunities. For instance, instead of wrapping calls to MultiByteToWideChar() in a custom unicode conversion utility, we can use MultiByteToWideChar() as the utility function and provide an implementation on non-Windows systems. As a general rule in WinPR, if a utility function can be replaced by a part of the Windows API, then the Windows API will have precedence. Otherwise, a utility method can be used, keeping in mind the downsides of it. WinPR is also designed to be as modular as possible, using the MinWin architecture as a reference. MinWin is a refactoring effort of the Windows API which is more cleaner and comprehensive than the original. The API has been separated into logical sets, each with a DLL. Not a lot of documentation is available online about MinWin, but one can find its structure in the MSDN article “Windows API Sets”: http://msdn.microsoft.com/en-us/library/hh802935/ Just like MinWin, WinPR aims at being minimalistic and modular, such that one can have fine grained control over what is to be used. For projects making use of only a small amounts of WinPR, it should be possible to depend only on the minimum required. At last, why not simply use Wine or code from other projects like ReactOS or Samba? In all of these cases, there are both licensing and architectural problems which make it fairly hard for us to use in FreeRDP. For instance, Wine provides binary compatibility, and it’s not easy for a native Linux application to make use of parts of it without being built for Windows. Samba has an interesting MSRPC implementation, but it’s a fairly big dependency, without counting the fact that we can forget about portability on mobile platforms like Android and iOS. Unfortunately, none of these provide a highly portable implementation of the Windows API in the way we would like and under a license which is suitable to us, justifying the existence of WinPR. Through WinPR, investment done in FreeRDP development will take a new life and become even more valuable. We will open new doors to even higher levels of interoperability. We will foster collaboration with other projects following similar goals and reach new heights at an increasingly faster pace. Stay tuned, you will be amazed! ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freerdp-devel mailing list Freerdp-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

1 0

Re: [5/5] propsys: Implement IPropertyStore::GetCount.
by Marvin May 24, 2012

May 24, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18573 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [4/5] propsys: Implement IPropertyStore::SetValue and GetValue.
by Marvin May 24, 2012

May 24, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18572 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: gdiplus: Reimplement GdipIsEmptyRegion.
by Dmitry Timoshkov May 24, 2012

May 24, 2012

Hello, I'm surprised that such a trivial patch wasn't accepted yet. But just in case it matters, current implementation doesn't work for paths and combined/complex regions. -- Dmitry.

2 2

Re: windowscodecs: Add a stubbed out IWICMetadataBlockReader interface.
by Vincent Povirk May 24, 2012

May 24, 2012

Please add a test showing that some builtin metadata handler implements this interface. On Thu, May 24, 2012 at 4:39 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/windowscodecs/metadatahandler.c | 69 ++++++++++++++++++++++++++++++++++ > 1 file changed, 69 insertions(+) > > diff --git a/dlls/windowscodecs/metadatahandler.c b/dlls/windowscodecs/metadatahandler.c > index afcff21..ffe6763 100644 > --- a/dlls/windowscodecs/metadatahandler.c > +++ b/dlls/windowscodecs/metadatahandler.c > @@ -39,6 +39,7 @@ typedef struct MetadataHandler { > IWICMetadataWriter IWICMetadataWriter_iface; > LONG ref; > IWICPersistStream IWICPersistStream_iface; > + IWICMetadataBlockReader IWICMetadataBlockReader_iface; > const MetadataHandlerVtbl *vtable; > MetadataItem *items; > DWORD item_count; > @@ -55,6 +56,11 @@ static inline MetadataHandler *impl_from_IWICPersistStream(IWICPersistStream *if > return CONTAINING_RECORD(iface, MetadataHandler, IWICPersistStream_iface); > } > > +static inline MetadataHandler *impl_from_IWICMetadataBlockReader(IWICMetadataBlockReader *iface) > +{ > + return CONTAINING_RECORD(iface, MetadataHandler, IWICMetadataBlockReader_iface); > +} > + > static void MetadataHandler_FreeItems(MetadataHandler *This) > { > int i; > @@ -92,6 +98,10 @@ static HRESULT WINAPI MetadataHandler_QueryInterface(IWICMetadataWriter *iface, > { > *ppv = &This->IWICPersistStream_iface; > } > + else if (IsEqualIID(&IID_IWICMetadataBlockReader, iid)) > + { > + *ppv = &This->IWICMetadataBlockReader_iface; > + } > else > { > *ppv = NULL; > @@ -317,6 +327,64 @@ static const IWICPersistStreamVtbl MetadataHandler_PersistStream_Vtbl = { > MetadataHandler_SaveEx > }; > > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_QueryInterface(IWICMetadataBlockReader *iface, > + REFIID iid, void **ppv) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_QueryInterface(&This->IWICMetadataWriter_iface, iid, ppv); > +} > + > +static ULONG WINAPI MetadataHandler_MetadataBlockReader_AddRef(IWICMetadataBlockReader *iface) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_AddRef(&This->IWICMetadataWriter_iface); > +} > + > +static ULONG WINAPI MetadataHandler_MetadataBlockReader_Release(IWICMetadataBlockReader *iface) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_Release(&This->IWICMetadataWriter_iface); > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetContainerFormat( > + IWICMetadataBlockReader *iface, GUID *guid) > +{ > + FIXME("(%p,%p): stub\n", iface, guid); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetCount( > + IWICMetadataBlockReader *iface, UINT *count) > +{ > + FIXME("(%p,%p): stub\n", iface, count); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetReaderByIndex( > + IWICMetadataBlockReader *iface, UINT index, IWICMetadataReader **reader) > +{ > + FIXME("(%p,%u,%p): stub\n", iface, index, reader); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetEnumerator( > + IWICMetadataBlockReader *iface, IEnumUnknown **enum_metadata) > +{ > + FIXME("(%p,%p): stub\n", iface, enum_metadata); > + return E_NOTIMPL; > +} > + > +static const IWICMetadataBlockReaderVtbl MetadataHandler_MetadataBlockReader_Vtbl = > +{ > + MetadataHandler_MetadataBlockReader_QueryInterface, > + MetadataHandler_MetadataBlockReader_AddRef, > + MetadataHandler_MetadataBlockReader_Release, > + MetadataHandler_MetadataBlockReader_GetContainerFormat, > + MetadataHandler_MetadataBlockReader_GetCount, > + MetadataHandler_MetadataBlockReader_GetReaderByIndex, > + MetadataHandler_MetadataBlockReader_GetEnumerator > +}; > + > HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > { > MetadataHandler *This; > @@ -333,6 +401,7 @@ HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkO > > This->IWICMetadataWriter_iface.lpVtbl = &MetadataHandler_Vtbl; > This->IWICPersistStream_iface.lpVtbl = &MetadataHandler_PersistStream_Vtbl; > + This->IWICMetadataBlockReader_iface.lpVtbl = &MetadataHandler_MetadataBlockReader_Vtbl; > This->ref = 1; > This->vtable = vtable; > This->items = NULL; > -- > 1.7.10.1 > > >

1 0

Testing regedit
by Daniel Jelinski May 24, 2012

May 24, 2012

Hello, I just noticed that wine's regedit has a few interesting bugs that appear when running with native comctl32. Can I/should I file them in the bugzilla? Regards, Daniel

3 3

Re: [PATCH variant 1] dsound: use a low-quality FIR for games
by Andrew Eikum May 23, 2012

May 23, 2012

Thanks Alexander. Thoughts below... On Sat, May 19, 2012 at 09:09:35PM +0600, Alexander E. Patrakov wrote: > There are two ways to implement a high-performance resampler, and I > have prepared (conflicting, pick no more than one) patches for both: > > 1 (this patch): Use a shorter FIR with the existing code. This has the > advantage of higher quality (unwanted frequencies are at least > attempted to be rejected) and almost no new code. > 2 (the other patch): Write new code. E.g., linear interpolation. This > is what Windows XP does at its lowest quality setting, and it eats > less CPU than variant 1. > Do you have an opinion on which of these patches to use? The low-quality FIR has the advantage of not introducing another codepath. On the other hand, the linear resampler codepath is very simple, and even easier on the CPU. I'm leaning towards the linear resampler for its larger CPU usage benefits. > Also note that, as evicenced by the debugging patch, a Core 2 Duo > E6420 @ 2.13 GHz _can_ resample more than 32 streams simultaneously > from various weird rates to 48000 Hz. As GTA:SA reportedly creates > only 16 secondary buffers, it _should_ have more than enough CPU time > to mix them. IMHO, this makes bug #30639 look somewhat strange: on > GyB's computer, GTA:SA stutters, while Darwinia (which looks more > demanding about sound) doesn't. It may well be that in fact none of my > patches are needed, and that the real bug is that the CPU-intensive > cp_fields() function is called from a wrong thread or process. I don't > have the expertise needed to debug this. > I did some research on this. Darwinia creates up to 32 buffers, like you said. GTA:SA creates and destroys buffers as needed, and I saw it go as high as 31 in a quick test. Darwinia's buffer frequencies range in the 40-90 kHz range and resample to 22050 Hz, while GTA:SA's range around 10-20 kHz and resample to 48 kHz. So in each time step, GTA:SA requires about 1000-2000 get_current_sample() calls, but 4800 FIR convolutions per buffer. Darwinia requires 4000-9000 get_current_sample() calls, but only about 2200 convolutions per buffer. I suspect the convolutions are considerably more expensive than the get_current_sample() calls, so I would actually expect GTA:SA to be more CPU taxing. That should explain what's going on here. We could test this on Gyb's machine by setting DefaultSampleRate=22050 and hacking <dlls/dsound/primary.c:primarybuffer_SetFormat> to return S_OK without actually changing the primary buffer's format. That should give GTA:SA similar cp_fields performance to Darwinia, and I expect it would fix the lag issue. Andrew

2 2

Re: vbscript: Add support for integer values in conditional jumps.
by Marvin May 23, 2012

May 23, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18547 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

Re: [2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
by Bruno Jesus May 22, 2012

May 22, 2012

On Mon, Apr 30, 2012 at 6:52 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/gdi32/freetype.c | 35 +++++++++++++++++++- > dlls/gdi32/tests/font.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 116 insertions(+), 2 deletions(-) I don't know if this patch was directly related to a bug or not but now we are sure it does really fix at least this bug: http://bugs.winehq.org/show_bug.cgi?id=12476 Best wishes, Bruno

1 0

Re: wineqtdecoder: Recreate audio extraction session when we run out of frames.
by Alexandre Julliard May 22, 2012

May 22, 2012

Aric Stewart <aric(a)codeweavers.com> writes: > This is instead of waiting until a movie is fully loaded before being > able to start playing. This eliminates the up to several second pause > when starting some, mostly avi, movies. > --- > dlls/wineqtdecoder/qtsplitter.c | 66 > +++++++++++++++++++++++++++++++++------ > 1 files changed, 56 insertions(+), 10 deletions(-) What about the comment that says that we can't do that? -- Alexandre Julliard julliard(a)winehq.org

2 1

winetricks & DLL overrides
by wylda＠volny.cz May 22, 2012

May 22, 2012

Hi Dan, i'm happy user of winetricks and thanks for all that work. Today i found out, that i wasn't able to reveal, that apps uses some native dll when using: winetricks settings alldlls=builtin further checking revealed, that winetricks(20120308) has several no longer available dll override compared to winecfg and some are missing, thus application uses them as native. So i add/del dlls from override_all_dlls list based on winecfg (1.5.3-164-gdec3d50) and the result is attached as a patch. Probably unusable for you, because: * no care about line length * i do not know whether removing no longer available dll's override is allowed (what's happen for users using old wine-1.0 and need dlls's override no longer available in wine-1.5.3) * shouldn’t be the dll's override in user.reg simply overwritten? As i noticed the names are there twice - 2nd one with "*" prefix making it confusing, which value will be used and the list in winecfg is twice as long. Thanks and regards, W.

2 2

Re: [1/2] ole32: Forward OleCreateLinkFromData and OleCreateStaticFromData to OleCreateFromData.
by Alexandre Julliard May 22, 2012

May 22, 2012

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +/****************************************************************************** > + * OleCreateLinkFromData [OLE32.@] > + */ > +HRESULT WINAPI OleCreateLinkFromData(LPDATAOBJECT data, REFIID iid, > + DWORD renderopt, LPFORMATETC fmt, > + LPOLECLIENTSITE client_site, LPSTORAGE stg, > + LPVOID *obj) > +{ > + return OleCreateFromData(data, iid, renderopt, fmt, client_site, stg, obj); > +} > + > +/****************************************************************************** > + * OleCreateStaticFromData [OLE32.@] > + */ > +HRESULT WINAPI OleCreateStaticFromData(LPDATAOBJECT data, REFIID iid, > + DWORD renderopt, LPFORMATETC fmt, > + LPOLECLIENTSITE client_site, LPSTORAGE stg, > + LPVOID *obj) > +{ > + return OleCreateFromData(data, iid, renderopt, fmt, client_site, stg, obj); > +} Surely there's more to these functions than that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: quartz/tests: Fix compilation on systems that don't support nameless structs.
by Marvin May 21, 2012

May 21, 2012

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18512 Your paranoid android. === WNT4WSSP6 (32 bit filtermapper) === filtermapper.c:96: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:233: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:347: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:405: Test failed: CoCreateInstance failed with 80040154

2 1

Re: [PATCH 3/3] shell32: Move the pidl handling to the ExtractIcon_Constructor
by Nikolay Sivov May 20, 2012

May 20, 2012

On 5/20/2012 18:47, Detlef Riekenberg wrote: > } else if (IsEqualIID(riid,&IID_IExtractIconA)&&(cidl == 1)) { > - pidl = ILCombine(This->pidlRoot, apidl[0]); > - pObj = (LPUNKNOWN) IExtractIconA_Constructor(pidl); > - SHFree(pidl); > - hr = S_OK; > + return IExtractIconAW_Constructor(This->pidlRoot, apidl[0], FALSE, ppvOut); > } else if (IsEqualIID(riid,&IID_IExtractIconW)&&(cidl == 1)) { > - pidl = ILCombine(This->pidlRoot, apidl[0]); > - pObj = (LPUNKNOWN) IExtractIconW_Constructor(pidl); > - SHFree(pidl); > - hr = S_OK; > + return IExtractIconAW_Constructor(This->pidlRoot, apidl[0], TRUE, ppvOut); > } else if ((IsEqualIID(riid,&IID_IShellLinkW) || IsEqualIID(riid,&IID_IShellLinkA)) I think it's better to pass riid to constructor helper and return appropriate vtable according to that riid. That will also collapse this to a single 'if' testing for both interfaces. > +HRESULT IExtractIconAW_Constructor(LPCITEMIDLIST root, LPCITEMIDLIST item, BOOL is_unicode, void ** ppvOut) > { > - IExtractIconWImpl *ei; > + IExtractIconWImpl *ei = HeapAlloc(GetProcessHeap(), 0, sizeof(IExtractIconWImpl)); > + LPITEMIDLIST pidl = ILCombine(root, item); > > - TRACE("%p\n", pidl); > + if (!pidl || !ei) { > + SHFree(pidl); > + HeapFree(GetProcessHeap(), 0, ei); > + return E_OUTOFMEMORY; > + } > > - ei = HeapAlloc(GetProcessHeap(), 0, sizeof(*ei)); > ei->ref=1; > ei->IExtractIconW_iface.lpVtbl =&eivt; > ei->IExtractIconA_iface.lpVtbl =&eiavt; > ei->IPersistFile_iface.lpVtbl =&pfvt; > ei->pidl=ILClone(pidl); > > - pdump(pidl); Same here as in previous patch - storing combined result vs. making another clone.

1 0