Make a 16-bit test in wine for krnl386.exe16
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16. Is there any way to make a test that compiles and runs against krnl386 instead of kernel32? I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet). Any help is appreciated, thanks in advance, Bruno
Am 29.11.2015 um 18:30 schrieb Bruno Jesus:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
Any help is appreciated, thanks in advance, Bruno
Hi Bruno, winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code)
On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 29.11.2015 um 18:30 schrieb Bruno Jesus:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
Hi Bruno,
winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code)
Hi, I'm compiling a standard wine test so gcc is being used and it does not recognize -m16. I then tried to change the Makefile compiler to winegcc and I get: winegcc -c -o profile.o ../../../../wine/dlls/krnl386.exe16/tests/profile.c -I. \ -I../../../../wine/dlls/krnl386.exe16/tests -I../../../include -I../../../../wine/include \ -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement \ -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter \ -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -g -O0 -m16 -nodefaultlibs gcc: error: unrecognized command line option ‘-m16’ So in the end winegcc is calling gcc.
On Sun, Nov 29, 2015 at 8:46 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote:
On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 29.11.2015 um 18:30 schrieb Bruno Jesus:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
Hi Bruno,
winegcc links to kernel32 by default, try adding -m16 or -nodefaultlibs somewhere (see winegcc code)
Hi, I'm compiling a standard wine test so gcc is being used and it does not recognize -m16. I then tried to change the Makefile compiler to winegcc and I get:
winegcc -c -o profile.o ../../../../wine/dlls/krnl386.exe16/tests/profile.c -I. \ -I../../../../wine/dlls/krnl386.exe16/tests -I../../../include -I../../../../wine/include \ -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement \ -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter \ -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf \ -fno-omit-frame-pointer -g -O0 -m16 -nodefaultlibs gcc: error: unrecognized command line option ‘-m16’
So in the end winegcc is calling gcc.
What about -nodefaultlibs? -- -Austin
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
Any help is appreciated, thanks in advance, Bruno
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
So basically it is not possible to integrate such tests in wine as a standard test like any other.
Bruno Jesus <00cpxxx(a)gmail.com> writes:
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
So basically it is not possible to integrate such tests in wine as a standard test like any other.
Right, that's not supported. -- Alexandre Julliard julliard(a)winehq.org
On 11/30/2015 03:47 AM, Bruno Jesus wrote:
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
So basically it is not possible to integrate such tests in wine as a standard test like any other. Afair Dan Kegel worked on that back in the days. Might be still available somewhere on the net. The easiest would be to take that and make it a separate project aka keep it out of tree. Providing a prebuilt winetest16.exe would make it easy for people to test without having to go through the pain of setting the build environment up.
bye michael
On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
On 11/30/2015 03:47 AM, Bruno Jesus wrote:
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
So basically it is not possible to integrate such tests in wine as a standard test like any other. Afair Dan Kegel worked on that back in the days. Might be still available somewhere on the net. The easiest would be to take that and make it a separate project aka keep it out of tree. Providing a prebuilt winetest16.exe would make it easy for people to test without having to go through the pain of setting the build environment up.
bye michael
It's at https://code.google.com/archive/p/win16test/downloads The initial problem IIRC was OpenWatcom's license, which isn't acceptable to Debian/Fedora/et al: https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License Dan speculated that AJ wouldn't add a patch that used OpenWatcom since it's not packaged in the major distributions, but AFAIK he never actually asked :). Perhaps an optional build of win16 tests if it's installed would be acceptable. I've also exported a copy to my Github account: https://github.com/austin987/win16test/ -- -Austin
On Tue, Dec 1, 2015 at 1:17 AM, Austin English <austinenglish(a)gmail.com> wrote:
On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
On 11/30/2015 03:47 AM, Bruno Jesus wrote:
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4.
So basically it is not possible to integrate such tests in wine as a standard test like any other. Afair Dan Kegel worked on that back in the days. Might be still available somewhere on the net. The easiest would be to take that and make it a separate project aka keep it out of tree. Providing a prebuilt winetest16.exe would make it easy for people to test without having to go through the pain of setting the build environment up.
bye michael
It's at https://code.google.com/archive/p/win16test/downloads
The initial problem IIRC was OpenWatcom's license, which isn't acceptable to Debian/Fedora/et al: https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License
Dan speculated that AJ wouldn't add a patch that used OpenWatcom since it's not packaged in the major distributions, but AFAIK he never actually asked :). Perhaps an optional build of win16 tests if it's installed would be acceptable.
I've also exported a copy to my Github account: https://github.com/austin987/win16test/
Thanks for all answers, I installed OpenWatcom and was able to produce the test I need and it works in Windows and not in Wine so the problem was confirmed by tests (bug https://bugs.winehq.org/show_bug.cgi?id=9919). I had a small problem tough, in the compiled version of the program printf works in wine but does not in Windows (no, not a buffering problem, fflush does not help). In Windows not a single line is printed to the console, maybe that is correct, I don't know so I changed to output a text file instead. I tried compiling the win16 tests but there were too many compilation errors, I'm probably doing something wrong. I'll be back to that in some days. The question that remains, how to submit a patch that was tested with an external (not wine test suite) program? (test attached)
On 30.11.2015 21:03, Bruno Jesus wrote:
On Tue, Dec 1, 2015 at 1:17 AM, Austin English <austinenglish(a)gmail.com> wrote:
On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
On 11/30/2015 03:47 AM, Bruno Jesus wrote:
On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 29.11.2015 20:30, Bruno Jesus wrote:
Hi all, I'm trying to create tests for GetPrivateProfileString16 but it is not working as expected because the test is calling the kernel32 version of the function instead of the krnl386.exe16.
Is there any way to make a test that compiles and runs against krnl386 instead of kernel32?
I tried a few different things and the attached patch is the last attempt (the tests are wrong but that is not the point yet).
I think the main problem is to actually be able to build NE binaries, for that you'll need tools that support this, for example openwatcom C compiler, or some old enough Visual C++, maybe version 5 or 4. So basically it is not possible to integrate such tests in wine as a standard test like any other. Afair Dan Kegel worked on that back in the days. Might be still available somewhere on the net. The easiest would be to take that and make it a separate project aka keep it out of tree. Providing a prebuilt winetest16.exe would make it easy for people to test without having to go through the pain of setting the build environment up.
bye michael It's at https://code.google.com/archive/p/win16test/downloads
The initial problem IIRC was OpenWatcom's license, which isn't acceptable to Debian/Fedora/et al: https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B_compiler#License
Dan speculated that AJ wouldn't add a patch that used OpenWatcom since it's not packaged in the major distributions, but AFAIK he never actually asked :). Perhaps an optional build of win16 tests if it's installed would be acceptable.
I've also exported a copy to my Github account: https://github.com/austin987/win16test/ Thanks for all answers, I installed OpenWatcom and was able to produce the test I need and it works in Windows and not in Wine so the problem was confirmed by tests (bug https://bugs.winehq.org/show_bug.cgi?id=9919).
I had a small problem tough, in the compiled version of the program printf works in wine but does not in Windows (no, not a buffering problem, fflush does not help). In Windows not a single line is printed to the console, maybe that is correct, I don't know so I changed to output a text file instead. Even if it's not possible for some reason, you can always make it write to a file directly.
I tried compiling the win16 tests but there were too many compilation errors, I'm probably doing something wrong. I'll be back to that in some days.
The question that remains, how to submit a patch that was tested with an external (not wine test suite) program? (test attached) Currently the only way is to submit without it, and mention it in a mail. Hopefully in the future tests could be kept in similar separate repository, and built regularly.
On Tue, Dec 1, 2015 at 2:17 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote:
On 30.11.2015 21:03, Bruno Jesus wrote:
I had a small problem tough, in the compiled version of the program printf works in wine but does not in Windows (no, not a buffering problem, fflush does not help). In Windows not a single line is printed to the console, maybe that is correct, I don't know so I changed to output a text file instead.
Even if it's not possible for some reason, you can always make it write to a file directly.
Yes, that is what the test is doing by using fprintf to output.txt.
The question that remains, how to submit a patch that was tested with an external (not wine test suite) program? (test attached)
Currently the only way is to submit without it, and mention it in a mail. Hopefully in the future tests could be kept in similar separate repository, and built regularly.
I attached a zip file to the bug containing the test source, compiled 16-bit exe and outputs before and after the test. The output is only loosely based in wine test suite.
participants (7)
-
Alexandre Julliard -
André Hentschel -
Austin English -
Bruno Jesus -
Michael Stefaniuc -
Nikolay Sivov -
Nikolay Sivov