Dmitry Timoshkov dmitry@baikal.ru writes:
The tests clearly show that this commit is wrong. If there is an application or a test case which fails because of this, it would be helpful to at least mention it.
It fixes the test for .bss protection, in ntdll:info.c.
Alexandre Julliard julliard@winehq.org wrote:
The tests clearly show that this commit is wrong. If there is an application or a test case which fails because of this, it would be helpful to at least mention it.
It fixes the test for .bss protection, in ntdll:info.c.
I don't see that test failing before that commit or after the revert.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
The tests clearly show that this commit is wrong. If there is an application or a test case which fails because of this, it would be helpful to at least mention it.
It fixes the test for .bss protection, in ntdll:info.c.
I don't see that test failing before that commit or after the revert.
It fails with PE binaries but not Unix ones.
Alexandre Julliard julliard@winehq.org wrote:
The tests clearly show that this commit is wrong. If there is an application or a test case which fails because of this, it would be helpful to at least mention it.
It fixes the test for .bss protection, in ntdll:info.c.
I don't see that test failing before that commit or after the revert.
It fails with PE binaries but not Unix ones.
So the test doesn't really exist? Why do you think that a failure you see is a loader thing and not something that happens at run-time? Please add a real test and I'll have a look.
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
The tests clearly show that this commit is wrong. If there is an application or a test case which fails because of this, it would be helpful to at least mention it.
It fixes the test for .bss protection, in ntdll:info.c.
I don't see that test failing before that commit or after the revert.
It fails with PE binaries but not Unix ones.
So the test doesn't really exist? Why do you think that a failure you see is a loader thing and not something that happens at run-time? Please add a real test and I'll have a look.
The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest:
$ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4
Alexandre Julliard julliard@winehq.org wrote:
The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest:
$ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4
The test above this one accepts both PAGE_READWRITE and PAGE_WRITECOPY (why?), shouldn't the failing test accept both values for consistency then?
Dmitry Timoshkov dmitry@baikal.ru writes:
Alexandre Julliard julliard@winehq.org wrote:
The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest:
$ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4
The test above this one accepts both PAGE_READWRITE and PAGE_WRITECOPY (why?), shouldn't the failing test accept both values for consistency then?
Not unless you can show that it's necessary for the test to succeed on Windows.
On Thu, 17 Nov 2011, Alexandre Julliard wrote:
The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest:
$ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4
IIRC, some of tests already craft minimal PE binaries in manual way. So it would be nice to have some tool inside the tree to generate PEs independetly, no?
Several years ago I've tried testing GetStdHandle() from within two PE binaries with different header flags set (IMAGE_SUBSYSTEM_WINDOWS_[GC]UI).
For a start I have copied some code of manual PE crafting to build PE header. Then there came .text section's order. I realized it's sufficient to write small assembler file, run it through the gas crosscompiler, disasm it and parse the results to have _not only_ binary data for rebuilding PE, but also symbolic one.
I wrote some awk-script then to convert .S file into C-function this way. With it it was easy to adjust options for crosscompiling gas/ld tools to get PE with needed structure.
But maybe there is point in creating some universal in-tree tool? Or integrate the functionality into winegcc (or else) so as not to depend on a crosscompiling suite but still have readable and easy changeable source.
Guys, what do you think?
S.
Am 17.11.2011 18:49, schrieb Saulius Krasuckas:
On Thu, 17 Nov 2011, Alexandre Julliard wrote:
The test requires a PE binary because obviously we can't test PE protections on Unix binaries. That doesn't mean it doesn't exist. Just build a crosstest:
$ wine ntdll_crosstest.exe info.c info.c:1296: Test failed: mbi.Protect is 0x8, expected 0x4
IIRC, some of tests already craft minimal PE binaries in manual way. So it would be nice to have some tool inside the tree to generate PEs independetly, no?
Several years ago I've tried testing GetStdHandle() from within two PE binaries with different header flags set (IMAGE_SUBSYSTEM_WINDOWS_[GC]UI).
For a start I have copied some code of manual PE crafting to build PE header. Then there came .text section's order. I realized it's sufficient to write small assembler file, run it through the gas crosscompiler, disasm it and parse the results to have _not only_ binary data for rebuilding PE, but also symbolic one.
I wrote some awk-script then to convert .S file into C-function this way. With it it was easy to adjust options for crosscompiling gas/ld tools to get PE with needed structure.
But maybe there is point in creating some universal in-tree tool? Or integrate the functionality into winegcc (or else) so as not to depend on a crosscompiling suite but still have readable and easy changeable source.
Guys, what do you think?
I would love to see such a tool, i could use it for some actctx tests in ntdll (Bug 18889)
-
Alexandre Julliard -
André Hentschel -
Dmitry Timoshkov -
Saulius Krasuckas