October 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

Getting Wine's PO files on Launchpad
by Francois Gouget Jan. 20, 2012

Jan. 20, 2012

Launchpad has a PO file translation website. This makes it easier for non-developpers to contribute and review translations. https://translations.launchpad.net/ So what would it take to get Wine's PO files on Launchpad? * Launchpad tracks who translated what string and if we choose the 'Closed' permissions model only approved translators can update the translations. So that means we should be able to get patches with full attribution. https://help.launchpad.net/Translations/YourProject/PermissionPolicies * Launchpad would need to pull updated PO files from Wine regularly. Ideally that would be automatic and happen daily (both to account for translations happening outside Launchpad and to take changes in the resource files into account quickly). https://help.launchpad.net/Translations/YourProject/ImportingTranslations * Conversely Launchpad should submit patches back to Wine. Ideally that would be automated as much as possible but I'm fuzzy on the details here (especially on how to preserve attribution). As for the periodicity, maybe the best would be weekly or just before Alexandre makes a release. https://help.launchpad.net/Translations/YourProject/Exports https://help.launchpad.net/Translations/YourProject/PartialPOExport -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

8 10

crypt32: Cryptic string resources
by Francois Gouget Jan. 17, 2012

Jan. 17, 2012

Are these strings seem to be lacking spaces a bit. Are they real names or mere identifiers? Are they actually translatable? dlls/crypt32/crypt32.rc: IDS_SPC_SP_AGENCY_INFO "SpcSpAgencyInfo" IDS_SPC_FINANCIAL_CRITERIA "SpcFinancialCriteria" IDS_SPC_MINIMAL_CRITERIA "SpcMinimalCriteria" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.

3 3

Updated Clang static analysis results / Valgrind update
by Austin English Dec. 5, 2011

Dec. 5, 2011

Web space usage was getting a bit high, so I've uploaded a tarball to a file download service: http://www.sendspace.com/file/5hot36 austin(a)aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 to use, just extract and open in your favorite browser: $ firefox index.html this was run against Clang from svn: clang version 3.0 (trunk 134320) Please send me any false positives that you'd like me to report upstream. Cheers, Austin P.S. For those of you wanting Valgrind results, I'm currently hitting a nasty Valgrind bug, waiting on upstream to fix: https://bugs.kde.org/show_bug.cgi?id=275673 (Thanks to Andrew N for finding the faulty commit)

4 7

Re: [3/4] d3d9/tests: Test partial block locks
by Henri Verbeet Oct. 31, 2011

Oct. 31, 2011

On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + case D3DPOOL_SCRATCH: > + case D3DPOOL_SYSTEMMEM: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > + D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.

2 1

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.
by Stefan Dösinger Oct. 31, 2011

Oct. 31, 2011

On Monday 31 October 2011 19:48:12 Henri Verbeet wrote: > --- > dlls/ddraw/surface.c | 3 +++ > dlls/wined3d/surface.c | 11 +++++++++++ > include/wine/wined3d.h | 1 + > 3 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3860959..567d086 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5273,6 +5273,9 @@ HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl > *surface, IDirectDrawImpl *ddr if (desc->ddsCaps.dwCaps & DDSCAPS_ZBUFFER) > usage |= WINED3DUSAGE_DEPTHSTENCIL; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_OWNDC) > + usage |= WINED3DUSAGE_OWNDC; You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Probably ddrawex should do that since it sets DDSCAPS_OWNDC, assuming that IE 8 still uses ddrawex. > + /* Similar to lockable rendertargets above, creating the DIB section > + * during surface initialization prevents the sysmem pointer from > changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Otoh we don't really want to create a DIB section for every sysmem surface, especially with bug 5535 in mind.

2 2

Re: [4/4] wined3d: YUY2 and UYVY are block based
by Marvin Oct. 31, 2011

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

1 0

Re: [3/4] d3d9/tests: Test partial block locks
by Marvin Oct. 31, 2011

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

1 0

Re: ddraw/tests: Move some surface attachment tests from refcount to dsurface and enhance them.
by Marvin Oct. 31, 2011

Oct. 31, 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=15183 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WXPPROSP3 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WVISTAADM (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K8SE (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PRO (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a

1 0

Re: [4/4] wined3d: YUY2 and UYVY are block based
by Henri Verbeet Oct. 31, 2011

Oct. 31, 2011

On 31 October 2011 20:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > {WINED3DFMT_ATI2N, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, 0, > GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > - WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_COMPRESSED, > GL_COMPRESSED_RED_GREEN_RGTC2 is also compressed.

1 0

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.
by Josh Juran Oct. 31, 2011

Oct. 31, 2011

On Oct 31, 2011, at 11:48 AM, Henri Verbeet wrote: > --- > dlls/wined3d/buffer.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c > index 45518cc..69c110a 100644 > --- a/dlls/wined3d/buffer.c > +++ b/dlls/wined3d/buffer.c > @@ -76,9 +76,9 @@ static inline void buffer_clear_dirty_areas(struct wined3d_buffer *This) > This->modified_areas = 0; > } > > -static inline BOOL buffer_is_dirty(struct wined3d_buffer *This) > +static BOOL buffer_is_dirty(const struct wined3d_buffer *buffer) > { > - return !!This->modified_areas; > + return !!buffer->modified_areas; > } > > static inline BOOL buffer_is_fully_dirty(struct wined3d_buffer *This) > -- Looks like you lost an 'inline'. Was that intentional? Josh

2 1

Re: 80199: shdocvw: add a stub for InstallReg_RunDLL
by Dan Kegel Oct. 31, 2011

Oct. 31, 2011

Fails to build here? On Thu, Oct 20, 2011 at 3:51 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/803 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > shdocvw_main.c: In function 'InstallReg_RunDLL': > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [shdocvw_main.o] Error 1 > make: *** [dlls/shdocvw] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().
by Stefan Dösinger Oct. 31, 2011

Oct. 31, 2011

On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: > + if (FAILED(hr = > wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, > + src_level->wined3d_surface, &src_rect, 0, NULL, > WINED3DTEXF_POINT))) Wouldn't wined3d_device_update_surface be a better match? IDirect3DDevice7::Load could probably be handled by wined3d_device_update_texture if it wasn't for color keys/palettes.

2 1

RFC: Make X11 window rect empty for WS_EX_TRANSPARENT windows
by Octavian Voicu Oct. 30, 2011

Oct. 30, 2011

Hi, Attached patch fixes http://bugs.winehq.org/show_bug.cgi?id=28678. The root problem is that X11 windows cannot be made transparent (allowing other windows to draw over them). My approach I to make the X11 window with WS_EX_TRANSPARENT extended style have an empty region. Obviously, this is very hacky and except for very particular cases (like the bug I'm trying to fix) it won't work at all, so this patch is more like a proof-of-concept than a fix. For example, window decorations aren't drawn and not even the window can paint itself. This becomes kind of a recursive question -- how to draw the contents of the window-less window? Can this approach ever work? Any comments or suggestions are welcome. Octavian

1 0

d3dx9_36: Simplify the computation of a 2-adic valuation
by David Adam Oct. 29, 2011

Oct. 29, 2011

Hello, please discard this patch. It is logically wrong. David

1 0

Re: cmd: Avoid mixing signed and unsigned type in conditional expression
by Eric Pouech Oct. 28, 2011

Oct. 28, 2011

why do we check for ptr being null or not, when we deref ptr one line above ? something's wrong in the code logic A+ Le 27 octobre 2011 04:53, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > --- > programs/cmd/wcmdmain.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c > index 56aa85f..1bcc598 100644 > --- a/programs/cmd/wcmdmain.c > +++ b/programs/cmd/wcmdmain.c > @@ -278,7 +278,7 @@ static void WCMD_output_asis_handle (DWORD std_handle, > const WCHAR *message) { > ptr++; > }; > if (*ptr == '\n') ptr++; > - WCMD_output_asis_len(message, (ptr) ? ptr - message : > strlenW(message), handle); > + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : > strlenW(message), handle); > if (ptr) { > numChars = 0; > if (++line_count >= max_height - 1) { > -- > 1.7.7.1 > > > > -- -- Eric Pouech

3 4

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)
by Alexandre Julliard Oct. 28, 2011

Oct. 28, 2011

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +/* Max ATR size defined by ISO-7816 */ > +#define MAX_ATR_SIZE 33 I don't see that one in my PSDK, where does it come from? -- Alexandre Julliard julliard(a)winehq.org

3 3

kernel32: Update English resource
by Ken Sharp Oct. 28, 2011

Oct. 28, 2011

I suspect this is the wrong way to update the US English resource for an .mc file. Could anyone comment? Thanks

1 0

basic_ifstream implementation
by Josh Juran Oct. 28, 2011

Oct. 28, 2011

I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. http://bugs.winehq.org/show_bug.cgi?id=28612 First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Josh

4 5

Antw.: signal_arc.c failing to cross-compile
by André Hentschel Oct. 28, 2011

Oct. 28, 2011

Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. Gesendet mit meinem HTC ----- Reply message ----- Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Betreff: signal_arc.c failing to cross-compile Datum: Fr., Okt. 28, 2011 06:46 Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: ntdll: Make the VirtualProtect tests pass under Wine. Resend.
by Alexandre Julliard Oct. 28, 2011

Oct. 28, 2011

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Updated to current git. > --- > dlls/kernel32/tests/virtual.c | 16 ---------------- > dlls/ntdll/virtual.c | 3 +++ > 2 files changed, 3 insertions(+), 16 deletions(-) This completely breaks Wine here. There are several places where we use WRITECOPY for protections, they would have to be fixed first. -- Alexandre Julliard julliard(a)winehq.org

1 0

signal_arc.c failing to cross-compile
by Roger Cruz Oct. 28, 2011

Oct. 28, 2011

Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: winscard/tests: Add the tests file
by Marvin Oct. 26, 2011

Oct. 26, 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=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006

2 1

re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)
by Dan Kegel Oct. 26, 2011

Oct. 26, 2011

Hi Bernhard, build fails here: widl.o: In function `write_dlldata': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:423: undefined reference to `write_dlldata_list' widl.o: In function `main': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:781: undefined reference to `write_dlldata_list' http://winehq.org:8010/builders/runtests-default/builds/106 Also, patch 2/3 doesn't apply: error: patch failed: Make.rules.in:20 error: Make.rules.in: patch does not apply http://winehq.org:8010/builders/runtests-default/builds/107

2 2

Re: [PATCH 2/2] d3dx9/test: Fix typo.
by Marvin Oct. 26, 2011

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

1 0

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h
by Jacek Caban Oct. 26, 2011

Oct. 26, 2011

Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote: > --- > include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- > 1 files changed, 91 insertions(+), 91 deletions(-) > > diff --git a/include/d3d9caps.h b/include/d3d9caps.h > index 8ed6598..64dba21 100644 > --- a/include/d3d9caps.h > +++ b/include/d3d9caps.h > @@ -29,13 +29,13 @@ > #define D3DCURSORCAPS_LOWRES 2 > > > -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L > -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L > -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L > -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L > -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L > -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L > -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L > +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 > +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 > +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 > +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 > +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 > +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 > +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 > mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek

5 7

Re: [PATCH 1/2] d3dx9: Improve argument check in D3DXFindShaderComment().
by Marvin Oct. 26, 2011

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

1 0

winealsa: 6 Channel Audio
by Joerg-Cyril.Hoehle＠t-systems.com Oct. 26, 2011

Oct. 26, 2011

Hi, Andrew Eikum wrote: > > A configuration option (in winecfg/control panel) [...] > My reaction to this is "urrrrrrrghhhhhhh". >Tucking stuff away in the registry makes it a pain to screw >up their config, which means they'll probably turn to submitting bug >reports with the default config first, which is exactly what I want. Interesting wish. Somehow understandable, however ... Currently I see the winecfg as the only viable solution to the issue that we (at least I) don't know how to get the best default parameters. E.g. dmix prefers 48000Hz but this is settable somewhere in /etc/alsa or /usr/share/alsa PA seems to use 44100 on my system (and I'm wondering whether PA may end up using dmix as back-end, involving some resampling from 44100 to 48000?!?) All of them will happily accept any rate and resample. I don't know how to get hw:0's preferred rate short of disabling resampling, which will cause compatibility trouble (perhaps open hw:0 twice, once without resampling to investigate the bare bones, then with resampling which is what Wine needs for its operations). >GetMixFormat(). For example, >it should really be a per-device (and therefore per-backend) setting. Huh? it's already dependent on This->pcm_handle, hence the backend. IMHO we need enumeration tests to verify that GetMixFormat exists for every mmdevapi device. Conceptually IMHO, GetMix is all about a mixer. I don't believe MS provides N mixers, rather than one for each of "Default Voice output channel" and "Multimedia output" and perhaps "Comm output" -- should these be different. That's 1-3. OTOH, it's possible that it supplies on-demand mixing services for every mmdevapi backend, e.g. the poor built-in speaker, on-board audio and distinct 5:1 PCI card. Can an app open any device in shared (=mixer) mode, even when it's not one of the default devices? It's quite logical that there's a control panel in Windows Vista-7. Their users must be able to define which is their default (preferred) voice, multimedia and comm output card, and possibly how their 5/7:1 speakers are positioned. Ideally, Wine should detect whether ALSA has a distinct (and working) "surround" or "5.1" output device, use that and detect (or map) its speaker configuration. >Apparently ALSA is capable of handling up to 10,000 channels The message means nothing more than that dmix will accept upto 10000 channels and map that somehow to the underlying device. Not unlike that systematic test performed by a German guy IIRC about channel mapping on MS, where 1-6 channels were also accepted and distributed somehow to the existing speakers. Regards, Jörg Höhle

1 0

D3DXCreatePolygon
by paulo lesgaz Oct. 26, 2011

Oct. 26, 2011

Hello, any problem with my D3DXCreatePolygon patch? Thanks in advance. David

2 1

Re: Wine's configure script when cross-compiling
by Roger Cruz Oct. 26, 2011

Oct. 26, 2011

Hi Dan, So far that autoconf script has been a nightmare. It doesn't include string.h (where strerror.h is defined) directly BUT I did include unistd.h in order to get autoconf to find getpagesize(). I'm building under the Android development which uses GCC for cross-compiling for ARM. I decided to continue making progress on my project by taking autoconf's output (config.h) and hand tweaking the #define HAVE_xxx functions that I know the cross-compile environment provide. I get a lot farther now but a new error arises, for which I have no clues yet on how to fix. make[1]: Entering directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/acledit -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o main.o /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/main.c /home/rcruz/sandbox/wine-builds/wine32-dev/tools/winegcc/winegcc -b arm-linux-androideabi -B/home/rcruz/sandbox/wine-builds/wine32-dev/tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a ../../dlls/winecrt0/libwinecrt0.a(dll_entry.o): In function `__wine_spec_dll_entry': /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:42: undefined reference to `_fini' /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:37: undefined reference to `_init' /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: acledit.dll.so: hidden symbol `_init' isn't defined /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: arm-linux-androideabi-gcc failed make[1]: *** [acledit.dll.so] Error 2 make[1]: Leaving directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' ________________________________ From: Dan Kegel <dank(a)kegel.com> To: wine-devel(a)winehq.org Cc: roger_r_cruz(a)yahoo.com Sent: Wednesday, October 26, 2011 12:49 AM Subject: re: Wine's configure script when cross-compiling Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

re: Wine's configure script when cross-compiling
by Dan Kegel Oct. 25, 2011

Oct. 25, 2011

Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

Wine's configure script when cross-compiling
by Roger Cruz Oct. 25, 2011

Oct. 25, 2011

I'm still attempting to cross-compile Wine to ARM and I'm running into many compile errors right off the bat. I have tracked these down to the lack of HAVE_xxx in the config.h file generated from configure script. Many of the functions being checked from this list fail when they are compiled by ac_fn_c_check_func () for ac_func in \ _finite \ _isnan \ _pclose \ _popen \ ... snprintf \ spawnvp \ statfs \ statvfs \ strcasecmp \ strdup \ strerror \ One example of a failure is strerror which does not compile because it is missing one argument conftest.c:165: error: too few arguments to function 'strerror' The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? int main () { return $2 (); ; return 0; } Thanks in advance Roger R. Cruz

1 0

Regression testing breakthrough
by Damjan Jovanovic Oct. 25, 2011

Oct. 25, 2011

Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during "reverse regression testing"), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. "configure" takes at least 40 seconds, without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows "make" to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow "configure", only "make". It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic

12 22

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Alex Henrie Oct. 25, 2011

Oct. 25, 2011

Hello, Last week I submitted a patch to make kernel32 output an error message in UTF-8 rather than the current codepage. This fixed a bug in which the command "wine /." would produce a garbled error message in languages other than English. However, thinking about this some more, I'm not sure that my patch fixes the bug correctly. I made WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more about the codepage setting, I think I should have used either CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? -Alex

2 1

Re: [PATCH 2/5] d3d8/tests: Add a small test for multisampled CopyRects().
by Francois Gouget Oct. 25, 2011

Oct. 25, 2011

commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Oct 19 22:03:11 2011 +0200 d3d8/tests: Add a small test for multisampled CopyRects(). This commit causes the d3d8:visual to crash on my desktop (Debian Testing, 9600GT, 285.05.09-1 proprietary driver): wine: Unhandled stack overflow at address 0x7e3ab8bf (thread 0009), starting debugger... err:seh:setup_exception_record stack overflow 1100 bytes in thread 0009 eip 7ef8952b esp 00240ee4 stack 0x240000-0x241000-0x340000 The call that causes the crash is: hr = IDirect3DDevice8_CopyRects(device, rt, NULL, 0, readback, NULL); The stack trace seems to point towards an out of hand recursion problem that eventually causes a stack overrun: Backtrace: =>0 0x7e3a7a32 d3dfmt_get_conv+0x12(surface=0x161728, need_alpha_ck=0x1, use_texturing=0x1, format=0x242074, convert=0x24210c) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:4372] in wined3d (0x00242018) 1 0x7e3b05ee surface_load_texture+0xcd(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5953] in wined3d (0x00242128) 2 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242258) 3 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242388) 4 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242498) 5 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x002425c8) 6 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002426f8) 7 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242808) 8 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242938) 9 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242a68) 10 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242b78) 11 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242ca8) 12 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242dd8) 13 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242ee8) 14 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243018) 15 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00243148) 16 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00243258) 17 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243388) 18 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002434b8) 19 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x002435c8) [...] -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

1 0

D3DXCreatePolygon
by David Adam Oct. 25, 2011

Oct. 25, 2011

Any problem with my D3DXCreatePolygon patch? Thanks in advance. David

1 0

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]
by Alexandre Julliard Oct. 24, 2011

Oct. 24, 2011

Thomas Faber <thfabba(a)gmx.de> writes: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. > The patch fixes riched20 to correctly handle either behavior by > adding a fast path for cx <= 0 (the function obviously needs to return 0 in > the cx == 0 case too, so it can skip the calculation). You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: riched20: explicitly cast WPARAM to character types
by Michael Stefaniuc Oct. 24, 2011

Oct. 24, 2011

On 10/22/2011 10:38 PM, Thomas Faber wrote: > This makes the use of casts more consistent and shows the conversion > from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. > Also fixes two MSVC warnings. To make it consistent remove the WCHAR cast 3 lines above. Casts are *not* there to show a conversion is intentional. They tell the compiler to STFU and to the human reader they mean "*WARNING* doing something odd here". So don't cry wolf when there's no wolf in sight. No clue anyway why MSVC even warns, integer to integer conversions are allowed. If you still want to get rid of those warnings the fix would be to change the type of charCode to WCHAR. To correctly unmarshal the WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). bye michael

3 2

Re: [PATCH 4/5] wined3d: Refuse to create a D3D10 wined3d device if it is not supported by the GPU.
by Henri Verbeet Oct. 24, 2011

Oct. 24, 2011

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (wined3d->dxVersion >= 10 && (shader_caps.VertexShaderVersion < WINED3DVS_VERSION(4,0) > + || shader_caps.PixelShaderVersion < WINED3DPS_VERSION(4,0))) This should probably be handled in dxgi_device_init().

1 0

Re: [PATCH 2/5] d3d9: Limit VS/PS reported version.
by Henri Verbeet Oct. 24, 2011

Oct. 24, 2011

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(3,0)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(3,0); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(3,0)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(3,0); > + This should probably go into filter_caps().

1 0

Re: [PATCH 1/5] d3d8: Limit VS/PS reported version.
by Henri Verbeet Oct. 24, 2011

Oct. 24, 2011

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4); > + fixup_caps() should already do this.

1 0

Re: [PATCH 5/7] msxml3: Make positions returned by ISAXLocator compatible with msxml6
by Nikolay Sivov Oct. 24, 2011

Oct. 24, 2011

On 10/24/2011 14:55, Piotr Caban wrote: > --- > dlls/msxml3/factory.c | 8 ++++- > dlls/msxml3/msxml_private.h | 1 + > dlls/msxml3/saxreader.c | 62 > +++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 64 insertions(+), 7 deletions(-) > > > > static ClassFactory saxreadcf = { {&ClassFactoryVtbl }, SAXXMLReader_create }; > +static ClassFactory saxread6cf = { {&ClassFactoryVtbl }, SAXXMLReader6_create }; > static ClassFactory httpreqcf = { {&ClassFactoryVtbl }, XMLHTTPRequest_create }; Such version dependent behaviour is handled currently with additional argument of MSXML_VERSION enum type. It's better to do it the same way in SAX too, to be consistent.

1 0

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.
by Matteo Bruni Oct. 24, 2011

Oct. 24, 2011

Hi Michael, + for (i = 0; declaration1[i].Stream != 0xff; i++) + { + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) Doesn't that loop need to stop at the first end marker of either declaration? I.e. may the first vertex declaration be longer than the second one?

2 2

winealsa: 6 Channel Audio
by Jonathan McCrohan Oct. 24, 2011

Oct. 24, 2011

Hi, Using foobar2000 (Wine 1.3.31) to output 6 channel audio via WASAPI, I get an error in foobar2000, and the following Wine errors in the terminal: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels However, when using a patched version of Wine with hardcoded support for 6 channel audio, foobar2000 6 channel audio works correctly (patch attached). While this works, it is just a hack and doesn't fix the underlying issue; the additional 9,994 audio channels. This also merely just changes the error message from 2s channel to 6 channels: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 6 channels Would someone with a better knowledge of Wine and/or ALSA be able to assist me in tracking down the source of this bug? Thanks, Jonathan

3 4