RE: msvcrt: make WEOF returned from swscanf signed
> === WNT4WSSP6 (32 bit scanf) === > scanf.c:257: Test failed: sscanf returns 0 instead of Apparently, msvcrt.dll returns 0 but msvcr90.dll returns -1 for the same arguments. I'll fix and resubmit later (and I'll fix the 'sscanf' to 'swscanf')
Re: msvcrt: make WEOF returned from swscanf signed
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=16267 Your paranoid android. === WNT4WSSP6 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W2KPROSP4 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === WXPPROSP3 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W2K3R2SESP2 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === WVISTAADM (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W2K8SE (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W7PRO (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W7PROX64 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === TEST64_W7SP1 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === W7PROX64 (64 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of === TEST64_W7SP1 (64 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of
Re: D3DXHANDLE for ID3DXConstantTable
2012/1/5 Rico Schüller : > I'm not sure what you mean by a "normal handle table". > > Do you mean a list? > It's pretty much just a table of handles. There are a couple of different variants spread over the Wine source. For example, http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/main.c#l50 is what ddraw uses.
Re: D3DXHANDLE for ID3DXConstantTable
Am 04.01.2012 13:23, schrieb Henri Verbeet: 2012/1/5 Rico Schüller: Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3]. Any thoughts which way is preferred? It's not entirely clear to me from any of those links why simply using a normal handle table wouldn't work. I'm not sure what you mean by a "normal handle table". Do you mean a list? Cheers Rico
Re: FYI: Pangolin script needs libfreeytype6-dev:386 but it cannot be installed
On Wed, Jan 4, 2012 at 07:25, Susan Cragin wrote: > The configure script seems to be looking for > libfreetype6-dev:386 > but this cannot be installed without removing the compilers and other files > Should I alert Ubuntu? Isn't this their problem? Yes. -- -Austin
Re: po: Update Italian translation
2012/1/4 Luca Bennati : > > > #: winmm.rc:34 > -#, fuzzy > msgid "There is no driver installed on your system!" > -msgstr "Non è stato installato nessun driver nel sistema !\n" > +msgstr "Non è presente nessun driver installato nel sistema!" Hi Luca, While your new translation is clearer than the previous one, I think in the new translation "presente" and "installato" mean more or less the same thing i.e. having both is redundant IMO. How about something like "Nessun driver è installato nel sistema!" (or "presente", or "attualmente installato"... you got it) instead?
Re: Any bad side-effects from not building with HAL if udisks is enabled?
Scott Ritchie writes: > Assuming udisks support exists on the system, anything wrong with this? > Does the new udisks do everything HAL used to do? If udisks is present, the HAL support is not used at all. -- Alexandre Julliard julli...@winehq.org
Re: D3DXHANDLE for ID3DXConstantTable
2012/1/5 Rico Schüller : > Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions > are listed in [3]. > > Any thoughts which way is preferred? > It's not entirely clear to me from any of those links why simply using a normal handle table wouldn't work.
D3DXHANDLE for ID3DXConstantTable
Hi, I'd like to get up the discussion for the D3DXHANLE in the ID3DXConstantTable again. There were several tries in the past, but there wasn't made a decision for one solution. My opinion about the handles is, that they have to allow at least the following options: 1. D3DXHANDLEs have to be global (not local to a ID3DXConstantTable), so the way the effect interface does it is not an ideal option for the ID3DXConstantTable 2. D3DXHANDLEs could also be strings and thus it is a requirement that this could be detected (at least for !D3DXCONSTTABLE_LARGEADDRESSAWARE) Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3]. Any thoughts which way is preferred? Cheers Rico References: [1] http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html [2] http://www.winehq.org/pipermail/wine-patches/2011-July/104325.html [3] http://www.winehq.org/pipermail/wine-devel/2011-July/091091.html
FYI: Pangolin script needs libfreeytype6-dev:386 but it cannot be installed
The configure script seems to be looking for libfreetype6-dev:386 but this cannot be installed without removing the compilers and other files Should I alert Ubuntu? Isn't this their problem? Susan
Any bad side-effects from not building with HAL if udisks is enabled?
Assuming udisks support exists on the system, anything wrong with this? Does the new udisks do everything HAL used to do? Thanks, Scott Ritchie
Re: [PATCH 2/7] wined3d: Move srgb checks away from d3dfmt_get_conv.
On 4 January 2012 01:48, Diego Nieto Cid wrote: > After adding the conditional to wine-1.3.33, Fallout runs without any > error. > > A patch against HEAD is attached. > Looks good to me, please send that to wine-patches, perhaps with a small comment. > On Wed, Dec 28, 2011 at 09:17:26PM -0300, Diego Nieto Cid wrote: >> The HEAD checkout is randomly failing due to >> >> wine: Unhandled page fault on read access to 0x at address (nil) >> (thread 0036), starting debugger... >> X Error of failed request: GLXBadDrawable >> Major opcode of failed request: 128 (GLX) >> Minor opcode of failed request: 5 (X_GLXMakeCurrent) >> Serial number of failed request: 621 >> Current serial number in output stream: 621 >> > > HEAD still shows the error above. I'll try to find what happened through > bisection. > > Any idea what to look for? :) > The message suggests it's a glXMakeCurrent() / wglMakeCurrent() call with a bad Drawable / window, perhaps because the window was already destroyed. It might be something along the lines of http://bugs.winehq.org/show_bug.cgi?id=29236, although that bug turned out to be invalid.
Re: imm32: add a stub for ImmGetHotKey
Austin English wrote: > +BOOL WINAPI ImmGetHotKey(DWORD hotkey, UINT modifiers, UINT VKey, HKL hKL) What SDK/MSDN version does this match? Also please avoid using hungarian or capitalized variable names in Wine. > +@ stdcall ImmGetHotKey(long ptr ptr long) This doesn't match the implementation. -- Dmitry.
