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

Re: Babystep: Testing framework

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > I'm not > going to create dozens of directories and spec files > in the CVS tree > pending a better solution As I mentioned earlier I'm not very experienced with this stuff. Excuse me for asking newbie questions: 1) why do we have to create a separate directory for each winelib application? 2) can we pack .spec information to one big file and then generate .spec files from it? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

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

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > The idea is that you might want to run the TODO_WINE > tests under Wine > in Windows mode, for instance to find a problem > you'd like to work > on. You could grep for TODO_WINE in the test scripts > but this is less > convenient IMO. Understood. IMO grep is better - you can choose from list of TODO's. Lets leave it to the time when somebody needs the feature. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

Re: Babystep: Testing framework

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > Well, I was sufficiently impressed with the Cygwin install > to think it wouldn't be that bad; if nothing else, I think > we should try to have both. If we can support Cygwin without major trouble of course we should do it. But if the idea is to attract Windows developers, offering them a Unix environment may not be the best choice. > I would argue, that except perhaps for your objection to > my *.test format, that the framework as I have proposed would > be a good start. We can refine the Winelib stuff later. > > It seems to me that the alternate is to spend another five > weeks debating possible frameworks, and ending with none implemented. It's not really a question of debating frameworks, it's more a question of getting the building process into a useable form. I'm not going to create dozens of directories and spec files in the CVS tree pending a better solution. But I'll work on getting at least the Perl stuff into the tree, and then we can work on refining the C infrastructure. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Do not understand why we need to have the command line > option. TODO_WINE will automatically detect when the > application runs under Wine. Under Windows the code in > TODO_WINE will be executed like there is no TODO. The idea is that you might want to run the TODO_WINE tests under Wine in Windows mode, for instance to find a problem you'd like to work on. You could grep for TODO_WINE in the test scripts but this is less convenient IMO. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

Re: Listview ctrl

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Good point. I'm convinced. But since we are on the subject, why did you > prefer the use of the WideToXXX function instead of the > RtlCreateUnicode...Asciiz? No real reason, mostly laziness. It was easier to simply copy the 3 lines from HEAP_strdup into the code than to change it to use the Rtl* functions. But if you feel like changing that you are most welcome to do it. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

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

by Andriy Palamarchuk

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > 3) Organization of the unit tests in such way, so > they > > can be used by other Win32 implementation > projects. > > Conditional TODOs I suggested above will help to > > manage different TODO lists for different > projects. > > Looks good, though I would suggest having simply a > TODO_WINE instead > of making people write the same test thousands of > times. Then we can > add TODO_ODIN or whatever if the need arises. Good idea, updating the library. > And I think the TODOs > should be controlled by a command-line option, so > you can switch them on under Wine too. Do not understand why we need to have the command line option. TODO_WINE will automatically detect when the application runs under Wine. Under Windows the code in TODO_WINE will be executed like there is no TODO. > But these are details, I think > overall it looks quite good. I'm also satisfied by the overall status. Don't have big experience in build process creation, leaving this part up to you. Otherwise I'm willing to work further on unit tests.time. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

Is W really UTF-16?

by Bill Medland

Sorry to resurrect an old subject, and please excuse my ignorance; I am only just getting started on this "character encoding" stuff. While I was working on the DrawText functions over the past many months I started wondering about when it would fail. (I'm pedantic and such things fascinate me!). The main concern I have is how to walk a W string correctly. For example while "ellipsifying" text we will need to "move the pointer to the previous character" which is currently done by decrementing the pointer by 1. But from what I currently understand that won't work if there are surrogate pairs. I see that MSDN these days keeps talking about surrogate pairs and the fact that strings of WCHARS might include them and I started to get the impression that the inputs to the W functions were truly UTF-16. I have just been looking at the discussions from April 2000 on this subject and I get the impression that we believe it too. My understanding of UTF-16 is that a surrogate pair is quite obvious and doesn't require any context information; if you come across a 16 bit value in 0xDC00 to 0xDFFF then it must be the low surrogate and there must be a high surrogate just before it. So I presumed that CharNextW must be the function that correctly walks a W string and I tried to find out what its behaviour was for the error cases (e.g. high surrogate with no low surrogate). On finding that CharNextW didn't do anything clever, it just incremented by 1, I tested and found that CharNextW always incremented by 1. So now I am confused. 1. Does anyone know under what circumstances CharNextW isn't +1 (apart from when pointing at the terminating 0) 2. Is e.g. XP really using UTF-16 or is it actually still UCS2? 3 Have we thought about how we should handle walking along a W string (in a fashion that doesn't reduced the speed to a crawl). I guess that in the short term I am expecting some sort of macro or inline. Bill Medland

Jan. 9, 2002

Re: Babystep: Testing framework

by Jeremy White

> I can't say I like your *.test files; I think this should be taken > care of by the makefile directly. I started down this road, but then I ended up needing PERL_TESTS and INVOKE_TESTS in the Makefile, and IMHO, that was uglier than the *.test file. This may simply be a lack of Makefile moxy on my part; the point where I threw up my hands in disgust was when I was requiring my Winelib/C tests to be compiled into a 'foo.itest' so that I could do a .itest.test.out dependency rule. > Also it seems the consensus is that > we should simply check the exit status of the test, not compare the > test output. Sorry, this wasn't clear. That is the default behavior. I preserved the pattern and reference checking as an optional addition. > > >>Flaws: >> 1. It has no provision for use on Windows. >> IMO the right way to fix this is to >> go through the effort of making Wine's >> ./configure script be intelligent enough >> to build 'Winelib' programs, so that >> in Windows a 'make test' should just work. >> > > I'm not sure about that; I think it would be preferable to have a > simple, self-contained environment. Running configure would require a > lot of stuff to be installed on the Windows side. Well, I was sufficiently impressed with the Cygwin install to think it wouldn't be that bad; if nothing else, I think we should try to have both. > > >> 2. I really don't like that a C/Winelib >> test requires its own directory >> (see samples/sample3). However, AFAICT, >> that was the only way to create a simple >> and clean build environment for the Winelib app. >> > > That's the problem with C tests. You cannot have one executable for > each test, at least not with Winelib, so we need a way to build > multiple tests inside a single executable. Not very hard, but there's > a bit of work involved. I would argue, that except perhaps for your objection to my *.test format, that the framework as I have proposed would be a good start. We can refine the Winelib stuff later. It seems to me that the alternate is to spend another five weeks debating possible frameworks, and ending with none implemented. Jer

Jan. 9, 2002

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Which approaches can you suggest to reach goals I > believe are important: > > 1) bundling - are we going to have separate > distributions - Wine with tests, tests only, Wine > only? There are a lot of cases where only one of them > is required. My view is that everything is distributed with Wine, and we have a script on WineHQ that builds a zip of the test-only environment for use under Windows, and/or a script to fetch it from CVS on Windows. > 2) development of the unit tests under Windows. > Obviously, we don't need to have Wine itself when we > work with unit tests on Windows. Plus, we need to > create development environment, usable by Windows > developers. For Perl we need to ship a winetest.exe and a couple of scripts to run through the tests. For C we need to generate makefiles one way or another, including support for the major Windows compilers. > 3) Organization of the unit tests in such way, so they > can be used by other Win32 implementation projects. > Conditional TODOs I suggested above will help to > manage different TODO lists for different projects. Looks good, though I would suggest having simply a TODO_WINE instead of making people write the same test thousands of times. Then we can add TODO_ODIN or whatever if the need arises. And I think the TODOs should be controlled by a command-line option, so you can switch them on under Wine too. But these are details, I think overall it looks quite good. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

Re: Babystep: Testing framework

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > It has provisions for Perl and Winelib/C tests, as > well as allowing for the arbitrary execution of > any other command (which should allow any other > test tools to be plugged in). I can't say I like your *.test files; I think this should be taken care of by the makefile directly. Also it seems the consensus is that we should simply check the exit status of the test, not compare the test output. > Flaws: > 1. It has no provision for use on Windows. > IMO the right way to fix this is to > go through the effort of making Wine's > ./configure script be intelligent enough > to build 'Winelib' programs, so that > in Windows a 'make test' should just work. I'm not sure about that; I think it would be preferable to have a simple, self-contained environment. Running configure would require a lot of stuff to be installed on the Windows side. > 2. I really don't like that a C/Winelib > test requires its own directory > (see samples/sample3). However, AFAICT, > that was the only way to create a simple > and clean build environment for the Winelib app. That's the problem with C tests. You cannot have one executable for each test, at least not with Winelib, so we need a way to build multiple tests inside a single executable. Not very hard, but there's a bit of work involved. -- Alexandre Julliard julliard(a)winehq.com

Jan. 9, 2002

Babystep: Testing framework

by Jeremy White

The attached revision to Alexandres patch modifies the Wine makefiles such that a Linux developer can: make test (to confirm all regression tests) make clean-test (to clear the tests and try again) It also creates three sample tests in programs/winetest/samples which hopefully demonstrate to a test author how to write a test. (The *.test files are human readable). It has provisions for Perl and Winelib/C tests, as well as allowing for the arbitrary execution of any other command (which should allow any other test tools to be plugged in). It has many flaws, but is intended as a possible jumpstart to get this process rolling. Flaws: 1. It has no provision for use on Windows. IMO the right way to fix this is to go through the effort of making Wine's ./configure script be intelligent enough to build 'Winelib' programs, so that in Windows a 'make test' should just work. 2. I really don't like that a C/Winelib test requires its own directory (see samples/sample3). However, AFAICT, that was the only way to create a simple and clean build environment for the Winelib app. 3. No doco. Thoughts? Comments? Jer diff --exclude=CVS -rNu oldwine/programs/winetest/Makefile.in wine/programs/winetest/Makefile.in --- oldwine/programs/winetest/Makefile.in Sat Nov 24 11:07:14 2001 +++ wine/programs/winetest/Makefile.in Wed Jan 9 09:20:50 2002 @@ -12,6 +12,8 @@ EXTRA_OBJS = wine.o +SUBDIRS = samples + @MAKE_PROG_RULES@ diff --exclude=CVS -rNu oldwine/programs/winetest/runtest wine/programs/winetest/runtest --- oldwine/programs/winetest/runtest Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/runtest Wed Jan 9 10:22:42 2002 @@ -0,0 +1,70 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# runtest <wine dir> <test name> <output file name> +# Run a regression test +# +# This script sources a '.test' file which must set one of the following: +# test_invoke (a command to invoke) +# test_perl_script (a Perl test script to be run with winetest) +# and can set one of the following: +# test_reference=<name of reference file with required diff> +# test_pattern=<pattern required in output> +#---------------------------------------------------------------------------- +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 + +testfile="$1" +testfiledir=`dirname $testfile` +shift + +outfile="$1" + + +export test_invoke= +export test_perl_script= +export test_reference= +export test_pattern= + +source $testfile + + +if [ "$test_perl_script" ] ; then + $perldir/winetest -debugmsg -all -- -I $perldir $testfiledir/"$test_perl_script" >$outfile +elif [ "$test_invoke" ] ; then + $testfiledir/$test_invoke >$outfile +else + echo "Error - neither test_invoke nor test_perl_script set in .test file" + rm -f $outfile + exit 1 +fi +return_status=$? + +if [ $return_status -ne 0 ] ; then + echo "Test $@ failed - return status $return_status" + rm -f $outfile + exit $return_status +fi + +if [ "$test_reference" ] ; then + diff -q $outfile $testfiledir/"$test_reference" >/dev/null 2>&1 + if [ $? -ne 0 ] ; then + echo "Test $@ failed - output failed to match reference" + rm -f $outfile + exit $? + fi +fi + +if [ "$test_pattern" ] ; then + grep -q "$test_pattern" $outfile + if [ $? -ne 0 ] ; then + echo "Test $@ failed - pattern $test_pattern not found" + rm -f $outfile + exit $? + fi +fi + diff --exclude=CVS -rNu oldwine/programs/winetest/samples/Makefile.in wine/programs/winetest/samples/Makefile.in --- oldwine/programs/winetest/samples/Makefile.in Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/Makefile.in Wed Jan 9 10:23:08 2002 @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = samples + +SUBDIRS = sample3 + +TESTS = sample1.test \ + sample2.test \ + sample3.test + +(a)MAKE_RULES@ + diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.ref wine/programs/winetest/samples/sample1.ref --- oldwine/programs/winetest/samples/sample1.ref Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.ref Tue Jan 8 22:51:51 2002 @@ -0,0 +1 @@ +Sample Test 1 Output diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.sh wine/programs/winetest/samples/sample1.sh --- oldwine/programs/winetest/samples/sample1.sh Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.sh Tue Jan 8 22:51:32 2002 @@ -0,0 +1,2 @@ +#!/bin/bash +echo Sample Test 1 Output diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample1.test wine/programs/winetest/samples/sample1.test --- oldwine/programs/winetest/samples/sample1.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample1.test Tue Jan 8 23:29:30 2002 @@ -0,0 +1,15 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample1 +# +# Test Purpose: +# To show how to write a simple test that runs a shell script +# +#---------------------------------------------------------------------------- +#test_perl_script=<name of Perl script to be used> +test_invoke=sample1.sh +test_reference=sample1.ref +test_pattern='Sample Test' diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample2.pl wine/programs/winetest/samples/sample2.pl --- oldwine/programs/winetest/samples/sample2.pl Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample2.pl Tue Jan 8 22:59:07 2002 @@ -0,0 +1,28 @@ +# +# Test script for the winetest program +# + +use wine; + +$wine::debug = 0; + +################################################################ +# Declarations for functions we use in this script + +wine::declare( "kernel32", + GetCurrentProcessId => "int" +); + +################################################################ +# Test some simple function calls + +# Test string arguments +$pid = GetCurrentProcessId(); +print "pid is *$pid\n"; + +if ($pid == 0) +{ + exit 1 +}; + +exit 0; diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample2.test wine/programs/winetest/samples/sample2.test --- oldwine/programs/winetest/samples/sample2.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample2.test Tue Jan 8 22:54:53 2002 @@ -0,0 +1,16 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample2 +# +# Test Purpose: +# Show how to use the Perl winetest prgoram to invoke a simple +# Windows API and check results +# +#---------------------------------------------------------------------------- +test_perl_script=sample2.pl +#test_invoke=<cmd to invoke> +#test_reference= +#test_pattern= diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/Makefile.in wine/programs/winetest/samples/sample3/Makefile.in --- oldwine/programs/winetest/samples/sample3/Makefile.in Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/Makefile.in Wed Jan 9 10:21:36 2002 @@ -0,0 +1,12 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = sample3 + +C_SRCS = \ + sample3.c + +(a)MAKE_PROG_RULES@ + +### Dependencies: diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/sample3.c wine/programs/winetest/samples/sample3/sample3.c --- oldwine/programs/winetest/samples/sample3/sample3.c Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/sample3.c Wed Jan 9 09:14:36 2002 @@ -0,0 +1,16 @@ +#include <windows.h> + + +void main(void) +{ + HANDLE pid; + + pid = GetCurrentProcessId(); + + printf("pid is 0x%x\n", pid); + + if (pid) + exit(0); + + exit(1); +} diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3/sample3.spec wine/programs/winetest/samples/sample3/sample3.spec --- oldwine/programs/winetest/samples/sample3/sample3.spec Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3/sample3.spec Wed Jan 9 09:15:25 2002 @@ -0,0 +1,16 @@ +name sample3 +type win32 +mode cuiexe +init main + +import advapi32.dll +import comdlg32.dll +import gdi32.dll +import kernel32.dll +import ntdll.dll +import odbc32.dll +import ole32.dll +import oleaut32.dll +import shell32.dll +import user32.dll +import winspool.drv diff --exclude=CVS -rNu oldwine/programs/winetest/samples/sample3.test wine/programs/winetest/samples/sample3.test --- oldwine/programs/winetest/samples/sample3.test Wed Dec 31 18:00:00 1969 +++ wine/programs/winetest/samples/sample3.test Wed Jan 9 10:20:24 2002 @@ -0,0 +1,16 @@ +#!/bin/sh +#---------------------------------------------------------------------------- +# Wine Regression Test Driver File +# +# Name: +# sample3 +# +# Test Purpose: +# Show how to use a C Winelib to invoke a simple +# Windows API and check results +# +#---------------------------------------------------------------------------- +#test_perl_script=<perl script> +test_invoke=sample3/sample3 +#test_reference= +#test_pattern= --- oldwine/Make.rules.in Fri Dec 14 17:14:22 2001 +++ wine/Make.rules.in Wed Jan 9 09:10:16 2002 @@ -58,6 +58,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 +97,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 .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $< @@ -121,6 +123,9 @@ .c.ln: $(LINT) -c $(ALLLINTFLAGS) $< || ( $(RM) $@ && exit 1 ) +.test.test.out: + $(RUNTEST) $(TOPOBJDIR) $< $@ + .PHONY: all install uninstall clean distclean depend dummy # 'all' target first in case the enclosing Makefile didn't define any target @@ -216,7 +221,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:%=%.out) $(PROGRAMS) # Rules for installing @@ -226,6 +231,22 @@ $(SUBDIRS:%=%/__uninstall__): dummy cd `dirname $@` && $(MAKE) uninstall +# Rules for testing + +$(SUBDIRS:%=%/__clean-test__): dummy + @cd `dirname $@` && $(MAKE) clean-test + +$(SUBDIRS:%=%/__test__): dummy + @cd `dirname $@` && $(MAKE) test + +test:: $(SUBDIRS:%=%/__test__) $(WINETEST) $(TESTS:%=%.out) + +clean-test:: $(SUBDIRS:%=%/__clean-test__) + $(RM) $(TESTS:%=%.out) + +$(WINETEST): + cd $(TOPOBJDIR)/programs/winetest && $(MAKE) winetest + # Misc. rules $(SPEC_SRCS:.spec=.spec.c): $(WINEBUILD) --- oldwine/Makefile.in Sun Jan 6 12:38:45 2002 +++ wine/Makefile.in Wed Jan 9 09:10:16 2002 @@ -130,6 +130,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` --- oldwine/configure Mon Jan 7 15:00:27 2002 +++ wine/configure Wed Jan 9 10:20:42 2002 @@ -6250,16 +6250,15 @@ #line 6251 "configure" #include "confdefs.h" #include <stdio.h> -#include <sys/types.h> -main() +int main() { FILE *f=fopen("conftestval", "w"); - if (!f) exit(1); + if (!f) return(1); fprintf(f, "%d\n", sizeof(long long)); - exit(0); + return(0); } EOF -if { (eval echo configure:6263: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:6262: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sizeof_long_long=`cat conftestval` else @@ -6280,12 +6279,12 @@ echo $ac_n "checking whether linux/input.h is for real""... $ac_c" 1>&6 -echo "configure:6284: checking whether linux/input.h is for real" >&5 +echo "configure:6283: checking whether linux/input.h is for real" >&5 if eval "test \"`echo '$''{'wine_cv_linux_input_h'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6289 "configure" +#line 6288 "configure" #include "confdefs.h" #include <linux/input.h> @@ -6298,7 +6297,7 @@ ; return 0; } EOF -if { (eval echo configure:6302: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6301: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_input_h=yes else @@ -6322,12 +6321,12 @@ echo $ac_n "checking whether we can use re-entrant gethostbyname_r Linux style""... $ac_c" 1>&6 -echo "configure:6326: checking whether we can use re-entrant gethostbyname_r Linux style" >&5 +echo "configure:6325: checking whether we can use re-entrant gethostbyname_r Linux style" >&5 if eval "test \"`echo '$''{'wine_cv_linux_gethostbyname_r_6'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6331 "configure" +#line 6330 "configure" #include "confdefs.h" #include <netdb.h> @@ -6348,7 +6347,7 @@ ; return 0; } EOF -if { (eval echo configure:6352: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6351: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_gethostbyname_r_6=yes else @@ -6374,12 +6373,12 @@ if test "$ac_cv_header_linux_joystick_h" = "yes" then echo $ac_n "checking whether linux/joystick.h uses the Linux 2.2+ API""... $ac_c" 1>&6 -echo "configure:6378: checking whether linux/joystick.h uses the Linux 2.2+ API" >&5 +echo "configure:6377: checking whether linux/joystick.h uses the Linux 2.2+ API" >&5 if eval "test \"`echo '$''{'wine_cv_linux_joystick_22_api'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6383 "configure" +#line 6382 "configure" #include "confdefs.h" #include <sys/ioctl.h> @@ -6394,7 +6393,7 @@ /*empty*/ ; return 0; } EOF -if { (eval echo configure:6398: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6397: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_linux_joystick_22_api=yes else @@ -6421,12 +6420,12 @@ if test "$ac_cv_header_sys_vfs_h" = "yes" then echo $ac_n "checking whether sys/vfs.h defines statfs""... $ac_c" 1>&6 -echo "configure:6425: checking whether sys/vfs.h defines statfs" >&5 +echo "configure:6424: checking whether sys/vfs.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_vfs_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6430 "configure" +#line 6429 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6443,7 +6442,7 @@ ; return 0; } EOF -if { (eval echo configure:6447: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6446: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_vfs_has_statfs=yes else @@ -6470,12 +6469,12 @@ if test "$ac_cv_header_sys_statfs_h" = "yes" then echo $ac_n "checking whether sys/statfs.h defines statfs""... $ac_c" 1>&6 -echo "configure:6474: checking whether sys/statfs.h defines statfs" >&5 +echo "configure:6473: checking whether sys/statfs.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_statfs_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6479 "configure" +#line 6478 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6490,7 +6489,7 @@ ; return 0; } EOF -if { (eval echo configure:6494: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6493: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_statfs_has_statfs=yes else @@ -6517,12 +6516,12 @@ if test "$ac_cv_header_sys_mount_h" = "yes" then echo $ac_n "checking whether sys/mount.h defines statfs""... $ac_c" 1>&6 -echo "configure:6521: checking whether sys/mount.h defines statfs" >&5 +echo "configure:6520: checking whether sys/mount.h defines statfs" >&5 if eval "test \"`echo '$''{'wine_cv_sys_mount_has_statfs'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6526 "configure" +#line 6525 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6537,7 +6536,7 @@ ; return 0; } EOF -if { (eval echo configure:6541: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6540: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_sys_mount_has_statfs=yes else @@ -6563,7 +6562,7 @@ echo $ac_n "checking for statfs.f_bfree""... $ac_c" 1>&6 -echo "configure:6567: checking for statfs.f_bfree" >&5 +echo "configure:6566: checking for statfs.f_bfree" >&5 if eval "test \"`echo '$''{'wine_cv_statfs_bfree'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -6572,7 +6571,7 @@ wine_cv_statfs_bfree=no else cat > conftest.$ac_ext <<EOF -#line 6576 "configure" +#line 6575 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6599,7 +6598,7 @@ ; return 0; } EOF -if { (eval echo configure:6603: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6602: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_statfs_bfree=yes else @@ -6623,7 +6622,7 @@ fi echo $ac_n "checking for statfs.f_bavail""... $ac_c" 1>&6 -echo "configure:6627: checking for statfs.f_bavail" >&5 +echo "configure:6626: checking for statfs.f_bavail" >&5 if eval "test \"`echo '$''{'wine_cv_statfs_bavail'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -6632,7 +6631,7 @@ wine_cv_statfs_bavail=no else cat > conftest.$ac_ext <<EOF -#line 6636 "configure" +#line 6635 "configure" #include "confdefs.h" #include <sys/types.h> @@ -6659,7 +6658,7 @@ ; return 0; } EOF -if { (eval echo configure:6663: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6662: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* wine_cv_statfs_bavail=yes else @@ -6684,12 +6683,12 @@ echo $ac_n "checking for msg_accrights in struct msghdr""... $ac_c" 1>&6 -echo "configure:6688: checking for msg_accrights in struct msghdr" >&5 +echo "configure:6687: checking for msg_accrights in struct msghdr" >&5 if eval "test \"`echo '$''{'ac_cv_c_msg_accrights'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6693 "configure" +#line 6692 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6697,7 +6696,7 @@ struct msghdr hdr; hdr.msg_accrights=0 ; return 0; } EOF -if { (eval echo configure:6701: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6700: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_msg_accrights="yes" else @@ -6720,12 +6719,12 @@ echo $ac_n "checking for sa_len in struct sockaddr""... $ac_c" 1>&6 -echo "configure:6724: checking for sa_len in struct sockaddr" >&5 +echo "configure:6723: checking for sa_len in struct sockaddr" >&5 if eval "test \"`echo '$''{'ac_cv_c_sockaddr_sa_len'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6729 "configure" +#line 6728 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6734,7 +6733,7 @@ static struct sockaddr addr; addr.sa_len = 1 ; return 0; } EOF -if { (eval echo configure:6738: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6737: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_sockaddr_sa_len="yes" else @@ -6757,12 +6756,12 @@ echo $ac_n "checking for sun_len in struct sockaddr_un""... $ac_c" 1>&6 -echo "configure:6761: checking for sun_len in struct sockaddr_un" >&5 +echo "configure:6760: checking for sun_len in struct sockaddr_un" >&5 if eval "test \"`echo '$''{'ac_cv_c_sockaddr_sun_len'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6766 "configure" +#line 6765 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/socket.h> @@ -6771,7 +6770,7 @@ static struct sockaddr_un addr; addr.sun_len = 1 ; return 0; } EOF -if { (eval echo configure:6775: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:6774: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_c_sockaddr_sun_len="yes" else @@ -6794,12 +6793,12 @@ echo $ac_n "checking whether we need to define __i386__""... $ac_c" 1>&6 -echo "configure:6798: checking whether we need to define __i386__" >&5 +echo "configure:6797: checking whether we need to define __i386__" >&5 if eval "test \"`echo '$''{'ac_cv_cpp_def_i386'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <<EOF -#line 6803 "configure" +#line 6802 "configure" #include "confdefs.h" #if (defined(i386) || defined(__i386)) && !defined(__i386__) yes @@ -7075,6 +7074,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile @@ -7338,6 +7339,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile --- oldwine/configure.in Mon Jan 7 15:00:27 2002 +++ wine/configure.in Wed Jan 9 10:20:39 2002 @@ -1328,6 +1328,8 @@ programs/wineconsole/Makefile programs/winemine/Makefile programs/winetest/Makefile +programs/winetest/samples/Makefile +programs/winetest/samples/sample3/Makefile programs/winhelp/Makefile programs/winver/Makefile relay32/Makefile --- oldwine/dlls/Makedll.rules.in Mon Sep 17 15:09:08 2001 +++ wine/dlls/Makedll.rules.in Wed Jan 9 09:10:16 2002 @@ -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

Jan. 9, 2002

Simple C testing framework

by Andriy Palamarchuk

Alexandre, attached is very simple framework which suits your testing model. On any failure the framework prints an error message and exits with error code 1. The framework features: * ok function - fails if condition is FALSE * conditional TODO sections - ok functions fail in TODO section if its condition is TRUE and TODO condition is TRUE. * get_w32_impl function which returns implementation of Win32 api the test is running on. In our case these are W32_MS, W32_WINE. Is used for conditional TODO Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

Re: Immediate IO in ReadFile / WriteFile

by Martin Wilck

Hi Mike, > Another day, another problem. :-) Indeed :-/ > You can't unconditionally use overlapped operations... OK, forget it. But we agree that to read() unconditionally is also The Wrong Thing (tm)? > I don't think WaitForMultipleObjectsEx(0,NULL,FALSE,0,TRUE) then read, > is the right way... My idea was rather WaitForSingleObject (overlapped->hEvent, 0). Why can't that work? AFAICS, - the thread enters the wait state. - If data is available, the server will signal that. * If our request is first in the queue, it will read the data and return STATUS_SUCCESS (as your braindead app expects). It's hEvent will be activated, and we will leave the wait state with SUCCESS. * Otherwise, another async request will get activated, and we will receive a WAIT_TIMEOUT. After that we go pending (what else could we do?) - If no data is available, we'll also receive a timeout, and go pending as well. Again, there seems to be no other option. > I think the best solution is to let the server decide. Basically this approach means we *do* let the server decide, or am I missing something ? The only problematic case I can think of is: - a 1kB read request pending, - >2kB data arrive, - another 1kB read request. In principle there would be enough data for the second read to complete with SUCCESS, but I am not sure my approach guarantees it, nor how Windows handles it. Compatibiliy has its limits here, since on Windows the requests run truly asynchronously, in Wine they don't. > Some (braindead) programs check that there is data is ready to read, then > do an overlapped read, but expect it *not* to go overlapped. How do you check if data is ready in Windows? I didn't find a select() equivalent, nor is it possible to wait on file handles. >switch(GetLastError()) > { > case STATUS_SUCCESS: > ovp->func(ovp); > break; In what case would register_async return STATUS_SUCCESS ? > There's a minefield of special cases... but the essence is that the > wine server instructs the client to do one of the following things: > > * perform the action (read/write/etc) > * return from the call with success > * return from the call with ERROR_PENDING > * wait for an event flag (ie. not return yet) What is the difference between case 1 and 2 ? Case 4 is excluded for overlapped operations. They are supposed to return "immediately" in any case. Waiting with timeout 0 seems to be justified IMO, but all else would be against the specs. Wrt the minefield, a *really* braindead app could also schedule some overlapped requests followed by a non-overlapped one (at least in winsock that's possible, for file IO I think it's forbidden). I have no idea how windows behaves in that case. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

Re: lpOverlapped = NULL

by Mike McCormack

Hi Martin, Sure, feel free to change it. I used the lpOverlapped to identify the async operation, but any pointer will do. The only reason for not using async_private* was to have some way to verify that the pointer was valid... Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Mike, > >I should have been aware of this before :-/ > >As mentioned in my other mail, >** Winsock allows NULL pointers for lpOverlapped. ** > >AFAICS, Mike, your server-side code uses the overlapped field >only for identifying a certain request. This will obviously >break if the overlapped field may be NULL. > >Question: Would it hurt to use the async_private pointer of a >request rather than the overlapped pointer to pass to the >server? If no, I guess that would be the way to go, because >the async_private structs are allocated by us and therefore necessarily >different and non-NULL. > >Wrt to the status and "bytes read", I already have a pretty elegant >solution which keeps the overlapped struct outside the generic code >(scheduler and server). > >Please comment, >Martin ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Jan. 9, 2002

Re: Immediate IO in ReadFile / WriteFile

by Mike McCormack

Hey Martin, Another day, another problem. :-) You can't unconditionally use overlapped operations... the code used to do that exactly, and it caused all sorts of breakages. eg. some (braindead) programs check that there is data is ready to read, then do an overlapped read, but expect it *not* to go overlapped. I don't think WaitForMultipleObjectsEx(0,NULL,FALSE,0,TRUE) then read, is the right way... I think the best solution is to let the server decide. Something like this: BOOL ReadFile_overlapped () { ovp = new async_private; while(1) { ovp->func = FILE_AsyncReadService; wine_server_call(register_async); switch(GetLastError()) { case STATUS_SUCCESS: ovp->func(ovp); break; case STATUS_PENDING: return FALSE; case STATUS_TIMEOUT: goto finish_it; default: delete ovp; return FALSE; } if(count >= bytes_to_read) break; } finish_it: delete ovp; *bytes_read = count; } This is the kind of structure i was trying to describe to you in a previous private mail... i was trying to address a different problem but it should address the one you mention too. In fact, WaitCommEvent also needs to work in this way. (Somebody on wine-users has a program that needs that behaviour now.) There's a minefield of special cases... but the essence is that the wine server instructs the client to do one of the following things: * perform the action (read/write/etc) * return from the call with success * return from the call with ERROR_PENDING * wait for an event flag (ie. not return yet) Does that make sense to you? Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi Mike, > >I just had the following thought on the immediate IO in ReadFile() / >WriteFile() that you implemented: > >Consider the following situation: > >1. There is no data available for reading on some fd (serial port, pipe, > socket). >2. An application calls ReadFile() in overlapped mode. > since no data is there, an overlapped request is scheduled. >3. Data becomes available before the app issues a wait request of any > kind. >4. The application starts another ReadFile() request. > Now data is there, and will be read immediately. > No async request is scheduled. >5. Eventually, more data will become available, and the async request > first scheduled will also return. > >However, this basically destroys the order of the requests. >I am unsure how Windows would behave in such a case, and it is certainly >difficult to provide a test case for this situation. It can occur, though, >and my guess is this is the wrong behaviour. > >Thus, probably before doing the immediate read it should be checked >if there are asynchronous requests already scheduled for reading, >and if yes, ReadFile() should _not_ try to read immediately but go >pending. Of course, this check would require a server call. > >The same reasoning applies for writing, of course. > >Things become even more confusing if you think of several threads >reading from the same file. > >A very simple workaround would be to go pending unconditonally for >overlapped requests. Although not optimal, this would be certain >not to corrupt data. > >What do you think? > >Martin ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Jan. 9, 2002

lpOverlapped = NULL

by Martin Wilck

Mike, I should have been aware of this before :-/ As mentioned in my other mail, ** Winsock allows NULL pointers for lpOverlapped. ** AFAICS, Mike, your server-side code uses the overlapped field only for identifying a certain request. This will obviously break if the overlapped field may be NULL. Question: Would it hurt to use the async_private pointer of a request rather than the overlapped pointer to pass to the server? If no, I guess that would be the way to go, because the async_private structs are allocated by us and therefore necessarily different and non-NULL. Wrt to the status and "bytes read", I already have a pretty elegant solution which keeps the overlapped struct outside the generic code (scheduler and server). Please comment, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

Re: struct async_private needs generalization for Winsock

by Martin Wilck

On 7 Jan 2002, Alexandre Julliard wrote: > But in our case Wine would be considered the service provider, so we > can use the structure. It seems you should be able to use the existing > code by providing a different async_handler function, and storing the > needed information in the WSAOVERLAPPED structure. That would be > cleaner than having the low-level file I/O routines know about winsock > structures. I have overseen something: In Winsock routines it is allowed to pass a NULL LPWSAOVERLAPPED pointer, if a completion routine is specified (they may even both be NULL, then the operation is carried out synchronously). Thus the overlapped field obviously cannot be used by Wine for internal purposes, unless you want to allocate one if the user hasn't done so (but that would mean allocating a lot of useless memory space and causing confusion). I am not certain if the fact that Mike's server code identifies requests by their OVERLAPPED pointers may cause trouble with NULL OVERLAPPED pointers. I guess not, though, because for activating requests the first NULL pointer request will be scheduled, and the Winsock2 Specs state that "There is no way to cancel indiviual overlapped operations pending on a given socket". Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

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

by Andriy Palamarchuk

Alexandre Julliard wrote: > I don't really care about the output. My point is that this output is > not necessary, a simple "assertion foo failed at line xx" on failure > and no output at all on success would work just as well. I've nothing > against such an output either, but I don't think it justifies > introducing the complexity of reusing the Test stuff. I already created small library with api like in Test::Simple - functions ok, TODO, SKIP. The implementation can be easy changed to the behaviour you described. I also suggest for library to fail on successful TODO test. TODO tests will be conditional - they are TODO only under Wine, not on Windows. Careful usage SKIP sections can easy cover differences between Windows platforms, using TODO - between different non-Microsoft Win32 implementations. On other hand, SKIP sections were important for Test::Harness, which needed to control number of tests. For your goals conditional execution of the tests is sufficient. Which approaches can you suggest to reach goals I believe are important: 1) bundling - are we going to have separate distributions - Wine with tests, tests only, Wine only? There are a lot of cases where only one of them is required. 2) development of the unit tests under Windows. Obviously, we don't need to have Wine itself when we work with unit tests on Windows. Plus, we need to create development environment, usable by Windows developers. 3) Organization of the unit tests in such way, so they can be used by other Win32 implementation projects. Conditional TODOs I suggested above will help to manage different TODO lists for different projects. 4) besides narrow-scope regression testing you suggested we need to run all the tests from time to time, even if it takes more than 1 hour to run the whole suite. The reasons for this are: a) we need to run the tests on all Windows platforms to make sure the tests correctly document their behaviour b) Wine should be reguraly tested by the whole testing suite. Some regressions will be caught in unit tests of the modules other than changed. In other cases changed module may not have tests at all, but will brake modules, dependent on it. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

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

by Andriy Palamarchuk

--- Gerard Patel <gerard.patel(a)nerim.net> wrote: > At 04:44 PM 08/01/2002 -0500, you wrote: > > <snip> > >(Another Pythoner, cool :) ) > > This has given me an idea - while I don't expect it > to be > used in Wine, I will try to write my own test progs > with it : use the *windows* python interpreter under > Wine. > From the doc, it's possible to call any win32 api > from > it using a 'calldll' interface. If it works well, I > won't need > a 'test framework' - just use the standard, > available tool. Could you, please, port my or Alexandre's Perl samples to Python, so we'll be able to easy compare them? It will be interesting to see differences. There is no big difference between Perl and Python for this application. IMHO they have the same problems: a) you have no C compiler support. We need to define manually constants, types of parameters, returning values, sizes of structures, etc. Even with C I saw on this list discussions about correct sizes of the structures, leave alone scripting languages. b) developer skills. C the most familiar language to those who knows/learns Win32. About my backround - I know Perl pretty well, know and like Python too. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 9, 2002

Re: Immediate IO in ReadFile / WriteFile

by Martin Wilck

What about the following idea: Instead of doing an explicit immediate IO operation in e.g. ReadFile(), que an asynchronous request by calling ReadFileEx() as if no data were available. Then issue a WaitForSingleObject (overlapped->hEvent, 0) /* zero timeout ! */ to see if the request can be handled immediately. Apart from preserving request order, this would also ensure that previous async requests are actually scheduled. Opinions? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

Immediate IO in ReadFile / WriteFile

by Martin Wilck

Hi Mike, I just had the following thought on the immediate IO in ReadFile() / WriteFile() that you implemented: Consider the following situation: 1. There is no data available for reading on some fd (serial port, pipe, socket). 2. An application calls ReadFile() in overlapped mode. since no data is there, an overlapped request is scheduled. 3. Data becomes available before the app issues a wait request of any kind. 4. The application starts another ReadFile() request. Now data is there, and will be read immediately. No async request is scheduled. 5. Eventually, more data will become available, and the async request first scheduled will also return. However, this basically destroys the order of the requests. I am unsure how Windows would behave in such a case, and it is certainly difficult to provide a test case for this situation. It can occur, though, and my guess is this is the wrong behaviour. Thus, probably before doing the immediate read it should be checked if there are asynchronous requests already scheduled for reading, and if yes, ReadFile() should _not_ try to read immediately but go pending. Of course, this check would require a server call. The same reasoning applies for writing, of course. Things become even more confusing if you think of several threads reading from the same file. A very simple workaround would be to go pending unconditonally for overlapped requests. Although not optimal, this would be certain not to corrupt data. What do you think? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

Re: wine/ files/file.c server/file.c

by Martin Wilck

On 8 Jan 2002, Alexandre Julliard wrote: > > If you wish, I can strip the patch down to its essential part > > (have separate flags for overlapped and timeout flags). > > That would be better yes. Also I think they should be really separate: > the type should be an enum and the flags should be in a separate > variable. This is impossible without major effort, because we are talking about the return value of the get_file_info() methods of struct object. We'd have to change the prototype of get_file_info to take an additional (flags) argument. Honestly, because we use at most 5 bits of that return value currently, splitting that into 2 variables seems a bit too much cleanliness to me. As long as there are clean macros to set and test the different fields, it should be ok to have type & flags in a single variable. It would be possible to represent the return value of get_file_info with a bit field, but that wouldn't make things more beautiful to my taste. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Jan. 9, 2002

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

by Dimitrie O. Paun

On Wed, 9 Jan 2002, Francois Gouget wrote: > That's true on Unix because sh, perl, and C executables will just > work. But if some of your tests are sh scripts you will have trouble > running them on Windows. Yes, but nobody really proposes writing tests in Bourne-shell. In fact, you can't easily do it wether you run under Unix or Windows. What I was saying is that the execution engine should not really matter, generally speaking. In practice, there are only 3 choices: 1. Native executable (most likely C based) 2. Perl script 3. Python script In all this cases we can package things such that the *exact* same tests run under both Wine & Windows. In all this cases, it is possible to make it trivial for the tester to run the tests, without them knowing what language has been used to write the actual tests. > We probably won't often need to run all the tests in Windows, but I > can imagine that it would still be necessary to check behavior on > different setups: in 16bpp vs. 32bpp, in the english vs. the russian vs. > chinese version, with IE 5 installed or not installed, etc. So we need a > framework that makes it easy to run all the tests on Windows. Since sh > scripts tend to invoke a ton of Unix tools like expr, awk, sed, perl, > this seems not to be a good basis for writing tests. Again, you will not be able to easily invoke Win32 APIs from sh anyway, so this is not really an option. -- Dimi.

Jan. 9, 2002

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

by Francois Gouget

On Tue, 8 Jan 2002, Dimitrie O. Paun wrote: [...] > Now, from the POV of Wine, we don't care (just like the kernel), if the > executable is a native binary or a #! executable. Everything else are a > few Makefile rules, which are conditional on the given > compiler/interpreter being available (which can be checked quite easily by > configure). That's true on Unix because sh, perl, and C executables will just work. But if some of your tests are sh scripts you will have trouble running them on Windows. We probably won't often need to run all the tests in Windows, but I can imagine that it would still be necessary to check behavior on different setups: in 16bpp vs. 32bpp, in the english vs. the russian vs. chinese version, with IE 5 installed or not installed, etc. So we need a framework that makes it easy to run all the tests on Windows. Since sh scripts tend to invoke a ton of Unix tools like expr, awk, sed, perl, this seems not to be a good basis for writing tests. But I agree with the approach: a test is an executable that returns 0 if successfull and non-zero if not. It's pretty much the foundation of my proposal except that all tests should either be of the same type: perl or C (or whatever). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Jan. 9, 2002

Re: Listview ctrl

by Dimitrie O. Paun

On Tue, 8 Jan 2002, Alexandre Julliard wrote: > The W->A case is not a strdup, it's a simple WideCharToMultiByte. > > Probably at least 90% of the existing calls to HEAP_strdupWtoA are > because of a W function calling a A function, which is precisely what > should be discouraged. Good point. I'm convinced. But since we are on the subject, why did you prefer the use of the WideToXXX function instead of the RtlCreateUnicode...Asciiz? -- Dimi.

Jan. 9, 2002