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

some 16 bit apps crash with gcc-4.3 (Ubuntu Intrepid); work with 4.2 (Hardy) - Caesar 3
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 21, 2009

Dec. 21, 2009

Hi, the news is that a few 16bit apps crash in Wine, apparently depending on the gcc version used to compile Wine. This was known to affect copy-protected apps, but in the present case, copy protection is not involved. >perhaps that old wine-1.1.16 was compiled with Ubuntu Hardy, not Intrepid... Indeed that is the difference: - Meine Traumburg (children game probably nobody knows outside Germany) crashes at start; - Caesar III from Sierra (mine is the German version) aborts before the second installer screen ("error 112") with no revealing error message or stack dump using a Wine compiled in Ubuntu Intrepid. They work fine with a Wine compiled in Ubuntu Hardy. Sorry, I don't use any newer Ubuntu (yet). Wine-1.1.16 and 1.1.34 behave the same. http://wiki.winehq.org/GccVersions mentions that some versions of gcc miscompile some code relevant for copy protection. However the above apps are not protected AFAICT! (They are trivial to install on HD without the need for the CD at run-time.) So gcc (presumably) affects "regular" code in Wine. The winesrc/include/config.h file on both systems is the same except for one line about mpg123; that's why I believe gcc is to blame (or Wine does some 16bit assembly magic that's not supported by gcc and thus produces random results). Hardy uses gcc-4.2 (Wiki page says "known to work/this isn't certain") Intrepid uses gcc-4.3 (Wiki page says "not tested") It would be interesting to re-evaluate bugs.winehq for bugs with keyword "win16". Regards, Jörg Höhle

1 0

Re: [2/2] wininet: Free per-thread error info upon exit from an async procedure.
by Jacek Caban Dec. 21, 2009

Dec. 21, 2009

Hi Hans. On 12/21/09 11:14 AM, Hans Leidekker wrote: > Found by Valgrind. > --- > dlls/wininet/internet.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > index d749e53..2b8d767 100644 > --- a/dlls/wininet/internet.c > +++ b/dlls/wininet/internet.c > @@ -3127,8 +3127,12 @@ static DWORD CALLBACK INTERNET_WorkerThreadFunc(LPVOID lpvParam) > HeapFree(GetProcessHeap(), 0, lpRequest); > > workRequest.asyncproc(&workRequest); > - > WININET_Release( workRequest.hdr ); > + > + if (g_dwTlsErrIndex != TLS_OUT_OF_INDEXES) > + { > + HeapFree(GetProcessHeap(), 0, TlsGetValue(g_dwTlsErrIndex)); > + } > You have to set TLS value to NULL otherwise it will crash on next INTERNET_SetLastError in the same thread on another async call. But the right way to fix this is to get rid of INTERNET_[GS]etLastError. This is useless and has proven to result in code that has many failure paths without last error set. I've already removed most of these calls and I'm near to getting rid of all of them except ones in ftp.c. Thanks, Jacek

2 1

Isn't it a bug?
by Luis Busquets Dec. 21, 2009

Dec. 21, 2009

From some time when I run Civilization4 I get a myriad of these messages and others with other formats: err:d3d:getColorBits Unsupported format: WINED3DFMT_R16G16_FLOAT err:d3d:IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt Unable to check compatibility for Format=WINED3DFMT_R16G16_FLOAT After looking in the wine code I have found out that what happens is that Civ calls the function IDirect3D9Impl_CheckDepthStencilMatch The implementation of wine then calls IWineD3D_CheckDepthStencilMatch which then calls IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt <http://source.winehq.org/ident?i=IWineD3DImpl_IsPixelFormatCompatibleWithRe…> for each format that the adapter supports until it finds a supported format: Problem: IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt <http://source.winehq.org/ident?i=IWineD3DImpl_IsPixelFormatCompatibleWithRe…> tries to match the supported pixel format of the adapter with the requested format. If the supported pixel format of the adapter is of type WGL_TYPE_RGBA_ARB, it tries to getColorBits of the format even if the format to try is a floating format, getColorBits responds with an error and same does IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt <http://source.winehq.org/ident?i=IWineD3DImpl_IsPixelFormatCompatibleWithRe…>. Certainly, the answer is correct (FALSE) but the problem is that it fills the screen with ERR that are due to wine checking things for which there is no need as they are directly false. So my question is if it is possible to do IWineD3DImpl_IsPixelFormatCompatibleWithRenderFmt <http://source.winehq.org/ident?i=IWineD3DImpl_IsPixelFormatCompatibleWithRe…> right away check if: cfg->iPixelType ==WGL_TYPE_RGBA_ARB <http://source.winehq.org/ident?i=WGL_TYPE_RGBA_ARB> and format_desc is a floating format then return FALSE right away no need to fill ERR same if cfg->iPixelType ==WGL_TYPE_RGBA_FLOAT_AR <http://source.winehq.org/ident?i=WGL_TYPE_RGBA_FLOAT_ARB>B <http://source.winehq.org/ident?i=WGL_TYPE_RGBA_ARB> and format_desc is not a floating format then return FALSE right away no need to fill ERR If you do not like this solution, getColorBits could be modified so that it does not file an error for floating point formats but just responds with 0 for all bit sizes when the format is a floating point without filling an error. What do you prefer? Can somebody propose a patch with this kind of behaviour or something better so that my Civ4 does not respond with this myriad of errors? <http://source.winehq.org/ident?i=WGL_TYPE_RGBA_ARB>

2 2

Limit Bugzilla fields access
by Nikolay Sivov Dec. 21, 2009

Dec. 21, 2009

Hi. I think it's not bad to remove some not useful in Wine's bugzilla fields from bug page: - whiteboard: what is it for? - difficulty - this really means nothing, usually set by reporter and not used by developers at all; - alias - used by reporters some times, but often reset by bugzilla buys (don't know why actually). Also it might be good to enable version field only on bug creation for people with report only permissions, version is often changed after reporter tested app again on newer version, after that bugzilla maintainers change it back and so on. The less the better, should be a rule here. Don't know is some of that fields configurable or code change required, but still I'm sure it's possible. Thanks.

2 1

WineTestBot changes
by Greg Geldorp Dec. 20, 2009

Dec. 20, 2009

Updates to the test bot: - Improve log parsing and error reporting - Send notification email on job completion - Run winetest64-latest.exe on 64-bit machines - Show warning message if job is submitted without command line arg - Attempt to display times in users own timezone - Add possibility to set WINETEST_DEBUG and WINETEST_REPORT_SUCCESS env vars The code (LGPL) is now hosted on SourceForge in the "wine/winetestbot" git repository. Ge.

1 0

Broken-down time (struct tm)
by Erich Hoover Dec. 20, 2009

Dec. 20, 2009

I will soon have access to a network license for a piece of software that uses the Sentinel Protection Driver (ie. I do not need USB support), so I am looking into implementing ExSystemTimeToLocalTime (Bug 19395) so that the driver will work properly. In the process of researching a good way to support this feature I found that the "broken-down time structure" (struct tm) has a member for the local timezone offset from GMT (tm_gmtoff). According to the man pages this feature requires that _BSD_SOURCE be defined before including time.h; however, I found this member being used in dlls/msvcrt/time.c without this #define. So, the question I have is whether it is OK to use tm_gmtoff in Wine (whether there is a portability concern) and the proper way to include time.h to use this feature. Erich Hoover ehoover(a)mines.edu

2 2

Recent User32 <=> windowClass assembly findings
by Nikolay Sivov Dec. 20, 2009

Dec. 20, 2009

Hopefully my first attempt to implement class redirection wasn't committed --- http://source.winehq.org/patches/data/56761 --- cause it's definitely incomplete. After some testing I've got new info here (to be added to patch comments above): 1) not statically linked sxs module is loaded not only on window creation but on GetClassInfo() (GetClassInfoEx() is to be tested but I think it's the same). This is a case only on vista+ systems, xp doesn't attempt to load assembly on GetClassInfo(); 2) "versioned" attribute in windowClass element affects redirection behavior, when set to "no" user32 doesn't try to load assembly at all. Second problem requires a FindActCtxSectionString() to actually fill key data with undocumented format, I did some dumping basing on length value reported: similar way it's done for dll redirection test (with a dword pointer) and useful fields are actually obvious - such as classname and module name. First problem stops me cause I don't know what way to prefer here. Any advices are welcome. P.S. Maybe it helps - native returned class data in case of vista+ and comctl32 v6 contains pointers to winproc as "FFFFxxxx" format, high word is constant. Personally I don't know what is supposed to mean, builtin classes without redirection don't show such patterns.

1 0

Re: wine autodetec 32/64 application
by Roderick Colenbrander Dec. 20, 2009

Dec. 20, 2009

Hi Giuseppe, Support for 64-bit is under heavy development and it our goal for Wine 1.2. A simple script to forward execution to 32-bit or 64-bit wine is not enough. Work is going on to integrate 32-bit and 64-bit Wine. Parts of the infrastructure for this are already in place (e.g. a shared wineserver) but other bits for a shared registry and prefix are still in development. It is not clear how we will invoke 32-bit or 64-bit Wine yet. I would recommend to check out Alexandre his keynote which discusses 64-bit Wine http://haar.student.utwente.nl/~julius/wineconf/julliardkeynote2009.ogv Roderick On Sat, Dec 19, 2009 at 5:17 PM, Giuseppe Della Bianca <bepii(a)libero.it> wrote: > Hi. > > This attached wine script can autodetect the wine 32/64 and application > PE32/PE32+, and autorun the correct wine program. > > This wine script support the application with name with space, and with > windows path. > > Regards. > Gdb > > > >

2 1

Conformance tess for cmd?
by Dan Kegel Dec. 19, 2009

Dec. 19, 2009

Has anyone written conformance tests for cmd? I imagine they'd mostly just be a bunch of batch files with matching expected output files.

4 6

re: Broken-down time (struct tm)
by Dan Kegel Dec. 19, 2009

Dec. 19, 2009

fwiw, looks like it might be a problem when building on Solaris: https://issues.asterisk.org/view.php?id=12022 Not sure what to do when that field is missing offhand.

1 0

Re: comdlg32: Check if the shell view exists before using it to execute commands
by Nikolay Sivov Dec. 19, 2009

Dec. 19, 2009

On 12/19/2009 20:47, Paul Chitescu wrote: > Changelog: > comdlg32: Check if the shell view exists before using it to execute commands. > > Prevents crashing if trying to create new folder with a R/O Registry (which is > a bug by itself in a different module). > Don't you mind add a test for that and previous patches?

2 1

Re: [2/2][tools]winetest: fix filesize limit
by Paul Vriens Dec. 19, 2009

Dec. 19, 2009

Hi André, On 12/19/2009 06:01 PM, André Hentschel wrote: > if (defined $dll) { We should only get here if we've received a start of a test but not the end. > # Either winetest crashed or the report file was cut off > $_=""; > - if ($filesize == $maxfilesize) { > + if ($filesize> $maxfilesize) { This can never happen as $maxfilesize is where it is cut off. The whole reason for this check is to decide whether we have a crash or "just" a file limit reached. If the size of the file is the maximum and we didn't get an end for the test we can assume it has been cut off at the sender. -- Cheers, Paul.

2 1

ucla dxdiag sources now in separate repo...
by Dan Kegel Dec. 19, 2009

Dec. 19, 2009

... until they can be merged. That seems like a better solution than just keeping the patches around in hyperspace. The tree is at http://code.google.com/p/yadxdiag/ If anyone would like to help finish this up, please let me know. The spinning cube test is pretty cool. - Dan

1 0

re: msi: fix leak in cond.y
by Nate Gallaher Dec. 18, 2009

Dec. 18, 2009

I should have mentioned in the commit message that this approach took heavy inspiration from the solution to the same problem in sql.y.

1 0

re: daily 16 bit tests?
by Dan Kegel Dec. 18, 2009

Dec. 18, 2009

Joerg-Cyril.Hoehle wrote: > there have been a number of 16bit changes lately (accompanied by a > few regressions) and I've been wondering whether some bot somewhere > has been setup to execute 16 bit tests (I read that there's a 16bit > testsuite somewhere, not integrated into Wine tests)? The procedure for running the 16 bit tests is given at http://code.google.com/p/win16test/source/browse/trunk/src/README It'd be great to integrate them into the daily test runs somehow. Maybe they could at least be incorporated into winetest.exe? Tips: When installing openwatcom with winetricks, be sure to select 'all' rather than 'selective', or you'll end up without the 16 bit tools you need; the symptom will be 'make all' fails because it's trying to use 32 bit headers. About four tests hang currently - you have to kill them with ^C use touch to bypass them, and rerun 'make tests'. Of the tests that don't hang, three currently fail. And it looks like a few of the tests don't pass on all windows machines, see http://code.google.com/p/win16test/issues/detail?id=1

1 0

Re: [usp10 5/6] Fix the ABC width calculations in ScriptPlace
by Alexandre Julliard Dec. 18, 2009

Dec. 18, 2009

Jason Green <jave27(a)gmail.com> writes: > - if (pABC) TRACE("Total for run: abcA=%d, abcB=%d, abcC=%d\n", pABC->abcA, pABC->abcB, pABC->abcC); > + if (pABC) > + { > + ABC tmp; > + > + > + /* the compositie 'A' width is simply the padding from the first glyph in the run */ > + get_cache_glyph_widths(psc, pwGlyphs[0], &tmp); > + pABC->abcA = tmp.abcA; > + > + /* the compositie 'C' width is simply the padding from the last glyph in the run */ > + get_cache_glyph_widths(psc, pwGlyphs[cGlyphs - 1], &tmp); > + pABC->abcC = tmp.abcC; > + > + /* since the 'B' width now includes the 'A' and 'C' widths, we must adjust it slightly */ > + pABC->abcB -= pABC->abcA + pABC->abcC; > + > + TRACE("Total for run: abcA=%d, abcB=%d, abcC=%d\n", pABC->abcA, pABC->abcB, pABC->abcC); > + } That's too complicated, there's no reason to retrieve the sizes twice, just handle that in the main loop. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [usp10 3/6] Fix the handling of spaces in ScriptBreak and ScriptShape
by Alexandre Julliard Dec. 18, 2009

Dec. 18, 2009

Jason Green <jave27(a)gmail.com> writes: > commit 93b60cf8b1bcdabf008437b00cde35e162bdad1c > Author: Jason Green <jason(a)transgaming.com> > Date: Thu Dec 17 10:56:39 2009 -0500 > > Fix the handling of spaces in ScriptBreak and ScriptShape > From: Eric van Beurden <ericvb(a)transgaming.com> It doesn't work: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:1245: Test failed: fWhiteSpace set usp10.c:1256: Test failed: fWhiteSpace set make[2]: *** [usp10.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mapi32: add French translation
by Nicolas Le Cam Dec. 18, 2009

Dec. 18, 2009

Hi Frédéric, Using "absence" and "installé" in the same sentence doesn't sound right. Something like "L'envoi de courriel a échoué car vous n'avez pas de client mail MAPI installé." or "L'envoi de courriel a échoué du fait de l'absence de client mail MAPI." should be simpler and more correct. -- Nicolas Le Cam

2 1

gcrypt windows build is done on linux, uses wine to run test suite
by Dan Kegel Dec. 18, 2009

Dec. 18, 2009

Here's an interesting tidbit. gcrypt's windows version's only supported build environment is mingw on unix/linux, and it relies on wine to run its test suite. - Dan ---------- Forwarded message ---------- From: Simon Josefsson <simon(a)josefsson.org> Date: Thu, Dec 17, 2009 at 12:57 PM Subject: Re: gcrypt windows build To: "Hoyt, David" <hoyt6(a)llnl.gov> Cc: Werner Koch <wk(a)gnupg.org>, "gcrypt-devel(a)gnupg.org" <gcrypt-devel(a)gnupg.org> "Hoyt, David" <hoyt6(a)llnl.gov> writes: >> We only support cross-builds from a POSIX platform. If you try to build it on the traget platform it may or may not work. > > How do you test a cross-compiled library? How do you run your test > programs to validate your cross-compiled libraries are working > correctly? Do you have any tips on how I could get the test programs > working? Use wine. Just install MinGW and Wine under Linux, and then build libgcrypt like this: ./configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu It will invoke the self-tests automatically, if you have the binfmt-support package installed. If you want a makefile that does everything, check out <http://josefsson.org/gnutls4win/Makefile>. /Simon _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel(a)gnupg.org http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

2 1

daily 16 bit tests?
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 18, 2009

Dec. 18, 2009

Hi, there have been a number of 16bit changes lately (accompanied by a few regressions) and I've been wondering whether some bot somewhere has been setup to execute 16 bit tests (I read that there's a 16bit testsuite somewhere, not integrated into Wine tests)? I believe that would be a good thing to have. BTW, I've come across a weird situation where a 16bit app crashes in "recent" Wine. Actually, I've an old build of wine-1.1.16 which works, but when I recompile 1.1.16 (or anything more recent) nowadays, the app crashes. Except for Ubuntu's security updates and installation of libmpg123, I don't see what's changed on this machine. Anybody with similar experience? Hmm, perhaps that old wine-1.1.16 was compiled with Ubuntu Hardy, not Intrepid... Regards, Jörg Höhle.

1 0

Re: Alexandre Julliard : user32: Add a thunking mechanism for 16-bit edit word break procedures.
by Eric Pouech Dec. 17, 2009

Dec. 17, 2009

Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: dcec342b50524562844f64d43d423ed2c83c1f97 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dcec342b50524562844f64d43… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Fri Dec 11 14:52:28 2009 +0100 > > user32: Add a thunking mechanism for 16-bit edit word break procedures. > > > Alexandre, shouldn't the thunk be released in EDIT_WM_NCDestroy upon EDITSTATE destruction ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 3

Re: [5/5] WineD3D: Implement buffer subrange mapping with GL_APPLE_flush_buffer_range
by Henri Verbeet Dec. 17, 2009

Dec. 17, 2009

2009/12/15 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct wined3d_buffer *This) ... > + This->maps = HeapAlloc(GetProcessHeap(), 0, sizeof(*This->maps)); This is the wrong place for that. Either do it in buffer_init(), or in buffer_Map(). Keeping track of maps should also be in a separate patch, and you should integrate "lock_count". > +struct map_range A "wined3d_" prefix wouldn't hurt. > + LONG maps_size; Does a signed variable really make sense here? > + /* TODO: GL_ARB_map_buffer_range */ > + return gl_info->supported[APPLE_FLUSH_BUFFER_RANGE]; As a general rule, I think it makes sense to add support for ARB extensions (when available) before vendor specific extensions.

3 7

Re: [usp10 1/6] Fix an uninitialized static variable.
by Juan Lang Dec. 17, 2009

Dec. 17, 2009

Hi Jason, - static const ABC nil; + static const ABC nil = {0}; This has no effect, as static variables are implicitly initialized to 0 anyway. It might be a little less surprising this way.. --Juan

3 6

Re: [dbghelp 1/2] Check for incorrectly set ClientPointers flag
by Eric Pouech Dec. 17, 2009

Dec. 17, 2009

Jason Green a écrit : I don't think it's a good idea to change the exception structure passed by the caller to the minidump creation it's better to hard wire the optimization in dump_exception_info A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Valgrind warnings down 50% from last month
by Dan Kegel Dec. 17, 2009

Dec. 17, 2009

The total count of valgrind warnings in the wine test suite has gone down from about 2000 a month ago http://kegel.com/wine/valgrind/logs/2009-11-16-19.12.errs.txt to about 1000 today http://kegel.com/wine/valgrind/logs/2009-12-15-07.57.errs.txt (as computed by http://kegel.com/wine/valgrind/logs/count.sh.txt ). Thanks to everyone who has been helping clean this up! Let's see if we can cut it down another 50% by this time next month...

1 2