August 2015 - 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

Speed of gdi vs opengl DirectDrawRenderer
by Jonas Maebe Oct. 11, 2015

Oct. 11, 2015

Hi, I had a problem with Majesty Gold HD running at glacial speed on my machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5). I'm using wine 1.7.35, but I've had similar problems with older wine versions. It's a DirectDraw7 game that has been partially remastered to run on modern systems, but still uses DirectDraw7. This is a common problem on Windows too, but generally can be resolved by telling the game to use the DirectDraw blitter (instead of blitting itself). That didn't help on Wine though. I profiled wine (Instruments time profile) and noticed that most time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing that routine with an optimized sse2 version from pixman did not make much of a difference. Then I discovered that if I told the game to render to a 16 bit instead of to a 32 bit surface, wine would let OpenGL handle the colour conversion. Unfortunately, while this significantly reduced wine's cpu usage, it by no means made the game any faster. Looking at the OpenGL Driver Monitor stats, it seems the cpu was simply waiting all the time on the GPU, probably while it was blitting all of those 1920x1080 images to the screen. Reducing the resolution to the lowest supported by the game (800x600) made it slightly faster, but not much. Next, I added the DirectDrawRenderer registry key and set it to gdi. Now, while it's still slow at 1920x1080, the game runs much faster at 800x600 and even still at 1024x768. Profiling the gdi renderer shows that it has way higher cpu usage than the OpenGL renderer (virtually all in convert_to_8888), but it seems that for some reason it has causes much less traffic to the GPU. The wiki's wording suggests the gdi renderer is deprecated though. Does that mean this qualifies as a bug in the OpenGL renderer (maybe it tries to update the screen more often than necessary, saturating the bus that way?), and are there any things I can try to narrow down why the gdi renderer is so much faster? I didn't immediately see where it blits things actually to the screen. Thanks, Jonas

4 10

Migrating away from Sourceforge
by Austin English Sept. 29, 2015

Sept. 29, 2015

Howdy all, I noticed there was some discussion of this on #winehackers a week or two ago, but I haven't seen any formal discussion about it. Given SourceForge's recent activities [1] [2] with taking over open source projects for their own gain, I propose that we migrate away from SourceForge. The main uses for SourceForge is for mirroring tarballs, wine-gecko/wine-mono installers, and the wine-gecko git repository. @Jeremy, would it be feasible for winehq's (existing) servers to handle the additional load? [1] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… [2] http://www.extremetech.com/computing/206687-sourceforge-accused-of-hijackin… -- -Austin

14 22

Re: [PATCH 2/2] ucrtbase: Make the strtod implementation C99 compatible
by Piotr Caban Sept. 21, 2015

Sept. 21, 2015

On 08/30/15 22:47, Martin Storsjo wrote: > @@ -339,6 +341,38 @@ static double strtod_helper(const char *str, char **end, MSVCRT__locale_t locale > } else if(*p == '+') > p++; > > +#if _MSVCR_VER >= 140 > + if(p[0] == '0' && tolower(p[1]) == 'x') { > + char *e; > + MSVCRT_long val = sign*MSVCRT_strtol(p, &e, 16); This will not work for doubles > LONG_MAX. It will also not work if specified hexadecimal value has dot, e.g.: strtod("0x1.1p+1") = 2.125 Thanks, Piotr

2 1

Prep for Wineconf - testing
by Jeremy White Sept. 17, 2015

Sept. 17, 2015

Hi folks, Now that I have my room booked, my thoughts turn to what we'll actually do at Wineconf. And, of course, a Wineconf tradition is for me to lock everyone in the room, away from the bar, until the test situation improves. Sadly, despite the best efforts of some people (yay, Huw!), we are still staring at a range of test failures on Windows. It looks like we've got XP and 2003 starting to show green, and 2000 and 2008 look tantalizingly close. Looks like msi timeouts remain a problem. We had some discussion of throwing some hardware at the problem; I'm happy to do that, but, afair, it wasn't clear that it would help. Weren't we going to run an experiment by setting the run queue size to 1 to see if that prevented the msi timeout failures? If changing the run queue size from n to 1 and buying n machines will 'fix' this, maybe it's time to do that. I seem to recall that Francois needed cooperation from Alexandre to run that experiment - is that right? Once we think we've got robust Windows tests, then we move on to pursuit of the the holy grail - having at least two Linux machines capable of running make test cleanly. (I recall a glorious day when we achieved that; sadly, that moment didn't last :-/). So does it make sense to ask people to start daily winetest runs so we can populate a bit more data? Looks like we've got the CodeWeavers test boxes, and one from Austin. And I don't see any for Mac :-(. Cheers, Jeremy

7 16

Re: [website] Update Debian downloads info
by Jeremy Newman Sept. 11, 2015

Sept. 11, 2015

Patch looks good. We will also need to update all the other languages and put in a redirect for the /downloads/debian page to the regular downloads page. -N On 07/22/2015 01:43 PM, Rosanne DiMesio wrote: > Updates the Debian links on the Downloads page to point to packages.debian.org and deletes the obsolete WineHQ Debian downloads page. > > > >

8 18

Re: po: Update German translation.
by Florian Pelz Sept. 5, 2015

Sept. 5, 2015

Sorry for sending to the wrong list. On 08/28/2015 03:03 PM, Florian Pelz wrote: > On 08/28/2015 02:35 PM, Julian Rüger wrote: >> +"Wine Anwendungsentferner\n" > > This needs a hyphen ("Wine-Anwendungsentferner\n"). >

4 10

Re: [PATCH 1/2] vcruntime140: Add the new MSVC 2015 compiler specific DLL.
by Alexandre Julliard Sept. 1, 2015

Sept. 1, 2015

Martin Storsjo <martin(a)martin.st> writes: > Since MSVC 2015/Windows 10, the C runtime has now been split into two > parts, ucrtbase, which is the generic C runtime which is now considered > a system component, and vcruntimeX which is specific to the compiler > version. > > Even if this DLL only has a fraction of the functions of the full > msvcrt/ucrtbase, it still requires almost all the object files from > msvcrt. It would be better to isolate the corresponding code so that we don't need all the files. -- Alexandre Julliard julliard(a)winehq.org

2 2

RFC: New dependency on FFmpeg?
by Andrew Eikum Aug. 31, 2015

Aug. 31, 2015

I have a working implementation of the new xaudio2 API in my tree. Microsoft is treating it as a replacement for dsound[1], and as a result, this new API is used by lots of recent games; see Bug 26808[2] for some examples. Most games that use the xaudio2 API use a version of Microsoft's WMA codec. Wine doesn't currently have the ability to decode this audio for playback. In order for the xaudio2 implementation to be useful for most games, we'll need some way to convert it. I chose to use the FFmpeg library to decode WMA audio. This means for most games, Wine's built-in xaudio2 will require that the 32-bit FFmpeg library be available on the system to successfully play audio. The new code only uses the audio decoding features of FFmpeg, specifically linking only against libavcodec and libavutil. The newest APIs that we use were introduced in 2013. Most of the rest date from 2011 and a few from 2002. FFmpeg's API isn't stable, but I don't expect much maintenance burden from the small piece that we're using. An additional complication is the libav fork. The APIs that we're using are currently unchanged between FFmpeg and libav, so libav should function as a drop-in replacement. Further, distros seem to be migrating back to FFmpeg, if they ever changed. So again, I don't expect this to be a barrier. Wine packagers and developers, do you have any thoughts or objections to depending on FFmpeg/libav's libavutils and libavcodec for xaudio2 support? [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ee415813%28v=vs.85… [2] https://bugs.winehq.org/show_bug.cgi?id=26808 Thanks, Andrew

7 17

Re: [PATCH 2/4] ntdll: Fix read_directory_getdirentries().
by Ken Thomases Aug. 31, 2015

Aug. 31, 2015

On Aug 27, 2015, at 2:08 PM, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > > --- > The man page for getdirentries mentions that only positions previously > returned from lseek or getdirentries should be used, I'm arguably abusing > the pointer to store the index and then restoring the position using > SEEK_CUR. It seems to work fine for me, not sure if that might cause > issues with some specific filesystem setups. You're not restoring it, you're setting it to a computed value. The computation assumes that the file position is the index of the entry that was read. For example, you get the current position and then you're setting the position to that original position minus 2 (for the synthesized . and .. entries). That doesn't seem like a reasonable assumption to me. In some quick testing (with different code), I get results like these: rc 8172 base 0/0x00000000 filepos 469762300/0x1c0000fc entries 252/0x000000fc total 252/0x000000fc rc 8188 base 469762300/0x1c0000fc filepos 469762640/0x1c000250 entries 340/0x00000154 total 592/0x00000250 rc 2364 base 469762640/0x1c000250 filepos 469762732/0x1c0002ac entries 92/0x0000005c total 684/0x000002ac The file positions seem to be 0x1c000000 with the entry index added to it. However, each run of my test program gives a different fixed baseline. The file positions are definitely not _just_ entry indices. It does seem to work to seek to an entry index in some quick testing, but it makes me very nervous. > --- > dlls/ntdll/directory.c | 143 ++++++++++++++++++------------------------------- > 1 file changed, 53 insertions(+), 90 deletions(-) > > diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c > index f9562d2..eb6cd45 100644 > --- a/dlls/ntdll/directory.c > +++ b/dlls/ntdll/directory.c > @@ -1820,27 +1820,27 @@ static int read_directory_getdirentries( int fd, IO_STATUS_BLOCK *io, void *buff > BOOLEAN restart_scan, FILE_INFORMATION_CLASS class ) > { > long restart_pos; > - ULONG_PTR restart_info_pos = 0; > - size_t size, initial_size = length; > - int res, fake_dot_dot = 1; > - char *data, local_buffer[8192]; > + off_t newcursor; This newcursor variable is only ever set and then never used. > + int total, res, i; > + char data[8192]; > struct dirent *de; > - union file_directory_info *info, *last_info = NULL, *restart_last_info = NULL; > + union file_directory_info *info, *last_info = NULL; > > - size = initial_size; > - data = local_buffer; > - if (size > sizeof(local_buffer) && !(data = RtlAllocateHeap( GetProcessHeap(), 0, size ))) > + io->u.Status = STATUS_SUCCESS; > + > + if (restart_scan) > { > - io->u.Status = STATUS_NO_MEMORY; > - return io->u.Status; > + lseek( fd, 0, SEEK_SET ); > + i = 0; > + } > + else > + { > + i = lseek( fd, 0, SEEK_CUR ); > + lseek( fd, 0, SEEK_SET ); > + newcursor = lseek( fd, i < 2 ? 0 : i - 2, SEEK_CUR ); Here's where you're seeking to an arbitrary position. Also, the last two seeks can be combined (if they were right). That is, seeking to the beginning (0, SEEK_SET) and then seeking relative to the current position is just seeking to the relative position as though it were absolute. > res = 0; > done: > - if (data != local_buffer) RtlFreeHeap( GetProcessHeap(), 0, data ); > return res; This wasn't changed by your patch, but it appears that this function can only return 0 at this point, so it should just do so. res is set to 0 just before the "done" label. All "goto done" statements are immediately preceded by setting res to 0. So, the conflation of "res" with a return value should be eliminated. Setting it to 0 in those various places is unnecessary. Once that's cleared up, I would rename res and total to something like bytes_left and bytes_read, respectively. To me, on my first scan through your patch, I was expecting total to accumulate the total amount read over several iterations. (Not that that would have been useful, but it confused me.) -Ken

2 5

Does wine send window messages without waiting apps to reenter userdll?
by Javier Pimás Aug. 31, 2015

Aug. 31, 2015

Hi! this is a very low-level technical question and my first one to this list so please take with a grain of salt. I'm debugging a 32 bit app in wine 1.6.2, on ubuntu 15.04 64 bits. The app I'm debugging is a smalltalk vm, so it is very possessive with the native stack, synchronization, callbacks and things like that. I'm having a problem that happens in wine and not in windows, and the following thing I describe might be the cause, it's very subtle. The problem is related with non-queued messages, in a loop that calls WaitMessage and does something more if there's a message. When running on windows, WaitMessage blocks the thread until there's something (queued or non-queued). If the message is non-queued, it is not immediately delivered (adding frames to the stack by hand), but windows just awakes the thread and waits it to reenter the OS (or userdll, I guess). I'm not sure if i can trust wine to do the same, or if it awakes the process with a bunch of frames pushed in the stack so that the non-queued message is delivered as if WaitMessage never returned. Here is a small idea of the subtle stack variations: always in windows: | VM Callback | <--- stack top | WndProc context | | .... | | Next userdll call context | <- WaitMessage already returned | VM Callout | | .... | ------------------ never happens in windows (*i think*), possible in Wine?: | VM Callback | <--- stack top | WndProc context | | .... | | WaitMessage context | <--- never returned | VM Callout | | .... | As I said, this is very low-level and subtle. Most apps wouldn't notice the difference, but this is a VM. Is the second layout possible in wine? Thanks for reading! -- Javier Pimás Ciudad de Buenos Aires

4 10

Re: [PATCH 6/7] dxgi: Store parents in textures.
by Henri Verbeet Aug. 31, 2015

Aug. 31, 2015

On 31 August 2015 at 00:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2875,7 +2875,7 @@ static HRESULT CDECL device_parent_surface_created(struct wined3d_device_parent > TRACE("device_parent %p, container_parent %p, surface %p, parent %p, parent_ops %p.\n", > device_parent, container_parent, surface, parent, parent_ops); > > - *parent = container_parent; > + *parent = NULL; > *parent_ops = &d3d10_null_wined3d_parent_ops; > > return S_OK; I don't get what this patch is trying to achieve. For one, the description doesn't quite seem to match what it does. As it is, it looks like an odd mix of making it harder to get at the d3d11 texture from the wined3d surface and some bits that should have been in an earlier patch.

2 2

Re: [PATCH 2/7] wined3d: Return a texture from wined3d_swapchain_get_back_buffer.
by Henri Verbeet Aug. 31, 2015

Aug. 31, 2015

On 31 August 2015 at 00:25, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + wined3d_surface = wined3d_surface_from_resource(wined3d_resource); > surface_impl = wined3d_surface_get_parent(wined3d_surface); This works, but it's a bit silly. You can just use wined3d_resource_get_parent(). > diff --git a/dlls/dxgi/swapchain.c b/dlls/dxgi/swapchain.c > index ce09450..cfc1a09 100644 > --- a/dlls/dxgi/swapchain.c > +++ b/dlls/dxgi/swapchain.c > @@ -152,13 +154,15 @@ static HRESULT STDMETHODCALLTYPE dxgi_swapchain_GetBuffer(IDXGISwapChain *iface, > > EnterCriticalSection(&dxgi_cs); > > - if (!(backbuffer = wined3d_swapchain_get_back_buffer(This->wined3d_swapchain, > + if (!(texture = wined3d_swapchain_get_back_buffer(This->wined3d_swapchain, > buffer_idx, WINED3D_BACKBUFFER_TYPE_MONO))) > { > LeaveCriticalSection(&dxgi_cs); > return DXGI_ERROR_INVALID_CALL; > } > > + resource = wined3d_texture_get_sub_resource(texture, 0); > + backbuffer = wined3d_surface_from_resource(resource); > parent = wined3d_surface_get_parent(backbuffer); > hr = IUnknown_QueryInterface(parent, riid, surface); > LeaveCriticalSection(&dxgi_cs); And here you don't even need the sub-resource, because you want the (d3d11) texture in the first place. I.e., you can just use wined3d_texture_get_parent().

1 0

Re: mciavi32: Add partial support for MCI_DGV_PLAY_REPEAT
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 31, 2015

Aug. 31, 2015

Bruno, >If you ever have time, please take a look. + wma->dwCurrVideoFrame = wma->dwCurrAudioBlock = 0; I'm sorry I'd reject this patch because it's missing integration for the MCI_FROM keyword. Example using MS' clock.avi: OPEN clock.avi alias c WINDOW c State Show ; may still be needed in Wine PLAY c FROM 2 TO 5 repeat should open the window and repeat stepping the clock from 3 to 6 o'clock. (You remember my MCI shell in bugzilla, don't you?) You could argue that there's no need to bother for MCI_FROM, because it's not yet supported with audio output (see mmoutput.c). However, play c FROM x to y currently works with video only output (e.g. clock.avi), thus new patches should at least support what's already in place. BTW (not in your patch): FIXME("Should recompute dwCurrAudioBlock, except unsynchronized sound & video\n"); Typo, should be "expect" Supporting sound with MCI_FROM non-zero would be the matter of another patch for a volunteer... In summary, I believe that a better patch would either add dwFromVideoFrame to WINE_MCIAVI or remember dwCurrentVideoFrame (but see below) at the entrance of MCIAVI_Player and use that. Note that I'd expect any patch to handle this scenario correctly: Play c FROM 2 TO 5 repeat Play c TO 8 repeat In native, the second play would *continue* playing from the current position upto 9 o'clock, then resume from 0 (not 3 o'clock, because 0 is the default FROM value in the second play command). Well, that's probably too much for a single patch, since it would likely require keeping the player thread alive, just changing its start/repeat and end positions, rather than restarting a new one. Regards, Jörg Höhle

2 1

Re: [PATCH] dxgi/tests: Avoid c++ style comment.
by Stefan Dösinger Aug. 31, 2015

Aug. 31, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-30 um 21:59 schrieb Józef Kucia: > - {FALSE, 0, 2 /* undefined */, DXGI_ERROR_INVALID_CALL, DXGI_ERROR_INVALID_CALL, 0}, //30 > + {FALSE, 0, 2 /* undefined */, DXGI_ERROR_INVALID_CALL, DXGI_ERROR_INVALID_CALL, 0}, /*30 */ better to remove those index comments entirely. While they may seem useful on first sight, it's easy for them to become misleading if lines are added / removed / commented out. I'll send my patch, then Henri can chose whatever he likes best. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV44HSAAoJEN0/YqbEcdMwqWMP/35BfDqJhe7KvM5poSHoIq+8 4KbFkdZkfDkRsLBXQsRlFDDME/VXE74rUA55iOA8rhHqfHt4cUEYrjLBxY8mJ2MK FaSb3Vcp+eUxOrXs/mrtIbUq1ZhrqOwFNHQH/1w+dspozxxg0k9WeK+5Tj1sU+Kx J8RycMNn049rqiJ2TGJq9FV+4w8cvrhJH/DO3I8xu+wSMK8SPeGx7QuYiQ2xO4Th IkBLkiOIOwfghn8ehqS4yzWv2333BlUZDAJruUiZ62ISWj1UqZTRMFA0Al4KT+v4 qO+pB/jym9YIqXUKwufi9z4Y0MYM8fADLeW2VLvrp+TiYz8ahp5Ed5UygizHXHRD aIaFu+RoECUoWb7l//RHBfhm3CyEuElP1IBXfLVeNm1WIt2q4EJhICkVBDcgVDaQ ygX4uxmfjW3Iswl/vHJxXM1BlD/ryycoPJ7/FzytFBzvUH/q6XX+45+NpmtfV5ZR wa6hk0UjFLdmMgwkP03W315Co4OuUVToQGX+M3vGqqQz2dMZ3tlz0NjGHAg4YUDV 9iUFYjIGtiZBnaz7CVVlsMbf+pVd65D2sxCeGodfDDYV/feek0yHykYY6GDGPzfb vhaL/38ejg24Z704ayk1St12RWX9iaXZkzPbCicWtC0avpYzjA2/WlH/X8TS/FFm lCJBPUM5GioDhUI9oqcp =PvBv -----END PGP SIGNATURE-----

1 1

Re: [PATCH 5/7] d3d8/tests: Add more GetBackBuffer error handling tests.
by Marvin Aug. 31, 2015

Aug. 31, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=16429 Your paranoid android. === w8 (32 bit device) === device.c:1225: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1270: Test failed: Reset failed, hr 0x88760868. device.c:1272: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1276: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1283: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1284: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1285: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1286: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1287: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1288: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1293: Test failed: Screen width is 640, expected 800. device.c:1294: Test failed: Screen height is 480, expected 600. device.c:1300: Test failed: Back buffer width is 640, expected 800. device.c:1302: Test failed: Back buffer height is 480, expected 600. device.c:1332: Test failed: Screen width is 640, expected 1024. device.c:1333: Test failed: Screen height is 480, expected 768. device.c:2580: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2585: Test failed: The focus window is active. device.c:2593: Test failed: Got unexpected hr 0x88760869. device.c:2599: Test failed: Got unexpect screen size 800x600. device.c:2614: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2623: Test failed: Got unexpect screen size 800x600. device.c:2636: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2644: Test failed: Got unexpect width 640. device.c:2645: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 2/2] gdi32: Added GetFontRealizationInfo() export
by Marvin Aug. 31, 2015

Aug. 31, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=16404 Your paranoid android. === wvistau64 (64 bit font) === The test timed out

2 1

Re: [PATCH] shell32: Fix SHFileOperation(FO_MOVE) for creating subdirectories.
by Zhenbo Li Aug. 30, 2015

Aug. 30, 2015

Excuse me, Does anyone knows how patch 113646 can be improved? Thank you very much 2015-08-14 21:18 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > This patch fixes bug 25207. Seems that a dozen of apps are affected by this > bug, so please tell me how I can improve this patch if this patch can't be > committed directly. > > There will be a test error: > shlfileop.c:818: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR > > It is not related to my patch. > > Hope you enjoy your weekend. > > --- > dlls/shell32/shlfileop.c | 11 +++++++++-- > dlls/shell32/tests/shlfileop.c | 6 +++--- > 2 files changed, 12 insertions(+), 5 deletions(-) > > -- Have a nice day! Zhenbo Li

2 2

Can't compile wine-git: initializer element is not constant in d3d11
by Bruno Jesus Aug. 30, 2015

Aug. 30, 2015

Hi all, I have not compiled wine in one about 4 days and now I updated and tried and the results are: ../../../wine/dlls/d3d11/utils.c: In function ‘d3d11_resource_misc_flags_from_d3d10_resource_misc_flags’: ../../../wine/dlls/d3d11/utils.c:473:13: error: initializer element is not constant ../../../wine/dlls/d3d11/utils.c: In function ‘d3d10_resource_misc_flags_from_d3d11_resource_misc_flags’: ../../../wine/dlls/d3d11/utils.c:501:13: error: initializer element is not constant make[1]: ** [utils.o] Erro 1 make[1]: Saindo do diretório `/home/bruno/programs/wine32/dlls/d3d11' make: ** [dlls/d3d11] Erro 2 Is anyone experiencing a similar issue? I already tried make clean && make. Best regards, Bruno

5 8

Re: findstr: Minimal implementation
by Nikolay Sivov Aug. 30, 2015

Aug. 30, 2015

Hi, Mikhail. Some comments: > +static void __cdecl printError(unsigned int id, ...) Why explicit __cdecl? > + WCHAR format[1024]; Here, and everywhere else - please use 4 spaces per indentation level instead of a tab. > + if (!LoadStringW(GetModuleHandleW(NULL), id, format, sizeof(format) / sizeof(format[0]))) I think calling it as LoadStringW(NULL, ...) has same effect. > +int find(WCHAR* patternW, WCHAR* filename) This should be static. > + WideCharToMultiByte(CP_OEMCP, 0, patternW, -1, pattern, patternLen, NULL, NULL); Why OEMCP and not ACP? > + // Latest char, include them to line Please avoid this C99/C++ comment style.

2 1

Re: krnl386.exe16: Avoid shift overflows in DMA_ioport_in.
by André Hentschel Aug. 30, 2015

Aug. 30, 2015

Am 29.08.2015 um 22:51 schrieb Gerald Pfeifer: > Use 0xFFu isntead 0xFF to indicate we are looking at an unsigned > value/constant. > > Gerald > --- I think the change in gcc origins in the fact that there are different shift implementations which vary across cpu architecture. Personally I have ARM in mind which shifts different from x86, so I highly value your work on it.

1 0

How X11 server generate XClientMessageEvent ?
by Changhui LIU Aug. 30, 2015

Aug. 30, 2015

Dear Alexandre, I'm debugging a window set focus problem on Deepin Linux(www.deepin.org), I found some hints in handle_wm_protocols function of winex11.drv. But I feel very strange, I don't find where generate the XClientMessageEvent with event.data.l[0] = x11drv_atom(WM_TAKE_FOCUS) when I git grep WM_TAKE_FOCUS in wine source directory. How X11 server generate XClientMessageEvent with event.type = x11drv_atom(WM_PROTOCOLS) and event.data.l[0] = x11drv_atom(WM_TAKE_FOCUS) ? Thank you! ------------------ Regards, Changhui Liu

2 2