November 2002 - Wine-Devel - list.winehq.org

valgrind and wine

by Dan Kegel

valgrind wine reports: ==6476== Valgrind detected that your program requires ==6476== the following unimplemented functionality: ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. ==6476== This may be because the functionality is hard to implement, ==6476== or because no reasonable program would behave this way, ==6476== or because nobody has yet needed it. In any case, let me know ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Dang. - Dan

Nov. 30, 2002

The conformance tests need you!

by Francois Gouget

Hi, I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms. That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine). You can see things more graphically at the following URL: http://fgouget.free.fr/wine/tests-en.shtml Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Nov. 30, 2002

Re: [RFC] Wine headers

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers I think everything should be under wine/ otherwise we risk conflicts with other packages. So I'd suggest something like this: ${prefix}/include/wine/windows -- standard Windows headers ${prefix}/include/wine/msvcrt -- MS Visual C Runtime library ${prefix}/include/wine -- Wine specific headers It means the Windows headers are a bit buried instead of being directly under wine/, but it's not too bad. As long as you don't change anything in the source tree I could be convinced to go along with that... -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2002

Case of Guiness offered (was: Re: Partial success report: Toshiba 220CDS electronic manual)

by Dan Kegel

Dimitrie O. Paun wrote: > On November 26, 2002 12:39 pm, Dan Kegel wrote: >> http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe >>I unzipped it with Linux unzip, then ran its setup and >>the app itself with Wine20020605-2 from Red Hat 8. > > ^^^^^^^^ > Wow, that is ancient. It seems like such a long time ago... :) > (But I don't mean to say that the test is not relevant) OK, I tried the same app with a freshly compiled Wine20021125. The results are no better. The commandline to run the program is cd c/docs wine toshdoc.EXE With either version of Wine, clicking around for a while locks the app up. (e.g. clicking on the big red Right Arrow 10-15 times locks it up). Plus the display artifacts (text being overwritten without being cleared) are still there. Wow, I'm really striking out running either the 16 bit or 32 bit version of this old app (see my other post today). Both are freely downloadable... I'd gladly buy a case of Guiness for anyone who contributed patches to the Wine tree that got either of these apps running cleanly. I sadly don't have time to do much more than test. - Dan

Nov. 30, 2002

Failure running 1998-era online manual

by Dan Kegel

I grabbed Wine-20021125 and built it on my Red Hat 7.3 box. Its behavior installing http://enduser:enduser(a)bbs.toshiba.co.uk/file/area128/S22D95UM.ZIP (the Windows 95 version of the user manual for my 1998-era Toshiba laptop) seems much improved over May/June 2002 wine, cool! However, running the app does no better. To run the app, you do cd 'c/Program Files/DOC' wine edoc32.exe TOSHIBA.M14 On Windows, it works fine. On Wine, it displays a splash screen, then exits. Here's a partial log: 08074e50:Ret kernel32.lstrcpyA() retval=406d2dc0 ret=01643c25 08074e50:Call winmm.mmioInstallIOProcA(2034314d,01643b30,10010000) ret=01643c54 trace:mmio:MMIO_InstallIOProc (540291405, 0x1643b30, 10010000, 1) fixme:mmio:MMIO_InstallIOProc Global procedures not implemented ... 08074e50:Ret winmm.mmioInstallIOProcA() retval=01643b30 ret=01643c54 08074e50:Ret PE DLL (proc=0x1641030,module=0x1640000,type=1,res=0x1) retval=1 ... 08074e50:Starting process C:\Program Files\DOC\edoc32.exe (entryproc=0x41c9b0) ... 08074e50:Call winmm.mmioOpenA(406d2cfc "+init",00000000,00000000) ret=00405fd6 trace:mmio:MMIO_Open ('+init', (nil), 00000000, 1); 08074e50:Call ntdll.RtlAllocateHeap(40380000,00000008,0000005c) ret=40c3e59b 08074e50:Ret ntdll.RtlAllocateHeap() retval=403c42b8 ret=40c3e59b trace:mmio:MMIO_ParseExtA ("+init") err:mmio:MMIO_ParseExtA + but no . in szFileName: "+init" It sounds like mmioOpen's documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… is incomplete; it doesn't describe what the function does when there's no filename, just a +init, in the string passed to mmioOpen. I tried patching the source for MMIO_ParseExtA to assume an extension of "" in this case, but it didn't help, the program still exits. Any suggestions? - Dan

Nov. 30, 2002

Re: [RFC] Winelib enhancements (Compiler)

by Acke Carlsson

On Thursday 28 November 2002 08:00 pm, Dimitrie O. Paun wrote: > On November 28, 2002 01:35 pm, Alexandre Julliard wrote: > > > -CC=gcc > > > +CC=wcc > > > > > > Q: Alexandre, would you accept such a utility in the tree? > > > > I don't know, I don't think you can write a one-size-fits-all script, > > different apps will require different options, and then it will get > > even more confusing IMO if you have two different ways of doing it > > depending on your options. Maybe we should simply have a script > > example in the documentation that people can adapt and ship with their > > app if the makefile really makes it hard to set options. > > Sorry, maybe I was unclear. This wrapper will probably be a small C > program that understands gcc's options. It needs to do the following: > -- add the include dirs first > -- add -fshort-wchar > -- add -D__int8=char -D__int16=short -D__int32=int "-D__int64=long long" > -- remove cygwin options not recognized by the Linux gcc > > If you think about them, it kindda makes sense, as under a Windowish > environment these options are _implied_ in the invocation of gcc, > just like -I /usr/include is implied when you invoke gcc under Linux. > > So to be honest, I don't see why it would be confusing, and second, > why we can not have a one-size-fits-all wrapper. > > As I said, this is more a porting tool, to help you with the initial port. > If the app has a configure script, you would want to instrument it to > generate the correct flags for the compiler, and use gcc directly. But this > is time consuming, and you have to worry about so many things at the > beginning, I find it so much easier to have something working, and tweak > only one thing at a time. Some small ide from uClibc.

Nov. 29, 2002

Re: ppdebug

by Duane Clark

Michael Sauer wrote: > ... > P.S.: sorry if this mail reaches the list twice, but the first one i send > with some private e-mail address and the list moderator will (hopefully) > erase it (as he does it every time). > Hmmm... since I am the moderator, I am a bit puzzled by that. On rare occasions I will reject a post, but always supply a reason. The only ones I "erase" are spam. In any case, starting Saturday afternoon for about a week, I will be gone. Hopefully some of the other folks with moderator access will fill in, otherwise moderated posts are going to get stuck in moderator limbo for quite awhile.

Nov. 29, 2002

RE: Janitorial Projects

by Patrik Stridvall

> "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > >I have updated the Janitorial section: > > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > > > >with the list of cross calls from 32->16, and W->A. > > > >There are currently 13 cross calls from 32->16 bit code, > >and 194 cross calls from Unicode to ASCII. [snip] > But what the heck do the errors about AW functions calling Unicode > mean? It means that winapi_check has a bug. Fixed in my tree. > Isn't that the actual idea about the AW functions? Yes. :-)

Nov. 29, 2002

RE: Wine conformance tests with MSVC headers

by Patrik Stridvall

> I tried to compile the various conformance tests with MSVC 6.0. There > are two different configurations for each project: with MSVC or Wine > headers. With the MSVC headers configuration, it doesn't find > "wine/test.h" (since wine/include is not in the include > path). Is it a > known behavior? With the Wine headers configuration, I don't > get those > errors It is bug. Fixed in my tree. Patch comming soon. > (but there are a bunch of warnings concerning signed/unsigned > comparisons, for which I'll try to send a patch tonight). OK.

Nov. 29, 2002

Re: Janitorial Projects

by Rolf Kalbermatter

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: >I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > >with the list of cross calls from 32->16, and W->A. > >There are currently 13 cross calls from 32->16 bit code, >and 194 cross calls from Unicode to ASCII. I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version. But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions? Rolf Kalbermatter

Nov. 29, 2002