January 2003 - Wine-Devel - list.winehq.org

Re: Problem in dlls/ddraw/dsufrace/main.c

by Lionel Ulmer

> trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface > (0x402a9418)->Looking for caps: 4,0,1,1 output: 0x741ed0 > Caps are : DDSCAPS_BACKBUFFER > trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Surface: > (0x402a9b38) caps: 1000601c,0,0,0 > Surface caps are : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP > DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM > trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface Returning surface > 0x402a9b38 with description : > - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP > DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM > - DDSD_HEIGHT : 480 > - DDSD_WIDTH : 640 > - DDSD_PITCH : 1280 > - DDSD_LPSURFACE : 0x424b0000 > - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B 001f) Well, you completely lost me here... Could you restate your problem from the beginning ? Because well, in your trace, I see that you actually FOUND a valid attached surface. So the 'if (found == NULL)' test will be FALSE and thus whether this code is in or not would not change anything at all. So I doubt that removing this piece of code would change anything in the application's behaviour. The only thing I could see would be that you were running with a quite old CVS version and when you ugraded you got one fix I did on the GetAttachedSurface code to handle some problem we had with useless caps in the DDSCAPS structure being tested whereas they should not have been. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 8, 2003

Re: Symbol stripping?

by Mike Hearn

What does gcc prior to 3.1 do with the -gstabs+ flag? If it ignores it, or it's implied anyway, we could just have it always on. If not then I have some bash here that can parse the output of gcc -v and determine whether it's >= 3.1, would that be acceptable as a patch to configure.ac? The only other way would be to compile a little test app then run objdump on it to figure out if stabs data was included, but testing the GCC version would be faster. On Tue, 2003-01-07 at 09:19, Shachar Shemesh wrote: > Eric Pouech wrote: > > > aren't you, by any chance, compiling with gcc >= 3.1 ? > > if so, you need to force emission of stabs as a debugging format while > > running configure > > something like this should work > > CFLAGS=-gstabs+ ./configure > > Maybe we should patch configure.ac to detect this and add the apropriate > compile switch? > > > > > A+ > > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Mike Hearn

> You're mixing installed base numbers with new shipments ("market share"). Indeed, I've run across this distinction before. By that logic however stuff that's given away for free has no market share, meaning that Opera is the worlds most important browser. Hence installed user base is a more useful metric, sorry if I mixed up the terminology. > Yes, of course there are reasons. If I wanted to use Linux for my > desktop I would do so. I find Mac OS X to be the best desktop OS in > the world. Very touching. I'm not suggesting you use it as your desktop, I'm suggesting you use it as a place to start the port. If you decide to make things hard for yourself due to some bizarre hatred of desktop Linux, then you're just increasing the amount of work you'd need to do. You don't even have to dual boot or anything, just stick it on an old PC and ssh into it if you absolutely must have glowing buttons. As you've seen, Darwin/x86 is basically useless, and as the opcode translation is probably one of the hardest but also most interesting parts (I don't think anybody has attempted Bochs integration before), it makes sense to get it out the way. But - if you want to leave it until later, you do it how you think is best. > What I'ld > really like to see is Red Hat binary compatibility If you're going to target a distro, I'd go for Debian as it has more binary packages available. Considering how frequently Redhat has broken compatability even with itself (esp with C++), there aren't all that many working Redhat (or suse, or conectiva etc) binaries out there compared to Debian. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 8, 2003

distcc and wine

by Martin Pool

I saw (reading my referrer logs :-) people were interested in distcc with Wine, so I thought I would add it to distcc's performance benchmark. Across three machines I saw a 2.58x speedup -- details are attached. The machines were all 1GB, 1700MHz Pentium IV with a 100Mbps switched connection. Building on just one took 22m57s, and across all three took 8m53s. There is probably still some scheduling inefficiency here, which I hope to reduce over the next few months. I'm not sure what was happening with the person who saw little change. Perhaps they had distcc misconfigured, or perhaps they hit a bug. Either way I would be interested in hearing the details ($DISTCC_HOSTS, etc) and seeing if I can help fix it. I hope you find ccache and distcc useful. Wine is a cool project. Please cc me on replies. -- Martin

Jan. 8, 2003

Re: Re: bug report.

by yf

>> [yf(a)yf 2002]$ wine ./hexin.exe >> fixme:ole:CoRegisterMessageFilter stub >> fixme:shdocvw:WBPCI2_GetGUID stub: dwGuidKind = 1, pGUID = {00000000-0000-0000-0000-000000000000} >> fixme:shdocvw:WBPCI2_GetGUID Wrongly returning IPropertyNotifySink interface {9bfbbc02-eff1-101a-84ed-00aa00341d07} >> fixme:shdocvw:WBQA_QuickActivate stub: QACONTAINER = 0x40760874, QACONTROL = 0x407608b4 >> fixme:shdocvw:WBPSI_InitNew stub >> fixme:shdocvw:WBCP_Advise stub: IUnknown = 0x4183bfe4, connection cookie = 0 >> fixme:shdocvw:WBOOBJ_SetExtent stub: (0x41f0a940, 1, (0 x 0)) >> fixme:shdocvw:WBOOBJ_DoVerb : stub iVerb = -5 >> fixme:shdocvw:WBOOBJ_DoVerb stub for OLEIVERB_INPLACEACTIVATE >> fixme:shdocvw:WBOC_GetControlInfo stub: LPCONTROLINFO = 0x4183bf84 >> fixme:shdocvw:WBOIPO_GetWindow stub HWND* = 0x40760980 >> fixme:shdocvw:WB_Invoke stub dispIdMember = -518, IID = {00000000-0000-0000-0000-000000000000} >> fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1099153244 >> fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1099153168 >> fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1 >> fixme:shdocvw:WBOIPO_InPlaceDeactivate stub >> fixme:shdocvw:WBOOBJ_SetClientSite stub: (0x41f0a940, (nil)) >> fixme:shdocvw:WBOOBJ_Close stub: () >I get as far, than it fscks up its double byte names. >With what 'LANG' var do you run it? my 'LANG' is zh_CN.GB18030 >> err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. >This will do an immediate exit(1); so WINE terminates here. It probably should not.

Jan. 8, 2003

Re: wxWindows: it's official!

by Dimitrie O. Paun

On January 7, 2003 03:15 pm, Alexandre Julliard wrote: > IMO it is right. I would say this is a cygwin bug; cygwin is supposed > to be Unix compatible, and under Unix access() is in unistd.h. So if > the app needs access() it should include unistd.h; if it needs the > other functions from io.h then it has to use msvcrt because they don't > exist in the Unix libc. Right -- I now see better where you guys come from. Now, thing is, cygwin does include io.h, and apps expect it. You can make a good argument that it shouldn't, but it does. I don't know much about their problem space, so I give them the benefit of the doubt that they knew what they were doing. In all honesty, I can also see a good argument for it being in cygwin, but this is besides the point -- the file is there, and apps depend on that. I just want to say that it has been proved, time and again, that in the long term we are better off sticking to common practice. Every time we tried to cure worlds problems, we got bitten back. We have already so many battles to fight, do we want to take on this one? -- Dimi.

Jan. 8, 2003

Re: getting started

by David Fraser

Francois Gouget wrote: > 2. we can modify Winemaker to generate Mingw makefiles (does that rule >out using autoconf?) and assume that a 3 line change will turn them into >Winelib makefiles (or the other way around). Actually, has anyone >written a .dsp to Mingw makefile converter? > > http://lnxscene.org/jylam/dsp2make/ Details: GPL, written in C, at version 0.3 (May 2002) Seems very simple and would need quit some work but I ran it on some of my projects and seemed to produce something reasonably sensible. Maybe we could take this and develop it. Alternative would be to do it in Perl etc. I don't know Perl. bother.

Jan. 8, 2003

Help with /?? stuff

by Shachar Shemesh

Hi list, Can someone please give me a good place to RTFM what the !$&!% to do with paths that have /?? in them? Can I just give them over to win32 functions, or do I need to do something with them first? Also, does anyone have any docs on "runonce.exe"? I have a very vauge knowledge of what it does, and I could find -q -b mentioned as command lines. Shachar

Jan. 8, 2003

Re: getting started

by David Fraser

Francois Gouget wrote: >On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > > > >>On January 7, 2003 02:25 pm, Francois Gouget wrote: >> >> >>> * winemaker >>> The assumption is that you have a Windows application (complete with >>>CR/LF), most likely based on Visual C++ and thus with no suitable >>>makefiles. So winemaker's goal is to quickly generate suitable Makefiles >>>that will build Winelib applications/dlls from what it's given and fix >>>the simple issues in the source (CR/LF, #pragmas). The backend is >>>somewhat secondary. >>> >>> >>This touches on an issue that I'd like to avoid discussing now -- >>it deserves a separate thread. But just to note that the things >>you've mentioned are not mutually exclusive: >> >> >[...] > > >> -- Having the make files portable between Wine/Linux/MinGW >> can only be a good thing, right? >> >> > >I think our views are not incompatible and even that we basically agree. >However there is a difference in emphasis. I'm more interested in >improving the front-end, especially by adding support for dsp file which >I think would improve the usefulness of winemaker tremendously (so >that's what I would work on if I had time). You are more interested in >the backend and in making it compatible with MinGW. > >However since I probably won't have time to make significant changes to >winemaker in the near future my preferences are moot. > >Call for help: > >Please if you are interested in working on either aspect let us know (me >or Dimitrie) and we will try to help you each with the part we are more >familiar with. > > > Me! Do we have a task list for this? David

Jan. 8, 2003

Re: Registering DLL's

by John K. Hohm

On Wed, Dec 04, 2002 at 05:14:23PM -0800, Alexandre Julliard wrote: > "John K. Hohm" <jhohm(a)acm.org> writes: > > > I posted my idea for representing the registration data, accidentally from > > "jhohm(a)happyhappy.dyndns.org" rather than my usual "jhohm(a)acm.org" (see > > http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html) but I haven't > > gotten any responses, not even "looks fine" or "you are a moron". I guess I'll > > just start submitting patches, then. > > Sorry, I must have missed that one. I don't really like the ASCII > description of the registry keys; I think it would be better to do it > at a more symbolic level. For instance you shouldn't hardcode the > ASCII form of the CLSID, you should have some kind of "register CLSID" > function that takes a CLSID and uses StringFromCLSID or whatever to > create the corresponding registry key. The types of things that a COM server DLL is likely to register are fairly limited; essentially just classes and interfaces. I have come up with a different interface, that accepts a list of structures more closely matching the requirements of registering and unregistering a COM server. This is the interface in regsvr.h for use by Dll[Un]RegisterServer: struct regsvr_interface { IID const *iid; /* NULL for end of list */ LPCSTR name; /* can be NULL to omit */ IID const *base_iid; /* can be NULL to omit */ int num_methods; /* can be <0 to omit */ CLSID const *ps_clsid; /* can be NULL to omit */ CLSID const *ps_clsid32; /* can be NULL to omit */ }; HRESULT register_interfaces(struct regsvr_interface const *list); HRESULT unregister_interfaces(struct regsvr_interface const *list); struct regsvr_coclass { CLSID const *clsid; /* NULL for end of list */ LPCSTR name; /* can be NULL to omit */ LPCSTR ips; /* can be NULL to omit */ LPCSTR ips32; /* can be NULL to omit */ LPCSTR ips32_tmodel; /* can be NULL to omit */ }; HRESULT register_coclasses(struct regsvr_coclass const *list); HRESULT unregister_coclasses(struct regsvr_coclass const *list); Here is an example of its use in comcat_main.c; this is admittedly much less than would appear on ole32_main.c, but everything required there should be included in the structures: static struct regsvr_coclass coclass_list[] = { { &CLSID_StdComponentCategoriesMgr, "StdComponentCategoriesMgr", NULL, "comcat.dll", "Both" }, { NULL } /* list terminator */ }; HRESULT WINAPI COMCAT_DllRegisterServer() { TRACE("\n"); return register_coclasses(coclass_list); } HRESULT WINAPI COMCAT_DllUnregisterServer() { TRACE("\n"); return unregister_coclasses(coclass_list); } Alexandre, feel free to disapprove of this interface also; most of my experience writing interfaces to library pieces has either been big, complex Automation stuff to support VB database apps, or object-oriented C++. I would also like suggestions on whether an interface like this should be exported via a static library like libwine_unicode.a (can that work when I call advapi32 exports?), via a new wine-specific dll in src/dlls, or simply by copying the implementation around to all the COM server dlls (my least favorite option). -- John Hohm <jhohm(a)acm.org> I once had sufficient wisdom to value an absent .sig over a lame one.

Jan. 8, 2003