October 2002 - Wine-devel - list.winehq.org

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We could do that following instead: > > (1) /usr/include/wine => /usr/include/wine/windows > > (2) /usr/include/wine/wine => /usr/include/wine/windows/wine > > (3) /usr/include/wine/wine/wine => /usr/include/wine > > > > Also note (2) will disappear eventually. > > Well, it's somewhat better, but it's still too complex IMO. Where is the complexity? If you want to port a Window application, you add -I/usr/include/wine/windows and everything as much as like under Windows as possible. If you in addition wish to call some Wine "extension" no problem just do #include "wine/foo.h" or similar. If you just want to use the Windows API in an Unix application you need anything at all. Just do #include "wine/windows/wincrypt.h" and you're done. [Linking is a separate problem, of course. But then, this changes nothing as far as this is concerned] > Maybe what > we should do is put the (3) headers directly in /usr/include, like > /usr/include/wine_unicode.h. But this would work only if we don't have > many of them, so we probably want to work on simplifying this first. I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h None of them requires any -I. It is more a convention that if you have many .h you have a directory, if not, well then you can have a directory anyway, it is up to you. > Also note that this is not going to solve your problem, because > wine/test.h is more a category (2) header Well wine/test.h is really kind of a special case anyway it could be moved to programs/winetest/include/wine or something under whatever name it is not really a concern. Perhaps we should move programs/winetest/wtmain.c to test/ and make it a library similar to library/ and unicode/. This is what I did with MSVC, eventhough I did it in programs/winetest instead. > (or maybe you need a new > category for Wine internal headers that don't get installed). You mean for files like windef16.h? Well, in the long run such files really belongs in the dlls/* directories. In the extent that that can't they really are Wine "extension" that might as well be used by any Winelib application not just internally should IMHO be installed. But yes, we certainly need some place to put them in the meantime, since this isn't happing over night. However I think that they can remain in include/wine/ until we move them one by one. See below. > > PS. Of course we could move include/*.h to include/wine/windows or > > something like that but then it is no real use and beside it ruins > > the cvs patch log. Better stick to the ugly include/wine/wine > > solution interally IMHO. > > Not an option. If we have to move the files we'll move them; it's > better to avoid moving things around too much. but we shouldn't let > CVS limitations impose a broken structure. OK. > Now if we can find a non > broken structure that also doesn't involve moving files that's better. Perhaps this would work: mkdir library/wine mv include/wine/{library,port}.h library/wine mkdir unicode/wine mv include/wine/unicode.h unicode/wine mkdir dlls/ntdll/wine mv include/wine/exception.h dlls/ntdll/wine Sure it would mean a few more -I internally but it would not be that bad. Then during install all these files as well as some files from include/wine/ ends up in /usr/include/wine and the include/ files end up in /usr/include/wine/windows or /usr/include/wine/win32 not sure what is best. That would require moving a minimum of files. As before eventually far in the future include/wine/ would be empty. Transition done. We needn't move everything right now either. As mentioned before running the Wine test with the Microsoft headers currently AFAICS only requires that we fix wine/{exception,test,unicode}.h. Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though.

3 2

using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

3 2

Re: updated dlls/comctl32/commctrl.c comments
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 03:02 pm, Christian Neumair wrote: > Dimitrie started posting a header doc patch for listview.c, so I got > motivated and wrote the same thing for commctrl.c. > I hope it's complete. Thanks, Chris. In many respects, this is more important than code. For many reasons I will not go into here, I think it is vital that we have a header giving a _clear_ pictures of what remains to be done. I just hope others will do the same. -- Dimi.

1 0

Re: Don't return FILE_ATTRIBUTE_SYMLINK
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 04:25 pm, Medland, Bill wrote: > diff105.diff Can you please insert such files in the body of the message? It gets combersome to review patches in attachments... -- Dimi.

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I suggest that we gradually move the files in include/wine > > to include/wine/wine or in some cases other places like the DLL > > directories. Eventually, far in the future, the > include/wine directory > > will be empty (save for a wine directory). > > > > This provides a slow and steady migration path from the old > > to the new that doesn't have any of the problems you described. > > What more can you ask for? > > A clean solution? Seriously this is ugly as hell; It would have been nice if had been cleaner yes, but then you can't have everything can you? :-) Seriously, I think we can do a little better. See below. > especially when you > consider that after you install you will get Wine headers in > /usr/include/wine, /usr/include/wine/wine and > /usr/include/wine/wine/wine. Correct. [I think we understand each other at least this time] > Tell me this isn't confusing... First of all you have /usr/include/wine and /usr/include/wine/wine even today. Which already is a little confusing. But hey it works for most thing so I'm not complaining that much. But yes, it is a little confusing. Hmm. Thinking.... We could do that following instead: (1) /usr/include/wine => /usr/include/wine/windows (2) /usr/include/wine/wine => /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine => /usr/include/wine Also note (2) will disappear eventually. This would be very nice since now normal Winelib applications ie ports from Windows can do -I/usr/include/wine/windows regardless of whether they use the Wine "extensions" or not since #include "wine/test.h" for example will work without a -I. "Special" Winelib application could do #include "wine/windows/wincrypt.h" without any -I if somebody for example wanted to use the Windows encryption API in a normal Unix application. Hmm. Perhaps /usr/include/wine/windows should be /usr/include/wine/win32 instead, with perhaps /usr/include/wine/windows as symbolic link to /usr/include/wine/win32. But that is just details, what do you think in principle. > If you really want to make it possible to mix and match headers from > different sources, you need a more serious redesign of the whole > include layout, and you need to ensure that the normal case is at > least as easy and clean as it is today. I think the suggestion above would do nicely. Internally in the wine tree I think we might have to choose the ugly include/wine/wine solution, but we could install to the solution above which is what's really important. PS. Of course we could move include/*.h to include/wine/windows or something like that but then it is no real use and beside it ruins the cvs patch log. Better stick to the ugly include/wine/wine solution interally IMHO.

2 1

An RPC progress report
by Greg Turner 22 Oct '02

22 Oct '02

On Tuesday 22 October 2002 12:47 pm, you wrote: > Greg - > > I've been following the RPC merges lately, > looks like a lot of stuff added. I browsed > the code, but I couldn't really get a grasp > on some of it. That's OK, I'm not sure /I've/ got a grasp on some of it !! ;) > I was just wondering if > you'd like to write an update (short, long, > whatever) about what you've done, what's left > to do, major stumbling blocks, etc. I'll > include it in the next issue of Wine Weekly > News. Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extentions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler). My target right now is to get a "hello world" API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement "properly." I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near. Now, what remains to be done? Well, as Ove mentions in the TODO for his units, "a whole lot." Here are several things in no particular order: - widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler does some really wierd stuff. Then again, we don't neccesarily have to make widl work like MIDL, so it could be worse. - RPC has a quite featureful error handling mechanism; none of it is implemented right now. - The server portions of the patch don't seem to be getting accepted by Alexandre. My guess is that once I have a working test he'll conceed to let this in. To implement this properly is tricky and possibly beyond my abilities; Ove seems to think the right way to do this is to use LPC (Local Procedure Call, another undocumented monster). LPC has no implementation in wine and is not going to be trivial to create. - there are several different memory allocation schemes for MSRPC. I don't even understand what they all are yet, much less have them properly implemented. - MSRPC provides impersonation capabilities which currently are not possible to implement in wine. - Some transports are not yet implemented. The existing transport implementations are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call, etc --- the various types of low-level plumbing that can be used to connect the client and the server). - Data marshalling is the means by which RPC represents data across process and machine boundaries. MSRPC extends NDR format for this. The wire protocol is mostly documented, but the MS API's to convert data-types in memory into NDR are not. This, alone, is a sizable chunk of work. - ORPC is RPC for OLE; once we have a working RPC framework, we can use it to implement out-of-process OLE client/server communications. This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE expert (hell, I'm no RPC expert :) - Surely there is much more stuff I am forgetting. Like Ove said, it's "a whole lot" of stuff, approximately as big a project as, say, DirectX. Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to "solve" this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the "real" work, and deserves way more credit than me for any success I may achieve in the near future). wish me luck, -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

2 2

Re: using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

Thanks for the advice, this should get me by for now. Of course I would still like DllOverrides section to work as advertised, but maybe I can hack on it some more when I am more in the mood. P.S. Sorry about the HTML message, the Hotmail admins seem to be playing around with default settings. -- Jeff S. >From: Greg Turner To: "Jeff Smith" , wine-devel(a)winehq.com On Tuesday 22 >October 2002 01:01 pm, Jeff Smith wrote: > I know I must be missing > >something very simple, but I cannot seem to > > get native regedit to run. The builtin version always > runs instead. >The only thing I could think of was an entry > in DllOverrides: > > "regedit.exe" = "native, builtin". That did not work. > > > I have debugged a little and know MODULE_GetLoadOrder > is returning >{LOADORDER_BI, LOADORDER_DLL, LOADORDER_INVALID, > LOADORDER_INVALID} even >when I add that DllOverride line. > But I am just not in the mood at the >moment for deep digging if > I can help it. > -- Jeff S. >Well, if my wetware HTML parser is working today, I think I understand your >problem. Just rename regedit.exe to "winregedit.exe" (or whatever you >like), or create a symlink or copy of the native version. (some configs >don't respect symlinks). > >-- >gmt _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps (2) and (3) are not much different (se below), > > but (1) and (2/3) are clearly different. > > Well yes, that why they are in different directories. (1) is in > include and (2/3) is in include/wine. Yes, but because of how they are positioned in the filesystemet and used by C they are effectively "packaged together" in a bad way. It seems that I'm not the only one having this problem as well. Steven Edwards also wants a way to use the Mingw/W32api package together with Wine in a sane way. But I have a plan how to smoothly migrated from the current layout to a new layout. See below. > > That is why I think "-I../../include" shouldn't automatically give > > you (2) and (3) as it does now. Having to add -I../../include/wine > > or whatever to get it would make it possible in addition to > > solving my MSVC Microsoft header problem to make it possible to > > uses the Microsoft headers or whomevers headers even on Linux. > > The problem is that then you require everybody who wants to use > Winelib to add stuff to their include path, even if they don't use any > Wine header directly (since our Windows headers reference the Wine > ones). They currently do, yes. That is why I initially suggested creating a include/wine/wine and only moving the "extension" headers like over to include/wine/wine. The "extension" headers are files in include/wine like debug.h, exception.h, library.h, port.h, server.h, test.h, unicode.h that isn't or shouldn't be included by our Windows headers. In the extent that they are it is a bug IMHO and AFAICS one that is quite easily fixed in most cases as well. However, in the first phase to get the all the tests running I AFAICS only need exception.h, test.h and unicode.h. Of them only unicode.h is currently used by the Wine headers (file.h and heap.h). However fixing that shouldn't really be a problem. I will look into it. I suggest that we gradually move the files in include/wine to include/wine/wine or in some cases other places like the DLL directories. Eventually, far in the future, the include/wine directory will be empty (save for a wine directory). This provides a slow and steady migration path from the old to the new that doesn't have any of the problems you described. What more can you ask for? > So you are making the normal case more complex to simplify the > very unusual case of mixing headers. I prefer to ask people who want > to mix headers to do some extra steps and make the common case as easy > as possible. As stated above the problem can be solved. Wine itself is AFAIU (not tested) fixed by this patch. Nothing more should be needed. Index: Make.rules.in =================================================================== RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.131 diff -u -r1.131 Make.rules.in --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 22 Oct 2002 09:02:33 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ Normal Winelib application have shouldn't (and needn't) use the Wine "extension" header so they don't need the in the include path them. The few application that does, can be very easily fixed simply by adding an additional -I, which isn't to much to ask IMHO.

3 2

Problem with X11 driver
by Till Mossakowski 22 Oct '02

22 Oct '02

Hi, I have a problem with the X11 driver (it seems), related to bug 1027. When I run my program (Fitch.exe), wine gets stuck. All threads do a WaitForMultipleObjects, the main thread a WaitMessage. And I get an error err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080b8780 I read the FAQ about critical section errors, and it helped my to get the following calling stack: KERNEL32.DLL.WaitForMultipleObjectsEx+0x16a X11DRV.DLL.MsgWaitForMultipleObjectsEx+0xf3 USER32.DLL.MsgWaitForMultipleObjectsEx+0x14f USER32.DLL.WaitMessage+0x22 WINAWT.DLL.PrintEmbeddedFrame+0x7ca JAVAI.DLL.mmiFrameMethod+0x3625 JAVAI.DLL.mmiFrameMethod+0xb60 COMDLG32.DLL.PrintDlgExW+0x2a2dc0 JPEG.DLL..reloc+0x12e2cb9b *** Invalid address 0xc308c483 (IBMJITC.DLL..reloc+0x1df5f482) (Indeed, Fitch is written in Java - however, unfortunately it is not possible to run it directly under Linux. I also tried to get diagnostic messages from the Java runtime systems, but it seems that all classes are loaded correctly, and then the error occurs.) When I set "Synchronous" = "Y" in the x11drv section of config, everything works, but *very* slowly. Sometimes it takes 15 seconds until a mouse click leads to the desired action. I also played with the other x11drv settings in the config file, but without effect. The documentation says that one should set "Synchronous" = "Y" for debugging purposes. But how proceed then? Greetings, Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till(a)tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till

2 7

OleAut32.dll.DispCallFunc
by Fabian Cenedese 22 Oct '02

22 Oct '02

Hi all My app stumbled over a not implemented function from oleaut32.dll called DispCallFunc. It's only available as stub. I tried to find some info about this but it's an undocumented "feature". MSDN doesn't mention it at all (obviously) and on the net I could only find this short description: *** ITypeInfo::Invoke (or DispInvoke) needs v-table to call-in a method. But when we are talking about pure disp-interfaces - they don't have any info about v-table, but just a mapping between DISPID and method signature. Therefore these functions would fail miserably to convey the call to pure dispinterface, but as all we know - the majority of sources(/events) interfaces are these pesky dispinterfaces. DispCallFunc is a low-level routine (that btw is used by DispInvoke and ITypeInfo::Invoke internally). It pushes arguments from DISPPARAMS argument to the stack accordingly to supplied description of the method, calls specified function pointer and on the return adjusts stack back and return retval (both variant and HRESULT) to the caller. *** And I also found this example: *** //Helper for invoking the event HRESULT InvokeFromFuncInfo(void (__stdcall T::*pEvent)(), _ATL_FUNC_INFO& info, DISPPARAMS* pdispparams, VARIANT* pvarResult) { T* pT = static_cast<T*>(this); VARIANTARG** pVarArgs = info.nParams ? (VARIANTARG**)alloca(sizeof(VARIANTARG*)*info.nParams) : 0; for (int i=0; i<info.nParams; i++) pVarArgs[i] = &pdispparams->rgvarg[info.nParams - i - 1]; CComStdCallThunk<T> thunk; thunk.Init(pEvent, pT); CComVariant tmpResult; if (pvarResult == NULL) pvarResult = &tmpResult; HRESULT hr = DispCallFunc( &thunk, 0, info.cc, info.vtReturn, info.nParams, info.pVarTypes, pVarArgs, pvarResult); ATLASSERT(SUCCEEDED(hr)); return hr; } *** Does anyone know more about this function? Where would this have to be implemented? Thanks bye Fabi

2 1