Make a 16-bit test in wine for krnl386.exe16

[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

[André Hentschel]

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)

[Bruno Jesus]

On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel  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.

[Austin English]

On Sun, Nov 29, 2015 at 8:46 PM, Bruno Jesus  wrote:
> On Mon, Nov 30, 2015 at 2:09 AM, André Hentschel  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?

[Nikolay Sivov]

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.

[Bruno Jesus]

On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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.

[Alexandre Julliard]

Bruno Jesus  writes:
> On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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.

[Michael Stefaniuc]

On 11/30/2015 03:47 AM, Bruno Jesus wrote:
> On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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

[Austin English]

On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc  wrote:
> On 11/30/2015 03:47 AM, Bruno Jesus wrote:
> > On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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/

[Bruno Jesus]

On Tue, Dec 1, 2015 at 1:17 AM, Austin English  wrote:
> On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc  wrote:
> > On 11/30/2015 03:47 AM, Bruno Jesus wrote:
> > > On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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)

[Nikolay Sivov]

On 30.11.2015 21:03, Bruno Jesus wrote:
> On Tue, Dec 1, 2015 at 1:17 AM, Austin English  wrote:
> > On Mon, Nov 30, 2015 at 2:52 AM, Michael Stefaniuc  wrote:
> > > On 11/30/2015 03:47 AM, Bruno Jesus wrote:
> > > > On Mon, Nov 30, 2015 at 2:13 AM, Nikolay Sivov  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.

[Bruno Jesus]

On Tue, Dec 1, 2015 at 2:17 AM, Nikolay Sivov  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.