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

current cvs doesn't compile with freetype-2.0.3

by Ben Stanley

Hi, I tried compiling current cvs wine on RH 7.2, and it fails... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c:43:31: freetype/ftnames.h: No such file or directory make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi' It seems that the autoconf test for freetype/ftnames.h doesn't work properly. The file is not present in the RH package, and is not included in the freetype-2.0.3 tarball either. BTW, I'm not on the list atm. Ben.

Dec. 31, 2001

Re: We *really* need a development model change !

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Hmm, and different "winver" settings for testing of the behaviour of > different Wine --winver settings and adapting to different Windows versions > are possible with this framework, too ? In its current state it uses the default Wine config from ~/.wine so any config changes can be done this way (of course we will have to support -winver in the config file, but we need that anyway). We could provide a set of standardized configs to reduce variation, but it may in fact be preferable to let people run with the config they normally use, so that we have a wider coverage of the different options. > Oh, and what about Win16 support of the test suite ? Not supported yet, though this could be added. In fact since the Perl layer already needs to convert the arguments, making it support 16-bit should be relatively easy, and probably a lot more transparent than doing it in C. > Still, I think we should try to have a C "compatibility" layer, too, for > two reasons: > - people who aren't familiar with anything else > - supporting diversity (what if someday we find out that perl "sucks" ? :-) If it turns out Perl doesn't work, we can always convert the tests to C, this should be relatively easy. Most of the tests will simply be a bunch of function calls and result checks, which is simple to do in any language. Besides, unless you want to do elaborate tests, you really don't need to know much Perl to be able to write tests with winetest. -- Alexandre Julliard julliard(a)winehq.com

Dec. 31, 2001

Re: Wine Tasklist

by eric pouech

a few comments... > * Cross process messages > - used by many applications > - needed for DDE (bug 95) > - Alexandre, you worked on this recently, right? Is this working now? > - See bug 93 interprocess messages should be fine now (even if all the interprocess object sharing isn't over yet) DDE is being worked on, so I don't think you should keep the item > * Native Alsa support > - Could it offer capabilities that OSS does not offer? [snip] > - Anti-rational: Alsa includes an OSS compatibilty mode that seems to > work pretty well ALSA is needed when you need proper full duplex capabilities however, only ALSA 1.0 should be supported (0.5 and 0.9 shouldn't, except if 0.9 interface turns out to stay the one for 1.0) > * aRts support > * ESounD support I think it would be a too high task to implement all the drivers... there's quite some activity right now on linux audio to ease this a bit. let's see where stuff like JACK will go > * Move the winsock16 code to wsock32 more generally, it would be a good thing to be able to tear 16 bit code away from wine (with a configure switch). This would be a must-have for embedded wine. Not really fun to do. > > * Winedbg expression handling > - when modifying the contents of a variable there can be mixups where > the debugger modifies its own memory instead of that of the > debugged process. do you have a precise example for this one ? this is more a bug than a big thing to do. from the debugger stand point, you could add: - (re)implement function calls from interpreter - add 16 bit trap support - write a transformer to make MSVC .DBG files from wine's .so files (&stabs) so that standard windows debugger can handle native DLLs - implementing imagehlp (or debughlp) would also be appreciated > > * Winedbg g++ 3.0 support > - The debugging format and the ABI changed in g++ 3.0 and winedbg > does not support the new ABI. > - This prevents debugging of C++ Winelib applications > - This is especially troublesome for MFC Winelib applications > - Eric, you worked on this recently, do you know if this is a thing > of the past or is it possible that there are still problems (I did > not test recently) winedbg never had support for the C++ ABI (neither from GCC nor MSVC). So GCC 3.0 shouldn't be an exception regarding the debugging format, it seems more (but I didn't install nor looked closely at it) that gcc chooses which debug format to use instructing gcc with -gstabs (or -gstabs+) instead of -g should ease the issue some other items to look at: * make the server a linux kernel module (has been discontinued) but could provide some performance enhancements A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Dec. 30, 2001

Re: We *really* need a development model change !

by Andreas Mohr

[omitting comments about very nice "make test" framework] On Sun, Dec 30, 2001 at 12:34:06PM -0800, Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > 1) The discussion started from John Sturtz post, who > > created the Perl module for Win32 functions. > > Discussion what is better - C or Perl for unit testing > > started later as I understand there was no conclusion. > > Now I can assume that this topic was not "discussed to > > death" and we can do it now ;-) > > OK you are right, it was discussed to death inside CodeWeavers, but > not all of that was public. Basically the argument is that some sort Hmm right. I really should have remembered the extent of these discussions. > of scripting language is better than plain C for two reasons: > > 1. It is much easier to install under Windows than a full development > environment, and we don't have to worry about supporting a dozen > different compilers. We can simply provide a zip file containing the > compiled script interpreter, and people can be up and running in > seconds. That one goes to you, I guess. > There are probably a number of things you cannot do from Perl, like > threads or exception handling, and for that we will want some kind of > C framework too. But I believe we can already go a long way with the > Perl stuff we have today. Maybe I'm wrong, maybe it's really unusable > and we need to scrap it and redo a C environment from scratch; but we > won't know that until we try to use it seriously. ...at which point we already have a huge data collection of "known expected function behaviour" that's just waiting for us to port it easily to C then or so... Hmm, and different "winver" settings for testing of the behaviour of different Wine --winver settings and adapting to different Windows versions are possible with this framework, too ? (we'd very much want to have that, I guess) Oh, and what about Win16 support of the test suite ? This is why I started this in the first place. I'm very much afraid of losing HUGE amounts of Win16 compatibility due to everybody using more and more Win32 programs only... I haven't toyed with the "make test" environment yet (severe lack of time - exam time), so I don't know much about it. Unfortunately I'm afraid I won't have much time in the foreseeable future either. Still, I think we should try to have a C "compatibility" layer, too, for two reasons: - people who aren't familiar with anything else - supporting diversity (what if someday we find out that perl "sucks" ? :-) That's it for now, Andreas (who'd really like to be able to contribute more to this now)

Dec. 30, 2001

Re: We *really* need a development model change !

by David Elliott

On 2001.12.30 15:34 Alexandre Julliard wrote: > 2. The scripts are independent from the compilation environment, which > allows testing binary compatibility. In C you have to compile the > tests under Wine using the Wine headers, which means you can't spot > wrong definitions in the headers since the test will see the same > definition as Wine itself. The only way around is to build tests > under Windows and run them under Wine but this is a major pain. > With a script you are guaranteed to run the exact same thing in both > environments. > Well, if it helps any, I have recently built a linux-cross-mingw32 toolchain as RPMs. For those not running on an RPM distro the specfiles should be easy enough to understand and do manually. For those who are running RH7.2 (and probably 7.1 as well) you can have the binary packages. And for all other RPM distros the source RPMs should build without problems. I have the following RPMs built: i386-mingw32-binutils-2.11.2-0_biscuit_0 i386-mingw32-gcc-bootstrap-3.0.3-0_biscuit_0 (built from the same specfile as the normal gcc but only makes a C compiler good enough to build w32api and mingw-runtime properly). i386-mingw32-w32api-1.2-0_biscuit_0 i386-mingw32-mingw-runtime-1.2-0_biscuit_0 All the rest are part of the gcc build: i386-mingw32-gcc-3.0.3-0_biscuit_0 i386-mingw32-gcc-c++-3.0.3-0_biscuit_0 i386-mingw32-libstdc++-devel-3.0.3-0_biscuit_0 i386-mingw32-gcc-g77-3.0.3-0_biscuit_0 i386-mingw32-gcc-java-3.0.3-0_biscuit_0 (unfortunately it didn't compile the java runtime, so this one is useless until I figure that out) If anyone is interested in this I can probably put it in kernelrpm.sourceforge.net temporarily before I contact the MinGW team and see if they would be interested in hosting these files on their sourceforge site. Please note that this is not just a simple compile. I had to do quite a bit of patching (well, figuring out what to patch was the issue, the patches are tiny) to get it to build and work properly even including thread support. I also have compiled wxMSW with this compiler and successfully built and tested the minimal, mdi, and taskbar test programs. Of note is that the MDI program does not show any icons in the toolbar when run under Wine, but works perfectly under Windows (95osr2 in Win4Lin). Is anyone aware of this, might be related to IE5.5 displaying black squares instead of icons in its toolbar, and would be significantly easier to debug as I built all of this with debugging info (assuming winedbg can read it), plus you'd have the full sourcecode from wxwindows.org. -Dave

Dec. 30, 2001

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > 1) The discussion started from John Sturtz post, who > created the Perl module for Win32 functions. > Discussion what is better - C or Perl for unit testing > started later as I understand there was no conclusion. > Now I can assume that this topic was not "discussed to > death" and we can do it now ;-) OK you are right, it was discussed to death inside CodeWeavers, but not all of that was public. Basically the argument is that some sort of scripting language is better than plain C for two reasons: 1. It is much easier to install under Windows than a full development environment, and we don't have to worry about supporting a dozen different compilers. We can simply provide a zip file containing the compiled script interpreter, and people can be up and running in seconds. 2. The scripts are independent from the compilation environment, which allows testing binary compatibility. In C you have to compile the tests under Wine using the Wine headers, which means you can't spot wrong definitions in the headers since the test will see the same definition as Wine itself. The only way around is to build tests under Windows and run them under Wine but this is a major pain. With a script you are guaranteed to run the exact same thing in both environments. I started implementing a simple scripting language, but then John Sturtz showed that it was possible to leverage Perl to do the same thing, so I think it's the way to go. There are probably a number of things you cannot do from Perl, like threads or exception handling, and for that we will want some kind of C framework too. But I believe we can already go a long way with the Perl stuff we have today. Maybe I'm wrong, maybe it's really unusable and we need to scrap it and redo a C environment from scratch; but we won't know that until we try to use it seriously. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2001

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > No, ability to call W32 API functions is not > considered a unit test infrastracture. I may say Wine > has such infrastructure for C since 1993 :-). From > this point of view Andreas test application provides > more support for unit tests than plain Perl module. Not really, because you need a lot more infrastructure to build C tests than to simply run Perl scripts. For Perl all you need is the winetest app that is in the tree, plus a bit of Makefile glue which is pretty trivial to do. In fact here's a 10-minute hack to add a make test target. With that all you have to do is create a test script in dlls/xxx/tests/foo.test, put the expected output in tests/foo.test.ref (presumably generated by running the test under Windows), add your script to the makefile and run make test. Index: Make.rules.in =================================================================== RCS file: /opt/cvs-commit/wine/Make.rules.in,v retrieving revision 1.95 diff -u -r1.95 Make.rules.in --- Make.rules.in 2001/12/14 23:14:22 1.95 +++ Make.rules.in 2001/12/30 18:00:41 @@ -47,6 +47,7 @@ RM = rm -f MV = mv MKDIR = mkdir -p +DIFF = diff -u C2MAN = @C2MAN@ MANSPECS = -w $(TOPSRCDIR)/dlls/gdi/gdi32.spec \ -w $(TOPSRCDIR)/dlls/user/user32.spec \ @@ -58,6 +59,8 @@ ALLLINTFLAGS = $(LINTFLAGS) $(DEFS) $(OPTIONS) $(DIVINCL) WINAPI_CHECK = $(TOPSRCDIR)/tools/winapi_check/winapi_check WINEBUILD = $(TOPOBJDIR)/tools/winebuild/winebuild +WINETEST = $(TOPOBJDIR)/programs/winetest/winetest +RUNTEST = $(TOPOBJDIR)/programs/winetest/runtest MAKEDEP = $(TOPOBJDIR)/tools/makedep WRC = $(TOPOBJDIR)/tools/wrc/wrc WMC = $(TOPOBJDIR)/tools/wmc/wmc @@ -95,7 +98,7 @@ # Implicit rules -.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c +.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c .test .test.out .test.ref .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $< @@ -121,6 +124,12 @@ .c.ln: $(LINT) -c $(ALLLINTFLAGS) $< || ( $(RM) $@ && exit 1 ) +.test.test.out: + $(RUNTEST) $(TOPOBJDIR) $< > $@ + +.test.out.test.ref: + $(DIFF) $< $@ && touch $@ + .PHONY: all install uninstall clean distclean depend dummy # 'all' target first in case the enclosing Makefile didn't define any target @@ -216,7 +225,7 @@ -cd `dirname $@` && $(RM) $(CLEAN_FILES) clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) - $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(PROGRAMS) + $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(TESTS:%=tests/%.out) $(PROGRAMS) # Rules for installing @@ -225,6 +234,13 @@ $(SUBDIRS:%=%/__uninstall__): dummy cd `dirname $@` && $(MAKE) uninstall + +# Rules for testing + +test:: $(WINETEST) $(TESTS:%=tests/%.out) $(TESTS:%=tests/%.ref) + +$(WINETEST): + cd $(TOPOBJDIR)/programs/winetest && $(MAKE) winetest # Misc. rules Index: Makefile.in =================================================================== RCS file: /opt/cvs-commit/wine/Makefile.in,v retrieving revision 1.103 diff -u -r1.103 Makefile.in --- Makefile.in 2001/11/23 23:04:58 1.103 +++ Makefile.in 2001/12/30 18:00:41 @@ -132,6 +132,9 @@ @cd dlls && $(MAKE) checklink @cd debugger && $(MAKE) checklink +test:: + @cd dlls && $(MAKE) test + TAGS etags: etags `find $(TOPSRCDIR) -name '*.[chS]' -print | grep -v dbgmain` Index: dlls/Makedll.rules.in =================================================================== RCS file: /opt/cvs-commit/wine/dlls/Makedll.rules.in,v retrieving revision 1.16 diff -u -r1.16 Makedll.rules.in --- dlls/Makedll.rules.in 2001/09/17 20:09:08 1.16 +++ dlls/Makedll.rules.in 2001/12/30 18:01:00 @@ -36,6 +36,10 @@ checklink:: lib$(MODULE).$(LIBEXT) $(CC) -o checklink $(TOPSRCDIR)/library/checklink.c -L. -l$(MODULE) $(ALL_LIBS) && $(RM) checklink +# Rules for testing + +$(TESTS:%=tests/%.out): lib$(MODULE).$(LIBEXT) + # Rules for debug channels debug_channels: dummy Index: dlls/Makefile.in =================================================================== RCS file: /opt/cvs-commit/wine/dlls/Makefile.in,v retrieving revision 1.109 diff -u -r1.109 Makefile.in --- dlls/Makefile.in 2001/11/06 17:52:37 1.109 +++ dlls/Makefile.in 2001/12/30 18:01:02 @@ -764,6 +764,9 @@ # Misc rules +$(SUBDIRS:%=%/__test__): dummy + @cd `dirname $@` && $(MAKE) test + $(SUBDIRS:%=%/__checklink__): dummy @cd `dirname $@` && $(MAKE) checklink @@ -773,6 +776,8 @@ install:: $(SUBDIRS:%=%/__install__) uninstall:: $(SUBDIRS:%=%/__uninstall__) + +test:: $(SUBDIRS:%=%/__test__) checklink:: $(SUBDIRS:%=%/__checklink__) --- /dev/null Fri Dec 7 20:45:56 2001 +++ programs/winetest/runtest Sat Dec 29 17:00:48 2001 @@ -0,0 +1,9 @@ +#!/bin/sh +topobjdir="$1" +shift +perldir="$topobjdir/programs/winetest" +LD_LIBRARY_PATH="$topobjdir/dlls:$topobjdir:$LD_LIBRARY_PATH" +export LD_LIBRARY_PATH +WINESERVER="$topobjdir/server/wineserver" +export WINESERVER +exec $perldir/winetest -debugmsg -all -- -I $perldir $@ -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

Ok -I'm just about ready to submit a patch :) What I've done is to check for the pre-iso signature, and if it occurs, to increase the offset by 8. This puts the offset in a position that makes the get label function find the correct entry. I've tested it with both 'normal' iso9660 cds, and with pre-iso cds (e.g. MS Multimedia Beethoven, and MS Cinemania 92) and it works flawlessly in both cases. Any comments by anyone before I send in the patch? regards Chris Green

Dec. 30, 2001

Re: Mixed-mode CD Labels

by David Elliott

On 2001.12.30 05:10 Chris Green wrote: > On Sunday 30 December 2001 20:04, you wrote: > > > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp > bs=65536 > > > count=1' and compress the result before emailing it to me :) > > > > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? > > > > Maybe it doesn't make a damn bit of difference, but as the blocksize on > > cds is 2048 bytes I think it makes more sense to say gimme the first 32 > > 2048-byte sectors. > > > > six of one, half-a-dozen of the other :) they give the same data, I just > often go for large block sizes and smaller counts - some read-ahead type > operations run faster, I find, if you do that. I don't mind either way :) > Duh! For some reason I was thinking the other way around... i.e. If you specify the blocksize as less than what the blocksize is (or not on an integer multiple of it) then you run into issues. You are correct, specifying it as 64kiB (gotta love the new SI standards, hehe) would actually increase the reading performance, not decrease it. -Dave

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

On Sunday 30 December 2001 20:04, you wrote: > > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 > > count=1' and compress the result before emailing it to me :) > > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? > > Maybe it doesn't make a damn bit of difference, but as the blocksize on > cds is 2048 bytes I think it makes more sense to say gimme the first 32 > 2048-byte sectors. > six of one, half-a-dozen of the other :) they give the same data, I just often go for large block sizes and smaller counts - some read-ahead type operations run faster, I find, if you do that. I don't mind either way :) Chris

Dec. 30, 2001