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

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

by Aric Cyr

On 12/17/05, Segin <segin2005(a)gmail.com> wrote: > Aric Cyr wrote: > James Liggett <jrliggett <at> cox.net> writes: > > > > Hi Aric, > If you see stack corruption like this, you might want to try compiling > with optimization turned off. put the -O0 (a capital letter O followed > by a zero) flag in your CFLAGS when you run configure. I had a similar > situation where gcc was using fuzzy math when working with structures, > and turning off optimization helped. > > Thanks for the suggestion, but I already have wine compiled with only "-g". > Last time I checked gcc doesn't enable optimizations unless a -O option is > specified explicitly (don't know if this has changed though). > > > Wine uses -O2 by default even if you don't tell it to optimize. -Os will > product buggy code, and -mfpmath=sse,387 (yes only when you ask for BOTH sse > and 387) will problems occur (big one at that) > If you run configure with no other options "-g -O2" is default, however I run it as "CFLAGS=-g CXXFLAGS=-g ./configure"... so I'm positive (verified by make output) that there is no -O2 or any other options besides -g anywhere. Anyways it turned out not to be a compiler bug, so this is not too important now, but thanks for the suggestions. - Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)

Dec. 17, 2005

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

by Segin

Aric Cyr wrote: >James Liggett <jrliggett <at> cox.net> writes: > > > >>Hi Aric, >>If you see stack corruption like this, you might want to try compiling >>with optimization turned off. put the -O0 (a capital letter O followed >>by a zero) flag in your CFLAGS when you run configure. I had a similar >>situation where gcc was using fuzzy math when working with structures, >>and turning off optimization helped. >> >> > >Thanks for the suggestion, but I already have wine compiled with only "-g". >Last time I checked gcc doesn't enable optimizations unless a -O option is >specified explicitly (don't know if this has changed though). > >Anyways, I think I finally figured this all out. As I thought it turned out to >be stack corruption, due to differing calling conventions. It just required >fixing up my function pointers to be WINAPI (which I believe becomes stdcall) >for all the wgl functions. > >Now everything works fine, except this brings up another issue with >wglGetProcAddress. The problem is that all gl extensions function pointers are >declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is >expected to return. However for extensions that are not registered in >opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would >return a non-WINAPI function pointer. After the first call to such a function >we would have corrupted the stack. There doesn't seem to be a nice way to fix >this that I can think of. wglGetProcAddress should never return a non-WINAPI >function though, as that is just asking for trouble. Better to return NULL >instead of falling back to glXGetProcAddressARB. > >As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d >are now passed through the thunks. It is only one extra function call so the >impact should be minimal (too bad we can't inline these!), but I thought I >should mention it anyways. > >After cleaning up everything I've worked on I think I'll start submitting >patches. First some pre-requisite patches for dlls/opengl32 and include/ and >then the changes for dlls/wined3d. All together it is quite a large change, but >I should be able to break it up into manageable pieces (hopefully!). > >Regards, > Aric > > > > > > Wine uses -O2 by default even if you don't tell it to optimize. -Os will product buggy code, and -mfpmath=sse,387 (yes only when you ask for BOTH sse and 387) will problems occur (big one at that)

Dec. 17, 2005

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

by Aric Cyr

James Liggett <jrliggett <at> cox.net> writes: > Hi Aric, > If you see stack corruption like this, you might want to try compiling > with optimization turned off. put the -O0 (a capital letter O followed > by a zero) flag in your CFLAGS when you run configure. I had a similar > situation where gcc was using fuzzy math when working with structures, > and turning off optimization helped. Thanks for the suggestion, but I already have wine compiled with only "-g". Last time I checked gcc doesn't enable optimizations unless a -O option is specified explicitly (don't know if this has changed though). Anyways, I think I finally figured this all out. As I thought it turned out to be stack corruption, due to differing calling conventions. It just required fixing up my function pointers to be WINAPI (which I believe becomes stdcall) for all the wgl functions. Now everything works fine, except this brings up another issue with wglGetProcAddress. The problem is that all gl extensions function pointers are declared WINAPI, and indeed this is what type of functoin wglGetProcAddress is expected to return. However for extensions that are not registered in opengl_ext.c wglGetProcAddress falls back to glXGetProcAddressARB which would return a non-WINAPI function pointer. After the first call to such a function we would have corrupted the stack. There doesn't seem to be a nice way to fix this that I can think of. wglGetProcAddress should never return a non-WINAPI function though, as that is just asking for trouble. Better to return NULL instead of falling back to glXGetProcAddressARB. As an aside to the wglGetProcAddress issue, all GL extenions called by wined3d are now passed through the thunks. It is only one extra function call so the impact should be minimal (too bad we can't inline these!), but I thought I should mention it anyways. After cleaning up everything I've worked on I think I'll start submitting patches. First some pre-requisite patches for dlls/opengl32 and include/ and then the changes for dlls/wined3d. All together it is quite a large change, but I should be able to break it up into manageable pieces (hopefully!). Regards, Aric

Dec. 17, 2005

Supporting ISVs (was: Create new mailing list wine-isv?)

by Dan Kegel

Markus Goemmel wrote: > My partner and I are developing Windows applications > (http://www.emtec.com) Seeing Wine some months ago fascinated > me a lot, so since then I'm spending one or two hours a day > trying to bring our applications to work under Wine, too... > > But it's clear that there are not enough ressources there > to help ISVs like me out of some problems. Sometimes I have > contact with one of the developers after submitting a bug, > or writing something into the wine-devel list, but without > doing a lot of clarification before (like looking into the > Wine sources, close in the problem area, and asking really > specific questions to the corresponding 5 or 10 lines of code > in the Wine sources) nobody really have time to help. Hmm. Guess you're working on zoc: http://appdb.winehq.org/appview.php?versionId=3744 And you've filed ten bugs so far: http://bugs.winehq.org/buglist.cgi?emailreporter2=1&emailtype2=substring&em… only one or two of which have been fixed. I was curious, so I tried running zoc on wine-0.9.3 (compiled myself on FC3). The first time I started it, it exited with an assertion; the log is --- EmTec Application --- 12/17/2005 6:40:02 AM --- Condition: hwndLed Location : status.cpp line 878 Last Err.: 0L () Add. Info: Every time I started it after that, it exits with a dialog "Panic: no fonts!". I'd like to see this work; got any tips? I'm glad you're sticking around even though it's hard to get your questions answered! Hopefully we can improve the ISV experience with your feedback. Are you interested in being interviewed as a case study for my ISV page, http://kegel.com/wine/isv ? Thanks, Dan

Dec. 17, 2005

Re: Create new mailing list wine-isv?

by Vitaliy Margolen

Friday, December 16, 2005, 11:26:28 PM, Scott Ritchie wrote: > On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote: >> The goal is not to prevent regressions between every minor point >> release, it's to make releases frequently enough that regressions can >> be found and fixed quickly, so that they don't creep into the next >> major release. Now, if you think that doesn't work I'm certainly open >> to doing things differently. What do you suggest? >> > If I may make a humble suggestion, it would be to time another stable > (or semi-stable), regression-proofed release to roughly coincide with > the various distributions freezing schedules. Ubuntu, for instance has > an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. > In my ideal world, we would have a Wine release just before that Jan > 19th deadline, go into regression-fix and bughunt mode, and then have a > release come out around Feb 2nd that had no regressions relative to 0.9 > and the Jan 19th release. That sounds to aggressive to me. We still a long ways away from major pieces falling into place. Most regressions you see, especially with games caused be major developments in d3d part of Wine. I don't think that will be "fixed" by then. There are number of fixes being worked on for copy-protection systems. Some have to be tested over period of time to check for any regressions. Looking at the bugzilla I can see that major effort is under way to have Picasa2 working. And we haven't seen a major flood of patches yet. Also we are near the Christmas holidays which means everything will ground to a halt here soon. So basically we will have 2 weeks to wrap things up - too short of the time to get anything major out of the way. IMHO before we can go into a code freeze we should put a status of all the major Wine parts together. To see what are we in the middle of doing. And decide what do we want to have in the next release. And what will have to wait. Vitaliy.

Dec. 17, 2005

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Vitaliy Margolen

Friday, December 16, 2005, 11:20:34 PM, Dan Kegel wrote: > On 12/16/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> > $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe >> > wine: cannot open builtin library for >> > L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe": >> > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header >> >> Yeah. The only time I have seen this message in relation to regsvr32.exe >> is only when Wine's builtin regsvr32.exe.so was overwritten with native >> PE executable. ... >> In this case I don't know then what is going on. Could you follow all the >> symlinks and verify that it is in fact ELF? Also can you remove this file >> and remake it? If it is ELF it must be corrupted in some way. > No, it's ELF, and it's not corrupted. As I wrote a few posts ago, > the problem was caused by having an old copy of wine installed > in /usr/local while running a new copy of wine from the build > directory. Removing the old copy, and installing wine from the > build directory, fixes the problem; I can then run regsvr32 from > either the build directory or the installed copy without problems. Ah I see. Will add this to the list of things to watch for then. Thank you for taking time and figuring it out. The reason why I never seen this before is because I don't have Wine installed. I'm running it from the source tree. Saves me some some time and space on the hard-drive. And extra log-in as root <g> Vitaliy

Dec. 17, 2005

Re: Create new mailing list wine-isv?

by Scott Ritchie

On Fri, 2005-12-16 at 19:48 +0100, Alexandre Julliard wrote: > The goal is not to prevent regressions between every minor point > release, it's to make releases frequently enough that regressions can > be found and fixed quickly, so that they don't creep into the next > major release. Now, if you think that doesn't work I'm certainly open > to doing things differently. What do you suggest? > If I may make a humble suggestion, it would be to time another stable (or semi-stable), regression-proofed release to roughly coincide with the various distributions freezing schedules. Ubuntu, for instance has an upstream version freeze on Jan 19th and a Feature Freeze on Feb 2nd. In my ideal world, we would have a Wine release just before that Jan 19th deadline, go into regression-fix and bughunt mode, and then have a release come out around Feb 2nd that had no regressions relative to 0.9 and the Jan 19th release. Thanks, Scott Ritchie

Dec. 17, 2005

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Dan Kegel

On 12/16/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe > > wine: cannot open builtin library for > > L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe": > > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header > > Yeah. The only time I have seen this message in relation to regsvr32.exe > is only when Wine's builtin regsvr32.exe.so was overwritten with native > PE executable. ... > In this case I don't know then what is going on. Could you follow all the > symlinks and verify that it is in fact ELF? Also can you remove this file > and remake it? If it is ELF it must be corrupted in some way. No, it's ELF, and it's not corrupted. As I wrote a few posts ago, the problem was caused by having an old copy of wine installed in /usr/local while running a new copy of wine from the build directory. Removing the old copy, and installing wine from the build directory, fixes the problem; I can then run regsvr32 from either the build directory or the installed copy without problems. Nasty little troubleshooting problem. I guess I have to be a lot more careful, and make sure to uninstall all old copies of wine before running new builds without installing. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Dec. 17, 2005

Re: Error at end of app install: can't open builtin library for regsvr32.exe...

by Vitaliy Margolen

Friday, December 16, 2005, 10:45:06 PM, Dan Kegel wrote: > On 12/16/05, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> > $ rm -rf .wine >> > $ wine/wine notepad.exe >> > /home/dank/.wine updated successfully. >> > $ find .wine -name regsvr32.exe -ls >> > 4669487 0 lrwxrwxrwx 1 dank dank 40 Dec 17 03:35 >> > .wine/drive_c/windows/system32/regsvr32.exe -> >> > /home/dank/wine/programs/regsvr32.exe.so >> >> Yup, exactly what I said. > ? You were talking about something being overwritten with a > native copy by an installer, but you can see from the log > that no installer was run. That file is not in your ~/.wine directory. When you removed it, you haven't touched the actual "regsvr32.exe.so" file. >> Run >> 'file /home/dank/wine/programs/regsvr32.exe.so' to see what I'm talking >> about. > OK: > $ file /home/dank/wine/programs/regsvr32.exe.so > /home/dank/wine/programs/regsvr32.exe.so: symbolic link to > `regsvr32/regsvr32.exe.so' > $ file /home/dank/wine/programs/regsvr32/regsvr32.exe.so > /home/dank/wine/programs/regsvr32/regsvr32.exe.so: ELF 32-bit LSB > shared object, Intel 80386, version 1 (SYSV), not stripped > What does that tell you? The file looks like a perfectly good > ELF file, as one would expect. How do you explain the next line from the log, > $ wine/wine .wine/drive_c/windows/system32/regsvr32.exe > wine: cannot open builtin library for > L"Z:\\home\\dank\\.wine\\drive_c\\windows\\system32\\regsvr32.exe": > /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header Yeah. The only time I have seen this message in relation to regsvr32.exe is only when Wine's builtin regsvr32.exe.so was overwritten with native PE executable. That could happen only of you have write access to the the place where you installed wine, or if you running it from the source tree. In this case I don't know then what is going on. Could you follow all the symlinks and verify that it is in fact ELF? Also can you remove this file and remake it? If it is ELF it must be corrupted in some way. Vitaliy.

Dec. 17, 2005

SCREENSHOT: Windows Genuine Advantage 'GenuineCheck.exe' program generating key on Wine!

by Segin

The attached screenshot (UNMODIFIED) depicts the WGA 'GenuineCheck.exe' program that is used on the microsoft web site to 'validate' Windows so that you can download crap. Normally, it will not generate the needed key under Wine, but I have a screenshot (attached) of it doing so. I don't know is this is worth noting, as i couldn't tell you how I made it work (a LOT of things, too many to even count). However, I thought it might be something of intrest. If this is in any way useful to the development of Wine, please let me know.

Dec. 17, 2005