December 2005 - Wine-Devel - list.winehq.org

Re: [wined3d] Converting Wined3d to use WGL instead of GLX

by Aric Cyr

Aric Cyr <Aric.Cyr <at> gmail.com> writes: > > Raphael <fenix <at> club-internet.fr> writes: > > > > > On Wednesday 14 December 2005 04:53, Aric Cyr wrote: > > > 1) should the thunks returned from wglGetProcAddress be causing crashes at > > > all? Note that they don't crash right away, but "eventually" usually > > > during > > > a call to glDrawArrays it seems (after a call to glSecondaryColor3fEXT). > > > > The real problem here is "why it crash ?" > > It shouldn't as wine gl* calls are only "decorators" calls > > Maybe we have a declaration error... > > Yes that was what I was thinking as well. I haven't looked into it very much > yet, but I'll double check the definitions, although since opengl_ext.c is > autogenerated I can't imagine why there would be a problem (unless > include/wine/wined3d_gl.h has the wrong definitions... I'll have to check that > out) > > Also I'm not sure if calling conventions matter, or what is the correct way to > define a function. I'm referring to the WINAPI vs APIENTRY (vs stdcall?) > function pointer prefixes. Any pointers (no pun intended) in this area would > be much appreciated. > > > Can you provide more informations: > > - WINEDEBUG=+opengl log + winedbg crash log I debugged it more last night and I found the offending call. If I comment out just that one (probably unneeded from what I can tell) function everything works great. The code is in dlls/wined3d/drawprim.c (about halfway down): if (GL_SUPPORT(EXT_SECONDARY_COLOR)) { glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT); checkGLcall("glDisableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)"); GL_EXTCALL(glSecondaryColor3fEXT)(0, 0, 0); checkGLcall("glSecondaryColor3fEXT(0, 0, 0)"); } else { /* Missing specular color is not critical, no warnings */ VTRACE(("Specular colour is not supported in this GL implementation\n")); } If I comment out the GL_EXTCALL(glSecondaryColor3fEXT)(0,0,0); line everything works perfectly (well, the four dx9 demos I have been using). I tried debugging it (put a breakpoint in wine_glSecondaryColor3fEXT) but the function seems to work fine. It is only after this function is called, followed shortly by glDrawArrays() that the actual segfault occurs (inside glDrawArrays there is a NULL dereference it seems). I would blame ATI's drivers but as I said using glXGetProcAddress instead of wglGetProcAddress works without commenting this line. The only other thing I can think of is that the calling conventions are messed up somehow, either due to mismatched function declarations (which I thoroughly checked, but still could have missed something...) or some weird wine thing I don't understand. Also other GL_EXTCALL functions were not affected. For example, glPointParameter...EXT() calls are frequently made and don't seem to cause any problems at all. Any help or tips would be much appreciated, as I am running out of things to try and debug. - Aric

Dec. 15, 2005

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by Dustin Navea

I havent seen this mentioned in this thread yet, but did you try make distclean, and/or completely blowing away the directory you checked out wine into, and checking it out fresh? Another idea is to go ahead and create the directory, since it cant cd into it, and see what happens when you do that.. Also, make sure that there arent any stale wine process hanging around (either wineserver, wine, or wine-preloader), that might be locking the new server from spawing into a new directory. Dustin David Nolden wrote: >>There is no change in Wine that would have caused this. I seem to >>remember that this or a similar error was caused by threading problems >>in glibc in the past. Perhaps you upgraded glibc or the kernel on your >>system? > > > But when I checkout a cvs from the end of november, it runs.. when I checkout > a current one it doesn't. I didn't upgrade glibc, nor the kernel. (I checked > out and compiled a cvs from november just an hour ago, and it ran fine) > > greetings, David > > >

Dec. 15, 2005

Re: WLDAP32: link to the reentrant version of libldap

by Robert Reif

Hans Leidekker wrote: >On Wednesday 14 December 2005 01:56, Robert Reif wrote: > > > >>>Changelog >>> Link to the reentrant version of libldap. >>> >>> > > > >>This patch breaks builds on RH9 and appears to be responsible for the >>build breakage on http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php >> >> > >Can you send me the build errors and a relevant snippet from config.log, >say 20 lines after 'checking for ldap_initialize in -lldap_r'? > > -Hans > > > > > My build error is the same as the link above. Here is the log info: configure:9617: checking for ldap_initialize in -lldap_r configure:9647: gcc -o conftest -g -O2 conftest.c -lldap_r -lpthread >&5 configure:9653: $? = 0 configure:9656: test -z || test ! -s conftest.err configure:9659: $? = 0 configure:9662: test -s conftest configure:9665: $? = 0 configure:9678: result: yes configure:9681: checking for ber_init in -llber nm shows that the symbols are in libldap.so but not libldap_r.so.

Dec. 15, 2005

CoCreateInstance not working without TLS libraries

by Cihan Altinay

Hi, A very basic C++ program fails with err:ntdll:RtlpWaitForCriticalSection section 0x7f64c560 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 001c, blocked by 001e, retrying (60 sec) when the Linux TLS libraries are not in the library path (it works fine otherwise). The program does: CoInitialize() CoCreateInstance(<powerpoint viewer 97 clsid>) <dispatch the method "NewShow" to load and start a powerpoint presentation> CoUninitialize() quit I am happy to send the source/binary if it is of any help. I am trying to find out what is going on but the problem is that wine does not crash - the program does its job, powerpoint viewer starts up and shows the first slide but then after my program has quit the critical section times out (ie. the message is from the viewer). I tried different trace outputs with no luck. Note that since wine's builtin OLE libraries can't handle CoCreateInstance yet I am using natives. Does anybody have a suggestion how to track that down? Thanks a lot, Cihan

Dec. 15, 2005

Re: Create new mailing list wine-isv?

by Scott Ritchie

On Tue, 2005-12-13 at 22:33 -0800, Dan Kegel wrote: > I used to hate the term ISV (Independent Software Vendor) since > it sounded so acronymy compared to 'developer', but it's > very commonly used in the industry to refer to outfits which > are trying to write and sell off-the-shelf software -- and > as monkey-boy said, Microsoft is where it is partly because > it worked hard to attract and support those guys. > > So I've been thinking about how to attract more Windows ISVs > to test, support, and promote their apps on Linux with Wine. > DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS! I support this idea. -Scott Ritchie

Dec. 15, 2005

Printf Integer Conversions update

by Jesse Allen

Hi All, I've updated my patch and need comments on it. The patch is for a portible method for integer conversions in printf. Since it's primarily intended for I64 sizes that it is all it is used for to avoid breaking anything else, even though, it should be able to handle all integers. You can find it at http://www.chez.com/alors/ along with lots of tests. Since last time, I was wondering what to do about %I64e, and well, testing it out it seems to be just like %e on windows so I decided to not worry about our own float I64 conversion since it's the same. So only I64 integer types get fowarded to pf_integer_conv and floats just get put through libc's printf. I still wonder about %I64e versus %e just because libc's %lle and %e are different hmmmm. This time I use pf_output_format_A to handle the field output. I had to modify it to account for the extra sign and alternate formatting. I guess I need to modify pf_output_format_W the same way, but some one let me know if it is needed and whether just copying what I have over is ok. I added pf_is_integer_format to detect when I have an integer and I64 size case. I modified the others so each uppercase and lowercase type is explicit: static inline BOOL pf_is_valid_format( char fmt ) { - char float_fmts[] = "acdefginoux"; + char float_fmts[] = "acCdeEfgGinouxX"; if (!fmt) return FALSE; - fmt = tolower( fmt ); return strchr( float_fmts, fmt ) ? TRUE : FALSE; } Because D is not a valid conversion type, and especially 'I'. If we get passed %I0d for example, it should print I0d. If I didn't do this, then it tries to convert 'I' as an 'i' type, which would be a bug. I don't know if this will cause other things to regress, so I could back out the change. In my testing of I64 on windows 2k3 (x86), I hit an obscure bug? '%#+25.22I64u' for -1 prints ' 18446744073709551615' returning 21 but normally it should be ' 0018446744073709551615' returning 25. It only does it only for I64 types, and only in this exact combination -- precision and field doesn't matter what number, but #+ must be there and be unsigned. If I try '%+#25.22I64u' then I get correct output. You can see this in the tests and try it out. I tried about 20-30 other combinations and it only happens this way. I haven't built in support of the bug yet, but it is there. So I'm thinking, great, we have to support this obscure I64 with bugs too. Jesse

Dec. 14, 2005

Suggested changes to the menubuilder etc.

by Bill Medland

I am intending doing some work and submitting some patches to "improve" the integration with the operating system desktop integration. Rather than waste time coding up my ideas and having Alexandre reject them I thought I'd start by specifying what I intend and awaiting a barrage of complaints. So please do comment. 1. I reckon it would be a good idea if somewhere we actually wrote some prose that actually declared what it was we were trying to achieve. I have a real issue with trying to decide if the code does what it does because of a deliberate decision, because either Windows or Linux or ... changed or because we just had not got around to implementing what we want. Prose is much better for that. I could put it in the Wine Developer's Guide, in the Wiki (where?), or as a text file in the winemenubuilder directory (my preference). Any comments? 2. My main issue is that we do not replicate the menu structure under the start menu (and presumably the desktop too but I haven't looked there). The program I am working with goes several layers below the Programs directory. I see that wineshelllink is able to take a path for the link but winemenubuilder doesn't use that. I intend adding to winemenubuilder so that it passes a more complete link, with path, to get the depth. 3. I want to do something about looking for icons when the target is actually data, not an executable. Either I will just use no icon or I will see what I can do about looking up the handler for the file type and going from there (possibly even using the native OS's handler e.g. pdf files). Any complaints? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 14, 2005

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by David Nolden

> There is no change in Wine that would have caused this. I seem to > remember that this or a similar error was caused by threading problems > in glibc in the past. Perhaps you upgraded glibc or the kernel on your > system? But when I checkout a cvs from the end of november, it runs.. when I checkout a current one it doesn't. I didn't upgrade glibc, nor the kernel. (I checked out and compiled a cvs from november just an hour ago, and it ran fine) greetings, David

Dec. 14, 2005

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by Robert Shearman

David Nolden wrote: >Am Mittwoch, 14. Dezember 2005 21:00 schrieb Vitaliy Margolen: > > >>Wednesday, December 14, 2005, 12:55:13 PM, David Nolden wrote: >> >> >>>To get to another issue.. since a few weeks, the current CVS doesn't work >>>for me. Whenever I compile it, I get the error mentioned in the subject. >>>New .wine-dir and wiping /tmp doesn't help. >>> >>>When I checkout an older version, for example one from the end of >>>november, it runs fine. Does anyone know the reason for this, or will I >>>have to inspect the code to find it out? >>> >>>Sorry in case this is the wrong mailing-list.. >>> >>> >>This is a list if you "inspect the code to find it out" and have >>questions about what you found and how to fix it. >> >>Vitaliy >> >> > >Yes but I hoped that, since there must be some change that happened within the >last weeks that makes this happen, the one who did it knows and can answer it >directly, or at least that someone can point me into the right direction >where to search.. > There is no change in Wine that would have caused this. I seem to remember that this or a similar error was caused by threading problems in glibc in the past. Perhaps you upgraded glibc or the kernel on your system? -- Rob Shearman

Dec. 14, 2005

Re: chdir to /tmp/.wine-1000/server-307-6930068 : No such file or directory

by David Nolden

Am Mittwoch, 14. Dezember 2005 21:00 schrieb Vitaliy Margolen: > Wednesday, December 14, 2005, 12:55:13 PM, David Nolden wrote: > > To get to another issue.. since a few weeks, the current CVS doesn't work > > for me. Whenever I compile it, I get the error mentioned in the subject. > > New .wine-dir and wiping /tmp doesn't help. > > > > When I checkout an older version, for example one from the end of > > november, it runs fine. Does anyone know the reason for this, or will I > > have to inspect the code to find it out? > > > > Sorry in case this is the wrong mailing-list.. > > This is a list if you "inspect the code to find it out" and have > questions about what you found and how to fix it. > > Vitaliy Yes but I hoped that, since there must be some change that happened within the last weeks that makes this happen, the one who did it knows and can answer it directly, or at least that someone can point me into the right direction where to search.. Oh and I see that my text can be misunderstood.. the error doesn't happen when I compile it, it happens when I try to run a program with the compiled wine. Hmm then I guess I'll have to find it out myself.. sorry for bothering you, David

Dec. 14, 2005