Janitorial Projects

[Dimitrie O. Paun]

Folks,

I have updated the Janitorial section:
  http://www.dssd.ca/wine/Wine-Fun.html#janitorial

with the list of cross calls from 32->16, and W->A.

There are currently 13 cross calls from 32->16 bit code,
and 194 cross calls from Unicode to ASCII.

Any takers? :)

[Francois Gouget]

Here's a proposed addition to the Janitorial projects:

Fix the conformance tests wo that they pass on Windows!!!

Rationale: Running just the kernel tests on NT4 I could not help bu
notice that:
 * drive crashed and then was would not run unattended and then had many
failures
 * environ crashed and then had many failures
 * file has one failure
 * path has 133 failures!
 * process has 4 failures

Testing on Windows 98 also yielded a crash for environ, followed with 20
failures, followed with failures for pretty much every Unicode test out
there.

So according to our tests Windows 98 and NT4 do not conform to the
Windows behavior!

In other words many of our tests are plain incorrect. I strongly suspect
they were written and tested with Wine and never run on Windows
(actually when I tried compiling them some time ago most of them would
not even compile).

Now we have a way to pretty easily compile them on Windows. Here's the
procedure:

* get the Wine source
 * run ./tools/winapi/msvcmaker --no-wine
   (it's a perl script so you might even be able to do it on Windows)
 * make those source accessible by a Windows machine (e.g. export them
via Samba)
 * load winetest.dsw in Visual C++
 * hit that build button

What we need next:
 1. a way to run all tests. A batch file would do the job nicely.
Patrik, can that be added to msvcmaker?
 2. people to fix the tests so that they actually pass on *all* Windows
platforms
 3. volunteers who will run the tests their Windows platform of choice
on a regular basis so that we quickly fix incorrect tests

The people doing 2 could definitely use the help of a couple of people
doing 3 since they will probably not have access to all Windows
platforms.

Once the initial fixing is done we will really need people doing 3 to
prevent bad tests from comming back.

[Dustin Navea]

----- Original Message -----
From: "Francois Gouget" 
To: "Dimitrie O. Paun" 
Cc: "Wine Devel" 
Sent: Friday, November 29, 2002 2:06 PM
Subject: Re: Janitorial Projects
> Here's a proposed addition to the Janitorial projects:
>
> Fix the conformance tests wo that they pass on Windows!!!
>
> Rationale: Running just the kernel tests on NT4 I could not help bu
> notice that:
> - drive crashed and then was would not run unattended and then had many
>
> failures
> - environ crashed and then had many failures
> - file has one failure
> - path has 133 failures!
> - process has 4 failures
>
> Testing on Windows 98 also yielded a crash for environ, followed with 20
> failures, followed with failures for pretty much every Unicode test out
> there.
>
> So according to our tests Windows 98 and NT4 do not conform to the
> Windows behavior!
>
> In other words many of our tests are plain incorrect. I strongly suspect
> they were written and tested with Wine and never run on Windows
> (actually when I tried compiling them some time ago most of them would
> not even compile).
>
> Now we have a way to pretty easily compile them on Windows. Here's the
> procedure:
> - get the Wine source
> - run ./tools/winapi/msvcmaker --no-wine
> (it's a perl script so you might even be able to do it on Windows)
> - make those source accessible by a Windows machine (e.g. export them
>
> via Samba)
> - load winetest.dsw in Visual C++
> - hit that build button
>
> What we need next:
> - a way to run all tests. A batch file would do the job nicely.
>
> Patrik, can that be added to msvcmaker?
>  2. people to fix the tests so that they actually pass on *all* Windows
> platforms
>  3. volunteers who will run the tests their Windows platform of choice
> on a regular basis so that we quickly fix incorrect tests
>
> The people doing 2 could definitely use the help of a couple of people
> doing 3 since they will probably not have access to all Windows
> platforms.
>
> Once the initial fixing is done we will really need people doing 3 to
> prevent bad tests from comming back.

Are we going to divide this up by Major (Win98/NT4/2k) or Major and Minor
(SP1, SR1, SE, etc)?

I can volunteer for Win2k (SP3 if Major and Minor)

-Dustin

P.S. If needed I could probably find some free space or an old drive to
install Win98 Regular on and run some tests...

[Dimitrie O. Paun]

On November 29, 2002 03:06 pm, Francois Gouget wrote:
> Here's a proposed addition to the Janitorial projects:

Added:
  http://www.dssd.ca/wine/Wine-Fun.html#tests

Let me know if you want anything changed.

[Tony Lambregts]

Dimitrie O. Paun wrote:
> On November 29, 2002 03:06 pm, Francois Gouget wrote:
> > Here's a proposed addition to the Janitorial projects:
>
> Added:
>  http://www.dssd.ca/wine/Wine-Fun.html#tests
>
> Let me know if you want anything changed.

Well since I have Windows 98 on my computer I would like to volunteer to 
run the tests. I however do not have Visual C++ (or any other windows 
compiler). That leads me to the following question. Would someone place 
the compiled tests somewhere on the web so that I can download them.

I suppose that another solution would be to use MinGW (right?) If this 
is a Good Idea (tm) then some tips on how to do this (or a pointer to 
some relevant documentation) would be appreciated.

[Dustin Navea]

Sorry if this hits the list twice im not sure if i typed wine-devel into the
to line or not ;)

That is a good question, either that or i will need borrow a copy of msvc
from a friend..

-Dustin
----- Original Message -----
From: "Tony Lambregts" 
To: 
Cc: "Wine devel" 
Sent: Saturday, November 30, 2002 1:09 PM
Subject: Re: Janitorial Projects
> Dimitrie O. Paun wrote:
> > On November 29, 2002 03:06 pm, Francois Gouget wrote:
> > > Here's a proposed addition to the Janitorial projects:
> >
> > Added:
> >  http://www.dssd.ca/wine/Wine-Fun.html#tests
> >
> > Let me know if you want anything changed.
>
> Well since I have Windows 98 on my computer I would like to volunteer to
> run the tests. I however do not have Visual C++ (or any other windows
> compiler). That leads me to the following question. Would someone place
> the compiled tests somewhere on the web so that I can download them.
>
> I suppose that another solution would be to use MinGW (right?) If this
> is a Good Idea (tm) then some tips on how to do this (or a pointer to
> some relevant documentation) would be appreciated.
>
> --
>
> Tony Lambregts

[Dimitrie O. Paun]

On November 29, 2002 03:06 pm, Francois Gouget wrote:
> Now we have a way to pretty easily compile them on Windows. Here's the
> procedure:
> - get the Wine source
> - run ./tools/winapi/msvcmaker --no-wine
> (it's a perl script so you might even be able to do it on Windows)
> - make those source accessible by a Windows machine (e.g. export them
>
> via Samba)
> - load winetest.dsw in Visual C++
> - hit that build button

This is too complicated. First, it requires Visual C++, which sucks. 
We should be able to compile the tests with MinGW, as any OSS project
out there. So I would say the TODO for building the tests is as follows:
  * make sure we can compile them with MinGW
  * arrange such that we can generate _one_ executable for all tests
  * create script that builds them say, every few (3-5) days, tests
    if the executable changed (by comparing MD5 sums) from the last
    build, and if so, put it up for download on a site, and email
    the test volunteers a notification (containing the URL) that
    the tests have changed, and they should retest. The URL should
    be fixed (e.g. http://www.corp.com/wine/wine-tests.exe), so the
    tester can bookmark it, write scripts against it, etc.
  * enlist a volunteer to run said script on a regular basis.

As it stands, the tests have to do way too much work for this to have
a snowball's chance in hell of working long term. Don't forget that the
testers need to worry of a different box, etc. which is already enough
work. The rest can be automated, as I just described.

[Francois Gouget]

On Sun, 1 Dec 2002, Dimitrie O. Paun wrote:
[...]
> This is too complicated. First, it requires Visual C++, which sucks.

I think that being able to compile the tests with Visual C++ is very
important. There are a lot of professional Windows programmers out there
who have Visual C++ and who would be very qualified for writing tests
and who may not want to install MinGW on their Windows machine.  So it's
important to make it as easy as possible for them to write tests in the
environment they are most confortable with, i.e. Visual C++.
> We should be able to compile the tests with MinGW, as any OSS project
> out there. So I would say the TODO for building the tests is as follows:
> - make sure we can compile them with MinGW

That said I agree that the tests should also be compilable with MinGW
because OSS projects should strive to be self-sufficient.
> - arrange such that we can generate _one_ executable for all tests

I think this is not necessary. All we need is a batch file to invoke all
the tests and Patrik has already supplied that part.
> - create script that builds them say, every few (3-5) days, tests
> if the executable changed (by comparing MD5 sums) from the last
> build, and if so, put it up for download on a site, and email
> the test volunteers a notification (containing the URL) that
> the tests have changed, and they should retest. The URL should
> be fixed (e.g. http://www.corp.com/wine/wine-tests.exe), so the
> tester can bookmark it, write scripts against it, etc.

All that's needed now is the packaging of the batch file plus the test
executables. Then we may start on the automation aspects but it may not
be very easy unless we can cross-compile the tests, i.e. generate
Windows executables from Linux (which I believe should be possible).

[Dimitrie O. Paun]

On December 2, 2002 01:54 pm, Francois Gouget wrote:
> On Sun, 1 Dec 2002, Dimitrie O. Paun wrote:
> > - make sure we can compile them with MinGW
>
> That said I agree that the tests should also be compilable with MinGW
> because OSS projects should strive to be self-sufficient.

I've never argued _not_ supporting Visual C++. All I am saying is that
it's (more) important to have a build system based on MinGW. And this
not only based on self-sufficiency -- there are many people out there
that don't have MSVC++. Like myself for example :), and I have to admit,
I don't plan on installing it anytime soon...

So yeah, the msvcmaker is great, but we need a mingwmaker as well :)))
> > - arrange such that we can generate _one_ executable for all tests
>
> I think this is not necessary. All we need is a batch file to invoke all
> the tests and Patrik has already supplied that part.

It's not necessary, but it would be nice. A bunch of tests with a batch
file have to be packaged in a .zip, downloaded, unzipped, figure out what
to run, etc. If we could instead provide _one_ executable, testing on
Windows would be a simple click on a webpage, and I guess a lot of people
can, and are willing to do that.

Again, I take myself as an example: I simply loath to have to figure out
where to unzip something, pollute my dirs, etc. I just wouldn't do it.
You may say I'm lazy, and I'd agree with you, but that's how I operate.
On the other hand, if it would be a simple click thingy, I would find it
fun to do it from time to time, just for shits and giggles.
> > - create script that builds them say, every few (3-5) days, tests
> > if the executable changed (by comparing MD5 sums) from the last
> > build, and if so, put it up for download on a site, and email
> > the test volunteers a notification (containing the URL) that
> > the tests have changed, and they should retest. The URL should
> > be fixed (e.g. http://www.corp.com/wine/wine-tests.exe), so the
> > tester can bookmark it, write scripts against it, etc.
>
> All that's needed now is the packaging of the batch file plus the test
> executables. Then we may start on the automation aspects but it may not
> be very easy unless we can cross-compile the tests, i.e. generate
> Windows executables from Linux (which I believe should be possible).

Why is that? If we can get the MinGW stuff working, I'm sure will find
someone on the list willing to compile them from time to time...

[Francois Gouget]

On Mon, 2 Dec 2002, Dimitrie O. Paun wrote:
[...]
> > > - arrange such that we can generate _one_ executable for all tests
> >
> > I think this is not necessary. All we need is a batch file to invoke all
> > the tests and Patrik has already supplied that part.
>
> It's not necessary, but it would be nice. A bunch of tests with a batch
> file have to be packaged in a .zip, downloaded, unzipped, figure out what
> to run, etc. If we could instead provide _one_ executable, testing on
> Windows would be a simple click on a webpage, and I guess a lot of people
> can, and are willing to do that.
>
> Again, I take myself as an example: I simply loath to have to figure out
> where to unzip something, pollute my dirs, etc.

You should be able to unzip the tests anywhere. Sure that means you will
have a lot of choice and may have to make hard decisions<g>.

Besides, I'm not sure one can compile all the tests in just one
executable or that it would be wise. There would be quite a high risk of
naming conflicts between the tests, and that executable would have to
link with tons of libraries for instance.

[Dimitrie O. Paun]

On December 2, 2002 03:38 pm, Francois Gouget wrote:
> You should be able to unzip the tests anywhere. Sure that means you will
> have a lot of choice and may have to make hard decisions<g>.

:P No, it's that I have to unzip them anywhere that bothers me <g>
> Besides, I'm not sure one can compile all the tests in just one
> executable or that it would be wise. There would be quite a high risk of
> naming conflicts between the tests, and that executable would have to
> link with tons of libraries for instance.

Indeed. I still think would be nice to have a shell exe (sort of like
the one provided by JUnit), that contains the little exes, extracts
them in a temp dir one by one, runs them, and displays a nice progress
bar, and a list with the messages.

Essentially the main window should be a dialog that contains:
  -- a progress bar at the top that tracks the number of executed tests
  -- a listview in LVS_REPORT mode below, that displays the messages
  -- a "Cancel" button (that changes to "Close" when tests are done)
  -- a "Report..." button that brings up the "Save As..." dialog

Not hard to write, and quite cool to play with. Maybe I should add
it to the Fun Projects page. ;) Any takers? :)

[Alexandre Julliard]

Francois Gouget  writes:
> All that's needed now is the packaging of the batch file plus the test
> executables. Then we may start on the automation aspects but it may not
> be very easy unless we can cross-compile the tests, i.e. generate
> Windows executables from Linux (which I believe should be possible).

Not only possible, it's already implemented:

apt-get install mingw32
./configure
make crosstest

[Eric Pouech]

"Dimitrie O. Paun" a écrit :
> Folks,
>
> I have updated the Janitorial section:
>   http://www.dssd.ca/wine/Wine-Fun.html#janitorial

on the wine only header side, some headers listed as wine only are in
fact part of the DDK
IMO, we should list them as such
A+

[Dimitrie O. Paun]

On December 6, 2002 12:33 pm, Eric Pouech wrote:
> on the wine only header side, some headers listed as wine only are in
> fact part of the DDK
> IMO, we should list them as such

I don't have a SDK/DDK to check against, I've just generated the list
as the headers we do _not_ install. Help with this would be greatly
appreciated.

[Eric Pouech]

"Dimitrie O. Paun" a écrit :
> On December 6, 2002 12:33 pm, Eric Pouech wrote:
> > on the wine only header side, some headers listed as wine only are in
> > fact part of the DDK
> > IMO, we should list them as such
>
> I don't have a SDK/DDK to check against, I've just generated the list
> as the headers we do _not_ install. Help with this would be greatly
> appreciated.

those are (at least) the one I know
      d3dhal.h 		3D direct draw driver interface
      ddrawi.h          direct draw driver interface
      dsdriver.h 	direct sound driver interface
      mmddk.h 		winmm driver interface
      netspi.h		network provider interface
      ntddcdrm.h 	kernel cd rom ioctls
      ntddscsi.h 	kernel scsi ioctls
      ntddstor.h 	kernel mass storage ioctls

this one has been deprecated on NT (but is still valid on 9x)
      toolhelp.h

[Dimitrie O. Paun]

On December 6, 2002 01:11 pm, Eric Pouech wrote:
> those are (at least) the one I know
>       d3dhal.h          3D direct draw driver interface
>       ddrawi.h          direct draw driver interface
>       dsdriver.h        direct sound driver interface
>       mmddk.h           winmm driver interface
>       netspi.h          network provider interface
>       ntddcdrm.h        kernel cd rom ioctls
>       ntddscsi.h        kernel scsi ioctls
>       ntddstor.h        kernel mass storage ioctls
>
> this one has been deprecated on NT (but is still valid on 9x)
>       toolhelp.h

Thanks! Alexandre, shouldn't we install these as well?
If so, I can submit a patch, and take them off the list.

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> Thanks! Alexandre, shouldn't we install these as well?

Yes, the DDK ones should be installed I think. toolhelp.h probably
not, it's a 16-bit thing that Winelib apps are not supposed to use.

[Dimitrie O. Paun]

On December 6, 2002 01:40 pm, Alexandre Julliard wrote:
> Yes, the DDK ones should be installed I think. toolhelp.h probably
> not, it's a 16-bit thing that Winelib apps are not supposed to use.

OK, here it is:

ChangeLog
  Install DDK headers as well.

Index: include/Makefile.in
===================================================================
RCS file: /var/cvs/wine/include/Makefile.in,v
retrieving revision 1.68
diff -u -r1.68 Makefile.in
--- include/Makefile.in	3 Dec 2002 23:36:05 -0000	1.68
+++ include/Makefile.in	6 Dec 2002 18:38:37 -0000
@@ -23,11 +23,13 @@
    d3d8caps.h \
    d3d8types.h \
    d3dcaps.h \
+	d3dhal.h \
    d3dtypes.h \
    d3dvec.inl \
    dde.h \
    ddeml.h \
    ddraw.h \
+	ddrawi.h \
    digitalv.h \
    dinput.h \
    dispdib.h \
@@ -38,6 +40,7 @@
    docobj.h \
    dplay.h \
    dplobby.h \
+	dsdriver.h \
    dshow.h \
    dsound.h \
    fci.h \
@@ -65,6 +68,7 @@
    mediaerr.h \
    mediaobj.h \
    minmax.h \
+	mmddk.h \
    mmreg.h \
    mmsystem.h \
    msacm.h \
@@ -72,7 +76,11 @@
    mssip.h \
    mswsock.h \
    nb30.h \
+	netspi.h \
    nspapi.h \
+	ntddcdrm.h \
+	ntddscsi.h \
+	ntddstor.h \
    ntsecapi.h \
    ntstatus.h \
    oaidl.h \