- Wine-Devel - list.winehq.org

Re: the dreaded rpcss patch (rpc_J_PL0)
by Alexandre Julliard Nov. 20, 2002

Nov. 20, 2002

Greg Turner <gmturner007(a)ameritech.net> writes: > * configure; > configure.ac; > dlls/rpcrt4: .cvsignore, Makefile.in, rpc_binding.h, rpcrt4.spec, > rpcrt4_main.c, rpc_epmap.c (new); > include: rpcdce.h, rpcdcep.h, rpcndr.h, winbase.h; > include/wine: rpcss_shared.h (new); > programs: Makefile.in; > programs/rpcss (new dir): .cvsignore (new), Makefile.in (new), > README (new), atomicity.c (new), epmap_server.c (new), > named_pipe_kludge_client.c (new), named_pipe_kludge_server.c (new), > rpcss.h (new), rpcss_main.c (new): > Greg Turner <gmturner007(a)ameritech.net>, > Ove Kåven <ovek(a)transgaming.com> > - a preliminary implementation of endpoint-mapping via a new > on-demand server-ish process ("rpcss.exe.so") > - more header fixups > - (re)implement RpcEpRegisterA, RpcEpUnregister, and RpcEpResolveBinding > using the new rpcss functionality > - update the todo list in rpcrt4_main.c a bit A few things: - Please don't name files 'kludge_something'; this makes it impossible to implement things properly without renaming files. - Don't share C files between rpcrt4 and rpcss, just copy the stuff you need (and at least atomicity.c doesn't seem necessary at all, you could just as well make mutex calls directly). - Please get rid of the various #ifdefs. - It would be better to put the README documentation directly in rpcss_main.c, people don't notice README files in subdirectories. -- Alexandre Julliard julliard(a)winehq.com

2 4

Diablo II fails after a recent cvs update..
by Dustin Navea Nov. 20, 2002

Nov. 20, 2002

Going to start Diablo II after an update last night (after not updating for a couple of days) causes a crash. What debugmsgs would be needed to fix this I dunno, but I suppose I could do a regression test.. Anyone wanna take a look after I post the results of the regression test (probably some time thursday)? -Dustin

1 0

Wine merge required: COM/OLE header changes
by Ove Kaaven Nov. 20, 2002

Nov. 20, 2002

These patches are against ReWind and requires some merging work in order to apply to Wine. Could someone (hm... Greg?) do that for me? The fundamental idea here is to make sure that no files except unknwn.h ever include wine/obj_base.h directly, because the IUnknown interface definition will soon move to unknwn.h, and the API function prototypes will move to objbase.h (which indirectly includes unknwn.h through objidl.h). While I was at it, I also made sure that a couple of common to-be-IDL-generated files aren't included directly, as the headers in question have wrapper headers that are supposed to contain related API function prototypes - these prototypes will also be moved later, so I thought I might as well ensure that the wrapper headers are used now. The attached comhdr1.diff contains header changes and #ifdef guards that force a compilation error if any of these "forbidden" headers are included directly. It seems to apply to Wine as-is. (And I think the #ifdef guards should be applied to Wine even if #ifdefs aren't popular around here, because it protects against introduction of new bad code in Wine while the conversion is in progress; and when a particular header has been successfully converted, its respective #ifdef guard will of course be removed again.) The attached comhdr2.diff seems to fix all the resulting compilation errors in ReWind, and is what needs "merging". Apply as much of it as you can and fix the compilation errors that remain in Wine. Thanks.

2 1

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Still I think the code should verify that any assumptions > > made str really true, if possible. Like: > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && > > defined(HAVE_GETPWENT)) > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > There is absolutely no reason to do that, because we shouldn't assume > anything like that. As I said, if you use getpwnam() you check for > HAVE_GETPWNAM; whether getpwuid() also exists or not is completely > irrelevant. Well, the problem is it is possible that you in order to fail gracefully needs to do different things depending on whether some other function exists or not. OK, the functions meantioned above are not likely to have side effect or something else that effect the other functions in any relevant way. But there might be function pairs, tripples etc that does. Sure you can say that since any function might fail any code should always be able to handle a missing function as well since it in some abstract meaning it sufficiently similar to a normal failure. But regardless, I think it is good to make it clear that he or she who wrote expects certain things to be true and things might not work if they are not true. I somebody hits the "assertion" they can audit the code and if it seems that it doesn't matter they can modify the "assertion" to whatever is proper in the light of the new different enviroment. If it does matter they will modify the code accordingly... Somehow this seems much better than just hoping that the orginal programmer handled all error cases correctly...

1 0

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > > > 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). > > There's no reason to do that, it's trivial to check for both. If you > use getpwnam() check for HAVE_GETPWNAM, if you use getpwuid() check > for HAVE_GETPWUID. Simple, logical, and works even on strange > platforms. Of course. It was so obvious that I missed it. :-) Still I think the code should verify that any assumptions made str really true, if possible. Like: #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && defined(HAVE_GETPWENT)) # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif

2 1

RE: Stub implementation of CABINET.DLL
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> >However, when I saw that not much happend despite > >getting code from cabextrect under LGPL I thought > >that perhaps people were having trouble on how > >to create a new DLL in Wine and how to extract > >the declarations from the Microsoft header without > >creating a derived work. I have done it many > >times before so thought why not do it... > > > >So I very happy that somebody is intrested in continuing. > > > >PS. If anybody have some other DLL that they wish to implement > >but don't now how to do it, don't hesitate to ask me to > >create a stub DLL with related headers. > > If it is not too much effort, could you elaborate on the > derived work issue. I have been thinking about trying to > stub out, then work at implementing, a particular component. > Rather than have someone else do the work, I am more > interested in learning about doing it myself, and about > any issues (legal and technical) involved. > I am not asking for a complete howto here, but even a > summary of the highlights would be quite valuable (to me > at least). First of all copyright doesn't protection facts or ideas only a specific (and unique) expression of facts and ideas. This is normally called a work. Specifically it doesn't protect any underlying functionally inherent or derivable from the work. This is normally called the implementation of the functionallity. Even more specifically it doesn't protect the way interaction with any functionallity, that is possible to derived from the work, is done. This is normally called the interface to the functionallity. Header files for the most part defines interfaces; more specifically constant declarations (read: defines), function declarations, type declarations and. So all such things are free for taking. However netherless the less, the header file is not entirely free of possible protected expression. Specifically: 1. Formatting 2. Comments 3. Inline functions and complex macros I will address each them in turn. Formatting is not normally any problem since there are not that many way to format C declarations, none of which is likely to be unique to Microsoft, let alone expressive. Still I always format the new file in a way I personally like, just in case. Comments are are probably the largest proplem. They are not strictly part of the interface so if you are unsure you can just remove them. In most cases, in fact the intresting cases, however they contains facts about the interface. Note however I said _contains_ facts not are facts. Part of them might be protected expression so we have to be careful here. Again, note that in order to be protected an expression have to unique as well as expressive. Most short sentences are neither unique, nor are they expressive, they just explain the facts in some straight forward way. Still if the not formulated in a way I as well would use the express myself I rewrite them. As for longer sentences and specificially multi sentence paragraphs. I usually delete or reformulate and often shorten it using my own words. The comments are, as I said, not strictly needed in for the header file to work. Inline function and complex macros can be a little tricky. However they are usually rare so rewriting them in a way I would have written it is not that much work and functinallity in itself is I said explain above not protected by copyright.

1 0

RE: Get rid of W->A calls: LoadImageW
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> > 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 Nov. 19, 2002

Nov. 19, 2002

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 Nov. 19, 2002

Nov. 19, 2002

> 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 Nov. 19, 2002

Nov. 19, 2002

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