February 2008 - Wine-Devel - list.winehq.org

Re: wined3d: fix memcpy with wrong size parameter to simple assignment in GetScissorRect
by Stefan Dösinger Feb. 14, 2008

Feb. 14, 2008

Am Mittwoch, 13. Februar 2008 21:58:39 schrieb Rico Schüller: > Hi, > > this fixes the GetScissorRect function in wined3d. This is required for > the game Gothic3 where the misbehavior is seen. The patch looks ok to me

1 0

Weird failure in kernel32 volume test
by Maarten Lankhorst Feb. 14, 2008

Feb. 14, 2008

Hi all, The latest update of trying to be the second person for which all tests succeed. I sent a bunch of patches that make some tests pass. At the moment I have 3 failures on a clean wineprefix, with no icons on my desktop, and with wine in native window mode on kde 3.5.x: user32: 'msg' test fails. The famous 'win' test passes. kernel32: I get a very weird bug on the 'volume' test. It only occurs when I run my mini script for running the tests. I have absolutely no idea why I get ERROR_FILE_NOT_FOUND on FindFirstVolumeA on the first time I run the whole testsuite, and not successive runs. Anyone has experienced the same, or have an idea what is going on? msi: multi-sz failure in msi install, I did a todo_wine on it so it doesn't stop the build. It seems to be a recent failure though because I know that it didn't bomb out on install a few days ago. Anyone else has some tests that consistently fail on make test? Cheers, Maarten.

4 3

OUTB() and friends on Win32 and .sys files(Resent)
by Uwe Bonnes Feb. 14, 2008

Feb. 14, 2008

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Resend pdh[3:3]: remove unnecessary test done in PdhLookupPerfNameByIndexW
by Hans Leidekker Feb. 14, 2008

Feb. 14, 2008

On Thursday 14 February 2008 09:57:32 am Jeff Latimer wrote: > + machineW = pdh_strdup_aw( machine ); > + > + if (!(ret = PdhLookupPerfNameByIndexW( machineW, index, bufferW, &sizeW ))) In the unlikely event that pdh_strdup_aw fails the query will be run on the local machine instead of the remote machine. Please check for allocation failures like most other functions in there do. -Hans

3 2

[advapi32/tests] Don't crash tests for NT4
by Paul Vriens Feb. 14, 2008

Feb. 14, 2008

Hi, (Deliberately sent here and not to wine-patches). Hopefully someone can shed some light on this. I need this patch to have the security tests not crash on NT4. The part about the missing function is obvious. What is not so obvious though is that when I leave the LocalFree(NewAcl) in, the test crash. If I only do the LocalFree on success (as stated btw on MSDN for this function) this test doesn't crash. AFAIK LocalFree deals with passed NULL pointers so there must be something else going on. Changelog Don't crash tests for NT4 -- Cheers, Paul.

1 0

ddraw / wined3d fighting over the resolution!
by Peter Dons Tychsen Feb. 14, 2008

Feb. 14, 2008

Hi Stefan/Devs. The funny old game "Insane" has a resolution bug when it exits. I am not sure exactly how to fix this. 1) It call SetDisplayMode() - switches from 1280 x 1024 -> 640 x 480. OK. 2) It creates a 3D surface which starts the SwapChain - swapchain saves current resolution. 3) Exit. It calls RestoreDisplayMode() - switches back to 1280 x 1024. OK. 4) SwapChain is destroyed. Switches "back" to 640 x 480 ! BAD! I presume the code guesses that the caller does this in another sequence (and it does work fine in other sequences). Why does the SwapChain-destroy function play around with the resolution at all. Is that really necessary? I think it should not do it if the caller is ddraw at least. How do i fix this? Thanks, /pedro

2 1

Almost done...
by Maarten Lankhorst Feb. 13, 2008

Feb. 13, 2008

Hi all, Right now I got down to only the user32 msg test failing (minus the todo's). I solved the user32 win test with a very high-tech solution: Remove all icons from my desktop, which prevents the stupid file description popup from failing the user32 win test. The other way would be to run it in a wine desktop which would also prevent this (I got no failures on runtest, except the todo's). The msg tests are more difficult. For some reason I accidentally passed them once, when I had the debug scrolling on. But after that there were always failures on my pc. Is there any way to sync those so that it is less prone to timing issues? Cheers, Maarten.

1 0

Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
by Peter Dons Tychsen Feb. 13, 2008

Feb. 13, 2008

OK. I still think he should put a FIXME remark in the test-case, and document why Sleep() is needed. Someone might fix the driver someday. The only reason i yelled "alert!", is that i have seen so much bad code which has come to a state where the are Sleep(143) here and Sleep(1332) there, where nobody can remember why they are there and what the Sleep count represents (most of the time no-one ever knew! :-)). In the mean time, the real bugs just getter harder to find, as they are covered by all the messy Sleeps(). I see allot of this kind of yap in telecom embedded software (mobile phones etc.). In this case Maarten probably knows what he is doing (he usually does). But thanks for the follow up! And now i will go to Sleep(). Thanks, /p On Wed, 2008-02-13 at 11:28 +0100, Stefan Dösinger wrote: > Am Mittwoch, 13. Februar 2008 03:11:24 schrieb Peter Dons Tychsen: > > Eh, this does not seem like a proper way to get a unit test to pass. > > > > Sleep()... that leads to the dark side! :-) > I talked to Maarten on IRC about this. The problem seems to be that his > monitor takes ages to mode switch, but ChangeDisplaySettings returns before > this modeswitch is done. Also the opengl driver attempts to draw before the > setup is ready, which fails and causes the test failures. > > So it sounds like a driver bug which will only affect the tests(since games > draw repeatedly and do not care if the first few frames do not render > properly)

1 0

Re: [PATCH] include: add ISampleGrabber interface
by Lei Zhang Feb. 13, 2008

Feb. 13, 2008

On Feb 13, 2008 3:03 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This patch adds the ISampleGrabber interface, also needed by IMediaDet. > Bah, let me try again. Just realized I forgot to pass -n to git format-patch as well.

1 0

Re: msxml3: Implement IXMLDOMDocument IDispatch interface
by Alistair Leslie-Hughes Feb. 13, 2008

Feb. 13, 2008

Hi, Was there anything wrong with this patch? Dont commit this patch if nothing is wrong. I will submit a series of patches, that will include these changes. Best Regards Alistair Leslie-Hughes "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:fnchqv$a5r$1(a)ger.gmane.org... > Hi, > > Fixes bug http://bugs.winehq.org/show_bug.cgi?id=11257 > > Changelog: > msxml3: Implement IXMLDOMDocument IDispatch interface > > Best Regards > Alistair Leslie-Hughes > -------------------------------------------------------------------------------- > From 7cc5228684ed6d9aaace829cc1b8ebb43e5f4325 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Fri, 25 Jan 2008 22:34:36 +1100 > Subject: [PATCH] Implement IXMLDOMDocument IDispatch interface > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/msxml3/domdoc.c | 53 +++++++++++++++++++++++++++++++++------ > dlls/msxml3/main.c | 58 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/msxml_private.h | 8 ++++++ > 3 files changed, 111 insertions(+), 8 deletions(-) > > diff --git a/dlls/msxml3/domdoc.c b/dlls/msxml3/domdoc.c > index 06388c8..9d6b94b 100644 > --- a/dlls/msxml3/domdoc.c > +++ b/dlls/msxml3/domdoc.c > @@ -416,16 +416,29 @@ static ULONG WINAPI domdoc_Release( > > static HRESULT WINAPI domdoc_GetTypeInfoCount( IXMLDOMDocument2 *iface, > UINT* pctinfo ) > { > - FIXME("\n"); > - return E_NOTIMPL; > + domdoc *This = impl_from_IXMLDOMDocument2( iface ); > + > + TRACE("(%p)->(%p)\n", This, pctinfo); > + > + *pctinfo = 1; > + > + return S_OK; > } > > static HRESULT WINAPI domdoc_GetTypeInfo( > IXMLDOMDocument2 *iface, > UINT iTInfo, LCID lcid, ITypeInfo** ppTInfo ) > { > - FIXME("\n"); > - return E_NOTIMPL; > + domdoc *This = impl_from_IXMLDOMDocument2( iface ); > + HRESULT hr; > + > + TRACE("(%p)->(%u %u %p)\n", This, iTInfo, lcid, ppTInfo); > + > + hr = get_typeinfo(IXMLDOMDocument2_tid, ppTInfo); > + if(SUCCEEDED(hr)) > + ITypeInfo_AddRef(*ppTInfo); > + > + return hr; > } > > static HRESULT WINAPI domdoc_GetIDsOfNames( > @@ -436,8 +449,21 @@ static HRESULT WINAPI domdoc_GetIDsOfNames( > LCID lcid, > DISPID* rgDispId) > { > - FIXME("\n"); > - return E_NOTIMPL; > + domdoc *This = impl_from_IXMLDOMDocument2( iface ); > + ITypeInfo *typeinfo; > + HRESULT hr; > + > + TRACE("(%p)->(%s %p %u %u %p)\n", This, debugstr_guid(riid), > rgszNames, cNames, > + lcid, rgDispId); > + > + if(!rgszNames || cNames == 0 || !rgDispId) > + return E_INVALIDARG; > + > + hr = get_typeinfo(IXMLDOMDocument2_tid, &typeinfo); > + if(SUCCEEDED(hr)) > + hr = ITypeInfo_GetIDsOfNames(typeinfo, rgszNames, cNames, > rgDispId); > + > + return hr; > } > > > @@ -452,8 +478,19 @@ static HRESULT WINAPI domdoc_Invoke( > EXCEPINFO* pExcepInfo, > UINT* puArgErr) > { > - FIXME("\n"); > - return E_NOTIMPL; > + domdoc *This = impl_from_IXMLDOMDocument2( iface ); > + ITypeInfo *typeinfo; > + HRESULT hr; > + > + TRACE("(%p)->(%d %s %d %d %p %p %p %p)\n", This, dispIdMember, > debugstr_guid(riid), > + lcid, wFlags, pDispParams, pVarResult, pExcepInfo, puArgErr); > + > + hr = get_typeinfo(IXMLDOMDocument2_tid, &typeinfo); > + if(SUCCEEDED(hr)) > + hr = ITypeInfo_Invoke(typeinfo, &(This->lpVtbl), dispIdMember, > wFlags, pDispParams, > + pVarResult, pExcepInfo, puArgErr); > + > + return hr; > } > > > diff --git a/dlls/msxml3/main.c b/dlls/msxml3/main.c > index 62bf2b5..41afbe6 100644 > --- a/dlls/msxml3/main.c > +++ b/dlls/msxml3/main.c > @@ -21,6 +21,8 @@ > > #include "config.h" > > +#define COBJMACROS > + > #include <stdarg.h> > #include "windef.h" > #include "winbase.h" > @@ -34,6 +36,61 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(msxml); > > + > +static ITypeLib *typelib; > +static ITypeInfo *typeinfos[LAST_tid]; > + > +static REFIID tid_ids[] = { > + &IID_IXMLDOMDocument2 > +}; > + > +HRESULT get_typeinfo(enum tid_t tid, ITypeInfo **typeinfo) > +{ > + HRESULT hres; > + > + if(!typelib) { > + ITypeLib *tl; > + > + hres = LoadRegTypeLib(&LIBID_MSXML2, 3, 0, LOCALE_SYSTEM_DEFAULT, > &tl); > + if(FAILED(hres)) { > + ERR("LoadRegTypeLib failed: %08x\n", hres); > + return hres; > + } > + > + if(InterlockedCompareExchangePointer((void**)&typelib, tl, NULL)) > + ITypeLib_Release(tl); > + } > + > + if(!typeinfos[tid]) { > + ITypeInfo *typeinfo; > + > + hres = ITypeLib_GetTypeInfoOfGuid(typelib, tid_ids[tid], > &typeinfo); > + if(FAILED(hres)) { > + ERR("GetTypeInfoOfGuid failed: %08x\n", hres); > + return hres; > + } > + > + if(InterlockedCompareExchangePointer((void**)(typeinfos+tid), > typeinfo, NULL)) > + ITypeInfo_Release(typeinfo); > + } > + > + *typeinfo = typeinfos[tid]; > + return S_OK; > +} > + > +static void process_detach(void) > +{ > + if(typelib) { > + unsigned i; > + > + for(i=0; i < sizeof(typeinfos)/sizeof(*typeinfos); i++) > + if(typeinfos[i]) > + ITypeInfo_Release(typeinfos[i]); > + > + ITypeLib_Release(typelib); > + } > +} > + > HRESULT WINAPI DllCanUnloadNow(void) > { > FIXME("\n"); > @@ -53,6 +110,7 @@ BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD > fdwReason, LPVOID lpv) > case DLL_PROCESS_DETACH: > #ifdef HAVE_LIBXML2 > xmlCleanupParser(); > + process_detach(); > #endif > break; > } > diff --git a/dlls/msxml3/msxml_private.h b/dlls/msxml3/msxml_private.h > index 8d79d2e..c7d97a1 100644 > --- a/dlls/msxml3/msxml_private.h > +++ b/dlls/msxml3/msxml_private.h > @@ -91,4 +91,12 @@ extern HRESULT DOMDocument_create( IUnknown *pUnkOuter, > LPVOID *ppObj ); > extern HRESULT SchemaCache_create( IUnknown *pUnkOuter, LPVOID *ppObj ); > extern HRESULT XMLDocument_create( IUnknown *pUnkOuter, LPVOID *ppObj ); > > +/* typelibs */ > +enum tid_t { > + IXMLDOMDocument2_tid, > + LAST_tid > +}; > + > +extern HRESULT get_typeinfo(enum tid_t tid, ITypeInfo **typeinfo); > + > #endif /* __MSXML_PRIVATE__ */ > -- > 1.5.3.7 > > -------------------------------------------------------------------------------- > >

1 0

[PATCH] Environment variable to specify X11 window for desktop
by Timothy Lee Feb. 13, 2008

Feb. 13, 2008

Dear all, The attached patch allows the WINE desktop to be embedded within an existing X11 window, and is similar to the windowed mode in WINE. I've tested this feature using MS PowerPoint Viewer 2007, so that a fullscreen slideshow can be fitted inside any X11 window. Regards, Timothy Lee

2 1

Re: user32: correct the caption bar and it's buttons' sizes
by Peter Oberndorfer Feb. 13, 2008

Feb. 13, 2008

On Mittwoch 13 Februar 2008, Divan Burger wrote: > What is the problem without the patch? is the caption bar drawn too high 1 pixel? I ask because i have a patch that restores the 1 pixel high line between the caption bar and the client area (and at the same time decreases the height of the caption bar) see it attached for the NC_DrawXXXButton functions: you also need to update hittest calculation else the wrong buttons are activated. For example when you press the mouse down on the left side of the close button, but maximize gets activated > case SM_CYCAPTION: > if (!spi_loaded[SPI_NONCLIENTMETRICS_IDX]) load_nonclient_metrics(); >- return nonclient_metrics.iCaptionHeight + 1; >+ return nonclient_metrics.iCaptionHeight; this breaks a test in sysparams.c:2416 ok_gsm( SM_CYCAPTION, ncm.iCaptionHeight+1); and 5 other tests Greetings Peter

1 0

missed systray patches
by Kirill K. Smirnov Feb. 13, 2008

Feb. 13, 2008

Hello, Is there anything wrong with the serie of patches? systray[0/4]: systray improvements [try 2] http://www.winehq.org/pipermail/wine-patches/2008-February/049772.html -- Kirill

1 0

Re: Fixing the last failing tests
by Peter Dons Tychsen Feb. 13, 2008

Feb. 13, 2008

Hello M. What is wrong with detecting the version, and branching the test code accordingly? Other tests do that IIRC. I think that is a better solution, if the version selector in winecfg is still going to be meaningful (registry). How about fixing the functions as well (like IsWindowUnicode), so it returns the correct data according to the version in winecfg (registry). However, i do like the irony in your example :-) /pedro On Tue, 2008-02-12 at 18:09 -0800, Maarten Lankhorst wrote: > Hi all, > > I'm very close to passing the whole wine conformance suite on my pc. > The only tests failing are in user32. These tests are failing in any > version of windows though. How do I make them pass on at least 1 > version of windows and wine? Would patches to make it run on xp and > wine be accepted? > > And if I can succeed with that, how do I make it work with other > versions of windows as well. > > Cheers, > Maarten. > > An example is IsWindowUnicode. It always returns TRUE on XP, but it > won't do that on 9x. That would mean something like: > ok(IsWindowUnicode() || !IsWindowUnicode(), "How can this fail?"); > >

3 2

How is the testsuite built for windows
by Maarten Lankhorst Feb. 13, 2008

Feb. 13, 2008

Hi all, I'm trying to get the tests to run in windows, but I'm not sure how to build them. Any attempt to do mingw cross compiling fails badly. Who managed to compile all wine tests for windows, and how is it done? Cheers, Maarten.

3 2

Re: [PATCH #1] wininet: Added beginning support for HTTP cache files.
by Robert Shearman Feb. 13, 2008

Feb. 13, 2008

Jacek Caban wrote: > + /* FIXME: Better check, when we have to create the cache file */ > + if(bSuccess && (lpwhr->hdr.dwFlags & INTERNET_FLAG_NEED_FILE)) { > + WCHAR url[INTERNET_MAX_URL_LENGTH]; > + WCHAR cacheFileName[MAX_PATH+1]; > + BOOL b; > + > + b = HTTP_GetRequestURL(lpwhr, url); > + if(!b) { > + WARN("Could not get URL\n"); > + goto lend; > + } > + > + b = CreateUrlCacheEntryW(url, lpwhr->dwContentLength > 0 ? lpwhr->dwContentLength : 0, NULL, cacheFileName, 0); > + if(b) { > + lpwhr->lpszCacheFile = WININET_strdupW(cacheFileName); > + lpwhr->hCacheFile = CreateFileW(lpwhr->lpszCacheFile, GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, > + NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); > + if(lpwhr->hCacheFile == INVALID_HANDLE_VALUE) { > + WARN("Could not create file: %u\n", GetLastError()); > + lpwhr->hCacheFile = NULL; > + } > + }else { > + WARN("Could not create cache entry: %08x\n", GetLastError()); > + } > + } > > It may be beyond the scope of your patch, but you're creating the cache file without committing the entry elsewhere so that it can be found at a later time. According to MSDN, this should be done in HTTP_FinishedReading. -- Rob Shearman

1 0

Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
by Peter Dons Tychsen Feb. 13, 2008

Feb. 13, 2008

Eh, this does not seem like a proper way to get a unit test to pass. Sleep()... that leads to the dark side! :-) Why does it need a Sleep()? If its failing on Wine, then shouldn't it be fixed in the libs? And if its on orig-winxp-vista then there must be a better way to wait? Or no? The string "This makes the tests pass on my pc" isn't very good either. What system? In general, introducing magic Sleep() values in code is not a good idea. If the test system is stressed, you will start getting failures again = bad idea. /p On Wed, 2008-02-13 at 02:26 +0100, Stefan Dösinger wrote: > Am Mittwoch, 13. Februar 2008 02:25:30 schrieb Maarten Lankhorst: > > This makes the tests pass on my pc. > > d3d8 might need it as well > >

3 2

Re: Patch: create a WinHttpDetectAutoProxyConfigUrl function
by Dmitry Timoshkov Feb. 13, 2008

Feb. 13, 2008

"Joshua Hudson" <joshudson(a)gmail.com> wrote: > --- wine-0.9.54/dlls/winhttp/winhttp.spec 2008-02-11 20:54:39.000000000 > -0800 > +++ wine-0.9.54/dlls/winhttp/winhttp.spec.bak 2008-02-11 20:52:39.000000000 > -0800 The patch is wrapped. > @@ -8,7 +8,7 @@ > @ stub WinHttpConnect > @ stub WinHttpCrackUrl > @ stub WinHttpCreateUrl > -@ stdcall WinHttpDetectAutoProxyConfigUrl(long ptr) > +@ stub WinHttpDetectAutoProxyConfigUrl And this part seems to be reverted. -- Dmitry.

1 0

Alsa spitting out warnings every time Wine runs.
by Peter Dons Tychsen Feb. 13, 2008

Feb. 13, 2008

Hi Maarten & Devs. Great to see that audio is so much better in Wine now. But.... On fedora core 6 and 8 i get this every time i start Wine: ALSA lib conf.c:3949:(snd_config_expand) Unknown parameters 0 ALSA lib pcm.c:2145:(snd_pcm_open_noupdate) Unknown PCM default:0 ALSA lib conf.c:3949:(snd_config_expand) Unknown parameters 0 ALSA lib pcm.c:2145:(snd_pcm_open_noupdate) Unknown PCM default:0 I think its harmless, but what do you it means? How do i stop it? Should i fix it in Wine or Alsa? /p

2 1

Fwd: Congratulation!!!
by Maarten Lankhorst Feb. 13, 2008

Feb. 13, 2008

Hooray! I won the Microsoft e-mail award! And I thought my wine efforts would go unnoticed, but here I am winning the grand prize! ---------- Forwarded message ---------- From: marinamg(a)esplugues.org <marinamg(a)esplugues.org> Date: 12 feb. 2008 18:33 Subject: Congratulation!!! To: undisclosed-recipients Microsoft Award Team 22 Garden Close,PE9 2YP, London Date: 13th Feb 2008. Finally, Today we announce this year winners of the MICROSOFT E-MAIL AWARD held on the 13/02/2008, Your Email has won (£1,000,000.00) (CSC) Claims Security Code: CSC-74162007-04-LV-UK,Your Ref: MSC990/678. Contact your Fudiciary agent Mr. Steve Wallace along with your information via email. Sir. John Smith Email: johnsmithm(a)live.com

2 1

Fixing the last failing tests
by Maarten Lankhorst Feb. 12, 2008

Feb. 12, 2008

Hi all, I'm very close to passing the whole wine conformance suite on my pc. The only tests failing are in user32. These tests are failing in any version of windows though. How do I make them pass on at least 1 version of windows and wine? Would patches to make it run on xp and wine be accepted? And if I can succeed with that, how do I make it work with other versions of windows as well. Cheers, Maarten. An example is IsWindowUnicode. It always returns TRUE on XP, but it won't do that on 9x. That would mean something like: ok(IsWindowUnicode() || !IsWindowUnicode(), "How can this fail?");

2 1

Re: d3d: Add a slight delay before testing the ddraw and d3d9 visual tests
by Stefan Dösinger Feb. 12, 2008

Feb. 12, 2008

Am Mittwoch, 13. Februar 2008 02:25:30 schrieb Maarten Lankhorst: > This makes the tests pass on my pc. d3d8 might need it as well

1 0

Re: ddraw - Implement correct behavior for the DDEDM_REFRESHRATES flag in EnumDisplayModes() - REJECTED.
by Peter Dons Tychsen Feb. 12, 2008

Feb. 12, 2008

Hi Stefan. OK thanks for the fast, precise and well-cut review (and probably correct). I will fix the 3 issues and re-submit. /p On Wed, 2008-02-13 at 00:50 +0100, Stefan Dösinger wrote: > Am Mittwoch, 13. Februar 2008 00:39:52 schrieb Peter Dons Tychsen: > > Hi Devs. > > > > I had this patch silently rejected. > > Can anybody spot what is wrong with this patch? > My first thought was that filtering the modes like this is kinda ugly, but > given that ddraw uses wined3d and wined3d uses the d3d9 interface this is the > only way. (I don't think adding an extra flag to wined3d is cleaner, > considering that ddraw can sort this out on its own). > > However, I think you shouldn't clone the application's bug you're trying to > work around and deal with the "out of mode buffer" case. you can e.g. use > HeapReAlloc to increase the buffer without loosing the content. > > Another minor thing is the if(buffer) HeapFree(buffer) code. HeapFree checks > against NULL, so the extra check isn't needed, and it is sorta a policy not > to have redundant checks before HeapFree >

1 0

ddraw - Implement correct behavior for the DDEDM_REFRESHRATES flag in EnumDisplayModes() - REJECTED.
by Peter Dons Tychsen Feb. 12, 2008

Feb. 12, 2008

Hi Devs. I had this patch silently rejected. Can anybody spot what is wrong with this patch? It is really needed for some older games like Grand Theft Auto, and other oldies (but goodies!). /pedro

2 1

dbghelp/dwarf.c: new valgrind warnings?
by Dan Kegel Feb. 12, 2008

Feb. 12, 2008

I'm now seeing some new valgrind warnings when wine is doing stack dumps after crashes: + Conditional jump or move depends on uninitialised value(s) + at dwarf2_load_one_entry (dwarf.c:983) + by dwarf2_lookup_type (dwarf.c:858) + by dwarf2_load_one_entry (dwarf.c:1020) + by dwarf2_parse (dwarf.c:2060) + by elf_load_debug_info (elf_module.c:1085) + by module_get_debug (module.c:303) + by SymFromAddr (symbol.c:1071) + by stack_get_current_symbol (stack.c:143) + by display_print (display.c:174) + by wait_exception (tgt_active.c:178) + by dbg_active_auto (tgt_active.c:951) + by main (winedbg.c:544) I don't know when this started, but maybe it's related to recent changes by Eric Pouech? - Dan

2 1

[winetest] Would it be worthwhile to send zipped version of the reports?
by Paul Vriens Feb. 12, 2008

Feb. 12, 2008

Hi, As more and more tests are developed I think it could make sense to zip the report files before sending. It will of course put a small extra burden on the winehq server but as the reports are text only we gain a 90% or so per report. Thoughts? -- Cheers, Paul.

2 2

Re: [advapi32/tests] Only use functions if they are implemented
by James Hawkins Feb. 12, 2008

Feb. 12, 2008

On Feb 12, 2008 10:34 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Added some verbosity to the GetProcAddress stuff. The skips prevent the > crash(es) I'm seeing on win95. > What is the point of this 'verbosity'? You already add the skips, so if a function isn't available for a test, you're going to see it twice now. Also, it adds to the code size. -- James Hawkins

2 1

Re: browseui: Add undocumented Component Category Cache Daemon class
by Dmitry Timoshkov Feb. 12, 2008

Feb. 12, 2008

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > --- /dev/null > +++ b/dlls/browseui/compcatcachedaemon.c > @@ -0,0 +1,159 @@ > +/* > + * Progress dialog > + * > + * Copyright 2007 Mikolaj Zalewski Is the above information correct? -- Dmitry.

1 0

Re: Oleview: Added Dutch translations
by Dmitry Timoshkov Feb. 12, 2008

Feb. 12, 2008

"Frans Kool" <frans.kool(a)gmail.com> wrote: > From 2e5bda68273038f924f8f0d1b325a2a4c71f17ae Mon Sep 17 00:00:00 2001 > From: Frans Kool <Frans.Kool(a)gmail.com> > Date: Tue, 12 Feb 2008 12:04:56 +0100 > Subject: Oleview: Added Dutch translations This your patch as well as a previous one are wrapped. -- Dmitry.

1 0

Regesstion Tests
by Alistair Leslie-Hughes Feb. 12, 2008

Feb. 12, 2008

Hi, If I have Msxml3 with SP7 installed all the msxml tests pass without issue, but if I have Msxml3 SP3 installed, some fail. Should I improve the tests so that they can handle both cases? Best Regards Alistair Leslie-Hughes

2 1

Regular bugzilla hygeine
by Dan Kegel Feb. 12, 2008

Feb. 12, 2008

When we do a release, all the bugs in RESOLVED FIXED state can be closed (since they were only waiting on a release to be closed). We haven't been doing that, and as a result, lots and lots of bugs stacked up in RESOLVED FIXED state. But I don't see any reason we shouldn't start doing it, so I'm about to do it in honor of the 0.9.55 release. (I think I've figured out how to avoid changing any bugs flipped into that state since the 0.9.55 release, let's see if I get it right. Next time I'll do it right when Alexandre releases.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: comctl32: Fixed listview bug, when client sends bogus SETITEMSTATE request
by Dimi Paun Feb. 11, 2008

Feb. 11, 2008

On Tue, 2008-02-12 at 03:28 +0100, Peter Dons Tychsen wrote: > Fixed listview bug, when client sends bogus SETITEMSTATE request, > requesting all items to be focused. Looks good, tnx! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Resend patch from Norbert
by Vitaliy Margolen Feb. 11, 2008

Feb. 11, 2008

Rico Schüller wrote: > Hi, > > I only resend a patch because it isn't in the todays git and the author > didn't answer for a while. > > Cheers > Rico > > > ------------------------------------------------------------------------ > > > - memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(pRect)); > + memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(RECT)); To avoid such problems in the future one should use something like: *pRect = This->updateStateBlock->scissorRect; Doing a quick search through wined3d I've found number of places with memcpy instead of simple assignment of one struct to another struct. This is a good janitorial task to get rid of memcpy where simple assignment will work. Vitaliy.

3 2

Re: IStream interface for domdoc and terminate call
by Kornél Pál Feb. 11, 2008

Feb. 11, 2008

Also note you should test the behavior when call QueryInterface for IStream multiple times whether a new wrapper or the same wrapper is returned and whether the tree is cleared on QueryInterface. And I forgot to mention that calling Release on the IStream interface is the correct way of disposing the interface so that call may have effect on the object as well. Kornél ----- Original Message ----- From: "Kornél Pál" <kornelpal(a)gmail.com> To: "Josef Reidinger" <josef.reidinger(a)gmail.com>; <wine-devel(a)winehq.org> Sent: Monday, February 11, 2008 1:15 PM Subject: Re: IStream interface for domdoc and terminate call > OK, sorry I didn't realized that you try to modify the Wine > implementation. > > I think that delaying pasing for the fist time you call a method of the > DOMDocument object would be a good solution. This way you will not perform > any unnecessary parings. > > I don't know the exact details of MS implementations so you should check > when and how are parsing errors reported and when is the parsed document > available when you write the DOMDocument throug it's IStream interface and > you should dealy parsing to the latest possible time. > > Kornél > > ----- Original Message ----- > From: "Josef Reidinger" <josef.reidinger(a)gmail.com> > To: "Kornél Pál" <kornelpal(a)gmail.com> > Sent: Monday, February 11, 2008 12:58 PM > Subject: Re: IStream interface for domdoc and terminate call > > >> Hi >> I mean using call IStream_write like it is describe in bug #4811. >> >> Kornél Pál napsal(a): >>> Hi, >>> >>> If you mean passing an IStream interface to DOMDocument.save method: >>> As far as I know save method is synchronous (if I'm wrong you still can >>> set the async property to FALSE). So when the save method returns you >>> know that the entire document has been passed to the IStream. >>> >>> If you want to do something else please be more specific. >>> >>> Kornél >>> >>> ----- Original Message ----- From: "Josef Reidinger" >>> <josef.reidinger(a)gmail.com> >>> To: <wine-devel(a)winehq.org> >>> Sent: Monday, February 11, 2008 11:55 AM >>> Subject: IStream interface for domdoc and terminate call >>> >>> >>>> Hi, I try make IStream write interface for domdoc (msxml3). Problem is >>>> that microsoft doesn't have terminate string for write call and libxml >>>> have proble with it (more at >>>> http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does >>>> anyone has any idea how solve it? (test in each dom call if is some >>>> nonparsed characters and force parsing looks very ugly). >>>> JR >>>> >>>> >>> >> >

1 0

Re: IStream interface for domdoc and terminate call
by Kornél Pál Feb. 11, 2008

Feb. 11, 2008

OK, sorry I didn't realized that you try to modify the Wine implementation. I think that delaying pasing for the fist time you call a method of the DOMDocument object would be a good solution. This way you will not perform any unnecessary parings. I don't know the exact details of MS implementations so you should check when and how are parsing errors reported and when is the parsed document available when you write the DOMDocument throug it's IStream interface and you should dealy parsing to the latest possible time. Kornél ----- Original Message ----- From: "Josef Reidinger" <josef.reidinger(a)gmail.com> To: "Kornél Pál" <kornelpal(a)gmail.com> Sent: Monday, February 11, 2008 12:58 PM Subject: Re: IStream interface for domdoc and terminate call > Hi > I mean using call IStream_write like it is describe in bug #4811. > > Kornél Pál napsal(a): >> Hi, >> >> If you mean passing an IStream interface to DOMDocument.save method: >> As far as I know save method is synchronous (if I'm wrong you still can >> set the async property to FALSE). So when the save method returns you >> know that the entire document has been passed to the IStream. >> >> If you want to do something else please be more specific. >> >> Kornél >> >> ----- Original Message ----- From: "Josef Reidinger" >> <josef.reidinger(a)gmail.com> >> To: <wine-devel(a)winehq.org> >> Sent: Monday, February 11, 2008 11:55 AM >> Subject: IStream interface for domdoc and terminate call >> >> >>> Hi, I try make IStream write interface for domdoc (msxml3). Problem is >>> that microsoft doesn't have terminate string for write call and libxml >>> have proble with it (more at >>> http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does >>> anyone has any idea how solve it? (test in each dom call if is some >>> nonparsed characters and force parsing looks very ugly). >>> JR >>> >>> >> >

1 0

IStream interface for domdoc and terminate call
by Josef Reidinger Feb. 11, 2008

Feb. 11, 2008

Hi, I try make IStream write interface for domdoc (msxml3). Problem is that microsoft doesn't have terminate string for write call and libxml have proble with it (more at http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does anyone has any idea how solve it? (test in each dom call if is some nonparsed characters and force parsing looks very ugly). JR

2 1

Re: pdh[3:3]: remove unnecessary tests done in PdhLookupPerfNameByIndexW
by Dmitry Timoshkov Feb. 11, 2008

Feb. 11, 2008

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > --- a/dlls/pdh/pdh_main.c > +++ b/dlls/pdh/pdh_main.c > @@ -837,14 +837,7 @@ PDH_STATUS WINAPI PdhLookupPerfNameByIndexA( LPCSTR machine, DWORD index, LPSTR > > TRACE("%s %d %p %p\n", debugstr_a(machine), index, buffer, size); > > - if (machine) > - { > - FIXME("remote machine not supported\n"); > - return PDH_CSTATUS_NO_MACHINE; > - } > - > if (!buffer || !size) return PDH_INVALID_ARGUMENT; > - if (!index) return ERROR_SUCCESS; Changelog mentions PdhLookupPerfNameByIndexW by the change is in PdhLookupPerfNameByIndexA. Why are you removing the checks in one place by leave the same in other one? Why the tests are unnecessary? -- Dmitry.

2 6

Re: [1/9] WineD3D: Add a test for the vFace register
by H. Verbeet Feb. 11, 2008

Feb. 11, 2008

On 11/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > /* TODO: vFace (ps_3_0) */ You should probably remove that one :-)

1 0

re: Is there a Git Repositories for Unaccept Patches or (work in Progress)?
by Dan Kegel Feb. 11, 2008

Feb. 11, 2008

Joeseph wrote: > Is there a Git Repositories for Unaccept Patches or (work in Progress)? Not really, but people often attach patches to bugzilla entries if they're not quite good enough to submit. And if anybody wants to start such a git repository, more power to them. >An ntoskrnl.exe was written a couple of years ago to load drivers, >specifically the Safedisc Windows kernel driver, > but it still hasn't been accepted. The article you read is out of date; ntoskrnl.exe is now part of wine. > Basically threat unaccepted patch as bugs(while keeping the patch out of wine), instead of chucking it out the window. As I said above, developers are free to attach patches to bug reports. What you're really trying to get at is: sometimes developers get discouraged at how hard it is to get patches into Wine. But no mechanical aid will really help there. The only cure is persistance on the part of the developer, and assistance (chiefly good feedback) from other Wine developers. After a developer gets a few patches committed, the wine process starts to feel a lot smoother. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

6 11

Wine patches integrated into Valgrind svn
by Dan Kegel Feb. 10, 2008

Feb. 10, 2008

Hey, the Valgrind developers finally merged the Wine support patches! I just built Valgrind from svn as described here: http://valgrind.org/downloads/repository.html and on a fresh install of Gutsy, it just worked, no patches. To run Valgrind's tests under Wine, I configure valgrind with --prefix=/usr/local/valgrind-svn, then do something like cd wine-git/tools wget http://kegel.com/wine/valgrind/runtests.patch wget http://kegel.com/wine/valgrind/valgrind-daily.sh wget http://kegel.com/wine/valgrind/valgrind-suppressions wget http://kegel.com/wine/valgrind/valgrind-split-pl.txt -O valgrind-split.pl patch -p2 < runtests.patch Then to run all the tests, I do cd ~/wine-git sh tools/valgrind-daily.sh or to run just one test, I do export RUNTEST_USE_VALGRIND=1 cd ~/wine-git/dlls/riched20/tests make test I've only verified that this works well on one machine so far, but I have high hopes. Anyone else feel like giving it a whirl? - Dan

3 4

Re: Gdiplus: Implement GdipDrawArcI based on GdipDrawArc
by James Hawkins Feb. 10, 2008

Feb. 10, 2008

On Feb 10, 2008 4:04 PM, Royal Chan <chanroyal(a)gmail.com> wrote: > Change Log: > -Added GdipDrawArcI as GdipDrawArc that takes INT arguments > -Added a very similar conformance test to the one I did for GdipDrawArc > -Corresponding change to gdiplus.spec > No patch. -- James Hawkins

1 0

? on Repositories for Unaccept Patches and (work in Progress).
by Joseph Stein Feb. 10, 2008

Feb. 10, 2008

Is there a Git Repositories for Unaccept Patches or (work in Progress)? If not (which i think is the case and why I posting here instead of the user mailing list.), could you create one(along with a text file explain what need to be done to be accepted)? Here are some reason I think It is Needed. 1.) It would allow developer and users to see what the source done. I have read a very good article about usb support in wine an winehq.org here http://www.winehq.org/?issue=331 wich said that >An ntoskrnl.exe was written a couple of years ago to load drivers, >specifically the Safedisc Windows kernel driver, but it still hasn't been >accepted. Apparently there's some low-level internal Wine issues >and Alexandre wants those fixed before accepting the patch. 2.) Allow people two git possibly some things work that would other wise not work. using the patch for ntoskrnl.exe that was not accept as an example, (please correct me if i wrong), could possible git some drivers working (usb driver may be?) program to work. which is currently not possible with wine from what i read. Yes It dose cause other wine problem which is not big deal, if you compile and run wine form the source directory from which it is compiled instead of installing it (the multiple wine install way). In other words you code use the patch version of wine just for the program that need the patch to work .(Is it not better to have a broken wine (with partal diver) support, then a stable wine with-out (partal diver) support when The program you are running requires a driver.) 3.)If done right in my humble opinion would help prevent developer from getting discurage becuase all there work has be chuck out the window. Giving more Light to what i said above, What I mean buy "if done right",Is that if a developer(who is looking for something to do) would go look at what patches Have not be accepted (but have almost all basic done) and help the developer git it accepted ,Would in my humble opinion encourage more developer to join which is need for a complicated project such as wine. Basically threat unaccepted patch as bugs(while keeping the patch out of wine), instead of chucking it out the window. This type of thing is done in boost project i be-leave, but I taking it one step further and asking for a text file on "what need to be done to be include which each unaccepted patches". Thank you for any reply, Please forgive me if I got any of what i said above wrong, I'm not a real good developer and only have a real basic idea of wine and have not work on wine because it to confusing to me(but have download and looked at from git Repositories) --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

4 3

Re: Gdiplus: conformance test for GdipDrawLineI in graphics.c
by James Hawkins Feb. 10, 2008

Feb. 10, 2008

On Feb 10, 2008 3:46 PM, Royal Chan <chanroyal(a)gmail.com> wrote: > Change Log: > -added conformance test mainly checking for input parameters > You forgot the patch again. -- James Hawkins

1 0

Re: Gdiplus: GdipDrawArc in graphics.c does not return InvalidParameter for bad values of height and width
by James Hawkins Feb. 10, 2008

Feb. 10, 2008

On Feb 10, 2008 3:19 PM, Royal Chan <chanroyal(a)gmail.com> wrote: > Change Log: > -added two checks for non-positive values of width and height > -added a conformance test for invalid parameters > You forgot the patch. -- James Hawkins

1 0

winecfg improvements
by Reece Dunn Feb. 10, 2008

Feb. 10, 2008

Hi, I have just submitted 4 patches that make it possible to import a colour theme from winecfg and have it correctly apply the colours. One example is the Ubuntu Human theme (see attachment), adapted from http://tombuntu.com/wp-content/uploads/2008/01/winehumancolours.txt. Enjoy, - Reece

1 0

Re: dlls/gdi32/font.c warning removal (RESEND)
by Alexandre Julliard Feb. 10, 2008

Feb. 10, 2008

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > The reason is that we have > > #define HDPTOLP(y) ((y<0)? \ > (-abs(INTERNAL_YDSTOWS(dc, (y)))): \ > (abs(INTERNAL_YDSTOWS(dc, (y))))) > > which is overly complicated for unsigned types. We can avoid these > warnings by using plain INTERNAL_YDSTOWS instead of HDPTOLP here. No, you still need the abs(). -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: WineD3D: split framebuffer -> texture path from LoadLocation
by Stefan Dösinger Feb. 10, 2008

Feb. 10, 2008

Am Sonntag, 10. Februar 2008 17:37:25 schrieb Roderick Colenbrander: > Hi, > > This patch puts the framebuffer -> texture from LoadLocation in a separate > function in a similar way to read_from_framebuffer. It borrows some code > from LoadLocation and read_from_framebuffer. > > Regards, > Roderick Colenbrander You're mixing tabs and spaces in this patch

2 2

Re: Implemented a stub for MsiSetExternalUIRecord in msi.dll
by James Hawkins Feb. 10, 2008

Feb. 10, 2008

On Feb 10, 2008 1:11 PM, Luke Benstead <kazade(a)gmail.com> wrote: > This unimplemented function causes the .NET framework 3.0 installer to fail > (and also Visual C++ express 8.0) with this patch the installer continues > further before crashing. This is my first ever patch on Wine (and working > with GIT) so I'm sure I've done something wrong, if so I apologize in > advance :) > > diff --git a/dlls/msi/msi.c b/dlls/msi/msi.c > index 643f9cc..9fb6906 100644 > --- a/dlls/msi/msi.c > +++ b/dlls/msi/msi.c > @@ -992,6 +992,7 @@ end: > return state; > } > > + > INSTALLUILEVEL WINAPI MsiSetInternalUI(INSTALLUILEVEL dwUILevel, HWND *phWnd) > { > INSTALLUILEVEL old = gUILevel; Random whitespace change -> bad. > @@ -1008,6 +1009,18 @@ INSTALLUILEVEL WINAPI MsiSetInternalUI(INSTALLUILEVEL dwUILevel, HWND *phWnd) > return old; > } > > +/*********************************************************************** > + * MsiSetExternalUIRecord [MSI.@] > + */ > +UINT WINAPI MsiSetExternalUIRecord( INSTALLUI_RECORD_HANDLER puiHandler, > + DWORD dwMessageFilter, LPVOID pvContext, > + PINSTALLUI_RECORD_HANDLER ppuiPrevHandler ) > +{ > + FIXME("%p %08x %p %p", > + puiHandler, dwMessageFilter, pvContext, ppuiPrevHandler); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + > INSTALLUI_HANDLERA WINAPI MsiSetExternalUIA(INSTALLUI_HANDLERA puiHandler, > DWORD dwMessageFilter, LPVOID pvContext) > { Used tabs -> bad. > @@ -2452,3 +2465,5 @@ UINT WINAPI MsiAdvertiseScriptA( LPCSTR szScriptFile, DWORD dwFlags, > debugstr_a( szScriptFile ), dwFlags, phRegData, fRemoveItems ); > return ERROR_CALL_NOT_IMPLEMENTED; > } > + > + More random whitespace changes. > @@ -573,6 +576,7 @@ UINT WINAPI MsiAdvertiseScriptW(LPCWSTR, DWORD, PHKEY, BOOL); > UINT WINAPI MsiCloseHandle(MSIHANDLE); > UINT WINAPI MsiCloseAllHandles(void); > INSTALLUILEVEL WINAPI MsiSetInternalUI(INSTALLUILEVEL, HWND*); > +UINT WINAPI MsiSetExternalUIRecord( INSTALLUI_RECORD_HANDLER, DWORD, LPVOID, PINSTALLUI_RECORD_HANDLER); Inconsistent whitespace. The rest of the file does not have spaces after parentheses. -- James Hawkins

1 0

gecko download not robust?
by Dan Kegel Feb. 10, 2008

Feb. 10, 2008

Hmm. gecko download hung for me once. I saw fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 in the log, which makes me wonder if our download code doesn't handle transient network errors well. Time to get rid of the download, and just bundle gecko outright, I say...

2 1

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?
by Alex Jackson Feb. 10, 2008

Feb. 10, 2008

> That said, GL_ARB_vertex_blend is not very common. Only MacOS supports it, and > it is software emulated there. The Linux ATI driver used to support it until > ATI switched to a different codebase. So this constant ends up beeing 0 > almost everywhere. The extension was dropped in favor of vertex programs, > since vertex programs appeared shortly after vertex blending and no gl app > was using it at this time. On Windows drivers emulate vertex blending using > vertex shaders. > > I am not sure if 0 is the correct value to return in case of no vertex > blending support. What happens if you set it to 1? 1 would be a reasonable > default as well, because we're still able to transform vertices with one > matrix(ie, unblened transformation). It could also be that this game silently > expects vertex blending to be supported: For one part, all dx8+ cards support > this feature on Windows, and on older cards Windows has software vertex > processing which can perform blending in a slow, but working fashion. > > I have a patch for software emulated vertex blending somewhere, but I dropped > it because I didn't come across an app which uses this function. Maybe its > time to revive it, and continue the work on a fixed function replacement > shader. Even on Windows, no OpenGL implementation that I know of supports GL_ARB_vertex_blend other than ATI's (and as you've pointed out, the new OpenGL stack that the Radeon HD's use on Windows and that all Radeons now use on Linux has dropped it). History lesson: Both GL_ARB_vertex_blend and D3D vertex blending are historically tied to a specific piece of hardware: the original ATI Radeon (GL_ARB_vertex_blend started out as GL_ATI_vertex_blend). Presumably, due to ATI's historically spotty OpenGL driver performance (okay, "historically" is being kind to ATI), any game developer who wanted to use the Radeon's capabilities targeted their game for D3D rather than OpenGL. Consequently, when nVidia released the GeForce 3 (the first video card with vertex shaders) they did implement D3D vertex blending via shaders in their D3D driver (since games were using it, and it wouldn't do if the "new" GF3 couldn't handle effects that the "old" Radeon could), but they didn't bother to implement it in their OpenGL driver, even though ATI had gotten it ARB-approved some months before the GF3 came out, since no games/apps were using it. The other video hardware makers (the few that were left by the DX8 era) followed NV's example: implement D3D vertex blending via shaders or in software (for entry-level and onboard hardware without vertex shaders), but don't bother with GL_ARB_vertex_blend since no one uses it. The upshot is that GL_ARB_vertex_blend is an ARB extension In Name Only; it's effectively ATI-only--and even ATI has abandoned it now. On the other hand, D3D vertex blending is universally available on modern and semi-modern hardware regardless of maker, and it looks like even some D3D9 games still use it instead of using vertex shaders. So it's better for WINE to implement vertex blending via vertex programs rather than depending on GL_ARB_vertex_blend. --AWJ-- _________________________________________________________________

3 2

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez Feb. 9, 2008

Feb. 9, 2008

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. These are my findings: The main executable is eqgame.exe it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with a vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assambler (I burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg to be able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems its not wine's fault (for the most of it) The 'troublesome' vertex are apparently Blended ones on a Mesh setup. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models to not be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models work are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way

3 3

No win95 tests after commit "tests: Add a helper routine to wait for a child process and propagate its result correctly."
by Paul Vriens Feb. 9, 2008

Feb. 9, 2008

Hi, This commit: 05c7174909e975fc7d0ebf9a59bb07160c09d66d introduces a new helper script but uses InterlockedExchangeAdd that is not available on win95. This means that none of the tests run on win95 anymore. -- Cheers, Paul.

2 2

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez Feb. 9, 2008

Feb. 9, 2008

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357 These are my findings: The main executable is eqgame.exe it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with a vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assambler (I burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg to be able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems its not wine's fault (for the most of it) The 'troublesome' vertex are apparently Blended ones on a Mesh setup. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models to not be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models work are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way

1 0

re: msvcrt: Fix EOF behavior on read from pipe
by Dan Kegel Feb. 9, 2008

Feb. 9, 2008

Damjan wrote > The problem is more general: consoles *also* break on short reads > (Java 1.4.1's gdb takes 1 command then quits because it thinks it's > the end of file) Try my patch, it should help that case. > I'm sure short read != end of file for ordinary > files either, especially in *nix where read() can easily be > interrupted by a signal. If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it. - Dan

2 3

Is wine reporting the right value for MaxVertexBlendMatrices ?
by Julio Fernandez Feb. 9, 2008

Feb. 9, 2008

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. These are my findings: The main executable is eqgame.exe, it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running at the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assembler (I've burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg was able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems it's not wine's fault (for the most of it) The 'troublesome' vertex are apparently Blended ones on a Mesh setup. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, for the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models not to be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way

1 0

Re: wine keyboard fix
by Stefan Dösinger Feb. 9, 2008

Feb. 9, 2008

Am Samstag, 9. Februar 2008 04:52:23 schrieb dhliu: > Some input methods can send a much longer string. The original size is > too small. Please consider enlarging it. > Thanks. You should send a patch generated via git to wine-patches. If you do not know how to do this, plese consider filing a bugreport about this issue, together with an example for "Some input methods" which can trigger the issue.

1 0

Is wine reporting the right value for MaxVertexBlendMatrices?
by Julio Fernandez Feb. 9, 2008

Feb. 9, 2008

Hi, I don't know if this is the right place to post this, but sorry if not, and I'd like to be pointed to the right one I have been working last weeks on making the game Everquest to work under wine, since 0.9.49 it was working flawlesly, but most models were not shown properly. This corresponds with bug http://bugs.winehq.org/show_bug.cgi?id=8357. These are my findings: The main executable is eqgame.exe it typically accesses D3D through a custom dll eqgraphicsdx9 which interacts with D3D itself or through d3dx9_30.dll Using channels and adding some extra messages into certain source files I got to track a possible reason: The game was declaring vertex lists with a vertex of type '0xfe' and +189 offset Sadly, I could not get any extra information tracking just from source code, so I had to run the game under Windows on a computer and using windbg to debug it, while running the same time on another computer the game under Debian etch using winedbg to debug, and so tracing both programs in assambler (I burnt my eyelashes there!), the fact that I could have d3d dll symbols availables on the windows box was the key here, I really missed winedbg to be able to read pdb files :( After many hours I was able to track down the reason, and to my surprise it seems its not wine's fault (for the most of it) The 'troublesome' vertexes are apparently blended ones in mesh declarations. When d3dx9_30 calls ConvertToIndexedBlendedMesh, it calls GetDeviceInfo to get the device capabilites, in the end wine returns the capabilites through IWineD3DImpl_GetDeviceCaps in wine/dlls/wined3d/directx.c Here comes the fun thing, the attribute MaxVertexBlendMatrices in D3DCAPS9, from (MSDN): "Maximum number of matrices that this device can apply when performing multimatrix vertex blending. For a given physical device, this capability may vary across Direct3D devices depending on the parameters supplied to IDirect3D9::CreateDevice." At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends) which results in a value of 0 (at least in my Linux computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 d3dx9_30 has a check right after the capabilites are returned comparing that value with 2, resulting in different code paths for the remaining of MaxVertexBlendMatrices function, when the value was 0 both Linux and Windows (hacking the returned value to be 0) make those odd '0xfe' vertexes to be inserted (in Linux that makes the models to not be shown, in Windows it makes eqgame.exe to crash) I proceeded then to try to 'hack' wine to return a value of 4, adding the line pCaps->MaxVertexBlendMatrices=0x4; Before returning from function IDirect3DDevice9Impl_GetDeviceCaps(LPDIRECT3DDEVICE9 iface, D3DCAPS9* pCaps) at wine/dlls/d3d9/directx.c The result: MaxVertexBlendMatrices runs the same path as Windows does, the odd '0xfe' vertexes are not generated and the models work are now shown as expected My apologies for the long post, but I thought it would be handy to tell the full story to justify calling your atention on this - d3dx9_30 ConvertToIndexedBlendedMesh shows an 'odd' behavior when MaxVertexBlendMatrices capabilites in D3DCAPS9 is 0 - Is wine reporting the right value for MaxVertexBlendMatrices ??? As it seems the game works flawlesly in wine when it's hacked to be 4 (I don't know if this 'hack' would affect other programs in any other way

1 0

Code quality (was Re: comctl32: Fix invalid syntax)
by Bang Jun-young Feb. 9, 2008

Feb. 9, 2008

On 2/7/08, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Bang Jun-young wrote: > > On 2/7/08, Alexandre Julliard <julliard(a)winehq.org> wrote: > >> "Bang Jun-young" <junyoung(a)mogua.com> writes: > >> > >>> 18 hours passed, and it looks like Alexandre decided to ignore this...why? > >>> > >>> This fix is required for Wine to be built with VC2005/2008 (although > >>> Alexandre doesn't seem to care about it). > >> There's no need to count the hours, or to ask every day, especially not > >> with a mail to wine-patches. I have lots of pending patches from my > >> vacation, I'll get to it eventually, and if I don't you should resubmit > >> it after a week has passed. > > > > That's because you wanted yourself to be the only committer in the > > project. Why don't you give commit privilege to other Wine > > contributors as well? > Huh? Why would you need that? Because I'm concerned with the code quality of Wine. When Alexandre commits what he doesn't understand, it's a red sign to the project. Months ago I posted a patch similar to this one to wine-patches, and he committed it: typedef struct _OLEOBJECTVTBL { - void CALLBACK *(*QueryProtocol)(_LPOLEOBJECT,LPCOLESTR16); + void * (CALLBACK *QueryProtocol)(_LPOLEOBJECT,LPCOLESTR16); How did he know what the patch does from the same message "Fix invalid syntax?" IIRC, he didn't tell anything about what he doesn't understand. In fact, this is a well known mistake many newbie Win32 developers make (and fix in minutes). It shouldn't have been in the tree in the first place if he actually have read the patch. There are a lot of easily catchable bugs in the tree, for example, potential security holes like buffer overrun, meaningless comparison of unsigned < 0 (or > 0), misuse of BOOL vs. HRESULT, misuse of functions such as strcasecmp(), use of non-portable syntax, etc. Most of them (if not all) could be filtered out if he have read the patches carefully. That's the main reason why Wine keeps crashing every time I give it a try with my Windows apps. Since 1993, Wine has never gotten to the point where everybody could rely on it for his daily work. It has as awfully many bugs as Win95. I see something fundamentally wrong with development process. > Wine uses git, a distributed SCM. You are > free to publish your own Wine tree without waiting for Alexandre. 99% of the world won't benefit from what I have done in my own local repository. People usually don't have a much time to keep track of repositories of hundreds of developers around the world. That's why every open source project has the main repository even if developers usually maintain their own repostories at home. > People prefer to follow Alexandre's tree but nobody forces them to use it. If winehq.org is Alexandre's own property, this is something fundametally wrong again.

6 5

Bugzilla: Remove obsolete components
by Austin English Feb. 9, 2008

Feb. 9, 2008

Howdy, I just finished moving over the last of the obsolete components. _obsolete_binary, _obsolete_directx, and _obsolete_gui can all be removed now. -Austin

3 2

Re: user32: Implement GetWindowModuleFileName with tests
by Dmitry Timoshkov Feb. 8, 2008

Feb. 8, 2008

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > UINT WINAPI GetWindowModuleFileNameA( HWND hwnd, LPSTR lpszFileName, UINT cchFileNameMax) > { > - FIXME("GetWindowModuleFileNameA(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", > - hwnd, lpszFileName, cchFileNameMax); > - return 0; > + LPWSTR filenameW = NULL; > + UINT retval; > + > + if (cchFileNameMax) > + { > + filenameW = HeapAlloc(GetProcessHeap(), 0, cchFileNameMax); > + if (!filenameW) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return 0; > + } > + } Probably GetWindowModuleFileNameA should simply allocate a buffer of size MAX_PATH on the stack and fail with ERROR_FILENAME_EXCED_RANGE if unicode counterpart returns a string longer than MAX_PATH. kernel32 APIs behave that way. > + retval = GetWindowModuleFileNameW(hwnd, filenameW, cchFileNameMax); > + if (retval) > + { > + DWORD lasterror = GetLastError(); > + WideCharToMultiByte(CP_ACP, 0, filenameW, -1, lpszFileName, cchFileNameMax, NULL, NULL); > + SetLastError(lasterror); What's the point of saving/restoring last error value? If WideCharToMultiByte fails you need to return an error in that case, not silently continue. Also GetWindowModuleFileNameA also should be fixed to return correct value, and not assume that the buffer is '\0' terminated. > UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT cchFileNameMax) > { > - FIXME("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u) stub!\n", > - hwnd, lpszFileName, cchFileNameMax); > - return 0; > + PROCESS_BASIC_INFORMATION pbi; > + DWORD pid, retval; > + HANDLE hproc; > + DWORD lasterror = GetLastError(); > + UNICODE_STRING *pathname; > + TRACE("GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax %u)\n", hwnd, lpszFileName, > cchFileNameMax); TRACE/WARN/ERR/etc already print the caller's name, there is no need to duplicate it. > + if (!GetWindowThreadProcessId(hwnd, &pid)) > + { > + SetLastError(ERROR_INVALID_WINDOW_HANDLE); > + return 0; > + } GetWindowThreadProcessId already sets the error to the correct value, there is no need to guess why it failed. > + if (!cchFileNameMax) > + { /* Fail silently without setting filename */ > + SetLastError(lasterror); > + return 0; > + } Saving/restoring last error value doesn't look correct at all. > + hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); > + if (!hproc) > + { > + FIXME("Is this correct?"); > + SetLastError(ERROR_INVALID_WINDOW_HANDLE); > + return 0; > + } There is no need to guess why OpenProcess failed. > + retval = NtQueryInformationProcess(hproc, ProcessBasicInformation, &pbi, sizeof(pbi), NULL); > + pathname = &pbi.PebBaseAddress->ProcessParameters->ImagePathName; > + if (pathname->Length / sizeof(WCHAR) < cchFileNameMax) > + { > + memcpy(lpszFileName, pathname->Buffer, pathname->Length); > + lpszFileName[pathname->Length / sizeof(WCHAR)] = 0; > + retval = pathname->Length / sizeof(WCHAR) + 1; > + } > + else > + { > + memcpy(lpszFileName, pathname->Buffer, cchFileNameMax * sizeof(WCHAR)); > + retval = cchFileNameMax; > + } Both branches above should be merged, that will simplify the code. Just '\0' terminate the result if there is enough space in the provided buffer. > + CloseHandle(hproc); > + SetLastError(lasterror); > + FIXME("--> %u %s\n", retval, debugstr_w(lpszFileName)); Left-over from debugging? -- Dmitry.

3 7

AppDB Issues
by Jeremy Newman Feb. 8, 2008

Feb. 8, 2008

As many of you have noticed we've been having a bit of server trauma this past month. The issue boils down to a bug somewhere in mysqld. We are still trying to find the exact cause of the bug. We do have some leads. I just wanted to do a brain dump on wine-devel here before I go on Vacation for a week. The problem: mysqld will randomly eat up all resources on the system until the server is completely unresponsive to anything but pings. My band-aids thus far: 1. mysql is now running at a nice of 1. This should allow us to at least ssh in and kill it if it gets out of control again. 2. I've removed InnoDB table support to save on memory. Not many tables where using it anyway, and nothing is using transaction support at this time. 3. I've patched the appdb to use memcached for session management. This will reduce some load on the DB as the session table was busiest and slowest table of the appdb. These fixes should give longer uptime, but they are not solving the core issue. While I'm gone, if the server goes offline again, please contact Alexandre or Jeremy White. They can kick proverbial butt of the server to get it going again. Lastly, sorry for the issues. -Newman "We do what we must because we can" - GLaDOS

1 0

Re: More correctly handle the presence of the default ime inputwindow on Ime open and close
by Dmitry Timoshkov Feb. 8, 2008

Feb. 8, 2008

"Aric Stewart" <aric(a)codeweavers.com> wrote: > diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c > index 4acbde3..f3ed6f9 100644 > --- a/dlls/imm32/imm.c > +++ b/dlls/imm32/imm.c > @@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify, LPARAM lParam) > > static void ImmInternalSetOpenStatus(BOOL fOpen) > { > - TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); > + TRACE("Setting internal state to %s\n",(fOpen)?"OPEN":"CLOSED"); Wouldn't it be better to change indentation to commonly used 4 spaces instead of a strange mix of 3 and 4 spaces? -- Dmitry.

2 1

Fixing make test - progress update
by Jeremy White Feb. 8, 2008

Feb. 8, 2008

I believe that we have an easy way to find out the 'state of the art' wrt to make test. That is, my patch + request of a few days ago: http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html resulted in a very nice, easy to digest report http://test.winehq.org/data/20080205/ That data has five test runs and shows clear across the board failures in msi:install, shell32:shellink, user32:listbox, and user32:msg. So, we can quickly and easily collate and visually see the make test failures. And, heck, I'm sure that fixing those failures is now a trivial exercise. Now we just need the will. :-/. Not sure how to arrange that, but I think having make test succeed on all systems should be a mandatory requirement for Wine 1.0, so I think we have to work on solving it sooner rather than later. The todo's as I see them are as follows: 1. Revise winetest to not require the 'make dist' step, so that the function of my patch can be implemented more cleanly. 2. Persuade people to run a script on a regular basis so we always have this data. It's trickier than the average bear because the tests require the 'real' console, so you can't just stick it in a headless cron job. Maybe some xauth magic... :-/ 3. (The hard one) Focus in and fix the issues. I'll work on #1 and #2 (although not for a week or two), if everyone else agrees to do #3 <evil grin>. Cheers, Jeremy

3 3

Re: user32:scroll.c: Compulsory enabling/disabling scrollbars after setting scrollbar`s flags.
by Anatoly Lyutin Feb. 8, 2008

Feb. 8, 2008

Oh, Sorry! It crashes some another scrollbars. :( -- Best regards Anatoly Lyutin.

1 0

Re: msvcrt: Fix EOF behavior on read from pipe
by Damjan Jovanovic Feb. 8, 2008

Feb. 8, 2008

On Feb 8, 2008 4:31 PM, Dan Kegel <dank(a)kegel.com> wrote: > Nguyễn Thái Ngọc Duy's patch was almost right, he > forgot a test case, and he neglected to move where > EOF is detected for pipes instead of just removing it. > > Should fix http://bugs.winehq.org/show_bug.cgi?id=11187 > > > > The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file) and I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal. Damjan

1 0

re: [PATCH] msvcrt: Fix early pipe closing
by Dan Kegel Feb. 8, 2008

Feb. 8, 2008

On Sat Feb 2, Nguyễn Thái Ngọc Duy wrote: > Pipes are not like other normal files. If we do not read enough > bytes, it does not mean it reaches EOF > ... fixes broken pipe on git-fetch-pack (MinGW port) This is the same problem as http://bugs.winehq.org/show_bug.cgi?id=11187 so it's my fault. Thanks for the information about git-fetch-pack failing, and for the proposed fix. Before we can commit a fix like yours, we need a test case, so I improved msvcrt/tests/file.c to test EOF on pipes more thoroughly. It shows your patch was almost right. I've fixed up your patch and will send it in. - Dan

1 0

kernel32: Implement ReplaceFileW
by luis.busquets＠ilidium.com Feb. 8, 2008

Feb. 8, 2008

I have read this patch sent in several times and have realised that every time it contains a large number of "goto"'s. I certainly do not like "goto" in structured code. My question to the forum is if it is allowed to use "goto" in wine or if you prefer not to use it. Even when this will make the code larger but it may give a little nore readability,

2 1

Patch tracking system - again...
by Steven Edwards Feb. 8, 2008

Feb. 8, 2008

Hi, I'm not sure if this would even really be of use with most of the development being done on git anyway, but after re-reading the governance thread when the point of patch tracking was brought up, It got me thinking. last time around it got shelved as normal due to not wanting to disrupt Alexandre's work flow. Thinking about it a bit more I think I've come up with a solution to the problem that should not disrupt Alexandre's flow if I understand git properly. Let me preface this with saying that I don't. At first I thought we might be able to use the sha1 hashes that are the patch names themselves to track if a commit had be accepted or not, but then I guess that would only work if we were pushing and pulling directly in to each others tree's as I see the commit hash differs from the patch hash in the patches I've reviewed. I can only assume this is because of the way git views looks at the entire repo as one chunk of data rather than dealing with single patches. Then as I dug in to it a bit more I noticed the index's did match provided Alexandre did not make any changes before he committed. I was thinking this could be a use for a tracking system. Lets imagine there is this patch daemon that sits out there and reads wine-patches, storing the diff and parsing the index in to a database. This deamon could do a git fetch every 30 mins or so to compare and see if a patch has been merged in based on the index. It seems like we already have most of the tools we need to do it now if someone really wants the tracking system. We know about the patches and we know if its been merged or not, defining rules for accepted or rejected seem pretty trivial to me as we already have the rule, if its not merged in a week then resend. So here is what it would look like as far as work flow goes, someone submits a patch, it goes to this database and up to a website with a listview showing all the patches. Anything not merged yet still in the two week window would show up in the list as white meaning still pending. The further up the list we would have patches that were merged and accepted as is, like the following (showing up in green) http://www.winehq.org/pipermail/wine-patches/2008-February/049719.html http://source.winehq.org/git/wine.git/?a=commit;h=ac61b90f87a2062b99f6f7068… The following patch would show up in yellow as the index differs for the Makefile part of the patch as Julliard made local changes http://www.winehq.org/pipermail/wine-patches/2008-February/049720.html http://source.winehq.org/git/wine.git/?a=commit;h=5bad12c6bc3072a2676f0d9ed… Any other patches that don't get merged would show up in the list as red after the one week window went by. The tracker would assume they were rejected. The cool thing about this is that we could directly link it in to bugzilla so that when a patch is applied the bug could get automatically updated. Now this all hinges on being able to use the diff index to do the tracking. I imagine there might be conflicts if your trying to use that as the only data point as its not as long as a real hash, but assuming your only doing a compare over as period of a few weeks or a month I think it would work. Am I wack? Is there even still the desire to have a graphical patch tracking system? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1

re: Code quality (was Re: comctl32: Fix invalid syntax)
by Dan Kegel Feb. 7, 2008

Feb. 7, 2008

Bang Jun-young wrote: >In fact, this is a well known mistake many newbie Win32 developers >make (and fix in minutes). It shouldn't have been in the tree in the >first place if he actually have read the patch. There are a lot of >easily catchable bugs in the tree, for example, potential security >holes like buffer overrun, meaningless comparison of unsigned < 0 (or > > 0), misuse of BOOL vs. HRESULT, misuse of functions such as > strcasecmp(), use of non-portable syntax, etc. Most of them (if not > all) could be filtered out if he have read the patches carefully. >That's the main reason why Wine keeps crashing every time I give it a >try with my Windows apps. I don't think so. In my experience, it's either a missing feature or something more subtle. Outright bugs of the kind you describe are the minority. I think. > Since 1993, Wine has never gotten to the > point where everybody could rely on it for his daily work. It has as > awfully many bugs as Win95. I see something fundamentally > wrong with development process. Nah, Alexandre usually does a good job of screening patches. We're lucky to have such a good maintainer, IMHO. (I say this knowing full well that newbies are put off by how difficult it is to get feedback because I have seen much, much worse maintainers. Imagine if, say, that guy who always yells at the newbies to not paste logs in bug reports was the maintainer. We'd probably lose all our developers in a month.) So you're peeved you don't have commit access. That's understandable, but it's time to get over it. IMHO the single-committer system works pretty well once you get into the swing of it. It actually forces at least one code review on every patch! - Dan

1 0

War on conformance test suite failures!
by Dan Kegel Feb. 7, 2008

Feb. 7, 2008

Great progress was made at Wineconf last year on getting our test suite closer to always passing on wine, but http://test.winehq.org/data/200801301937/#Wine shows that, according to the results collected from people who run programs/winetest on Wine, twelve DLLs' tests are currently failing. (Let alone the test failures on Windows!) http://bugs.winehq.org/show_bug.cgi?id=9916 also talks about the fact that "make test" shows failures. This situation greatly confuses new developers, who assume that any test failure is somehow their fault. And that's a reasonable assumption, let's make it so! It would make validating a new Wine development environment easy -- it'd be great to be able to say If it doesn't pass "make test" with no errors, something's wrong with the build environment. What's the best way to encourage people to fix these problems? Should we designate some upcoming day, week, or month as a conformance test bug squishing party? Should we offer prizes (or at least notoriety) for the person who does the best job fixing conformance test suite bugs (as judged by Alexandre or his designate)? Or is a simple call to arms enough?

5 8

Re: comctl32: Fix invalid syntax.
by Bang Jun-young Feb. 7, 2008

Feb. 7, 2008

18 hours passed, and it looks like Alexandre decided to ignore this...why? This fix is required for Wine to be built with VC2005/2008 (although Alexandre doesn't seem to care about it). On 2/6/08, Bang Jun-young <junyoung(a)mogua.com> wrote: > Any reason why this hasn't been committed? >

3 3

Re: gdi32: correct the test message in font.c that was out of sync with the test. [RESEND]
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 7e560d2..bfdb0af 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c > @@ -604,7 +604,7 @@ static void test_GetGlyphIndices(void) > flags |= GGI_MARK_NONEXISTING_GLYPHS; > charcount = pGetGlyphIndicesW(hdc, testtext, (sizeof(testtext)/2)-1, glyphs, flags); > ok(charcount == 5, "GetGlyphIndices count of glyphs should = 5 not %d\n", charcount); > - ok((glyphs[4] == 0x001f || glyphs[4] == UNICODE_NOCHAR /* Vista */), "GetGlyphIndices should have returned a nonexistent char not %04x\n", glyphs[4]); > + ok((glyphs[4] == 0x001f || glyphs[4] == UNICODE_NOCHAR /* Vista */), "GetGlyphIndices should have returned a nonexistent char or UNICODE_NOCHAR, not %04x\n", glyphs[4]); UNICODE_NOCHAR is a nonexistent char too. And if someone really cares about the exact details they can always look at the test, we don't need to duplicate all of it in the error message. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: make the listbox tests pass in directories other than dlls/user32/tests. [RESEND]
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > diff --git a/dlls/user32/tests/listbox.c b/dlls/user32/tests/listbox.c > index 3645190..f1a7b2b 100644 > --- a/dlls/user32/tests/listbox.c > +++ b/dlls/user32/tests/listbox.c > @@ -560,6 +560,8 @@ static void test_listbox_LB_DIR() > char * p; > char driveletter; > > + fclose( fopen( "wtest1.tmp.c", "w" ) ); Using stdio is not really appropriate here, CreateFile() would be a better choice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: Fix security issue in SHELL_execute.
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > execfunc should not be called on files which aren't supposed to be > executable. This doesn't work: ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlexec.c && touch shlexec.ok shlexec.c:971: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", null, null) failed: rc=31 err=2 shlexec.c:974: Test failed: argvA3 expected 'Lnk', got '(null)' shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\nonexistent.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\nonexistent.noassoc"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\test file.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\/%nasty% $file.shlexec"", null) failed: rc=31 err=2 shlexec.c:1010: Test failed: ShellExecuteEx(null, "C:\windows\temp\\test_shortcut_exe.lnk", ""C:\windows\temp\\test file.noassoc"", null) failed: rc=31 err=2 shlexec.c:1062: Test failed: ShellExecuteEx(null, "Z:\home\julliard\wine\wine\dlls\shell32\tests\shell32_test.exe.so", "shlexec "C:\windows\temp\wt51f.tmp" Exec", null) returned 31 shlexec.c:1064: Test failed: argvA3 expected 'Exec', got '(null)' shlexec.c:1071: Test succeeded inside todo block: ShellExecute(null, "C:\windows\temp\\test file.noassoc", "shlexec "C:\windows\temp\wt51f.tmp" Exec", null) succeeded: rc=31 shlexec.c:1093: Test failed: ShellExecuteEx(null, "Z:\home\julliard\wine\wine\dlls\shell32\tests\shell32_test.exe.so", "shlexec "C:\windows\temp\wt51f.tmp" abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy", null) returned 31 shlexec.c:1095: Test failed: argvA3 expected 'abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy', got '(null)' shlexec.c:1102: Test succeeded inside todo block: ShellExecute(null, "C:\windows\temp\\test file.noassoc", "shlexec "C:\windows\temp\wt51f.tmp" abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxy", null) succeeded: rc=31 make: *** [shlexec.ok] Error 13 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi 2: Handle carriage returns in MsiDatabaseImport
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

"James Hawkins" <truiken(a)gmail.com> writes: > Hi, > > Fixes bug 11479. http://bugs.winehq.org/show_bug.cgi?id=11479 This doesn't work: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so automation.c && touch automation.ok automation.c:276: Test failed: Expected ERROR_SUCCESS, got 1627 wine: Unhandled page fault on read access to 0x00000018 at address 0x6002a3da (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000018 in 32-bit code (0x6002a3da). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6002a3da ESP:0033f400 EBP:0033f578 EFLAGS:00010206( - 00 - RIP1) EAX:00000018 EBX:60121844 ECX:00000018 EDX:0033f5b8 ESI:602adce0 EDI:0033f52d Stack dump: 0x0033f400: 00000000 4d430002 00132fac 00000004 0x0033f410: 600425f6 0033f44c 6065e20e 602adce0 0x0033f420: 0033f5b8 0033f5b8 00000001 7bc417fa 0x0033f430: 00000000 4d430002 00133004 00000004 0x0033f440: 00000010 0033f47c 0033f464 00000030 0x0033f450: 00134180 00110014 00000020 00000000 Backtrace: =>1 0x6002a3da vsnprintfW+0x3ca(str=0x33f67a, len=0x7fffffff, format=0x6065e20a, valist=0x33f5b8) [/home/julliard/wine/wine/libs/wine/string.c:376] in libwine.so.1 (0x0033f578) 2 0x6002a596 sprintfW+0x36(str=0x33f678, format=0x6065e20a) [/home/julliard/wine/wine/libs/wine/string.c:458] in libwine.so.1 (0x0033f5a8) 3 0x60610808 MSI_DatabaseImport+0x13e8(db=0x130ef8, folder=<is not available>, file=0x1329ca) [/home/julliard/wine/wine/dlls/msi/database.c:603] in msi (0x0033f7f8) 4 0x60610b29 MsiDatabaseImportW+0x129(handle=<register EDI not in topmost frame>, szFolder=0x12fcd0, szFilename=0x1329b0) [/home/julliard/wine/wine/dlls/msi/database.c:777] in msi (0x0033f828) 5 0x60610cce MsiDatabaseImportA+0x18e(handle=0x1, szFolder=0x605b43c0, szFilename=0x605a3db7) [/home/julliard/wine/wine/dlls/msi/database.c:803] in msi (0x0033f868) 6 0x60527631 test_Installer+0x571() [/home/julliard/wine/wine/dlls/msi/tests/automation.c:275] in msi_test (0x0033fbd8) 7 0x6052983b func_automation+0xebb() [/home/julliard/wine/wine/dlls/msi/tests/automation.c:2428] in msi_test (0x0033fe68) 8 0x60592cea run_test+0x14a(name=0x1103ec) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:389] in msi_test (0x0033fea8) 9 0x60593332 main+0x142(argc=<register ECX not in topmost frame>, argv=0x1103d0) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:437] in msi_test (0x0033fed8) 10 0x6059340b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x0033ff08) 11 0x7b8744ee start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:883] in kernel32 (0x0033ffe8) 12 0x600288d7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x6002a3da vsnprintfW+0x3ca [/home/julliard/wine/wine/libs/wine/string.c:376] in libwine.so.1: movzwl 0x0(%ecx),%edx 376 while (*striter) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 2/2 start.exe: Handle the process title argument (try3)
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > + vi.dwOSVersionInfoSize = sizeof(vi); > + GetVersionExW(&vi); > + > + /* On Windows 9x start does not have the process title argument. > + It works such that if the first parameter begins with a double quote ("), > + it is taken as the process title. Thus 'start "notepad" a' will work on > + Windows 9x but not NT variants */ > + if(argc > 1 && (vi.dwMajorVersion >= 5 || (vi.dwMajorVersion == 4 && vi.dwPlatformId == 2))) The right way to check for Win9x is GetVersion() & 0x80000000. > + { > + int cmdcount; > + WCHAR* cmdline = GetCommandLineW(); > + WCHAR** cmdargs = CommandLineToArgvW(cmdline, &cmdcount); > + WCHAR* pos = cmdline; > + > + pos += lstrlenW(cmdargs[0]); This won't work if the program name is quoted. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray[3/4]: Better validate icon owner
by Robert Shearman Feb. 7, 2008

Feb. 7, 2008

Kirill K. Smirnov wrote: > @@ -131,15 +130,18 @@ static LRESULT WINAPI adaptor_wndproc(HW > case WM_LBUTTONDBLCLK: > case WM_RBUTTONDBLCLK: > case WM_MBUTTONDBLCLK: > - /* notify the owner hwnd of the message */ > - WINE_TRACE("relaying 0x%x\n", msg); > - ret = PostMessage(icon->owner, icon->callback_message, (WPARAM) icon->id, (LPARAM) msg); > - if (!ret && (GetLastError() == ERROR_INVALID_HANDLE)) > + if (!IsWindow(icon->owner)) > { > WINE_WARN("application window was destroyed without removing " > "notification icon, removing automatically\n"); > delete_icon_directly(icon); > } > + else > + { > + /* notify the owner hwnd of the message */ > + WINE_TRACE("relaying 0x%x\n", msg); > + PostMessage(icon->owner, icon->callback_message, (WPARAM) icon->id, (LPARAM) msg); > + } > break; > > case WM_NCDESTROY: I don't get why you need this change. PostMessage should correctly handle the case where icon->owner has been destroyed and adding a call to IsWindow just introduces a race condition. -- Rob Shearman

2 2

Re: systray[3/4]: Better validate icon owner
by Kirill K. Smirnov Feb. 7, 2008

Feb. 7, 2008

> I don't get why you need this change. PostMessage should correctly > handle the case where icon->owner has been destroyed and adding a call > to IsWindow just introduces a race condition. Just a testcase: 1) run any wine app (to be sure that explorer is running), e.g winecfg 2) run taskmgr 3) select taskmgr process in tasklist and kill it. taskmgr window will dissapear but tray icon not. 4) move mouse cursor over taskmgr tray icon. Before this patch it will not dissapear, but should. The reason is that ERROR_INVALID_HANDLE is not the only value which indicates the absence of owner window (ERROR_INVALID_WINDOW_HANDLE too). I think that using robust and straightforward IsWindow() function is better than verify last error. Is it acceptable to check return value of PostMessage only and do not check last error? And what race condition introduces IsWindow() here? -- Kirill

2 1

Re: [PATCH] dinput: Skip old mouse movement evenets.
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > @@ -280,6 +281,9 @@ static void dinput_mouse_hook( LPDIRECTINPUTDEVICE8A iface, WPARAM wparam, LPARA > { > POINT pt, pt1; > > + /* Skip old movement events */ > + if (This->last_event_time > hook->time) break; That's not an appropriate way to compare timestamps. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: x11drv: implement X11DRV_AlphaRender for non bitmap sources
by Alexandre Julliard Feb. 7, 2008

Feb. 7, 2008

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -1569,12 +1570,14 @@ BOOL X11DRV_AlphaBlend(X11DRV_PDEVICE *devDst, INT xDst, INT yDst, INT widthDst, > > if (!devSrc->bitmap || GetObjectW( devSrc->bitmap->hbitmap, sizeof(dib), &dib ) != sizeof(dib)) > { > - FIXME("not a dibsection\n"); > - return FALSE; > + TRACE("not a dibsection\n"); > + bitmap = FALSE; It can be an invalid handle too, you can't assume that it's a valid bitmap just because it isn't a DIB. Also naming the boolean 'bitmap' for the DIB section case is very confusing, both are bitmaps. > > - if (xSrc < 0 || ySrc < 0 || widthSrc < 0 || heightSrc < 0 || xSrc + widthSrc > dib.dsBmih.biWidth > - || ySrc + heightSrc > abs(dib.dsBmih.biHeight)) > + if (xSrc < 0 || ySrc < 0 || widthSrc < 0 || heightSrc < 0 || (bitmap && xSrc + widthSrc > dib.dsBmih.biWidth) > + || (bitmap && ySrc + heightSrc > abs(dib.dsBmih.biHeight))) Testing the flag all over the place is ugly, you should separate the code completely, have one block for DIBs and one block for DDBs, with a single if at the top. -- Alexandre Julliard julliard(a)winehq.org

1 0

regression in worms2
by luis.busquets＠ilidium.com Feb. 7, 2008

Feb. 7, 2008

The same bug happens in Patrician3.exe If you apply the attached patch if should be ok. Please let me know, if that worked also for you.

3 2

Re: systray[2/4]: correctly handle icon addition/deletion
by Kirill K. Smirnov Feb. 6, 2008

Feb. 6, 2008

В сообщении от Thursday 07 February 2008 02:58:42 вы написали: > Kirill K. Smirnov wrote: > > @@ -71,6 +71,12 @@ struct icon > > static struct tray tray; > > static BOOL hide_systray; > > > > +static BOOL add_icon(NOTIFYICONDATAW *nid); > > +static BOOL modify_icon(NOTIFYICONDATAW *nid); > > +static BOOL delete_icon(const NOTIFYICONDATAW *nid); > > +static BOOL delete_icon_directly(struct icon *icon); > > +static BOOL display_icon(struct icon *icon, BOOL hide); > > + > > /* adaptor code */ > > > > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > > I don't see any reason why you need to add forward declarations for all > of these functions. Hmmmm..... It may be an artifact from my development when I need to call them from places before they defined.... Anyway, is it really bad to have them declared here? If so I'll remove it. -- Kirill

2 1

Re: systray[2/4]: correctly handle icon addition/deletion
by Robert Shearman Feb. 6, 2008

Feb. 6, 2008

Kirill K. Smirnov wrote: > @@ -71,6 +71,12 @@ struct icon > static struct tray tray; > static BOOL hide_systray; > > +static BOOL add_icon(NOTIFYICONDATAW *nid); > +static BOOL modify_icon(NOTIFYICONDATAW *nid); > +static BOOL delete_icon(const NOTIFYICONDATAW *nid); > +static BOOL delete_icon_directly(struct icon *icon); > +static BOOL display_icon(struct icon *icon, BOOL hide); > + > /* adaptor code */ > > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > I don't see any reason why you need to add forward declarations for all of these functions. -- Rob Shearman

1 0

Re: systray[1/4]: rewrite tooltips support
by Kirill K. Smirnov Feb. 6, 2008

Feb. 6, 2008

> Please explain better what you are doing, "rewrite tooltips support" > doesn't say what is changing or why the change is needed (and "rewrite" > is an exaggeration, you are mostly just moving code around). The main issue this patch fixes is an "attempt to set/modify a tooltip to a nonexistent window". This may happen when application modifies tip text while icon is hidden (e.g. when adding initially disabled icon with tooltip). [verbose] The change I did: 1) Store tip text in the icon structure. 2) Move tooltip creation code to the separate function. 3) Immediately bind tooltip to icon window at creation. We can bind empty tooltip text with icon window and further just update text when needed. 4) set_tooltip function was renamed to update_tooltip_text and simplified. Since tooltip support code is relatively small, this was enough for me to exaggeratedly proclaim tooltip support be rewritten ;-) [/verbose] So this ChangeLog is better: Avoid modifying non-existent tooltip windows of non-existent icon windows when application updates tip of hidden icon. -- Kirill

1 0

Re: systray[1/4]: rewrite tooltips support
by Alexandre Julliard Feb. 6, 2008

Feb. 6, 2008

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > diff --git a/programs/explorer/systray.c b/programs/explorer/systray.c Please explain better what you are doing, "rewrite tooltips support" doesn't say what is changing or why the change is needed (and "rewrite" is an exaggeration, you are mostly just moving code around). -- Alexandre Julliard julliard(a)winehq.org

1 0

Building tests with Visual Studio 2005 Express
by Dan Kegel Feb. 6, 2008

Feb. 6, 2008

After giving up for the moment on building with Visual C 6, I tried Visual Studio 2005. First hitch: Boy, does it spew out lots of warnings about deprecated functions! http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=87401&SiteID=1 talks about this a bit; defining _CRT_SECURE_NO_DEPRECATE and _CRT_NONSTDC_NO_DEPRECATE suppresses the warnings. Fix: You can't set them via corewin_express.vsprops because our project is converted from an older visual studio version, so you have to add those two defines to all the .dsp files, e.g. perl -p -i -e 's,/D "WIN32",/D "WIN32" /D "_CRT_NONSTDC_NO_DEPRECATE" /D "_CRT_SECURE_NO_DEPRECATE",' `find . -iname '*.dsp'` Second hitch: For some reason, the imported projects lose their list of .lib files to link against. Fix: As suggested at http://msdn2.microsoft.com/en-us/express/aa700755.aspx add user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib to the "Additional Dependencies" setting in the file corewin_express.vsprops. Third hitch: error C2065: 'PFORM_INFO_2A': undeclared identifier See http://msdn2.microsoft.com/en-us/library/aa383745(VS.85).aspx and http://blogs.msdn.com/oldnewthing/archive/2007/04/11/2079137.aspx winspool.h only defines the new symbol if NTDDI_VERSION is NTDDI_LONGHORN or higher. NTDDI_LONGHORN is 0x06000000. Fix: add /D _WIN32_WINNT=0x0600 to that list of changes to all the .dsp files in hitch #1 above. Fourth hitch: urlmon_test.exe refers to CLSID_IdentityUnmarshal, but that symbol is not defined. ?? Fifth hitch: generated.c refers to CS_STUB_INFO, which is not defined in Microsoft's rpcndr.h. ?? Sixth hitch: it can't find server.h Seventh hitch: can't find tmarshal.h Fix: Not sure, but maybe these files need to be generated by midl, and msvcmaker doesn't know about that yet? See http://www.mail-archive.com/wine-devel(a)winehq.org/msg37442.html Eighth hitch: riched20/tests/editor.c fails to compile because in GETTEXTEX, the field is named lpUsedDefChar, not lpUsedDefaultChar Fix: fix our richedit.h? ... Seventy-seventh hitch: gdiplus/tests/brush.c includes Microsoft's gdiplus.h, but that's not safe to include from C, so you get an error on the namespace. Golly. I guess I won't be building the tests with any flavor of microsoft C any time soon! - Dan

5 6

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Chris Robinson Feb. 6, 2008

Feb. 6, 2008

On Wednesday 06 February 2008 11:44:58 am you wrote: > Chris Robinson wrote: > > I don't think it's correct to add this since it's not supported (the > > extension string isn't exported and it can't be easilly emulated). If an > > app is trying to set that attribute without the extension being > > advertised, I'd say the app is broken. If you're intending on adding > > support, you may want to familiarize yourself with how wine emulates > > render_to_texture and look over the extension: > > http://opengl.org/registry/specs/NV/render_depth_texture.txt > > "I don't think it's correct to add this since it's not supported" > The > > case WGL_BIND_TO_TEXTURE_RGB_ARB: > case WGL_BIND_TO_TEXTURE_RGBA_ARB: > case WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV: > are not supported either. The WGL_BIND_TO_TEXTURE_DEPTH_NV came up as a > fixme since it isn't in the switch. The formats are supported in X11DRV_wglGetPixelFormatAttribivARB, X11DRV_wglCreatePbufferARB and the other render-to-texture functions, and the render-to-texture extension is advertised.. There's just nothing to do in that function for them since the hint will always be accepted. But I don't see the point in supporting a pbuffer creation hint that an app shouldn't be using without the extension being advertised (actually, I think pbuffer creation is supposed to fail if an unsupported attribute is specified). Which app is trying to use it? > Again, just trying to learn, not annoy > people with tiny fixes. No annoyance to me, just explaining why I don't think it's something to handle. :)

1 0

Stupid new winetricks: added a trivial GUI
by Dan Kegel Feb. 6, 2008

Feb. 6, 2008

Some users freak at the thought of a commandline, so I threw together a trivial GUI using whatever gui-from-shell tool is appropriate for the current desktop. Unfortunately, that means the default action is to put up a gui, not show help. You have to say winetricks -h or the like to get help. It's ugly, so shoot me :-) As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/

2 2

Re: RegOverridePredefKey stub - Take 2
by Dmitry Timoshkov Feb. 6, 2008

Feb. 6, 2008

"Jens Nestler" <nessi(a)nessi-online.de> wrote: > Stub implementation for RegOverridePredefKey. > The added prototype in the winreg.h is now in alphabetical order. Please review yuor patches before sending, this one contains not related changes. -- Dmitry.

1 0

Re: [5/8] WineD3D: Add infrastructure for faking driver versions
by Alexandre Julliard Feb. 6, 2008

Feb. 6, 2008

Stefan Dösinger <stefan(a)codeweavers.com> writes: > +/* Certain applications(Steam) complain if we report an outdated driver version. In general, > + * reporting a driver version is moot because we are not the Windows driver, and we have different > + * bugs, features, etc. > + * > + * Some drivers(ATI, Nvidia Linux drivers) have a shared codebase with the Windows driver, so we're > + * reading the Linux driver version and report it to the app. Some drivers(Apple drivers, Mesa) don't > + * have the version match, so we overwrite the OpenGL driver version with a hardcoded one. Obviously > + * the hardcoded driver version is outdated once a new Windows driver is released, so we'll have to > + * keep them in sync manually. > + * > + * If a card is not found in this table, the gl driver version is reported > + */ > +struct driver_version_information { > + WORD vendor; /* reported PCI card vendor ID */ > + WORD card; /* reported PCI card device ID */ > + BOOL loword_matches_apple; /* Are Mac and Win driver versions matching? */ > + BOOL loword_matches_linux; /* Are Lin and Win driver versions matching? */ The world is not limited to Mac and Linux, this sort of thing can't scale. -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: uxtheme: fix the system tests so they pass on Vista. [try 2] [RESEND]
by Alexandre Julliard Feb. 6, 2008

Feb. 6, 2008

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > The Vista return code is what wine is returning, so remove the todo > block as well. Not for me: ../../../tools/runtest -q -P wine -M uxtheme.dll -T ../../.. -p uxtheme_test.exe.so system.c && touch system.ok system.c:420: Test failed: Expected E_POINTER or S_OK, got 0x80070490 make: *** [system.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

winedbg - using pdb from Visual Studio 2005
by Michel Jacques Feb. 6, 2008

Feb. 6, 2008

Hello, I am using PDBs generated with 2005 with wine version 0.9.54. I get errors related to my PDBs and I am wondering if I need to change the pdb format? Anything special to do when using 2005? Here are the errors I get, each time one of my pdb gets loaded: 0009:trace:dbghelp:SymFindFileInPathW (hProcess = 0x30, searchPath = (null), full_path = L"C:\\master\\x86\\debug\\bin\\mydll.pdb", id = 0x34c160, two = 0x00000002, three = 0x00000000, flags = 0x00000008, buffer = 0x34b718, cb = 0x6020fb50, user = 0x34bd30) 0009:err:dbghelp_msc:pdb_process_types -Unknown type info version 20040203 0009:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0009:trace:dbghelp:pcs_callback 0x111998 2 0x34c378 0009:trace:dbghelp:pcs_callback 0x111998 1 0x34c378 0009:trace:dbghelp:pe_load_stabs failed to load the STABS debug info Thanks, Michel Jacques Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

4 5

Re: [winetest] Add a new utility to simply running + submitting tests via winetest when run from the Wine tree.
by Alexandre Julliard Feb. 6, 2008

Feb. 6, 2008

Jeremy White <jwhite(a)winehq.org> writes: > +date +%Y%m%d >build.id > +gcc --version >build.nfo > +uname -a >>build.nfo > +/lib/libc.so.6 >>build.nfo > +echo N/A >tests.url > +make dist > +make > +export WINEPREFIX=`mktemp -d` > +wineprefixcreate > + > +type winetricks >/dev/null 2>&1 > +if [ $? -eq 0 ] ; then > + winetricks gecko > +fi > + > +./winetest-dist -c -t "$1" None of that should be necessary. The make dist stuff is supposed to be for people who want to distribute a winetest binary. If what you want is simply run the tests then you should just have to run winetest; if some things don't work in that mode they should be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Bug in patch winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it.
by Vitaliy Margolen Feb. 6, 2008

Feb. 6, 2008

What bug # is this? Please note this is not bugzilla, you will be expected to debug this problem yourself and provide technical information. Vitaliy Luis C. Busquets Pérez wrote: > There is a bug in the patch: > > c19af910ebafa9b1928b0f67bee68f6b0b237e8e is first bad commit > commit c19af910ebafa9b1928b0f67bee68f6b0b237e8e > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Thu Jan 17 19:53:59 2008 +0100 > > winex11.drv: Don't create a win_data structure for the desktop > window, except in the process that owns it. > > Handle desktop size changes by sending a message to the desktop owner. > > :040000 040000 b7c030353fe92121bb999481724a3689429b2e8a > 80fd2c5f4ace2707abb01648bd61663a6c9d7626 M dlls > > > It affects to Patrician3.exe. When initiating, it hangs and does not > allow to play the movie. Actually, the programm changes the screen > resolution and hangs. I understand that the problem is that it does not > send the appropiate message for binkplayer.exe to play the movie. > >

3 2

New winetricks: msxml6, riched30
by Dan Kegel Feb. 6, 2008

Feb. 6, 2008

Johan Dahlin sent in a patch to add msxml6, and said "It's enough to make msi2xml.exe to at least start-up (before failing in msi later)." Tom Wickline some time ago sent in a suggestion for adding riched30. I didn't know any apps it helped, but apparantly Novell thinks it helps Groupwise a bit. So it's in now. Caution, it doesn't update riched32, no idea what happens if apps try to use it after this... As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/

1 0

regression in worms2
by Olaf Leidinger Feb. 6, 2008

Feb. 6, 2008

Hello! I noticed that the game "worms 2" broke between wine-0.9.53 and wine-0.9.54. A git-bisect revealed the guilty patches. The game includes a frontend.exe which starts game.exe and controls the settings of the game (the map and teams etc.). Running game.exe directly works but you can't alter the settings. When running game.exe via frontend the game doesn't show up but hangs after changing resolution. Before the following commit the game starts and is playable: 2921f5c156b368b4ce6e615eb61dad5c5f423bf8 is first bad commit commit 2921f5c156b368b4ce6e615eb61dad5c5f423bf8 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Jan 22 20:06:35 2008 +0100 server: Invalidate the correct region when custom valid rects are specified. :040000 040000 1385d5899b5b6affd5da84328e1bc15985406976 5c8756013a67c0402f3bb5fb9f3ee7b4a50e124a M server And this one makes worms2 hang after exiting the game: c19af910ebafa9b1928b0f67bee68f6b0b237e8e is first bad commit commit c19af910ebafa9b1928b0f67bee68f6b0b237e8e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Jan 17 19:53:59 2008 +0100 winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it. Handle desktop size changes by sending a message to the desktop owner. :040000 040000 b7c030353fe92121bb999481724a3689429b2e8a 80fd2c5f4ace2707abb01648bd61663a6c9d7626 M dlls Thanks for your attention! Ciao, Olaf

3 7

Re: RegOverridePredefKey stub
by Dmitry Timoshkov Feb. 5, 2008

Feb. 5, 2008

"Jens Nestler" <nessi(a)nessi-online.de> wrote: > diff -urN wine-0.9.54_org/include/winreg.h wine-0.9.54/include/winreg.h > --- wine-0.9.54_org/include/winreg.h 2008-01-25 17:05:38.000000000 +0100 > +++ wine-0.9.54/include/winreg.h 2008-01-28 22:07:55.000000000 +0100 > @@ -131,6 +131,7 @@ > WINADVAPI LSTATUS WINAPI RegLoadKeyA(HKEY,LPCSTR,LPCSTR); > WINADVAPI LSTATUS WINAPI RegLoadKeyW(HKEY,LPCWSTR,LPCWSTR); > #define RegLoadKey WINELIB_NAME_AW(RegLoadKey) > +WINADVAPI LSTATUS WINAPI RegOverridePredefKey(HKEY,HKEY); > WINADVAPI LSTATUS WINAPI RegLoadMUIStringA(HKEY,LPCSTR,LPSTR,DWORD,LPDWORD,DWORD,LPCSTR); > WINADVAPI LSTATUS WINAPI RegLoadMUIStringW(HKEY,LPCWSTR,LPWSTR,DWORD,LPDWORD,DWORD,LPCWSTR); > #define RegLoadMUIString WINELIB_NAME_AW(RegLoadMUIString) Isn't there something that suggests that the entries are alphabetically sorted? -- Dmitry.

2 4

Building tests with MSVC 6 broken?
by Dan Kegel Feb. 5, 2008

Feb. 5, 2008

Call me an oldtimer, but I decided to try building winetest with MSVC 6 today. I installed cygwin's git and perl, grabbed wine from git, and used msvcmaker as described at http://winehq.org/site/docs/winedev-guide/testing-windows I downloaded and installed the Platform SDK from the first google hit, the Windows Server 2003 SP1 Platform SDK, http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3… (although the latest is Windows Server 2003 R2 Platform SDK, I thought the slightly older one would be ok). Oddly, Microsoft's Platform SDK page lists the SP1 SDK as the latest. Pffft. I then used Tools/ Options / Directories to tell msdev about include and lib in both msvc6 and the platform SDK. Then I tried building wineruntests. First hitch: error C2065: 'RRF_RT_REG_DWORD' : undeclared identifier Fix: Move Platform SDK higher in the priority list in Tools / Options / Directories. msdev will then use the newer headers, which have that symbol. Second hitch: Linking... uuid.lib(cguid_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module Error executing link.exe. Fix: From http://blogs.msdn.com/stephen_griffin/archive/2006/08/03/building-mfcmapi-w… In the platform SDK's lib directory, rename uuid.lib to uuid.lib.bad. msdev will then use the older library. (Microsoft intentionally removed VC6 support from the newer one, whoops.) Third hitch: http://www.winehq.org/pipermail/wine-patches/2007-September/043988.html introduced a type LSTATUS into winreg.h. This isn't present in the 2003 SP1 platform sdk, nor in the newer 2003 R2 platform SDK, but as long as only our winreg.h uses it, that's fine. Sadly, that patch uses it elsewhere, so compilation breaks. A google search for LSTATUS at microsoft.com finds nothing. Fix: change the LSTATUS in comctl32/tests/mru.c to LONG (gee, maybe we should move the definition of LSTATUS from winreg.h to advapi32/registry.c, too). (But see below.) Fourth hitch: comdlg32\tests\printdlg.c: error C2064: 'LPPRINTDLGEXW' : undeclared identifier Turns out commdlg.h in the platform sdk only defines LPPRINTDLGEXW if STDMETHOD is declared. STDMETHOD is declared in basetyps.h, but including that file makes commdlg.h not even compile. Bleah. Fix: replace the #include "windef.h" ... "winuser.h" with #include "windows.h" in comdlg32/tests/printdlg.h. Fifth hitch: crypt32/tests/cert.c: error C2081: 'HCRYPTPROV_OR_NCRYPT_KEY_HANDLE': name in formal parameter list illegal Turns out that identifier was introduced in Vista, and added to Wine here: http://www.winehq.org/pipermail/wine-patches/2007-August/042250.html Fix: Uninstall the platform SDK and install the Windows SDK! http://www.microsoft.com/downloads/details.aspx?familyid=c2b1e300-f358-4523… Sixth hitch: c:\program files\microsoft sdks\windows\v6.0\include\specstrings.h: fatal error C1083: cannot open include file 'sal.h' I think sal.h comes with Visual Studio 8 and higher. Crap. Thus it looks like you can't build wine's tests with Visual C 6 and the Microsoft headers anymore. So I tried building with the Wine headers. That blows up with "can't find stdio.h". So I'm stuck. What's the recommended way to build the wine test suite with Visual C 6, if any? - Dan

3 5

re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
by Dan Kegel Feb. 5, 2008

Feb. 5, 2008

James McKenzie wrote: > Please submit a git diff not a UNIX diff. Now, hang on there. Jens submitted a perfectly good unified diff patch taken from the right directory. There is no reason to turn up our noses at it. It will apply using patch in exactly the same way as a diff generated by git. Jens, you're fine, I wouldn't bother rediffing. You might however resend your patch next week when Alexandre the maintainer is back from vacation! - Dan

2 1

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Chris Robinson Feb. 5, 2008

Feb. 5, 2008

On Tuesday 05 February 2008 02:09:09 pm Christopher Harvey wrote: > @@ -758,6 +758,7 @@ static int ConvertAttribWGLtoGLX(const int* iWGLAttr, > int* oGLXAttr, Wine_GLPBuf nvfloatattrib = iWGLAttr[++cur]; > TRACE("pAttr[%d] = WGL_FLOAT_COMPONENTS_NV: %x\n", cur, > nvfloatattrib); break ; > + case WGL_BIND_TO_TEXTURE_DEPTH_NV: > case WGL_BIND_TO_TEXTURE_RGB_ARB: > case WGL_BIND_TO_TEXTURE_RGBA_ARB: > case WGL_BIND_TO_TEXTURE_RECTANGLE_FLOAT_R_NV: I don't think it's correct to add this since it's not supported (the extension string isn't exported and it can't be easilly emulated). If an app is trying to set that attribute without the extension being advertised, I'd say the app is broken. If you're intending on adding support, you may want to familiarize yourself with how wine emulates render_to_texture and look over the extension: http://opengl.org/registry/specs/NV/render_depth_texture.txt

1 0

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Roderick Colenbrander Feb. 5, 2008

Feb. 5, 2008

> This patch doesn't implement the format, simply says that is can't be > converted. This is my first patch, sorry if the format is wrong. Ok not converting the format is fine but you are also changing the return value of wglMakeCurrent. Resubmit the patch without that unneeded change. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: Bug in patch winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it.
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> writes: > It affects to Patrician3.exe. When initiating, it hangs and does not > allow to play the movie. Actually, the programm changes the screen > resolution and hangs. I understand that the problem is that it does not > send the appropiate message for binkplayer.exe to play the movie. What message is that, and why doesn't it send it? -- Alexandre Julliard julliard(a)winehq.org

1 0

OUTB() and friends on Win32 and .sys files
by Uwe Bonnes Feb. 5, 2008

Feb. 5, 2008

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Call for winetest ing
by Jeremy White Feb. 5, 2008

Feb. 5, 2008

Okay, so I got winetest to do something rational, and now I'd like to see if it will work for someone else. It's easy! Just apply this patch to a current Wine tree: http://www.winehq.org/pipermail/wine-patches/2008-February/049675.html Then configure and make Wine as you normally would. Then, cd programs/winetest ./runtests <your-tag-here> (The tag I used was jwhite-etch64; I think you should identify who you are, and then if you have multiple systems, your system within that). If you have winetricks in your path, it should be completely unattended. (If you don't, you'll need to hang around to click 'go' to the Gecko install dialog). After about 5 minutes, your test results should be run and sent up to test.winehq.org. The cron job runs every 5 minutes, so sometime after that, a reload of: firefox http://test.winehq.org/data/`date +%Y%m%d`/ Should show you your results! Easy as Pi! There is still quite a bit to do. First, I'm waiting for a 'real' winetest expert to wack me with a clue bat. But I'll stumble along until the hammer falls... Second, I want to do a stupidity check and make sure that winetest essentially correlates to a make -k test run. If they are not really identical, then we need to fix that problem... Next, I think we should probably shift the build-id from being the date to being the HEAD sha1, but that's a radical enough change that I felt I needed to start simpler and within the current conventions. But I'd really appreciate it if folks could try this and see if we can gather some data quickly. In theory, we should be able to quickly see the common points of failure and know where to attack first. Cheers, Jeremy

5 7

Blocked conformance tests
by Francois Gouget Feb. 5, 2008

Feb. 5, 2008

When I run winetest on Windows XP I get some dialog boxes asking me: Do you want to keep blocking this program? According to the title bar, the impacted tests are: dplayx rpcrt4 'Microsoft DirectPlay Helper' ??? ws2_32 My understanding is that it should only prevent the test from receiving network connections which I guess is not common. Does anyone know if this could cause any test failure currently? How does XP determine whether to block the test or not? Is the 'authorisation' based on the executable hash? If so there's no way to pre-authorise the tests for nightly tests. Should the winetest mark the executable so it is not hampered by this check? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

2 1

Re: kernel32: Implement ReplaceFileW. [RESEND]
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > + /* > + * Open the replacement file for reading, writing, and deleting > + * (writing and deleting are needed when finished) > + */ > + if ((hReplacement = CreateFileW(lpReplacementFileName, > + GENERIC_READ | GENERIC_WRITE, > + FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > + NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > + { > + error = GetLastError(); /* Use error returned by CreateFileW */ > + goto fail; > + } Files should be opened with NtOpenFile the same way MoveFile does, to avoid having to convert path names twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/20] WineD3D: Make Clear aware of the depth stencil sharing
by H. Verbeet Feb. 5, 2008

Feb. 5, 2008

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Stefan already knows this, but just for what it's worth, I've got a more complete fix in my tree for depth stencil sharing. Unfortunately that patch causes a couple of regressions, so it needs more work.

2 2

Re: [7/20] WineD3D: De-Statify depth blit opengl resources
by H. Verbeet Feb. 5, 2008

Feb. 5, 2008

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I was aware of this issue, but technically these resources should be stored in the shader backend, not the device.

2 2

running "make test" results in an error
by Christopher Feb. 5, 2008

Feb. 5, 2008

I tried running "make test" under Ubuntu 7.10, and I just updated to the latest cvs this morning so it's not too old. However, after only running a couple of tests it exited with an error. Is this normal, and if so how do I run the rest of the tests? I attached a log showing which test fails. Christopher make[1]: Entering directory `/home/christopher/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/christopher/wine-git/tools' make[1]: Entering directory `/home/christopher/wine-git/dlls' make[2]: Entering directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so device.c && touch device.ok fixme:win:EnumDisplayDevicesW ((null),0,0x34f8c0,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:753: Test failed: Screen width is 1680 device.c:754: Test failed: Screen height is 1050 err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:798: Test failed: Screen width is 1680 device.c:799: Test failed: Screen height is 1050 err:d3d:IWineD3DDeviceImpl_DrawIndexedPrimitive (0x144548) : Called without a valid index buffer set, returning WINED3DERR_INVALIDCALL fixme:d3d:SetupForBlit >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ context.c / 622 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:transform_projection >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ state.c / 2802 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:IWineD3DDeviceImpl_SetLightEnable Too many concurrently active lights make[2]: *** [device.ok] Error 4 make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d9/tests' make[1]: *** [d3d9/tests/__test__] Error 2 make[1]: Leaving directory `/home/christopher/wine-git/dlls' make: *** [dlls/__test__] Error 2

4 3

Re: kernel32: Add tests for LoadLibraryEx
by Alexandre Julliard Feb. 5, 2008

Feb. 5, 2008

"James Hawkins" <truiken(a)gmail.com> writes: > I'm not sure how you feel this should be fixed. Is there a reason we > don't have tests for ntdll/loader.c? If not, I'd like add some tests > for LdrLoadDll. We don't have tests for it because apps don't use LdrLoadDll, so testing LoadLibraryEx should be enough. Of course if you have an app that depends on a specific behavior of LdrLoadDll then this should be tested. The todo in your test is because builtin dlls are supposed to get loaded even if the corresponding native file doesn't exist, that's a feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

comctl32 failures on Win95, Win98, NT4 asnd Win2K
by Reece Dunn Feb. 5, 2008

Feb. 5, 2008

These tests are all failing consistently with identical failures on these platforms: combobox - 21 failures; all identical across the platforms. datetime - 2 failures; all identical across the platforms. The rebar tests have 146 failures on some (Win95 and NT4) and 545 failures on others (Win98 and Win2K). This looks like it is due to a different comctl32 version as a result of a different IE version. Several of the others have failures on Win95 and Win98 only. Is anyone going to look at these? - Reece

3 2

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de Feb. 5, 2008

Feb. 5, 2008

Oh well, I forgot one point: if you take my example code again, but don't build it under winelib but under windows (i.e. it's a real win application) but later run it with wine it may also fail because all dlls forward to the D3DXCheckVersion of d3dx9_36. I know that you would have implemented another D3DXCheckVersion for each dll, but this again would've ended in the case I mentioned in the first e-mail. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2
by tony.wasserka＠freenet.de Feb. 5, 2008

Feb. 5, 2008

I probably should've gone into a bit more detail about this function: It's just for developer purpose. If you have a very big project and are trying to upgrade e.g. from d3dx9_27 to d3dx9_36 some files may need to be rebuild, some files may not. This function is just there to ensure the developer that all files are built with the right dll. Now THIS means, that we won't ever see an ENDUSER application fail because of a d3dx9 version mismatch. Also, we come to a problem when a user wants to built an application with Winelib, where we can only use one definition of D3DX_SDK_VERSION which only applies to ONE dll. Now just watch following code sample: > #include "d3dx9.h" > > int check_version() { > if( D3DXCheckVersion( D3D_SDK_VERSION, D3DX_SDK_VERSION ) == FALSE ) { > MessageBox( NULL, "D3DX9 Versions don't match!", "Error!", MB_OK ); > exit( 1 ); > } > } Now, if a Winelib user compiles this, D3DX_SDK_VERSION is 9 (as its specified in our current d3dx9core.h). But if the program requires to be built with d3dx9_36 (and thus uses our implementation of D3DXCheckVersion) it will report an error as D3DX_SDK_VERSION was expected to be 36. So, the only thing we can test in this function is if D3DX_SDK_VERSION is between 24 and 36, which are all compatible versions (also, no enduser application will need the accurate implementation as stated above). I have made a mistake though, when I defined D3DX_SDK_VERSION to be 9, which was caused by my somewhat old installation of the DX SDK, which is incompatible with d3dx9_24 to d3dx9_36. (it was statically linked at that time), You don't need correct this in your patch, as this will be addressed in one of my future patches, I am just waiting for Julliard to (hopefully) accept my d3dx9_24 patch. In conclusion, all you have to do is replace the line > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion==D3DX_SDK_VERSION)); with > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion>=24 && D3DXSdkVersion <=36)); (Could also be => and =<, ain't that familiar with it) Best regards, Tony

1 0

winetest experience
by Jeremy White Feb. 5, 2008

Feb. 5, 2008

Okay, so I boldly tried to use winetest with what documentation I could find, and had an...um...interesting time. I created these files: [jertop] cat build.id fcccd9fca605d1d4c462df5c33f4bacf03bdda5f [jertop] cat build.nfo A Large Shovel [jertop] cat tests.url http://www.IDontKnowWhatURLToPutHere.com/ [jertop] did a make dist, and then did: ./winetest -c -t "jw-etch32" It ran, did it's thing, and had one interactive thing (Gecko fussed at me; that's not a Winetest bug afaik). Then when it was all done, it transferred my nearly 1 MB file, and then errored out with: "Unknown build id" So then I looked at the output file, and sure enough, it had a - for build info, not my fancy git id. So I hacked that, put in jwtip, and then ran winetest -s to send my output file through. And then I have a lovely result here: http://test.winehq.org/data/jwtip/ So that's *something* at least. Although I suspect someone will now have to go clean up my mess :-/. So...what's the convention for build.id etc? And why didn't they get set? Cheers, Jeremy

2 2

re: running "make test" results in an error
by Dan Kegel Feb. 4, 2008

Feb. 4, 2008

Christopher raccoonone at procyongames.com wrote: >I tried running "make test" under Ubuntu 7.10, and I just updated to the >latest cvs this morning so it's not too old. However, after only running >a couple of tests it exited with an error. Is this normal Sadly, yes. See http://bugs.winehq.org/show_bug.cgi?id=9916 Believe it or not, the situation was much worse five months ago. At the last Wineconf, Jeremy White got everybody to spend a whole day just fixing test failures. We could use something like that again. > and if so how do I run the rest of the tests? Elementary, my dear Watson. "make -k test". - Dan

2 1

winedbg pdb issue - n00b
by Michel Jacques Feb. 4, 2008

Feb. 4, 2008

Hi. I've have setup my debug build (with pdbs) and MSVCRT debug dlls. When stopping on a breakpoint with winedbg, I get a stack of calls in winedbg which does not contains any function info from my dlls or app. I only get hex offset of call within my dll. But I do see the information for wine sources though, function name + line number. What do I need to do so that winedbg can extract info from my pdb? Thanks, Michel Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

2 1

attempt to install Wine from source
by Mike Harrison Feb. 4, 2008

Feb. 4, 2008

Dear Sir; This below is the config.log I got from trying to install Wine (a source archive from a British Linux mag) on to my AMD64 m/c under Debian 4.0. 64 bit OS. A similar message was obtained from an attempt to install Wine on my AMD64 laptop under Ubuntu 7.04. (not 64 bit). From the report log I can't identify just what went wrong. My aim is to use Wine to run Windows XP applications on both machines, and if possible Windows Vista applic'ns on the laptop - both machines running 32 bit applic'ns. My first priority for this is MS Excel XP pro. From a brief visit to WineHQ today (the connection died for some unknown reason) I believe it may not be as straightforward a project as I had hoped. Please tell me either what I must do to load/install my Wine source package, or where I have to go for help to go a little further. I prefer to load the sources I already have, plus supplementary programs, if that's possible. Any advice you can give would be appreciated. Thanks; Mike Harrison This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Wine configure 20050830, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure -C --prefix=/usr/local ## --------- ## ## Platform. ## ## --------- ## hostname = ultima uname -m = x86_64 uname -r = 2.6.18-4-amd64 uname -s = Linux uname -v = #1 SMP Mon Mar 26 11:36:53 CEST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/bin/X11 PATH: /usr/games ## ----------- ## ## Core tests. ## ## ----------- ## configure:1249: creating cache config.cache configure:1424: checking build system type configure:1442: result: x86_64-unknown-linux-gnu configure:1450: checking host system type configure:1464: result: x86_64-unknown-linux-gnu configure:1504: checking whether make sets $(MAKE) configure:1524: result: yes configure:1579: checking for gcc configure:1605: result: gcc -m32 configure:1849: checking for C compiler version configure:1852: gcc -m32 --version </dev/null >&5 ./configure: line 1853: gcc: command not found configure:1855: $? = 127 configure:1857: gcc -m32 -v </dev/null >&5 ./configure: line 1858: gcc: command not found configure:1860: $? = 127 configure:1862: gcc -m32 -V </dev/null >&5 ./configure: line 1863: gcc: command not found configure:1865: $? = 127 configure:1888: checking for C compiler default output file name configure:1891: gcc -m32 conftest.c >&5 ./configure: line 1892: gcc: command not found configure:1894: $? = 127 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "20050830" | #define PACKAGE_STRING "Wine 20050830" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:1933: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-unknown-linux-gnu ac_cv_build_alias=x86_64-unknown-linux-gnu ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-unknown-linux-gnu ac_cv_host_alias=x86_64-unknown-linux-gnu ac_cv_prog_ac_ct_CC='gcc -m32' ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ALSALIBS='' AR='' ARTSCCONFIG='' ARTSINCL='' ARTSLIBS='' AS='as --32' AUDIOIOLIBS='' BISON='' BUILTINFLAG='' CC='gcc -m32' CFLAGS='' COREFOUNDATIONLIB='' CPP='' CPPBIN='' CPPFLAGS='' CROSSCC='' CROSSTEST='' CROSSWINDRES='' CRTLIBS='' CURSESLIBS='' CXX='' CXXFLAGS='' DEFS='' DLLDEFS='' DLLEXT='' DLLFLAGS='' DLLIBS='' DLLTOOL='' DLLWRAP='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ESDCONFIG='' ESDINCL='' ESDLIBS='' EXEEXT='' EXTRACFLAGS='' FONTFORGE='' FONTSSUBDIRS='' FREETYPEINCL='' FREETYPELIBS='' GLU32FILES='' GLUT32FILES='' GLUT_LIBS='' ICULIBS='' IMPLIBEXT='' INSTALL_DATA='' INSTALL_PROGRAM='' INSTALL_SCRIPT='' IOKITLIB='' LCMSLIBS='' LD='ld -m elf_i386' LDAPLIBS='' LDCONFIG='' LDD='' LDDLLFLAGS='' LDEXECFLAGS='' LDFLAGS='' LDLIBWINEFLAGS='' LDPATH='' LDSHARED='' LEX='' LEXLIB='' LEX_OUTPUT_ROOT='' LIBEXT='' LIBOBJS='' LIBPTHREAD='' LIBS='' LINT='' LINTFLAGS='' LN='' LN_S='' LTLIBOBJS='' MAIN_BINARY='' NASLIBS='' OBJEXT='' OPENGLFILES='' OPENGL_LIBS='' PACKAGE_BUGREPORT='wine-devel(a)winehq.org' PACKAGE_NAME='Wine' PACKAGE_STRING='Wine 20050830' PACKAGE_TARNAME='wine' PACKAGE_VERSION='20050830' PATH_SEPARATOR=':' PKG_CONFIG='' PRELINK='' RANLIB='' SANEINCL='' SANELIBS='' SET_MAKE='' SHELL='/bin/sh' SOCKETLIBS='' STRIP='' TOOLSDIR='' WIN16_FILES='$(WIN16_FILES)' WIN16_INSTALL='$(WIN16_INSTALL)' WINDRES='' WINE_BINARIES='' XFILES='' XLEX='' XLIB='' XML2INCL='' XML2LIBS='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ac_ct_AR='' ac_ct_AS='' ac_ct_CC='gcc -m32' ac_ct_CPPBIN='' ac_ct_CXX='' ac_ct_DLLTOOL='' ac_ct_DLLWRAP='' ac_ct_LD='' ac_ct_RANLIB='' ac_ct_STRIP='' ac_ct_WINDRES='' bindir='${exec_prefix}/bin' build='x86_64-unknown-linux-gnu' build_alias='' build_cpu='x86_64' build_os='linux-gnu' build_vendor='unknown' datadir='${prefix}/share' exec_prefix='NONE' ft_devel2='' ft_devel='' host='x86_64-unknown-linux-gnu' host_alias='' host_cpu='i386' host_os='linux-gnu' host_vendor='unknown' includedir='${prefix}/include' infodir='${prefix}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localstatedir='${prefix}/var' mandir='${prefix}/man' oldincludedir='/usr/include' prefix='/usr/local' program_transform_name='s,x,x,' sane_devel='' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' ## ------------- ## ## Output files. ## ## ------------- ## MAKE_DLL_RULES='' MAKE_IMPLIB_RULES='' MAKE_LIB_RULES='' MAKE_PROG_RULES='' MAKE_RULES='' MAKE_TEST_RULES='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" #define PACKAGE_NAME "Wine" #define PACKAGE_STRING "Wine 20050830" #define PACKAGE_TARNAME "wine" #define PACKAGE_VERSION "20050830" configure: exit 77

4 3

winehq.org down?
by James Hawkins Feb. 4, 2008

Feb. 4, 2008

Hey guys, I'm having problems connecting to the winehq.org server. Is this a known issue? -- James Hawkins

6 6

cabinet: Include wine/port.h for strcasecmp().
by Kirill K. Smirnov Feb. 3, 2008

Feb. 3, 2008

>The rules are as follows: > * For case insensitive comparisons of 'windows strings', a Windows > function must be used (stricmp() or similar). and >In this case, KERNEL32 lstrcmpiA() would be more appropriate. In >general, using stricmp() in Win32 code should be discouraged since it >may cause unnecessary dependency on MSVCRT. Wine lstrcmpi is broken (bug #10767). There are cases GLIBC strcasecmp and Windows lstrcmpi handle correctly but wine not. Should we fix this first? -- Kirill

2 1

Re: winex11.drv: Use bitwise NOT not logical NOT
by Marcus Meissner Feb. 2, 2008

Feb. 2, 2008

On Sat, Feb 02, 2008 at 05:43:27PM +0000, Andrew Talbot wrote: > Changelog: > winex11.drv: Use bitwise NOT not logical NOT. > > diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c > index d68b674..2cd36c7 100644 > --- a/dlls/winex11.drv/settings.c > +++ b/dlls/winex11.drv/settings.c > @@ -369,10 +369,10 @@ LONG X11DRV_ChangeDisplaySettingsEx( LPCWSTR devname, LPDEVMODEW devmode, > devmode->dmBitsPerPel,devmode->dmDisplayFrequency, handler_name); > > dwBpp = devmode->dmBitsPerPel; > - if (devmode->dmFields & DM_BITSPERPEL) def_mode &= !dwBpp; > - if (devmode->dmFields & DM_PELSWIDTH) def_mode &= !devmode->dmPelsWidth; > - if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= !devmode->dmPelsHeight; > - if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= !devmode->dmDisplayFrequency; > + if (devmode->dmFields & DM_BITSPERPEL) def_mode &= ~dwBpp; > + if (devmode->dmFields & DM_PELSWIDTH) def_mode &= ~devmode->dmPelsWidth; > + if (devmode->dmFields & DM_PELSHEIGHT) def_mode &= ~devmode->dmPelsHeight; > + if (devmode->dmFields & DM_DISPLAYFREQUENCY) def_mode &= ~devmode->dmDisplayFrequency; I do not think this is right, def_mode is a boolean and we actually check for not-0-being of various struct members. Ciao, Marcus

3 3

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov Feb. 1, 2008

Feb. 1, 2008

"Bang Jun-young" <junyoung(a)mogua.com> wrote: >> > cabinet: Include wine/port.h for strcasecmp(). >> >> If a Wine DLL uses strcasecmp() then it's a bug. It should >> use an appropriate kernel32 API instead. > > I know, but it's too late. The tree is already contaminated with such > functions and quite a number of other unnecessary Wine-specific APIs > which shouldn't have been in the first place. It doesn't mean that instead of replacing them you can simply make an impression that it's OK to just hide the bug. -- Dmitry.

3 2

What's needed to make gdb work again?
by Maarten Lankhorst Feb. 1, 2008

Feb. 1, 2008

Hi folks, I've been trying some debugging with kdbg (Graphical kde debugger), but it fails on wine because it can't attach to a process. While it is of course possible to use WINEDEBUG flags, I want to be able to use a full debugger, and not just deduce from logs what happened, but rather be able to see the corresponding lines of source as well. so would it be possible to make gdb work with winedbg again, and perhaps make it understand threads this time? Cheers, Maarten.

2 1

test.winehq.org
by Stefan Leichter Feb. 1, 2008

Feb. 1, 2008

Hello, i just noticed that the test results for advapi32:service tests are not available for the last build (http://test.winehq.org/data/200801301937/) It looks like the parser did not create the files. Can someone familar with this stuff have a look? Thanks Stefan

4 4

Review comparing Wine and Vista for running games
by Dan Kegel Feb. 1, 2008

Feb. 1, 2008

http://wastingtimewithmikeandari.wordpress.com/2008/01/31/linux-has-better-… It'd be nice if we ran those games properly, but still, at least we didn't lock the system.

3 2

Re: cabinet: Include wine/port.h for strcasecmp().
by Dmitry Timoshkov Feb. 1, 2008

Feb. 1, 2008

"Bang Jun-young" <junyoung(a)mogua.com> wrote > cabinet: Include wine/port.h for strcasecmp(). If a Wine DLL uses strcasecmp() then it's a bug. It should use an appropriate kernel32 API instead. -- Dmitry.

1 0