- Wine-devel - list.winehq.org

RE: Get rid of W->A calls: LoadImageW
by Patrik Stridvall 19 Nov '02

19 Nov '02

> > Index: wine/windows/cursoricon.c [snip] > > - if (!screen_dc) screen_dc = CreateDCA( "DISPLAY", > NULL, NULL, NULL ); > > + if (!screen_dc) screen_dc = CreateDCW( DISPLAYW, [snip] > I don't see the point of this at all. Why does it matter that we're > calling CreateDCA here? it's not as if we're losing information by > converting a Unicode to an Ascii string. Policy reason: "No Unicode function should call an ASCII function if a Unicode variant of that function exists." But sure semantically speaking it might not make any difference in this case.

1 0

Re: problem with treeview
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

Here's the output from +treeview: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger... "Dustin Navea" <Speeddymon(a)ev1. To: Steve Lustbader/ANR/MS/PHILIPS(a)AMEC net> <wine-devel(a)winehq.org> cc: 11/19/2002 03:35 Subject: Re: problem with treeview PM Classification: Try running wine with --debugmsg +treeview and post that somewhere to look at.. -Dustin ----- Original Message ----- From: <steve.lustbader(a)philips.com> To: <wine-devel(a)winehq.org> Sent: Tuesday, November 19, 2002 1:51 PM Subject: problem with treeview > My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. > A backtrace is available at http://www.lustbader.net/bt.txt, and I can > provide any other debug output if anyone thinks it will help. > TreeView_InsertItem is called like this: > > TVITEM tviFoo; > tviFoo.mask = TVIF_TEXT | TVIF_PARAM; > tviFoo.pszText = LPSTR_TEXTCALLBACK; > tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL > TVINSERTSTRUCT tvinsFoo; > tvinsFoo.hParent = TVI_ROOT; > tvinsFoo.hInsertAfter = TVI_LAST; > tvinsFoo.item = tviFoo; > HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); > > Any ideas? > > -Steve > > >

1 0

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> Am Die, 2002-11-19 um 15.17 schrieb Patrik Stridvall: > > > One thing that you shouldn't assume is for example that > > if a function exists its reentrant variant exists as well. > Sure, got that. > > > And yes, you really should use the > > reentrent variant if present as well as having an > > alternative implementation if not. > > Hmm - really really always? This generates messy code, > and a lot of effort for very rare cases. Bad formulation. What I meant is that the code shouldn't depend on the existance of the reentrant function since it is not that unlikely that some platforms might only have the non reentrent one only. Still, I think we might need such a strict policy regardless. > I think we need a compromise, something in the line of either > > - a) use non-reentrant functions, protecting them with a critical > section (IMO ok for rarely called functions) or That is potentially slow since it uses locks. Not that likely to be a problem with the getpw* functions though but still... > - b) use only reentrant and treat the case where these aren't > available like the case where the respective functions aren't > available at all. No, not a good solution. There are rational reasons to not have the reentrent variants. > Of course b) would only be viable if a sufficiently large portion of > systems that support the non-reentrant variant support the > reentrant one > as well. I have no idea whether that's the case for the getpwXYZ > functions. If are on a embedded platform it is not entirely unlikely that it is possible to configure and compile the C library to not handle reentrancy issues in order to optimize for space. In fact it might make sense be able compile Winelib as not supporting reentrency either. It is a post 1.0 issue IMHO, but we should have a policy planning for that possiblity nether the less. So strictly speaking, we should IMHO do #ifdef HAVE_GETPWUID_R /* Use getpwuid_r */ #elsif defined(HAVE_GETPWUID) # ifdef _REENTRANT /* Lock. Use getpwuid. Unlock */ # else /* Use getpwuid */ # endif #else /* Fail gracefully */ #endif However adding the #ifdef _REENTRANT is a post 1.0 issue IMHO. > > As to the implict existance question: I'm not sure. > > First of all, to answer the related question: > > Should you have a alternative implementation for > > defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? > > > > IMHO the answer is no. It is not worth the effort to > > support hypotetical platforms unless we can verify the > > existance of one. > > Very true. Perhaps the practical way would be to assume > HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with > a really strange platform complains (but see below). Assume yes, however I think the should also verify as below. > > I suggest that we should detect the presence or absence > > of ALL function we use that is verified not to exist on > > some platform and have for example code like > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + > > defined(HAVE_GETPWENT)) == 3 > > # define __HAVE_GETPW > > # else > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > > > in order to formalize the assumptions and generate a common > define to use in > > the code. > > Well I'd say that for a start we could simply do something like > > /* CAUTION: If there turns out to be some insane platform that has > * getpwuid() but not getpwnam() and getpwent(), this must be > * improved. > */ > #define __HAVE_GETPW HAVE_GETPWUID > > This would keep bloat out of configure in the first place, while > providing a generic __HAVE_GETPW macro for possible later use. As Alexandre said, having a special define is completely unnessary. Just test for existance of whatever function when you call it.

1 0

problem with treeview
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

My app calls TreeView_InsertItem, which leads to a crash in ntdll.dll. A backtrace is available at http://www.lustbader.net/bt.txt, and I can provide any other debug output if anyone thinks it will help. TreeView_InsertItem is called like this: TVITEM tviFoo; tviFoo.mask = TVIF_TEXT | TVIF_PARAM; tviFoo.pszText = LPSTR_TEXTCALLBACK; tviFoo.lParam = (LPARAM)pFoo; //pFoo is guaranteed to be non-NULL TVINSERTSTRUCT tvinsFoo; tvinsFoo.hParent = TVI_ROOT; tvinsFoo.hInsertAfter = TVI_LAST; tvinsFoo.item = tviFoo; HTREEITEM hTreeFoo = TreeView_InsertItem(m_hWndUserTree, &tvinsFoo); Any ideas? -Steve

2 1

dlls/cabinet : CVS repository problem ?
by Sylvain Petreolle 19 Nov '02

19 Nov '02

When I updated my cvs tree (update -APd), I had problems with dlls/cabinet. It didn't add the files created by this patch : http://www.winehq.com/hypermail/wine-cvs/2002/11/0179.html The directory itself is unknown in the repository : [syl(a)snoop dlls]$ cvs update 2>&1 |tee cvslog ? cabinet ? cvslog cvs server: Updating . M Makefile.in cvs server: Updating advapi32 cvs server: Updating advapi32/tests ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

msvcrt vs std incl
by Dimitrie O. Paun 19 Nov '02

19 Nov '02

Hi guys, Here's a small test program: #include <windows.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int main() { printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t)); return 0; } And I want to compile this with our msvcrt headers. Look what happens: [dimi(a)dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:1257: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winbase.h:1258: parse error before "va_list" In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:4459: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winuser.h:4460: parse error before "va_list" In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:13:20: stdarg.h: No such file or directory In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:135: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:175: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:176: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:177: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:184: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:211: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:212: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:213: parse error before "va_list" test.c:4:20: assert.h: No such file or directory test.c: In function `main': test.c:8: `wchar_t' undeclared (first use in this function) test.c:8: (Each undeclared identifier is reported only once test.c:8: for each function it appears in.) [dimi(a)dimi wine]$ First off, are we supposed to die on the va_list stuff? Second, why is wchar_t undeclared? -- Dimi. P.S. Please do not ask why so many includes, I know they are not needed, but it should work, right?

5 11

Question: domain name
by Martin Wilck 19 Nov '02

19 Nov '02

Using a default domain name in Wine would be beneficial for certain Netapi functions. While it's no big deal to add a config option for that, there is the Windows registry value DefaultDomainName in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon which could be used for exactly that purpose. Is it better to - use a Wine config key, - use the above MS key, - or use both, the Wine key overriding the MS one if set? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: Configure question
by Patrik Stridvall 19 Nov '02

19 Nov '02

> I am thinking about some netapi32 improvements where I'd need to call > the functions of the getpw/getgr family: getpwnam(), getpwent(), > getgrent(), etc. > > Configure checks for the "pwd.h" header and getpwuid(). Must > I add more > checks for all the functions I use, or is it ok to assume that > getpwuid() presence implies getpwnam() presence? Good question. I'm don't think we have any policy concerning this. Perhaps we should have. One thing that you shouldn't assume is for example that if a function exists its reentrant variant exists as well. For example that fact getpwnam exists doesn't imply that getpwnam_r exists. And yes, you really should use the reentrent variant if present as well as having an alternative implementation if not. As to the implict existance question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the existance of one. To return to the original question: I suggest that we should detect the presence or absence of ALL function we use that is verified not to exist on some platform and have for example code like #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + defined(HAVE_GETPWENT)) == 3 # define __HAVE_GETPW # else # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif in order to formalize the assumptions and generate a common define to use in the code. Comments? Suggestions?

3 2

Re: CoInitialize
by steve.lustbader＠philips.com 19 Nov '02

19 Nov '02

>> On 13 Nov 2002 at 14:39, steve.lustbader(a)philips.com wrote: >> >> > One of the threads in my app calls CoInitialize, expecting it >> > to return S_OK (in fact, it's followed by an assert statement >> > requiring that it returns S_OK). When I run it in Wine, however, >> > CoInitialize returns S_FALSE, implying that this thread has >> > already initialized the COM library. Other threads call >> > CoInitialize, but this is the first time that this thread calls it. >> > Does Wine initialize COM differently from Windows? Are the other >> > threads' calls to CoInitialize screwing up this thread's call? > >Sort of, the problem is that Wine doesn't support apartments yet, so it >doesn't try to keep track of the threads that has called CoInitialize. > Does this mean that COM isn't being initialized properly for the calling thread, or only that it appears not to be initialized properly? -Steve

2 1

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis 19 Nov '02

19 Nov '02

Hi, Has started working again for me - but I am still Puzzled as to what the problem was! Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Gustavo Junior Alves Sent: Tuesday, November 19, 2002 9:49 PM To: Keith Matthews Cc: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) The command LPRT is used for ipv6 over FTP, but I don't know any FTP servers that allow this command, maybe oftpd. Keith Matthews wrote: >On Tue, 19 Nov 2002 16:29:09 +1100 >"Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > > > >>Hi, >> >>While trying to connect to the wineHQ ftp site, I am getting the >>following error with IE6: >> >>200 Type set to A. >>500 Illegal PORT command. >>500 LPRT not understood >> >> >> > >Don't know about the last error, but the illegal PORT is typically seen >when trying to use active FTP from behind a firewall that does not >support it. > >Command-line MS FTP clients don't support passive mode and I have heard >reports that IE does not also. If that is the problem you'll have to >switch to a Linux box or find a windows FTP client that supports >passive. > >

2 1