November 2006 - Wine-Devel - list.winehq.org

Bugs with new 'installer' keyword
by Dan Kegel Nov. 3, 2006

Nov. 3, 2006

I think the new 'installer' keyword is on every bug that needs it now. http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keyw… shows 94 downloadable apps with keyword 'installer'. Here's a breakdown by component: 24 wine-misc 17 wine-ole 15 wine-msi 7 wine-binary 6 wine-net 4 wine-x11 4 wine-msxml 3 wine-programs 3 wine-kernel 2 wine-user 2 wine-setupapi 2 wine-richedit 1 wine-shdocvw 1 Wine-Rebar 1 wine-msvcrt 1 wine-gdi-(printing) 1 wine-directx-d3d James is taking on the msi and setupapi ones, I think. Anyone else interested in plowing through these to see if we can resolve all the installer bugs before 1.0? - Dan

4 6

make test for 06/11/03 Wine
by Jozef Stefanka Nov. 3, 2006

Nov. 3, 2006

Hi ! I tested "make test" with today's (06/11/03) Wine checkouted from winehq.org CVS Testing system : Open SuSE 10.1 (i586), kernel : 2.6.16.13-4-default, glibc : 2.4-28 Failed tests : comctl32, kernel32, mshtml, user32 Logs are attached. Jozef

1 0

Re: ntdll: Add a stub implementation for RtlDllShutdownInProgress.
by Robert Shearman Nov. 3, 2006

Nov. 3, 2006

Mike McCormack wrote: > +NTSTATUS WINAPI RtlDllShutdownInProgress(void) > +{ > + FIXME("\n"); > + return STATUS_SUCCESS; > +} For undocumented functions like this, you should add a test case. -- Rob Shearman

2 3

mscoree: change WCHAR version[ ] in GetCORVersion to prevent a crash
by Louis. Lenders Nov. 3, 2006

Nov. 3, 2006

> >This will break the Acid Pro Media installer. It specifically checks >for the first value. I'm guessing your installer specifically checks >for the second value. I don't have a proper solution, just letting >you know that another installer will break. -- >James Hawkins Looks like it needs more testing then. will have another look later. Regards --------------------------------- Try the all-new Yahoo! Mail . "The New Version is radically easier to use" The Wall Street Journal

1 0

ntdll: Add a stub implementation for RtlDllShutdownInProgress
by Louis. Lenders Nov. 3, 2006

Nov. 3, 2006

a little test shows it returns some unknown status on my xp lap[top: 0x7c927f00, so likely not STATUS_SUCCESS. diff --git a/dlls/ntdll/tests/rtl.c b/dlls/ntdll/tests/rtl.c index 59871de..588e33e 100644 --- a/dlls/ntdll/tests/rtl.c +++ b/dlls/ntdll/tests/rtl.c @@ -66,6 +66,7 @@ static RTL_HANDLE * (WINAPI * pRtlAlloca static BOOLEAN (WINAPI * pRtlFreeHandle)(RTL_HANDLE_TABLE *, RTL_HANDLE *); static NTSTATUS (WINAPI *pRtlAllocateAndInitializeSid)(PSID_IDENTIFIER_AUTHORITY,BYTE,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,PSID*); static NTSTATUS (WINAPI *pRtlFreeSid)(PSID); +static NTSTATUS (WINAPI *pRtlDllShutdownInProgress)(void); #define LEN 16 static const char* src_src = "This is a test!"; /* 16 bytes long, incl NUL */ static ULONG src_aligned_block[4]; @@ -97,6 +98,7 @@ static void InitFunctionPtrs(void) pRtlFreeHandle = (void *)GetProcAddress(hntdll, "RtlFreeHandle"); pRtlAllocateAndInitializeSid = (void *)GetProcAddress(hntdll, "RtlAllocateAndInitializeSid"); pRtlFreeSid = (void *)GetProcAddress(hntdll, "RtlFreeSid"); + pRtlDllShutdownInProgress = (void *)GetProcAddress(hntdll, "RtlDllShutdownInProgress"); } strcpy((char*)src_aligned_block, src_src); ok(strlen(src) == 15, "Source must be 16 bytes long!\n"); @@ -848,6 +850,13 @@ static void test_RtlComputeCrc32(void) ok(crc == 0x40861dc2,"Expected 0x40861dc2, got %8x\n", crc); } +static void test_RtlDllShutdownInProgress(void) +{ + DWORD ret; + + ret = pRtlDllShutdownInProgress(); + ok(0x7c927f00 == ret,"Expected 0x7c927f00, got %08x\n", ret); +} typedef struct MY_HANDLE { @@ -933,4 +942,6 @@ START_TEST(rtl) test_HandleTables(); if (pRtlAllocateAndInitializeSid) test_RtlAllocateAndInitializeSid(); + if (pRtlDllShutdownInProgress) + test_RtlDllShutdownInProgress(); } Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: configure.ac: Turn off the stack protector for the preloader. (resend)
by Alexandre Julliard Nov. 3, 2006

Nov. 3, 2006

Mike McCormack <mike(a)codeweavers.com> writes: > --- > configure.ac | 14 ++++++++++++++ > loader/Makefile.in | 1 + > 2 files changed, 15 insertions(+), 0 deletions(-) It's better to fix the preloader to setup the proper environment, like we already do for some other variants of that problem. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shlexec: buffer work
by Alexandre Julliard Nov. 3, 2006

Nov. 3, 2006

Aric Stewart <aric(a)codeweavers.com> writes: > + len = ExpandEnvironmentStringsW(sei_tmp.lpFile, NULL, 0); > + if (len>0) > + { > + LPWSTR buf; > + buf = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); > + > + ExpandEnvironmentStringsW(sei_tmp.lpFile, buf, len+1); > + HeapFree(GetProcessHeap(), 0, wszApplicationName); > + dwApplicationNameLen = len+1; > + wszApplicationName = buf; > + > + sei_tmp.lpFile = wszApplicationName; > + } The indentation is all messed up, please fix your editor settings. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winhlp32 implementation
by Kirill K. Smirnov Nov. 2, 2006

Nov. 2, 2006

Eric, there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: what winhelp calls "topic", winhlp32 calls "context", and what winhelp calls "Context" winhlp32 calls "Topic without CNT section". So, the buttons are messed too. I suspect there are other "features". We couldn't implement winhlp32 and winhelp in one box. I suggest to at least get rid of old winhelp interface in favor of winhlp32, and create symlink winhelp->winhlp32 in windows directory. Does it save the day? >IMO, we don't need two apps but we could make most apps believe both >winhelp & winhlp32 are present and put all effort into a single application >we should also reimplement winhelp based on richedit for the rendering >A+ richedit sound very good - select/copy very easy! (but riched32 is not complete yet) -- Kirill K. Smirnov

3 3

Re: comctl32: Don't free user32 objects with a gdi32 function in imagelist test.
by Alexandre Julliard Nov. 2, 2006

Nov. 2, 2006

Robert Shearman <rob(a)codeweavers.com> writes: > Use DestroyIcon for releasing the resources associated with created icons. That's probably correct, but it causes the test to fail: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so imagelist.c && touch imagelist.ok imagelist.c:344: Test failed: icon 1 wasn't deleted imagelist.c:345: Test failed: icon 2 wasn't deleted imagelist.c:346: Test failed: icon 3 wasn't deleted imagelist.c:380: Test failed: icon 1 wasn't deleted imagelist.c:381: Test failed: icon 2 wasn't deleted imagelist.c:382: Test failed: icon 3 wasn't deleted make[2]: *** [imagelist.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: toolbar[7/8]: use the width of the current button instead of nButtonWidth to position the icon (fixes bug #3459)
by James Hawkins Nov. 1, 2006

Nov. 1, 2006

On 11/1/06, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > BTNS_AUTOSIZE buttons can have a non-standard width. > You forgot the patch. -- James Hawkins

1 0

Re: mscoree: change WCHAR version[ ] in GetCORVersion to prevent a crash
by James Hawkins Nov. 1, 2006

Nov. 1, 2006

On 11/1/06, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Hi, this, on top of previous patch, makes the directx redistributable 9.0c > october 2006 install succeed fine instead of crashing. > > > Send instant messages to your online friends http://uk.messenger.yahoo.com > diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c > index d3e522e..a17cc23 100644 > --- a/dlls/mscoree/mscoree_main.c > +++ b/dlls/mscoree/mscoree_main.c > @@ -100,7 +100,7 @@ DWORD _CorValidateImage(LPCVOID* imageBa > > HRESULT WINAPI GetCORVersion(LPWSTR pbuffer, DWORD cchBuffer, DWORD > *dwLength) > { > - static const WCHAR version[] = > {'1','.','1','.','4','3','2','2',0}; > + static const WCHAR version[] = > {'1',',','1',',','4','3','2','2',0}; > This will break the Acid Pro Media installer. It specifically checks for the first value. I'm guessing your installer specifically checks for the second value. I don't have a proper solution, just letting you know that another installer will break. -- James Hawkins

1 0

Re: Patch for opengl32.dll.so
by Jesse Allen Nov. 1, 2006

Nov. 1, 2006

On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> wrote: > Hi, > > The last release of Wine 0.9.24 contains an error in the code of opengl32.dll.so > under X11 : Wine tries to get the address of "wglGetIntegerv" (line 608 of > dlls/opengl32/wgl.c) before the extensions of WGL have actually been loaded > (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading of the > wglGetIntegerv address fails and afterwards, whenever internal_glGetIntegerv() > is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception is raised. This is probably already fixed in the git tree. See the commit: winex11.drv: Fixed the prototype of many OpenGL functions. Jesse

2 1

Re: [advpack] Fix typo's
by James Hawkins Nov. 1, 2006

Nov. 1, 2006

On 10/31/06, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > most likely lstrcat was intended. I haven't checked why this lead to errors on > Windows and not on Wine. > It works in XP, at least, because you don't have to specify a full pathname to the INF file. The test that shows that is just a couple lines up. Wine's implementation matches XP. -- James Hawkins

2 1

Re: gdi32: Remove call to CreateCompatibleDC() from GetDIBits() implementation (try 1)
by Alex Villacís Lasso Nov. 1, 2006

Nov. 1, 2006

Alex Villacís Lasso escribió: > Alex Villacís Lasso escribió: >> Huw Davies escribió: >>> On Fri, Oct 20, 2006 at 05:49:09PM -0500, Alex Villacís Lasso wrote: >>> >>>> This is the first attempt at a patch that will fix the debug >>>> assertion when icons are rendered into metafiles (triggered by >>>> Enterprise Architect 6.5, and possibly others). This patch simply >>>> removes mentions of memdc, created by a call to >>>> CreateCompatibleDC(), and redirects calls to GetDIBColorTable() to >>>> use the original DC instead of memdc. Intends to fix bug #6439. Now >>>> with patch. >>>> >>>> >>> >>> This can't work, since the bitmap needs to be selected into the dc for >>> GetDIBColorTable to succeed and you're not allow to call GetDIBits >>> with the bitmap selected into the dc... >>> >>> Huw. >>> >> Please correct me if the details of my understanding are wrong in any >> way. >> >> The problem is that in the wine implementation, the palette is *not* >> stored anywhere inside the returned HBITMAP from CreateDIBSection(). >> Instead, the HDC used by CreateDIBSection must implement the >> pCreateDIBSection (this already leads to loss of palette information >> if it doesn't, for example in enhmfdrv), and then pCreateDIBSection >> is called, and somehow associates the HBITMAP with the actual >> implementation (in winex11drv, an XContext is used to save the >> pointer to a X_PHYSBITMAP, indexed by the HBITMAP). The method of >> getting to the palette information given an arbitrary DIB HBITMAP is >> private to the driver, and the functions contained in the BITMAPOBJ >> structure are not enough - a PHYSDEV is also required, usually >> provided by the DC. Million dollar question: what happens in the >> current implementation if a DIB created with a reference DC that >> saves the palette with method A is used with GetDIBits() and a >> reference HDC that expects a PHYSDEV with a different method B of >> saving the palette? Also, how do we get the palette information from >> GetDIBits() if the reference HDC does not support pGetDIBColorTable()? >> >> Given that, I thought of a few solutions to get the palette >> information from a DIB without CreateCompatibleDC(): >> - Select the HBITMAP into the reference DC inside the implementation >> of GetDIBits(), then call GetDIBColorTable() on the reference DC. >> Although the HBITMAP should not be selected into the reference DC >> before calling GetDIBits(), MSDN says nothing about GetDIBits() >> itself selecting the bitmap into the reference DC. >> - Add a new field to BITMAPOBJ with the PHYSDEV from the reference >> DC. Then, the corresponding function pGetDIBColorTable could be >> called with the proper parameters without the need of a new DC. >> Palette information is still lost if reference DC of CreateDIBSection >> does not support pCreateDIBSection(). >> - Add a new field to BITMAPOBJ for the sole purpose of storing a copy >> of the DIB palette when calling CreateDIBSection(), and use it for >> GetDIBits(). Requires synchronization when calling >> SetDIBColorTable(), and possibly in other places, and also a rewrite >> of GetDIBColorTable(). However, this has the advantage that no >> palette information will be lost when creating a DIB section with a >> reference DC that does not implement pCreateDIBsection. The best >> method IMHO. >> >> What do you think of these suggestions? Any comments are welcome. >> >> Alex Villacís Lasso >> > Here is a patch that implements option 3 described above. > > Changelog: > * Store a copy of the DIB palette when creating a dibsection, and use > it to remove the need to use CreateCompatibleDC() in GetDIBits() > function. > > ------------------------------------------------------------------------ > > > Any comment on this patch (whether it needs cleaning up or anything else)? -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

1 0

select() on sockets considered harmful, use poll() instead?
by Dan Kegel Nov. 1, 2006

Nov. 1, 2006

This probably won't bite us for a while, but I noticed several uses of select() on sockets in the wine source code. This will fail in programs that need more than FD_SETSIZE file descriptors if one of the sockets being selected on happens to have a value of FD_SETSIZE or higher. Glibc fixes FD_SETSIZE at 1024, and does not allow this limit to be changed. Wine also uses poll(), which does not suffer from this limitation. We might want to rewrite this code to use poll() instead of select() sometime. The suspect statements are: dinput/joystick_linux.c: if (1>select(This->joyfd+1,&readfds,... dinput/joystick_linuxinput.c: if (1>select(This->joyfd+1,&readfds,... icmp/icmp_main.c: while ((res=select(icp->sid+1,&fdr,... netapi32/nbt.c: r = select(fd + 1, &fds, ... wininet/internet.c: if (select(nSocket+1,&infd,... wininet/netconnection.c: if (select(connection->socketFD+1,&infd,... ws2_32/socket.c: if( (highfd = select(highfd + 1, p_read, p_write, p_except, timeoutaddr)) Instance of select() that don't use file descriptors (i.e. that are just for delay) are safe, as are instances in conformance tests. Might make a nice little project for a new wine hacker... - Dan

1 0

Executing wine over make segfaults.
by Jimmy W Nov. 1, 2006

Nov. 1, 2006

I got a simple problem, that got really hard to fix. I am trying to cross-compile stuff over a Makefile with ms compiler. Problem is that when make are executing wine as a command, wine segfaults. An example: # wine --version Works! But: Makefile --------- test: wine --version --------- Then run: #make test Wine will segfault! I have tried making a wrapper that will reset env and argv fith static values, and then exec wine with totally new variables, and still fails. Specifications: ubuntu edgy, wine 0.9.22 running as local user. Thankfull for all help. Jimmy Wennlund

3 3