3 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html This report included a small test case.
It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html
and I used the patched Wine-20030508 to run MSVC, OpenWatcom C, and Borland C in a command line.
Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but GetExitCodeProcess() still always returns 1.
Igor Sysoev http://sysoev.ru/en/
Igor Sysoev wrote:
3 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html This report included a small test case.
It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html
and I used the patched Wine-20030508 to run MSVC, OpenWatcom C, and Borland C in a command line.
Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but GetExitCodeProcess() still always returns 1.
If you turn your test case into a Wine regression test, and add it to dlls/kernel/tests/process.c, then it won't be broken on Linux, and therefore there's a better chance it won't break on FreeBSD.
It's also up to FreeBSD users to make sure Wine doesn't break on FreeBSD by making the test cases pass and testing them regularly to find regressions.
Mike
On Thu, 23 Mar 2006, Mike McCormack wrote:
Igor Sysoev wrote:
3 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html This report included a small test case.
It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html
and I used the patched Wine-20030508 to run MSVC, OpenWatcom C, and Borland C in a command line.
Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but GetExitCodeProcess() still always returns 1.
If you turn your test case into a Wine regression test, and add it to dlls/kernel/tests/process.c, then it won't be broken on Linux, and therefore there's a better chance it won't break on FreeBSD.
It's also up to FreeBSD users to make sure Wine doesn't break on FreeBSD by making the test cases pass and testing them regularly to find regressions.
It seems that dlls/kernel/tests/process.c already has such test: test_ExitCode(). Does it run while usual build ?
Igor Sysoev http://sysoev.ru/en/
Igor Sysoev wrote:
It seems that dlls/kernel/tests/process.c already has such test: test_ExitCode(). Does it run while usual build ?
Yes, it is run after commits, so it's likely that it's only broken on FreeBSD.
Mike
On Thu, 23 Mar 2006, Mike McCormack wrote:
Igor Sysoev wrote:
It seems that dlls/kernel/tests/process.c already has such test: test_ExitCode(). Does it run while usual build ?
Yes, it is run after commits, so it's likely that it's only broken on FreeBSD.
Well, but then I could not build Wine port under FreeBSD: as I understand the port runs something like ./configure && make depend && make && make install
But I have built and installed Wine successfully.
Igor Sysoev http://sysoev.ru/en/
Igor Sysoev wrote:
Well, but then I could not build Wine port under FreeBSD: as I understand the port runs something like ./configure && make depend && make && make install
But I have built and installed Wine successfully.
Sorry, misunderstood you. The tests don't run on every build, you have to run them explicitly.
Try running "make test", or "cd dlls/kernel; make test"
Mike
On Thu, 23 Mar 2006, Mike McCormack wrote:
Igor Sysoev wrote:
Well, but then I could not build Wine port under FreeBSD: as I understand the port runs something like ./configure && make depend && make && make install
But I have built and installed Wine successfully.
Sorry, misunderstood you. The tests don't run on every build, you have to run them explicitly.
Try running "make test", or "cd dlls/kernel; make test"
Should Wine be already installed before run these tests ? I've tried:
make test ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok Warning: the specified Windows directory L"c:\windows" is not accessible. Warning: the specified System directory L"c:\windows\system32" is not accessible. Warning: could not find DOS drive for current working directory '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting in the Windows directory. wine: could not load L"c:\windows\system32\kernel32_test.exe.so": Module not found *** Error code 126
Igor Sysoev http://sysoev.ru/en/
Igor Sysoev wrote:
Should Wine be already installed before run these tests ? I've tried:
make test ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok Warning: the specified Windows directory L"c:\windows" is not accessible. Warning: the specified System directory L"c:\windows\system32" is not accessible. Warning: could not find DOS drive for current working directory '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting in the Windows directory. wine: could not load L"c:\windows\system32\kernel32_test.exe.so": Module not found *** Error code 126
No, it should work without Wine installed, and without a ~/.wine Perhaps try running wine/tools/wineprefixcreate first?
Mike
bash-3.00$ rm -rf ~/.wine bash-3.00$ cd dlls/kernel bash-3.00$ make test make[1]: Entering directory `/home/mike/wine/dlls/kernel/tests' ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok wine: creating configuration directory '/home/mike/.wine'... wine: '/home/mike/.wine' created successfully. ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so atom.c && touch atom.ok ...
On Thu, 23 Mar 2006, Mike McCormack wrote:
Igor Sysoev wrote:
Should Wine be already installed before run these tests ? I've tried:
make test ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok Warning: the specified Windows directory L"c:\windows" is not accessible. Warning: the specified System directory L"c:\windows\system32" is not accessible. Warning: could not find DOS drive for current working directory '/usr/ports/emulators/wine/work/wine-0.9.10/dlls/kernel/tests', starting in the Windows directory. wine: could not load L"c:\windows\system32\kernel32_test.exe.so": Module not found *** Error code 126
No, it should work without Wine installed, and without a ~/.wine Perhaps try running wine/tools/wineprefixcreate first?
bash-3.00$ rm -rf ~/.wine bash-3.00$ cd dlls/kernel bash-3.00$ make test make[1]: Entering directory `/home/mike/wine/dlls/kernel/tests' ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so alloc.c && touch alloc.ok wine: creating configuration directory '/home/mike/.wine'... wine: '/home/mike/.wine' created successfully. ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so atom.c && touch atom.ok ...
It seems the tests try to use my old .wine for Wine-20030508. I have renamed it and now I can run tests. Here are some failed tests (I run make -i test to ignore failures):
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so change.c && touch change.ok fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 change.c:287: Test failed: should be ready change.c:290: Test failed: should be ready change.c:302: Test failed: should be ready change.c:305: Test failed: should be ready fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1
[ Here Wine-0.9.10 hangs and I have killed the process ]
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so file.c && touch file.ok file.c:246: Test failed: shouldn't be able to delete a readonly file file.c:248: Test failed: couldn't change attributes on file file.c:250: Test failed: now it should be possible to delete the file! file.c:1271: Test failed: mapping should fail file.c:1275: Test failed: mapping should fail file.c:1281: Test failed: DeleteFile failed after map file.c:1288: Test failed: open testfile.xxx failed file.c:1290: Test failed: expected type disk got 0 *** Error code 8 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so mailslot.c && touch mailslot.ok mailslot.c:195: Test failed: dwNext incorrect mailslot.c:206: Test failed: dwNext incorrect mailslot.c:218: Test failed: dwNext incorrect mailslot.c:238: Test failed: dwNext incorrect mailslot.c:255: Test succeeded inside todo block: dwMsgCount incorrect mailslot.c:260: Test succeeded inside todo block: 3rd slot read failed *** Error code 6 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so pipe.c && touch pipe.ok pipe.c:134: Test succeeded inside todo block: peek3 got 21 bytes pipe.c:146: Test succeeded inside todo block: pipe content 3b check pipe.c:166: Test succeeded inside todo block: peek4 got 21 bytes pipe.c:178: Test succeeded inside todo block: pipe content 4b check pipe.c:138: Test failed: peek3 got 21 bytes pipe.c:170: Test failed: peek4 got 21 bytes pipe.c:215: Test failed: peek5 got 21 bytes pipe.c:246: Test failed: peek6 got 21 bytes *** Error code 8 (ignored) ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so process.c && touch process.ok err:wineconsole:WCUSER_SetFont wrong font process.c:1246: Test failed: ExitCode:value expected 1, but got 123 *** Error code 1 (ignored)
The last message is strange: process.c:1246: Test failed: ExitCode:value expected 1, but got 123
The child should return 123 and this value should be expected.
Igor Sysoev http://sysoev.ru/en/
Igor Sysoev wrote:
It seems the tests try to use my old .wine for Wine-20030508. I have renamed it and now I can run tests. Here are some failed tests (I run make -i test to ignore failures):
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so change.c && touch change.ok fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 change.c:287: Test failed: should be ready
<snip lots of failed tests>
Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the test suite where there's things that are hard to fix?
Mike
On Thu, 23 Mar 2006, Mike McCormack wrote:
Igor Sysoev wrote:
It seems the tests try to use my old .wine for Wine-20030508. I have renamed it and now I can run tests. Here are some failed tests (I run make -i test to ignore failures):
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.e xe.so change.c && touch change.ok fixme:file:NtNotifyChangeDirectoryFile parameters ignored 0x0 0x0 1 change.c:287: Test failed: should be ready
<snip lots of failed tests>
Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the test suite where there's things that are hard to fix?
It seems that I am the first person who ever run the Wine regression tests on FreeBSD :) Actually the test results did not bother me too much. The wrong exit code simply means that I could not use the "make" under Wine on FreeBSD: "make" stops after the first command.
Igor Sysoev http://sysoev.ru/en/
Hi Igor,
"Igor Sysoev" is@rambler-co.ru wrote:
Maybe Alexandre would accept patches to add a todo_wine_freebsd {} to the test suite where there's things that are hard to fix?
having todo_wine_xxx for each platform 'xxx' where a test is failing sounds not very elegant.
It seems that I am the first person who ever run the Wine regression tests on FreeBSD :) Actually the test results did not bother me too much. The wrong exit code simply means that I could not use the "make" under Wine on FreeBSD: "make" stops after the first command.
Actually failing tests on FreeBSD is a worrisome sign. That means that some applications may fail without an apparent reason. It's really worth a further investigation for every failing test in the Wine test suite.
Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it. If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed...
Tom
Igor Sysoev wrote:
file.c:246: Test failed: shouldn't be able to delete a readonly file
On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it. If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed...
Well the test passes on Win 2000.
C:>kernel32_crosstest.exe file file: 494243 test executed, 0 marked as todo, 0 failures.
Huw.
I'm at a windows XP machine right now.
I have no trouble deleting read-only files - I get the dialog informing me it's read-only, but then it allows me to delete it.
Is it the same on 95/98?
--Murph
On 3/23/06, Huw D M Davies h.davies1@physics.ox.ac.uk wrote:
On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it. If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed...
Well the test passes on Win 2000.
C:>kernel32_crosstest.exe file file: 494243 test executed, 0 marked as todo, 0 failures.
Huw.
Huw Davies huw@codeweavers.com
On Thu, Mar 23, 2006 at 01:24:53PM -0500, Matt Finnicum wrote:
I'm at a windows XP machine right now.
I have no trouble deleting read-only files - I get the dialog informing me it's read-only, but then it allows me to delete it.
Is it the same on 95/98?
How are you trying to delete them? The question is whether the DeleteFile() function works as tested - the way to find this is to run that test on Windows XP.
Huw.
Huw D M Davies wrote:
How are you trying to delete them? The question is whether the DeleteFile() function works as tested - the way to find this is to run that test on Windows XP.
DeleteFile on an read-only file under XP returns false. GetLastError returns 5 (Access denied)
On Thu, Mar 23, 2006 at 01:59:12PM -0500, Bryan Mayland wrote:
Huw D M Davies wrote:
How are you trying to delete them? The question is whether the DeleteFile() function works as tested - the way to find this is to run that test on Windows XP.
DeleteFile on an read-only file under XP returns false. GetLastError returns 5 (Access denied)
Right, which is what we're testing for (well ok we don't test GetLastError).
Huw.
Huw D M Davies wrote:
On Thu, Mar 23, 2006 at 01:24:53PM -0500, Matt Finnicum wrote:
I'm at a windows XP machine right now.
I have no trouble deleting read-only files - I get the dialog informing me it's read-only, but then it allows me to delete it.
Is it the same on 95/98?
How are you trying to delete them? The question is whether the DeleteFile() function works as tested - the way to find this is to run that test on Windows XP.
Huw.
I usually do Shift+Delete (skip the recycle bin), but delete will work to move a readonly file to the recycle bin as well...
Tom
Huw D M Davies wrote:
On Thu, Mar 23, 2006 at 06:04:21AM -0600, Tom Spear (Dustin Booker, Dustin Navea) wrote:
Umm.. I'm not totally sure this is 100% in conformance with windows. When I try to delete a readonly file, I get a dialog telling me that it is readonly, and asking me if I really want to delete it. If we are completely disallowing removal of a readonly file (by windows standard, not linux' standard), then it is incorrect and should be fixed...
Well the test passes on Win 2000.
C:>kernel32_crosstest.exe file file: 494243 test executed, 0 marked as todo, 0 failures.
Huw.
Hmm.. I'm thinking that the test isn't doing it right then... Cause windows will let you delete a readonly file, but it prompts you first
Tom
Tom Spear (Dustin Booker, Dustin Navea) wrote:
Hmm.. I'm thinking that the test isn't doing it right then... Cause windows will let you delete a readonly file, but it prompts you first
Deleting using the UI isn't the same as a program using DeleteFile().
Mike
Mike McCormack wrote:
Tom Spear (Dustin Booker, Dustin Navea) wrote:
Hmm.. I'm thinking that the test isn't doing it right then... Cause windows will let you delete a readonly file, but it prompts you first
Deleting using the UI isn't the same as a program using DeleteFile().
Mike
Crap, you are right.. doing del in the command prompt returns access denied.... ok the test is right....
On Thu, 23 Mar 2006, Igor Sysoev wrote:
3 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html This report included a small test case.
It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html
and I used the patched Wine-20030508 to run MSVC, OpenWatcom C, and Borland C in a command line.
Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but GetExitCodeProcess() still always returns 1.
The attached patch is the same patch but for Wine-0.9.10. I've tested it on FreeBSD 6.1.
Igor Sysoev http://sysoev.ru/en/
"Igor Sysoev" is@rambler-co.ru wrote:
The attached patch is the same patch but for Wine-0.9.10. I've tested it on FreeBSD 6.1.
Please send it to wine-patches. If it's not included within next week or so I'd suggest to ask Alexandre directly what are his preferences in fixing this problem.
-
Bryan Mayland -
Dmitry Timoshkov -
Huw D M Davies -
Igor Sysoev -
Matt Finnicum -
Mike McCormack -
Tom Spear (Dustin Booker, Dustin Navea)