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? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
----- Original Message ----- From: "Francois Gouget" <fgouget(a)free.fr> To: "Dimitrie O. Paun" <dpaun(a)rogers.com> Cc: "Wine Devel" <wine-devel(a)winehq.com> 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: 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.
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...
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. -- Dimi.
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
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" <tony_lambregts(a)telusplanet.net> To: <dpaun(a)rogers.com> Cc: "Wine devel" <wine-devel(a)winehq.com> 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
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. -- Dimi.
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). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
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... -- Dimi.
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. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.
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? :) -- Dimi.
Francois Gouget <fgouget(a)free.fr> 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 -- Alexandre Julliard julliard(a)winehq.com
"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+
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. -- Dimi.
"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
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. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> 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. -- Alexandre Julliard julliard(a)winehq.com
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 \ -- Dimi.
participants (6)
-
Alexandre Julliard -
Dimitrie O. Paun -
Dustin Navea -
Eric Pouech -
Francois Gouget -
Tony Lambregts