June 2004 - Wine-Devel - list.winehq.org

Re: [MSVCRT] Cross build fix

by Dimitrie O. Paun

On Tue, Jun 01, 2004 at 11:42:28AM +0200, Hans Leidekker wrote: > > Hi, > > This patch: > > http://www.winehq.org/hypermail/wine-cvs/2004/04/0357.html > > broke the MinGW build of msvcrt. The changelog says it's a compatibility > fix. Dimi: what compatibility were you aiming at with this patch? Compatibility with other headers. _WCTYPE_T_DEFINED is in a way part of the public interface, and when we use the headers in Winelib apps, we need to define it so we don't end up with duplicate declarations for wint_t/wctype_t. When we build msvcrt it's a different story of course, and we seem to need the exact opposite. Which is why I find the entire MSVCRT() thing not only ugly, but a bit problematic also. Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts. -- Dimi. P.S. Please note that in theory the same situation holds true for all the other sentries. So it's not like we only have a problem with wint_t/wctype_t.

June 1, 2004

Re: Current Wine CVS status

by Dmitry Timoshkov

"Mike Hearn" <mh(a)codeweavers.com> wrote: > > Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] > > You have invoked `ld.so', the helper program for shared library executables. > > Does this occur if you run Wine like this? > > wine ~/wine/wine --help Yes. > Also, what glibc version (exactly) is this? glibc-2.1.3-22.i386.rpm -- Dmitry.

June 1, 2004

Re: [REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)

by Luca Capello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, on 05/31/04 21:11, Tim Hentenaar wrote: > A friend of mine who has a recent release of wine uses Photoshop 7 > just fine. It was he and I who took the screenshot that's in the app > database (we were using 2003-12-12 at the time). He just updated his > wine install via gentoo's emerge about a week and a half ago. this sounds me strange, as in current CVS from command cvs -d $CVSROOT update -D "2004-06-01 CST" the XP extensions which cause the regression are still present. BTW, in the bug #2017 [1] there're some reports by Gentoo users about the same problem... Could you try to find which version does your friend use? Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAvF4KVAp7Xm10JmkRAl9tAJ9kzhiW/PjfJk9dIu6pjQVUUJmORwCdGAxr qD2QVjYQH6PTRtFy3x4z1JI= =CfN7 -----END PGP SIGNATURE-----

June 1, 2004

Re: Minor logging improvements to freetype.c

by Huw D M Davies

On Mon, May 31, 2004 at 09:47:35PM +0100, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Change some TRACEs into WARNs, WARN on skipping font due to wrong format. > > Index: dlls/gdi/freetype.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > retrieving revision 1.60 > diff -u -r1.60 freetype.c > --- dlls/gdi/freetype.c 20 Apr 2004 01:12:18 -0000 1.60 > +++ dlls/gdi/freetype.c 31 May 2004 20:47:29 -0000 > @@ -316,20 +316,21 @@ > } > > if(!FT_IS_SFNT(ft_face)) { /* for now we'll skip everything but TT/OT */ > + WARN("skipping font file %s, not TrueType/OpenType font\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } > if(!pFT_Get_Sfnt_Table(ft_face, ft_sfnt_os2) || > !pFT_Get_Sfnt_Table(ft_face, ft_sfnt_hhea) || > !(pHeader = pFT_Get_Sfnt_Table(ft_face, ft_sfnt_head))) { > - TRACE("Font file %s lacks either an OS2, HHEA or HEAD table.\n" > + WARN("Font file %s lacks either an OS2, HHEA or HEAD table.\n" > "Skipping this font.\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } > > if(!ft_face->family_name || !ft_face->style_name) { > - TRACE("Font file %s lacks either a family or style name\n", debugstr_a(file)); > + WARN("Font file %s lacks either a family or style name\n", debugstr_a(file)); > pFT_Done_Face(ft_face); > return FALSE; > } You could argue that these three should really be FIXMEs > @@ -369,13 +370,13 @@ > (*insertface)->font_version, pHeader->Font_Revision); > > if(fake_family) { > - TRACE("This font is a replacement but the original really exists, so we'll skip the replacement\n"); > + WARN("This font is a replacement but the original really exists, so we'll skip the replacement\n"); > HeapFree(GetProcessHeap(), 0, StyleW); > pFT_Done_Face(ft_face); > return FALSE; > } > if(pHeader->Font_Revision <= (*insertface)->font_version) { > - TRACE("Original font is newer so skipping this one\n"); > + WARN("Original font is newer so skipping this one\n"); > HeapFree(GetProcessHeap(), 0, StyleW); > pFT_Done_Face(ft_face); > return FALSE; > I don't think these two should be warnings. It's perfectly possible to have two copies of the same font installed and you don't want to confuse users by issuing warnings about something where we actually do the right thing. Huw. -- Huw Davies huw(a)codeweavers.com

June 1, 2004

Re: [REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)

by Luca Capello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, on 06/01/04 00:34, Troy Rollo wrote: > On Tue, 1 Jun 2004 01:53, Luca Capello wrote: >> as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after >> wine-20031212 (in the majority of cases). > *In what way* does it stop working? It might be that you're using a feature > that Wine coders using Photoshop 7.0 don't use. I thought it was superfluous to report again the problem, as it's perfect reported in the bug #2017 [1] and in the Wine App DB (Photoshop 7.0, [2]). Anyway, here the description: ===== luca(a)gismo:~/cvs/wine-cvs-20040130-165721$ ./wine /home/luca/.wine/fake_windows/Program\ Files/Adobe/Photoshop\ 7.0/Photoshop.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (United States keyboard layout (phantom key version)) for scancode mapping. Please define your layout in dlls/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. fixme:win32:SetCriticalSectionSpinCount critsection=0x40c338e0: spincount=20 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c33fa4: spincount=500 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c33aa4: spincount=500 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c33ca4: spincount=500 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c34028: spincount=500 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c3414c: spincount=500 not supported fixme:win32:SetCriticalSectionSpinCount critsection=0x40c341c8: spincount=50 not supported fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! fixme:actctx:QueryActCtxW stub! [a small window appears with "Success" and the 'OK' button, clicking on the button closes the window and exits wine with value 0] luca(a)gismo:~/cvs/wine-cvs-20040130-165721$ ===== If needed, I can provide the full 'WINEDEBUG=+warn,all ./wine' output. Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 [2] http://appdb.winehq.org/appview.php?appId=17&versionId=1336 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAvFuxVAp7Xm10JmkRAn8VAJ9fYqS3rMgqMq0zKDuPehyfvbZH8QCeLRT4 Yw6YMbG5xnoBsO14D4PnWYM= =0KLD -----END PGP SIGNATURE-----

June 1, 2004

Re: Wine bug with delphi Menus

by Robert van Herk

Dan Kegel wrote: > Please do put the source and executable of your demo > app online at some web page, and post the URL on wine-devel. Okay, please feel free to grab it from http://www.students.cs.uu.nl/people/rherk/DelphiMenuTest.tar.gz . Greetings, Robert P.S. Hope I got the bonus :-P

June 1, 2004

Re: broken mingw build

by Mike Hearn

On Tue, 2004-06-01 at 09:50 +0200, Hans Leidekker wrote: > I suspect .previous is ELF specific? Yes, .previous is ELF specific. It reverts the assembler to generating output in whatever the previous section was, so if you write: .text blah blah blah .previous then you are now back in the section you were before .text - PE doesn't really have the same idea of sections as ELF does. thanks -mike

June 1, 2004

Re: [OLEAUT32] Resend: Typelibs, Better handling of References

by Mike Hearn

On Tue, 2004-06-01 at 09:33 +0200, Raphael wrote: > Now we go further on many InstallShields (i'm using Prince Of Persia and > SplinterCell Demo) but InstallShield seems to freeze after creating the > "desktop/background" window (i only see Window messaging traces). > Any expert to help me ? > helpppp, i want a lot to use SplinterCell Demo :( Are you sure it's frozen, or is it actually that the big blue window was created as override-redirect so is placed always-on-top by your window manager? What happens if you use desktop mode? thanks -mike

June 1, 2004

Re: broken mingw build

by Hans Leidekker

On Sunday 30 May 2004 02:59, Kevin Koltzau wrote: > This patch > http://cvs.winehq.org/patch.py?id=12495 > seems to have broken the mingw build, currently getting Are you saying you could build Wine with MinGW before this patch? > i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c > {standard input}: Assembler messages: > {standard input}:124: Error: unknown pseudo-op: `.previous' > {standard input}:135: Error: unknown pseudo-op: `.previous' > {standard input}:145: Error: unknown pseudo-op: `.previous' > {standard input}:155: Error: unknown pseudo-op: `.previous' > {standard input}:165: Error: unknown pseudo-op: `.previous' > make[2]: *** [interlocked.o] Error 1 I suspect .previous is ELF specific? Don't know if it's worth fixing this since AFAICS this code is about portability toward Unix platforms and now we're trying to build PE executables from it with MinGW. Cygwin might be an interesting target in this respect though. -Hans Changelog: MinGW portability fix.

June 1, 2004

Re: Use TRACE rather than FIXME for check_resource_write

by Dmitry Timoshkov

[forgot to cc wine-devel] "Mike Hearn" <mh(a)codeweavers.com> wrote: > No need for this to be a fixme, we can't fix broken apps anyway and it > just confuses people. > > Mike Hearn <mh(a)codeweavers.com> > Use TRACE rather than FIXME for check_resource_write I have found and fixed at least one bug in Wine itself thanks to this fixme message. -- Dmitry.

June 1, 2004

Re: General serial communications issues

by James Courtier-Dutton

I have looked into the wine code now, and async reads from the COM port are just broken. The app calls read, wine sets off the FILE_AsyncReadService, and then returns to the app. FILE_AsyncReadService is called each time a character is received from the COM port, and it buffers up the received characters in the 1024 bytes buffer. The next time the app calls read, wine sets off a new (now making it two) FILE_AsyncReadService, but clears the buffer first, so all the characters received from the previous FILE_AsyncReadService get lost. This is where the input characters are getting lost. James

June 1, 2004