Btw,
in the code in ReadFile() / WriteFile() handling consoles,
shouldn't there be a
close (unix_handle)
statement before calling ReadConsoleA() / WriteConsoleA() ?
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Hi Martin,
Sorry, i should have been a little more clear: if there is a
overlapped console, the code in ReadFile (ie. the implemention) will
ignore the fact that it is a console, and treat it as a standard
overlapped file. In other words, ReadFile should check if the fd is a
console fd first, then check if it has the overlapped flag.
What you're trying to do is good, and my complaint is just a quibble
since the console code doesn't support overlapped operations now
anyway :-]
Mike
Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com>
>
>On Fri, 4 Jan 2002, Mike McCormack wrote:
>
>> looks good to me. The only complication i can see is if overlapped
>> operations are possible on consoles.
>
>Yes, but the OVERLAPPED flag must be set explicitly by the
get_file_info()
>method of the corresponding server object.
>console_get_file_info() will simply leave this flag unset if
overlapped
>operations are impossible on consoles.
>
>The idea is that get_file_info() has a more flexible way to
communicate
>the capabilities of a file descriptor; this doesn't imply all fields
are
>completely independent of each other.
>
>Martin
------------------------------------------
mailto:[email protected]
ph +82 16 430 0425
__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au
Hi Martin,
looks good to me. The only complication i can see is if overlapped
operations are possible on consoles.
Mike
Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com>
>
>
>The FD_TYPE_XXX macros are used in the ReadFile() and WriteFile()
>routines to invoke special read/write procedures for file descriptors
of
>certain types. I feel that for future improvements of Wine IO, it
>might be important to distinguish between FD type (regular file,
serial
>port, pipe, ...) and FD attributes (can do overlapped IO, uses
timeout,
>....).
>
>That is the rationale for the following small patch.
>Please comment.
>
>Martin
------------------------------------------
mailto:[email protected]
ph +82 16 430 0425
__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au
I sent this message before but I dont think it reached the list.
I am trying to make the debugger work on Solaris.
The wineserver and debugger currently co-operate using ptrace to debug a
client app, but on solaris the debugger deadlocks. It was previously thought
that this was due to the threading model on Solaris which is different.
(Different threads don't have different pids). The ptrace manual says that
a client must call ptrace(PTRACE_TRACEME...) before it can be debugged but
grepping the Wine source can find no useful references to TRACEME.
Without calling ptrace (TRACEME,...) Solaris returns ESRCH even though the
process exists which causes the wineserver to assume the process is defunct
and delete the app, apparently causing the deadlock (This deadlock will have
to be fixed too !).
Can anyone enlighten me as to what gotchas there are in fixing this since I
don't know much about Linux behaviour (Though the linux ptrace mentions
PTRACE_TRACEME too but apparently doesn't enforce it !)
Bob
On Thu, Jan 03, 2002 at 04:55:03PM -0500, Robert Baruch wrote:
> On Thursday 03 January 2002 07:54 am, Andriy Palamarchuk wrote:
> The value is when you add new functionality (and possibly new tests) and old
> tests break. Then you can pinpoint the changes that caused the old tests to
> break. Again, that can only work if all the old tests succeeded, which means
> you can't include tests that you know will fail in a release.
No, you can !
This is exactly what everybody seems to assume we don't need:
tests that are *known* to fail.
(like Ulrich Weigand said: have status variables like FAIL, XFAIL, GOOD, XGOOD)
The key to success is to check the *difference* to *expected* behaviour.
And if there is indeed a *difference*, then we know that something changed
and we need to examine it more closely and thus derive our ultimate result codes
from it.
Again, we can't just include tests that work on all occasions.
Instead we should have tests that are as thorough/strict as possible,
and thus with all sorts of failures, but which ultimately don't let the
test suite fail, since they're *expected* to currently fail.
--
Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Sylvain Petreolle wrote:
> Running test1.pl returns to me :
>
> [syl@snoop winetest]$ cd /c/winetest
> [syl@snoop winetest]$ perl test1.pl
> Can't locate wine.pm in @INC (@INC contains:
> /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
> /usr/lib/perl5/site_perl/5.6.0/i386-linux
> /usr/lib/perl5/site_perl/5.6.0
> /usr/lib/perl5/site_perl .) at test1.pl line 8.
> BEGIN failed--compilation aborted at test1.pl line
> 8.---
Sorry, I was not specific enough about the scripts
launching instructions.
It looks like you try to start the script from
directory, which does not have wine.pm module. You
need to put contents of the archive to directory
"programs/winetest" of the wine source tree, build
winetest application, then it will work. This
directory should have wine.pm.
Because of the problems I reported in the message (see
below) the scripts require different launching. You
can start the scripts as:
# this script uses winetest framework
winetest test1.pl
#these don't
perl test2.pl
perl test_all.pl
[...]
>>However I found a few issues with winetest:
>>1) For some reason running test_all.pl with winetest
>>gives compilation error. I saw the same compilation
>>error when I tried to use other Perl testing
>>framework
>>Test::Unit.
>>2) Compilation failure when I try to run test1.pl
>>directly with Perl, like "perl test1.pl"
Let me know if you still can't start the scripts.
Andriy Palamarchuk
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
Alexandre Julliard wrote:
> Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes:
>>Please comment on both my intended posting and the
way I programmed the first
>>version of the test suite (I'm not extremely happy
with the current program;
>>if you have any improvements, then get them here
ASAP !).
>
> Look at programs/winetest, that's the tool we should
use to write
> tests IMO.
Just looked at the tool. It only provides gateway from
Perl to wine API functions, right?
Advantages I see in using script-based tests:
1) tests can be used without recompilation
2) Perl is familiar to many developers
3) programming in scripting language is usually easier
than in C
4) Perl is widely used for testing purposes and I
expect to find many testing tools in Perl.
Cons:
1) Many current Wine contributors don't know Perl
2) one more level of abstraction does not give
significant advantages in this application. On the
contrary, it is more difficult to locate cause of
problems because developer has to go trough one more,
often not familiar layer. Absense of strict typing in
this layer will hurt a lot.
Advantages of using C-based tests:
1) compilation has to be used to run the tests. In
some cases this is an advantage. Before running the
tests you'd better be sure it at least compiles in
both environments.
2) C is the most familiar to developers language and
the language itself is simpler than Perl
3) Documentation for Win32 API is C-oriented.
Examples, given in documentation are in C or easy
translated to C
4) Developers already have some testing code snippets
in C
Summary:
Requirements to the unit testing tool:
1) should help to quickly create tests
2) easy to use, should help to involve as many
developers as possible.
3) may be useful for developers, using Wine for there
projects
Because of the goals I'm more inclined to use C-based
test suite. IMHO it is better suited for existing Wine
developers audience and will provide us much bigger
code pool. I'm even ready to have tests in both - Perl
and C.
The big question is a tool to test GUI. I did not find
any OS Windows GUI testing frameworks :-(
Comments, suggestions?
Thanks,
Andriy Palamarchuk
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
More stepping through the code, comparing Windbg to gdb, and I found
another landmine. Shrinker gets the address of the NTDLL procedure
LdrAccessResource, and looks for this code:
FF74XXXX push [esp+X]
E8XXXXXXXX call ....
Instead, it finds an unimplemented procedure in Wine. So now I will look
at LdrAccessResource (and friends) to see what's involved in implementing
it, whatever it is.
--Rob
Hi,
I've just experimentally, in my own copy of the CVS, changed the code in
misc/cdrom.c so that it handles mixed mode CDs the same as data CDs for
retrieving CD labels. (In the process of trying to get Age of Empires 1 to
run in single-player mode).
And surprisingly, it worked! (mind you AOE is not fast under wine, but that's
another problem).
Does anyone have any comments on this approach? if not I'll submit a patch...
regards
Chris Green
