April 2011 - 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: [patch] Support NULL puLen in VerQueryValue
by Andrew Nguyen Oct. 16, 2011

Oct. 16, 2011

On 01/03/2011 09:25 PM, Rafael Ávila de Espíndola wrote: > I couldn't find any documentation saying that this must be supported, > but running google code search on VerQueryValue.*NULL found some uses. > > Cheers, > Rafael > > > > You should write some tests to examine the behavior of VerQueryValue with NULL puLen.

3 2

Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
by James Hawkins Sept. 24, 2011

Sept. 24, 2011

I'm very hesitant about this. MSDN has no documentation about RegisterOCX, so I'm not sure how you're justifying this change. It's been a long time since I worked on this, so I don't remember much, but I do remember testing this method and documenting the parameters correctly. Where are you getting information that 'I' is required when using 'N'? James On Tue, May 11, 2010 at 1:24 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > This is my humble attempt of addressing Alexandre's feeback at > > http://www.winehq.org/pipermail/wine-devel/2010-May/083518.html > > It does pass testing for me, even on FreeBSD/i386, but I will say I did > not find the MSDN documentation I located too helpful/clear, and may have > been misled. > > As a next step we'd need to look into DllInstall. This change, hopefully, > is a move in the right direction, though. If not, some guidance or one of > the pros looking into it will be appreciated. > > Gerald > > --- > dlls/advpack/advpack.c | 14 ++++++++++---- > 1 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/dlls/advpack/advpack.c b/dlls/advpack/advpack.c > index 112d38a..f040ec6 100644 > --- a/dlls/advpack/advpack.c > +++ b/dlls/advpack/advpack.c > @@ -486,8 +486,10 @@ HRESULT do_ocx_reg(HMODULE hocx, BOOL do_reg) > * NOTES > * OCX - Filename of the OCX to register. > * flags - Controls the operation of RegisterOCX. > - * 'I' Call DllRegisterServer and DllInstall. > - * 'N' Only call DllInstall. > + * 'I' Call DllInstall and, unless 'N' is specified as well, > + * DllRegisterServer. > + * 'N' Do not call DllRegisterServer; only valid if 'I' is > + * specified too. > * param - Command line passed to DllInstall. > */ > HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) > @@ -519,8 +521,12 @@ HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) > if (!hm) > goto done; > > - hr = do_ocx_reg(hm, TRUE); > - > + if(strchrW(str_flags,'I')) > + { > + if (!strchrW(str_flags,'N')) > + hr = do_ocx_reg(hm, TRUE); > + } > + > done: > FreeLibrary(hm); > HeapFree(GetProcessHeap(), 0, cmdline_copy); > -- > 1.6.6.2 > > >

2 3

GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
by Michael Mc Donnell Aug. 25, 2011

Aug. 25, 2011

Dear Wine developers, I would like implement some of the missing mesh functions in Wine's D3DX9 for Google Summer of Code 2011. I would like to implement the following functions: - CloneMesh - CloneMeshFVF - ConvertPointRepsToAdjacency - ConvertAdjacencyToPointReps - GenerateAdjacency They seem to be suitable in size to implement during a summer, and I have a good idea of how to implement them. I expect to first implement tests and then implement the functions. I am a masters student at the Technical University of Denmark nearing the end of my studies, and I have specialized in 3D computer graphics, studying both real-time and physically based techniques, as well as how to use existing 3D modeling tools to create animations. The mesh functions should be fairly straight forward for me to implement as I have recently taken an advanced course on geometry processing which involved a lot of mesh manipulation. I have, furthermore, already tests (for a shell32 function) in the wine test suite so I have some knowledge of Wine development. Roderick Coldenbrander is listed as a possible mentor for "Direct3D - Implement missing D3D9_xx DLLs" on the wiki. Are you still interested, or would someone else like to be a mentor? Regards, Michael Mc Donnell

9 50

re: make "bisected" a keyword in bugzilla?
by Dan Kegel Aug. 8, 2011

Aug. 8, 2011

I think it's a good idea. 'regression' isn't as strong as 'bisected'. Unless there are objections, I'll add the keyword on Monday.

11 15

Re: ws2_32: return an error in SO_CONNECT_TIME stub
by Dmitry Timoshkov June 27, 2011

June 27, 2011

Austin English <austinenglish(a)gmail.com> wrote: > @@ -2554,7 +2554,7 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level, > } > *(DWORD*)optval = pretendtime++; > *optlen = sizeof(DWORD); > - return ret; > + return SOCKET_ERROR; > } Filling out optval and optlen but returning SOCKET_ERROR doesn't make sense. Probably Eye-Fi doesn't change the return value. What kind of socket both of the applications do pass? -- Dmitry.

2 1

CD-ROM ioctl support on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com June 6, 2011

June 6, 2011

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

2 3

Re: wineoss.drv: Add mmdevapi driver.
by Gerald Pfeifer June 4, 2011

June 4, 2011

I believe commit be332326ba8fc3def406c5f29adf04fbe9a83976 Author: Andrew Eikum <aeikum(a)codeweavers.com> Date: Wed Apr 27 09:12:36 2011 -0500 is causing the following build failures on my nightly FreeBSD testers: mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) Looks like some autoconfigury is not working or incomplete? Gerald

3 6

Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]
by Alexandre Julliard May 22, 2011

May 22, 2011

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > This is the first hunk of a patch a few days ago; testbot.winehq.org > thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291 You don't need casts. If the variable has the wrong type you can change that. -- Alexandre Julliard julliard(a)winehq.org

2 1

RFC: doc for message contexts additions in PO files
by Frédéric Delanoy May 8, 2011

May 8, 2011

Hi guys, I've put together the following doc for the introduction of message contexts. It's still a bit raw but I'd improve it for the wiki version. Could you please have a look and help proofread it? I'd like to ensure I didn't miss an important step. Thanks in advance. Frédéric Delanoy PS: BTW what is the reference version? en_US.po or en.po? ********* Adding one/more message contexts (ADD LINK TO EXTERNAL DOC) (QUICK MC EXPLANATION) Prerequisite: enable maintainer mode using ./configure --enable-maintainer-mode (you might have to add some development packages; check with your distribution for infos). 1. Locate strings to be "altered" Say you have in your localized po file: #: file1.rc:123 file2.rc:456 msgid "ambiguous word" msgstr "translation" and you want to disambiguate, you'd do the following 2. Find appropriate translations - check the respective rc entries (in file1.rc line 123) FOO "ambiguous word" (in file2.rc line 456) BAR "ambiguous word" and find their meaning/context (e.g. using some code browsing tools, like cscope to find references; running the program is recommanded, ...) 3. Add the messages contexts - The following syntax is used: "translation" -> "#msgctxt#your context#translation" - You end up with sthg like FOO "#msgctxt#context #ambiguous word#" Similarly BAR "#msgctxt#context 2#ambiguous word#" 3. Run 'make depend && make' 4. Edit your po file to add the new translations 5. Ideally, remove the "#, fuzzy" automatically inserted in the En_US.po reference file (and En.rc ). 6. Run 'make' again and test your changes.

2 1

D3D performance debugging report
by Stefan Dösinger May 2, 2011

May 2, 2011

Hi, I spent a few hours debugging wined3d performance today. No, I found no magic fix for the slowness, just some semi-usable data. First I wrote a hacky patch to avoid redundant FBO applications. This gave a tiny, tiny performance increase, see http://www.winehq.org/pipermail/wine- devel/2011-April/089832.html. The main investigation concerned redundant shader applications. The aim was to find out how many of our glBindProgramARB calls are re-binding the same program, and how much this costs. Depending on the game between 20% to 90% of all BindProgram calls are redundant. I'll attach my debug hack so others can test their own apps. I used ARB shaders for testing because they can apply vertex and fragment programs separately. This brings up two questions: (a) How much does this cost (b) Why does this happen The costs: In my draw overhead tester hacking out the redundant apply calls improved performance a lot, from about 101 fps to 157 fps. The biggest part of that are the GL calls. Without them but the remaining shader logic I get 144 fps. Unfortunately this does not translate to any performance gains in real apps. I tried to filter out the redundant apply calls in the simplest way possible: Track the current value per wined3d_context and check before calling glBindProgramARB. This gave the 144 fps in the draw overhead tester, but no measurable increase in any other apps(I tested StarCraft 2, HL2, Team Fortress 2, World in Conflict and a few others) Given the amount of redundant apply calls and the cost of them in the draw overlay tester I have expected at least some improvement. Certainly not a 50% performance increase(the draw overlay tester performs no shader changes at all in the draw loop), but at least a 2-3% gain. So far I have no explanation why I didn't see that. But why do those redundant apply calls happen? It seems like the state dirtification comes all the way from the stream sources and/or vertex declaration. STREAMSRC is linked to VDECL, which is linked to VERTEXSHADER, which in turn reapplies the pixel shader. This means redundant vertex and pixel shader applications. Separating those states will be a major challenge. The vdecl<->vshader link shouldn't be needed any more, except in rare cases where GL_ARB_vertex_array_bgra is not supported and the application switches one attribute from D3DDECL_D3DCOLOR to a non-d3dcolor attribute. If the vertex shader changes we still have to reparse the vertex declaraion and reapply the stream sources because the vshader determines the stream numbers. Maybe we can reduce the number of times this happens by ordering stream usages and indices to make sure shaders with compatible input get the same stream ordering. vdecl and streamsrc are pretty related. If the vdecl is changed we have to reapply the stream sources. The other way around shouldn't cause problems though. There's no need to reapply every stream except the changed ones and there's no need to reapply the vertex shader. The vertex and pixel shader are linked for a few reasons: The shader backend API offers only a function to set both. Basic GLSL only offers a function to set both at once(GL_ARB_separate_shader_objects changes that). And even in ARB the pixel shader input may require some changes in the vertex shader output to get Shader Model 3.0 varyings right. The shader backend API can be changed, but it has to be done in a way that doesn't hurt GLSL without ARB_separate_shader_objects. If we have classic GLSL we have to keep the link. With ARB we can conditionally reapply the vertex shader if the ps_input_signature is changed. To complicate matters there are additional states that affect the shaders, like fog, textures, clipping. We don't keep track of those dependencies. So it's a lot of work to clean up these state dependencies and we don't know how much it'll gain us :-( Stefan

4 8

re: comctl32: realloc or free and alloc
by Dan Kegel May 2, 2011

May 2, 2011

Alexey wrote: > i currently digg in comctl32 to find why my app fails. I found that > string conversation AtoW in some places silently fails. The problem is > that the destination for string is just a fresh pointer (not NULL). > Str_SetPtrAtoW check if it is NULL pointer and if not it trys to > ReAlloc. There was no Alloc before so ReAlloc returns NULL The code looks like it assumes that pointer is always managed by Alloc/ReAlloc/Free. In what context is the destination a fresh, non-Alloc'd pointer? Perhaps that's where the bug lies. Your proposed solution would pass a non-Alloc'd pointer to Free, which doesn't seem good. - Dan

4 9

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
by Marvin April 30, 2011

April 30, 2011

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=10648 Your paranoid android. === WNT4WSSP6 (32 bit ddrawmodes) === ddrawmodes.c:520: Test failed: EnumDisplayModes returned: 80070057 === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [Bug 26975] configure can't find OSSv4 (both Wine and OSSv4 is current from git and mercurial respectively)
by Brock York April 30, 2011

April 30, 2011

Interestingly enough I just had this error and it was solved by sudo apt-get install oss4-base oss4-dev

1 0

gecko and native msvcrt
by Dan Kegel April 30, 2011

April 30, 2011

While testing a game with current gecko, I saw the error wine: Call from 0x7bc4ad90 to unimplemented function msvcrt.dll._snwprintf_s, aborting The game needed a native msvcrt, so I had installed one with winetricks, and it didn't export that function. So it seems that new gecko is incompatible with old msvcrt, and using native msvcrt as a workaround for bugs in wine's version is going to be harder than it used to be. Time to fix more of them msvcrt bugs, I guess... And/or find a more up to date msvcrt.dll for winetricks.

4 5

Re: [PATCH] dinput: Mark internal symbols as hidden
by Vitaliy Margolen April 30, 2011

April 30, 2011

On 04/29/2011 01:31 AM, Marcus Meissner wrote: > --- > dlls/dinput/device_private.h | 148 +++++++++++++++++++++--------------------- > 1 files changed, 74 insertions(+), 74 deletions(-) What exactly is this supposed to to? This is inside header file, everything declared in it is internal to dinput. Why do we need some extra declarations on it? Vitaliy.

7 10

comctl32: realloc or free and alloc
by Alexey Fisher April 30, 2011

April 30, 2011

Hallo, i currently digg in comctl32 to find why my app fails. I found that string conversation AtoW in some places silently fails. The problem is that the destination for string is just a fresh pointer (not NULL). Str_SetPtrAtoW check if it is NULL pointer and if not it trys to ReAlloc. There was no Alloc before so ReAlloc returns NULL. Because there is no other checks, Str_SetPtrAtoW just go back without converting the string. Here is affected code: dlls/comctl32/comctl32undoc.c:999 > BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) > { > TRACE("(%p %s)\n", lppDest, lpSrc); > > if (lpSrc) { > INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0); > LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); > > if (!ptr) { > ERR("last error %x\n", GetLastError()); > return FALSE; > } > MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len); > *lppDest = ptr; > } > else { > Free (*lppDest); > *lppDest = NULL; > } > > return TRUE; > } The question is, is it appropriate reaction of ReAlloc and if it so, may be it make more sense to do this: --- a/dlls/comctl32/comctl32undoc.c +++ b/dlls/comctl32/comctl32undoc.c @@ -998,18 +998,26 @@ INT Str_GetPtrAtoW (LPCSTR lpSrc, LPWSTR lpDest, INT nMaxLen) */ BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc) { - TRACE("(%p %s)\n", lppDest, lpSrc); + TRACE("(%p, %s)\n", *lppDest, debugstr_a(lpSrc)); if (lpSrc) { + if (*lppDest) { + Free (*lppDest); + *lppDest = NULL; + } INT len = MultiByteToWideChar(CP_ACP,0,lpSrc,-1,NULL,0); - LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); + LPWSTR ptr = Alloc (len*sizeof(WCHAR)); - if (!ptr) + if (!ptr) { + ERR("Can't allocait memory size: %u," + " for string %s.\n", len*sizeof(WCHAR), lpSrc); return FALSE; + } MultiByteToWideChar(CP_ACP,0,lpSrc,-1,ptr,len); *lppDest = ptr; } else { + TRACE("lpSrc = NULL, nothing to convert.\n"); Free (*lppDest); *lppDest = NULL; } -- Regards, Alexey

1 0

Re: wined3d: If Wine fails to acquire the focus window, allow the wndproc function to continue receiving messages.
by Henri Verbeet April 30, 2011

April 30, 2011

On 30 April 2011 01:23, John Edmonds <pocketcookies2(a)gmail.com> wrote: > @@ -6559,6 +6559,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Reset(IWineD3DDevice *iface, > { > ERR("Failed to acquire focus window, hr %#x.\n", hr); > wined3d_swapchain_decref(swapchain); > + This->filter_messages = filter; > return hr; > } This patch looks right in principle. Note that if you're running into this code you probably have problems elsewhere though.

1 0

re: msvbvm60: add stub dll
by Dan Kegel April 29, 2011

April 29, 2011

Austin wrote: > Fixes http://bugs.winehq.org/show_bug.cgi?id=19816 That bug is "Add implementation of MSVBVM60". I don't think a stub fixes it. What apps benefit from having a stub? - Dan

1 0

Fix WineHQ bug #19762
by Joerg-Cyril.Hoehle＠t-systems.com April 29, 2011

April 29, 2011

Kai Wasserbäch wrote: >as bug #19762 is open for some time now, fully bisected, the solution applied for >several versions in my Debian packages ([0]) without reports about breakage, I >hearby propose the reversion of commit 67631163. http://bugs.winehq.org/show_bug.cgi?id=19762#c21 That commit is another example of a commit that introduced a regression while fixing another regression in another app. This does not prove that commit wrong, however, the burden is now on you (us) to prove it in order to change git. It's not an impossible task. Even code that seemed to be backed by tests in Wine was changed when the tests were proven wrong/incomplete. For a start, it may be worth testing that other app and see if it still needs that commit in current Wine. Does anybody know the bug number of that other app's original issue? Finally, are there any tests that support either behavior? Regards, Jörg Höhle

1 0

Re: Fix WineHQ bug #19762
by Henri Verbeet April 29, 2011

April 29, 2011

On 29 April 2011 12:29, Kai Wasserbäch <curan(a)debian.org> wrote: > several versions in my Debian packages ([0]) without reports about breakage, I > hearby propose the reversion of commit 67631163. Wylda tried to reach the I don't think reverting that commit is the right thing to do, it's just going to break something else instead.

1 0

Re: [1/5] wined3d: Add missing temporary variable declaration to ARB shader backend.
by Stefan Dösinger April 29, 2011

April 29, 2011

> + shader_addline(buffer, "TEMP TB;\n"); Which shader instruction uses this? Afair vertex shaders should only use TA, but there's no proper infrastructure that manages that.

2 2

Re: msvcrt: fix utime to correctly handle a NULL-pointer for the utimbuf structure field
by Marvin April 29, 2011

April 29, 2011

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=10627 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: po: Update French translation
by Nicolas Le Cam April 29, 2011

April 29, 2011

Hi Frédéric, Le 29 avril 2011 00:16, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > #: winerror.mc:441 > msgid "No more search handles\n" > -msgstr "Il n'y a plus de descripteurs de recherche\n" > +msgstr "Il n'y a plus de descripteur de recherche\n" This one isn't correct. There's not only one handle when available but many so it should take an 's' in the negative form too. Thanks for your work ! -- Nicolas Le Cam

2 1

Re: [2/5] wined3d: Remove rcp special handling of 0 from the ARB shader backend.
by Stefan Dösinger April 28, 2011

April 28, 2011

On Thursday 28 April 2011 00:34:24 Matteo Bruni wrote: > This should fix http://bugs.winehq.org/show_bug.cgi?id=26780 I see this patch was committed, I think I should really read wine-patches more often. I added the RCP 0 handling because StarCraft 2 needed it. Did you test this with SC2? Specifically, the Water was black without proper handling of rcp 0

1 0

Re: comctl32/tests: Remove practically unused parameters from test functions
by Vitaliy Margolen April 28, 2011

April 28, 2011

On 04/27/2011 01:14 AM, Nikolay Sivov wrote: > Remove practically unused parameters from test functions > So how is global variable any better then local variable passed as function parameter? IMHO this is s wrong thing to do - to move everything as global variables just to move it back whenever need arises. Vitaliy.

3 3

Re: include: Generate rmxftmpl.h from rmxftmpl.x using new build tool. (try 3)
by Austin English April 28, 2011

April 28, 2011

On Thu, Apr 28, 2011 at 14:52, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > --- > Now using atexit function to cleanup up the output file on errors, and > parsing errors are signaled using a boolean error variable. > > diff --git a/include/rmxftmpl.x b/include/rmxftmpl.x > new file mode 100644 > index 0000000..e7144b0 > --- /dev/null > +++ b/include/rmxftmpl.x > @@ -0,0 +1,268 @@ > +xof 0302txt 0064 > +// Copyright (C) 2011 Dylan Smith > +// > +// This library is free software; you can redistribute it and/or > +// modify it under the terms of the GNU Lesser General Public > +// License as published by the Free Software Foundation; either > +// version 2.1 of the License, or (at your option) any later version. > +// > +// This library is distributed in the hope that it will be useful, > +// but WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// Lesser General Public License for more details. > +// > +// You should have received a copy of the GNU Lesser General Public > +// License along with this library; if not, write to the Free Software > +// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA Looks like some C99 comments slipped in. -- -Austin

2 1

Re: include: Generate rmxftmpl.h from rmxftmpl.x using new build tool. (try 3)
by David Adam April 28, 2011

April 28, 2011

1 0

Re: [po]update korean resource
by Nikolay Sivov April 28, 2011

April 28, 2011

On 4/28/2011 13:25, Hwang YunSong(???) wrote: > updated > #: hhctrl.rc:73 > -#, fuzzy > -msgctxt "table of contents" > +msgctxt "????????+??? ?????????" > msgid "&Home" > -msgstr "???" > +msgstr "???(&H)" msgctxt is not a thing to translate as I understand it. It's an additional identifier to distinguish multiple translation variations.

1 0

Re: wined3d/state: Treat unrecognized D3DZBUFFERTYPEs as D3DZB_TRUE. (try 2)
by Henri Verbeet April 28, 2011

April 28, 2011

I'm not so convinced there's value in this, considering there are no known applications depending on this. Stefan thinks it's useful anyway. If you do want to spend the effort to make this go in, note that this affects ddraw and d3d8 as well, not just d3d9. The test should probably just have a loop in depth_buffer_test() itself, or even write a test specific for this purpose. The wined3d part might as well handle the state as a BOOL, considering WINED3DZB_USEW isn't handled all that different from WINED3DZB_TRUE, except for the FIXME.

3 2

Re: [4/5] wined3d: Fix pow handling with special values in ARB backend.
by Matteo Bruni April 28, 2011

April 28, 2011

Actually, this patch seems to break Bioshock with UseGLSL=disabled. Please drop/revert this one for the time being...

1 0

[Fwd: po files]
by Łukasz Wojniłowicz April 28, 2011

April 28, 2011

3 3

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.
by Joerg-Cyril.Hoehle＠t-systems.com April 28, 2011

April 28, 2011

Hi, Damjan Jovanovic wrote: >In the meanwhile I've found another problem: mciavi32 always deadlocks >when MCI_WAIT is not set:[...] ShowWindow() Looks like bug #21060 and the others http://bugs.winehq.org/show_bug.cgi?id=21060#c2 - bug #12908, bug #15669, bug #18363 involving ShowWindow; - bug #14785, bug #21060 involving EnterCriticalSection. But perhaps there's only a single issue. It would be nice if somebody who knows about windows and their messages would look at these. Regards, Jörg Höhle

1 0

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.
by Joerg-Cyril.Hoehle＠t-systems.com April 28, 2011

April 28, 2011

Damjan, can you recommend any downloadable 16bit app that stresses the MCI? It's good that you noticed that RECT16 and RECT do not have the same size (whack!). Yet I'm surprised that you left MCI_WINDOW untouched. I believe that the apps that use MCI_WHERE/PUT etc. (i.e. MCIAVI) are likely to use MCI_WINDOW as well to set the window handle. Does no FIXME appear in your console? http://source.winehq.org/source/dlls/mmsystem.dll16/mci16.c#L182 The comment there is obsolete. dwFlags is available and could be used like I did in db0df4c067fd6b701905aaef735c4729fca9d73f Regards, Jörg Höhle

2 1

Re: [PATCH 3/3] msvcrt: Updated spec file
by Alexandre Julliard April 28, 2011

April 28, 2011

Piotr Caban <piotr(a)codeweavers.com> writes: > +@ cdecl -arch=win32 __p___argc() > +@ cdecl -arch=win32 __p___argv() > +@ cdecl -arch=win32 __p___initenv() > +@ cdecl -arch=win32 __p___mb_cur_max() MSVCRT____mb_cur_max_func > +@ cdecl -arch=win32 __p___wargv() > +@ cdecl -arch=win32 __p___winitenv() > +@ cdecl -arch=win32 __p__acmdln() > +@ cdecl -arch=win32 __p__amblksiz() > +@ cdecl -arch=win32 __p__commode() > +@ cdecl -arch=win32 __p__daylight() MSVCRT___p__daylight > +@ cdecl -arch=win32 __p__dstbias() > +@ cdecl -arch=win32 __p__environ() > +@ stub -arch=win32 __p__fileinfo #() > +@ cdecl -arch=win32 __p__fmode() > +@ cdecl -arch=win32 __p__iob() MSVCRT___iob_func > +@ stub -arch=win32 __p__mbcasemap #() > +@ cdecl -arch=win32 __p__mbctype() > +@ cdecl -arch=win32 __p__osver() > +@ cdecl -arch=win32 __p__pctype() MSVCRT___pctype_func > +@ cdecl -arch=win32 __p__pgmptr() > +@ stub -arch=win32 __p__pwctype #() > +@ cdecl -arch=win32 __p__timezone() MSVCRT___p__timezone > +@ cdecl -arch=win32 __p__tzname() > +@ cdecl -arch=win32 __p__wcmdln() > +@ cdecl -arch=win32 __p__wenviron() > +@ cdecl -arch=win32 __p__winmajor() > +@ cdecl -arch=win32 __p__winminor() > +@ cdecl -arch=win32 __p__winver() > +@ cdecl -arch=win32 __p__wpgmptr() I just changed this the other way around recently. These are exported in at least some 64-bit versions. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] Add undocumented function to unify MultiByteToWideChar conversation
by Alexey Fisher April 28, 2011

April 28, 2011

MultiByteToWideChar are called directly only from one function. All other colls in comctl32 go thrue this function. It was recovered with from dissassambled code. Signed-off-by: Alexey Fisher <bug-track(a)fisher-privat.net> --- dlls/comctl32/comctl32undoc.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/dlls/comctl32/comctl32undoc.c b/dlls/comctl32/comctl32undoc.c index ff94051..6eb6c0f 100644 --- a/dlls/comctl32/comctl32undoc.c +++ b/dlls/comctl32/comctl32undoc.c @@ -560,6 +560,47 @@ INT WINAPI AddMRUStringW(HANDLE hList, LPCWSTR lpszString) } /************************************************************************** + * comctl_MultiByteToWideChar (internal) + * Convert Multibyte string to WideChar string. + * + * PARAMS + * CodePage [I] COdepage of lpMultiByteStr + * lpMultiByteStr [I] multibyte string + * + * RETURNS + * Pointer to lpWideCharStr [O] or NULL if failed. Do not forget to + * Free the lpWideCharStr after use! + */ +LPWSTR comctl_MultiByteToWideChar(UINT CodePage, LPCSTR lpMultiByteStr) +{ + LPWSTR lpWideCharStr; + int len; + + if (lpMultiByteStr == NULL || lpMultiByteStr == -1) + return NULL; + + if (IsBadReadPtr(lpMultiByteStr, 1)) + return NULL; + + len = MultiByteToWideChar(CodePage, NULL, lpMultiByteStr, -1, NULL, NULL); + if (!len) + len = 1; + + lpWideCharStr = LocalAlloc(len * sizeof(WCHAR), 0); + if (!lpWideCharStr) + return NULL; + + if (!MultiByteToWideChar(CodePage, 1, lpMultiByteStr, -1, + lpWideCharStr, len)) { + LocalFree(lpWideCharStr); + lpWideCharStr = NULL; + return NULL; + } + + return lpWideCharStr; +} + +/************************************************************************** * AddMRUStringA [COMCTL32.153] * * See AddMRUStringW. -- 1.7.4.1

3 6

Re: infosoft/tests: COM cleanup in infosoft.c.
by Marvin April 28, 2011

April 28, 2011

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=10605 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed

2 1

Question on Conformance Test
by James McKenzie April 27, 2011

April 27, 2011

All: I am writing a conformance test for the richedit function EM_FINDWORDBREAK. I realize that WindowsNT 4.0 is our base configuration and most of the values process the same. However, a couple of values process differently for Windows NT 4.0/Windows2000, WindowsXP/Windows2003 and Windows Vista onward. What would be the BEST method of annotating this: Per the development guide: ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); or: ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); In other words, should I avoid the use of Broken() in this case, as the returned value is correct? Thank you. James McKenzie

3 2

Re: wined3d: Track when the FBO is dirty. (try 4)
by Adam Martinson April 27, 2011

April 27, 2011

On Tuesday 26 April 18:16:27 Henri Verbeet wrote: > This is mostly the same as the previous version. Yes, it's just rebased. I'm happy to change it however you see fit, but I need to know what you'd like changed and how.

1 0

winealsa.drv: Add mmdevapi driver.
by Joerg-Cyril.Hoehle＠t-systems.com April 27, 2011

April 27, 2011

Andrew, + fmt->Format.nSamplesPerSec = 41100; + fmt->nSamplesPerSec != 41100 && 44100. IIRC, there was an error exactly like this somewhere in the old drivers. But why does your IsFormatSupported only accept 48kHz, 44.1, 22.050, etc.? Do the native drivers behave like this? Is this a reasonable subset such that Wine behaves the same on most HW (disregarding CONTINUOUS_RATE)? dump_fmt + TRACE("cbSize: %u\n", fmt->cbSize); Old Wine code contains several comments about never ever reading cbSize in the WAVE_FORMAT_PCM case because it's a potential read past the structure and may cause a segmentation fault. Is it not a valid concern anymore? WAVEFORMATEX contains the cbSize slot. However if the winmm:wave* functions pass through their argument to mmdevapi, it may well end up to be the smaller PCMWAVEFORMAT only. IsFormatSupported MSDN says that CoTaskMemFree will be used to free the output variable ppClosestMatch. Wine uses clone_format=>HeapAlloc to allocate it. Does CoTaskMemFree match HeapAlloc? I'd have expected CoTaskMemAlloc, but I've never used these OLE functions. + switch(fmt->wBitsPerSample){ + case 64: + if(!snd_pcm_format_mask_test(formats, SND_PCM_FORMAT_FLOAT64_LE)){ vs. + if(fmt->wBitsPerSample != 32){ + WARN("Unsupported float size: %u\n", fmt->wBitsPerSample); IsFormatSupported may accept 64 bit fp samples, but Initialize will refuse it. Did you add that code to hear about sound cards that process 64 bits so we know they exist? Regards, Jörg Höhle

3 4

Re: wined3d: Track when the FBO is dirty. (try 4)
by Adam Martinson April 27, 2011

April 27, 2011

On Wednesday 27 Apr 2011 01:19:51 Stefan Dösinger wrote: > > > On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as > WINED3DZB_TRUE.\n", > > stateblock->state.render_states[WINED3DRS_ZENABLE]); > > + /* falltrough */ > > + case WINED3DZB_TRUE: > Please provide a test for this. Will do, but this is for http://source.winehq.org/patches/data/73534 not http://source.winehq.org/patches/data/73533.

2 1

Re: wined3d: Track when the FBO is dirty. (try 4)
by Henri Verbeet April 27, 2011

April 27, 2011

This is mostly the same as the previous version.

2 1

Question on Conformance Test
by Joerg-Cyril.Hoehle＠t-systems.com April 27, 2011

April 27, 2011

Hi, James McKenzie wrote: >I realize that WindowsNT 4.0 is our base configuration IMHO that doesn't matter. Winecfg's default changed from w95 to w2k to xp while I was looking. >What would be the BEST method of annotating this: >ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); >or: >ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); You judge: - If you feel both results are quite logical, use ||. - I've used broken() to document which values Wine shall *not* return. That's IMHO an underestimated use of broken(). - OTOH, I've used || specifically when I thought Wine might/should perhaps change behavior in the future, such that no future patch would be needed to turn GetLastError() == WINXP_ERROR || broken(GetLastError() == WINNT40_ERROR) into broken(GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR - ... which never prevented me from writing todo_wine ok(broken(NT.../*what Wine returns today*/) || XP /*what I want it to return*/, ... (rather than that, put broken last). Regards, Jörg Höhle

1 0

Re: wined3d: Track when the FBO is dirty. (try 4)
by Stefan Dösinger April 27, 2011

April 27, 2011

On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as WINED3DZB_TRUE.\n", > stateblock->state.render_states[WINED3DRS_ZENABLE]); > + /* falltrough */ > + case WINED3DZB_TRUE: Please provide a test for this.

1 1