Hello,
I would like to thank everyone who has re-plied so far about the current wine status. I have a pre-1 hacked together and request any feed back that you can give. My main goal is the info I put up be as accurate as possiable . And since i'm not a Developer I have to bug/spam you guy's for the info :) So please bear with me ..........
Known ToDo's will be next on my list after ** WE ** get this up to date..
Tom
Wine status changes from 9-29-01 untill 9-01-02 pre-1 reply to : twickline2@triad.rr.com
( Aspect or Component )
Wine's fundamental architecture Documentation = workers = Alexandre Julliard % = 85%
Process/Address Space model Documentation = workers = Alexandre Julliard % = 100%
Threading model Documentation = workers = Alexandre Julliard % = 100%
Scheduling and synchronization Documentation = workers = Alexandre Julliard % = 100%
Supervisory process (wineserver) Documentation = workers = Alexandre Julliard % = 90%
Windows binary loader Documentation = workers = Alexandre Julliard % = 100%
Memory management Documentation = workers = Alexandre Julliard % = 90%
Wine DLL infrastructure Documentation = workers = Alexandre Julliard % = 95%
Need to ADD --- DLL separation Documentation = workers = AJ % = 75%
Message passing/queues Documentation = workers = Alexandre Julliard % = 95%
Window management Documentation = workers = ? % = 95%
Disk drive emulation Documentation = workers = ? % = 100%
CD-ROM emulation Documentation = workers = Eric Pouech eric.pouech@wanadoo.fr % 90%
Native DLL overrides Documentation = workers = ? % = 95%
X11 display/window driver Documentation = workers = ? % = 90%
X11 font mapper Documentation = workers = ? % = 70%
Registry handling Documentation = workers = ? % = 90%
Clipboard handling Documentation = workers = ? % = 90%
File I/O Documentation = workers = Mike McCormack % = 100%
TrueType support Documentation = workers = Huw D M Davies % = 80%
National Language Support (NLS) Documentation = Dmitry Timoshkov, Alexandre Julliard workers = % = 90%
Unicode support Documentation = workers = Dmitry Timoshkov, Alexandre Julliard % = 80%
Dynamic Data Exchange (DDE) Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 80%
Standard Windows Controls Documentation = workers = ? % = 95%
Serial/parallel ports 16-bit 95% 32-bit 90% Documentation = workers = Mike McCormack
I/O port access Documentation = workers = ? % = 100%
VxDs Documentation = workers = ? % = 5%
General printer setup Documentation = workers = Huw D M Davies % = 70%
Internal PostScript printer driver Documentation = workers = Huw D M Davies, Ian Pilcher % = 60%
Native Windows printer drivers 16-bit 50% 32-bit 0% Documentation = workers = ?
Win32 Console Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 75%
DOS application support Documentation = workers = Ove Kåven, Alexandre Julliard % = 60%
CPU emulation Documentation = workers = ? % = 5%
Multi-user support Documentation = workers = ? % = 20%
( DLLs )
crtdll&msvcrt: Standard C runtime library Documentation = workers = CodeWeavers % = 60%
comctl32: Common Controls Documentation = workers = CodeWeavers % = 95%
Note-- Is Macadamian still working on Wine ???
comdlg32: Common Dialogs Documentation = workers = ? % = 75%
riched32: Rich Text Control Documentation = workers = ? % = 20%
shell32: Shell interface Documentation = workers = CodeWeavers % = 80%
tapi32: Telephony API (TAPI) Documentation = workers = ? % = 0%
rasapi32: Dial-Up Networking (DUN) and Remote Access Service (RAS) Documentation = workers = ? % = 0%
wsock32: Windows Sockets (WinSock) 1.1 Documentation = workers = Macadamian ???????? % = 90%
ws2_32: WinSock 2 Documentation = workers = Macadamian ???????? % = 20%
wininet: Internet application protocols Documentation = workers = CodeWeavers % = 50%
winmm: Multimedia architecture Documentation = workers = Eric Pouech eric.pouech@wanadoo.fr % = 80% ( Eric has this changed ??? )
Multimedia wave audio Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 100% for OSS
Multimedia MIDI audio Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 100% for OSS **Preliminary ALSA support 10%
Multimedia joystick driver Documentation = workers = Eric Pouech eric.pouech@wanadoo.fr % = 80% ( Eric has this changed ??? )
Multimedia CD audio Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 100%
MCI (Media Control Interface) drivers Documentation = workers = Eric Pouech eric.pouech@wanadoo.fr % = 60% ( Eric has this changed ??? )
msacm32: Audio Compression Manager (ACM) Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 60%
msvfw32: Video for Windows (VFW) Documentation = workers =Eric Pouech eric.pouech@wanadoo.fr % = 30%
ddraw: DirectDraw Documentation = workers = TransGaming % = 85%
Direct3D Documentation = workers = TransGaming % = 30%
dinput: DirectInput Documentation = workers = TransGaming % = 40%
dplayx: DirectPlay Documentation = workers = Peter Hunnisett % = 25%
dsound: DirectSound Documentation = workers = TransGaming % = 80%
quartz: DirectShow core Documentation = workers = In TransGaming cvs ?? % = 0%
wing: WinG 16-bit game library Documentation = workers = ? % = 50%
rpcrt4: RPC/DCOM subsystem Documentation = workers = ? % = 0%
ole32: OLE/COM core Documentation = workers = CodeWeavers % = 60%
oleaut32: OLE Automation core Documentation = workers = CodeWeavers % = 60%
olecli32: OLE client library Documentation = workers = ? % = 5%
olesvr32: OLE server library Documentation = workers = ? % = 5%
oledlg: OLE user interface Documentation = workers = ? % = 5%
opengl32: OpenGL interface Documentation = workers = Lionel Ulmer, TransGaming % = 90%
odbc32: ODBC Database Manager Documentation = workers = Corel % = 100%
wnaspi32: Advanced SCSI Peripheral Interface Documentation = workers = ? % = 85%
( Tools )
Wine Resource Compiler Documentation = workers = Bertho Stultiens ??? % = 95%
Wine Message Compiler Documentation = workers = Bertho Stultiens ??? % = 75%
Wine Debugger Documentation = workers = Eric Pouech eric.pouech@wanadoo.fr % = 85%
Wine Porting Tool (winemaker) Documentation = workers = CodeWeavers % = 70%
Wine Installer (wineinstall) Documentation = workers = Andreas Mohr % = 90%
Wine Installation Checker (winecheck) Documentation = workers = Andreas Mohr % = 30%
Wine Setup Tool (winesetuptk) Documentation = workers = CodeWeavers % = 50%
Wine Launcher Documentation = workers = CodeWeavers % = 60%
Wine Regression Test Suite Documentation = workers = CodeWeavers % = 10%
( No-Windows installation issues )
Initial registry contents Documentation = workers = ? % = 25%
Initial directory structure Documentation = workers = ? % = 90%
Initial INI files Documentation = workers = ? % = 40%
DLL placeholder files Documentation = workers = CodeWeavers % = 100%
( Instructions )
How to install Wine Documentation = workers = Andreas Mohr % = 90%
How to debug Documentation = workers = Andreas Mohr % = 80%
How to create a useful bug report Documentation = workers = Andreas Mohr % = 80%
How to become a Wine developer Documentation = workers = Andreas Mohr % = 80%
How to use Winelib Documentation = workers = Andreas Mohr % = 90%
How to compile MFC with Winelib Documentation = workers = Andreas Mohr % = 80%
( Miscellaneous )
Wine 1.0 Release Plan Both link's are dead !! I did find this link: http://www.winehq.com/news/?view=118#Road%20to%200.9 Ove- do you plan to do a updated Road to 1.0 ?
The History of the Wine Project MS has got nervous and released junk API's
What a MS breakup might mean to Wine ? Remove as there not going to get BROKE -UP!!!! ): ???
WineHQ and Corel relationship CodeWeavers is the host of WineHQ now ?
-----------------
Need to ADD
BiDi Documentation = workers = Shachar Shemesh contact = wine-devel@sun.consumer.org.il % = 5%
individual control status Documentation = workers = Dimitrie O.Paun contact = dimi@bigfoot.com % = ?%
On Sun, 1 Sep 2002, tom wrote:
I have a pre-1 hacked together and request any feed back that you can give.
I'm doing rolling CVS regression/conformance testing and reporting back whenever something breaks. How about adding an extra line under the "Wine Regression Test Suite"?
Something like the following:
--- wine-status.txt-old Mon Sep 2 12:30:00 2002 +++ wine-status.txt Mon Sep 2 12:31:03 2002 @@ -399,6 +399,7 @@ Wine Regression Test Suite Documentation = workers = CodeWeavers +Rolling cvs testing = Paul Millar % = 10%
( No-Windows installation issues )
For the percentage value, I've hacked together a quick (and dirty ;) script for calculating it [attached]. Its says what percentage of implemented Windows functions are mentioned in at least one regression/unit/conformance test -- I think this is a reasonable number to use. 'coz of the quick and dirty nature of the script, it takes a fair time to run.
Currently the percentage is around 10.3%
HTH,
Paul.
---- Paul Millar
Paul Millar wrote:
On Sun, 1 Sep 2002, tom wrote:
I have a pre-1 hacked together and request any feed back that you can give.
I'm doing rolling CVS regression/conformance testing and reporting back whenever something breaks. How about adding an extra line under the "Wine Regression Test Suite"?
Hi Paul,
Is this ** Part ** of the Regression Test Suite or a different category to add ? I am not a developer so please look over me if this is a dumb question ... If it is part of the Regression Test Suite I will just add you in as a worker with CodeWeavers . If it is a Different category I think it shold be like this
Rolling cvs testing Documentation = workers = Paul Millar % = 10%
Is the ( Regression Test Suite ) a program to test the Regression % or the % of the Regression ? As one is a app the other is a % If it is a app do you know the current % done ?
Alexandre can you chime in here ?
Tom
Something like the following:
--- wine-status.txt-old Mon Sep 2 12:30:00 2002 +++ wine-status.txt Mon Sep 2 12:31:03 2002 @@ -399,6 +399,7 @@ Wine Regression Test Suite Documentation = workers = CodeWeavers +Rolling cvs testing = Paul Millar % = 10%
( No-Windows installation issues )
For the percentage value, I've hacked together a quick (and dirty ;) script for calculating it [attached]. Its says what percentage of implemented Windows functions are mentioned in at least one regression/unit/conformance test -- I think this is a reasonable number to use. 'coz of the quick and dirty nature of the script, it takes a fair time to run.
Currently the percentage is around 10.3%
HTH,
Paul.
Paul Millar
Hi Tom,
On Mon, 2 Sep 2002, tom wrote:
Paul Millar wrote:
On Sun, 1 Sep 2002, tom wrote:
I have a pre-1 hacked together and request any feed back that you can give.
I'm doing rolling CVS regression/conformance testing and reporting back whenever something breaks. How about adding an extra line under the "Wine Regression Test Suite"?
Hi Paul,
Is this ** Part ** of the Regression Test Suite or a different category to add ?
It could probably be argued either way ... :) In the limited meaning of Regression Test Suite, then the answer is no.
I am not a developer so please look over me if this is a dumb question ... If it is part of the Regression Test Suite I will just add you in as a worker with CodeWeavers .
Well, I don't claim to have written anything in the Regression Test Suite (only one completely trivial patch), so I'd rather my name wasn't in the "workers" section.
If it is a Different category I think it shold be like this
Rolling cvs testing Documentation = workers = Paul Millar % = 10%
Hmmm, yes. On the whole, I think this is better. You can put me down for Documentation too. I'm not sure what (if any) documentation is really needed, but I think there's a reasonable amount at: http://www.astro.gla.ac.uk/users/paulm/WRT/ and http://www.astro.gla.ac.uk/users/paulm/WRT/help.php
Its difficult to gauge a percent-completeness for the rolling regression testing. I'm quite happy with the functionality as it stands now (although I've got a few ideas for improvements). Its been quite stable (apart from some problems with thread deadlocks) for quite a while now, so I'd say its probably around 90% or so.
Is the ( Regression Test Suite ) a program to test the Regression % or the % of the Regression ? As one is a app the other is a % If it is a app do you know the current % done ?
I don't know if this answers your question, but the Regression Test Suite is a series of explicit statements of what is correct behaviour of the Windows API. Calling function Foo() with parameter "Bar" should return "Baz" : that sort of thing. Information is gleaned from MS's official documentation and from direct testing of various Windows platforms. There's a little more info on the first URL above.
Ideally we want all the functions implemented by wine to precisely match the result from Windows under all circumstances (or at least all circumstances where it matters for a program). This behaviour should then be tested to make sure nothing breaks at a later date.
For calculating a percentage, the script calculates the number of APIs implemented, and the number of those functions that appears in at least one regression test. The idea is divide one by the other and you have a measure of what percent of wine is tested by the Regression Suite (hence how complete it is).
Unfortunate the estimate almost certainly an over-estimate. The calculated number of implemented API is via a crude grep. The estimate also assumes that, just because a function is mentioned in a regression test, the function should be counted as "tested". Both bias towards an increased percentage, so the 10.3% value should be taken with a generous pinch of salt :)
Cheers,
Paul.
---- Paul Millar
Paul Millar wrote:
Hi Tom,
On Mon, 2 Sep 2002, tom wrote:
Paul Millar wrote:
On Sun, 1 Sep 2002, tom wrote:
I have a pre-1 hacked together and request any feed back that you can give.
I'm doing rolling CVS regression/conformance testing and reporting back whenever something breaks. How about adding an extra line under the "Wine Regression Test Suite"?
Hi Paul,
Is this ** Part ** of the Regression Test Suite or a different category to add ?
It could probably be argued either way ... :) In the limited meaning of Regression Test Suite, then the answer is no.
<picky>
What we have called in the past as "the regression test suite" should be called "the conformance test suite". One of the things it is usefull for is to test for regressions but that is only one of its uses. Its primary purpose is to ensure that the behaviour of the wine API conforms to that of Windows API.
</picky>
It is great to see this page updated.
Tony Lambregts
On Mon, 2 Sep 2002, Paul Millar wrote: [...]
Its difficult to gauge a percent-completeness for the rolling regression testing. I'm quite happy with the functionality as it stands now (although I've got a few ideas for improvements). Its been quite stable (apart from some problems with thread deadlocks) for quite a while now, so I'd say its probably around 90% or so.
Just to be clear, 90% might be accurate for the "testing framework", but certainly not for the completness of the tests. Even the framework needs some more components, see bugs 526, 527, 528, 529 and 530.
(making progress on 526 and 527)
Unfortunate the estimate almost certainly an over-estimate. The calculated number of implemented API is via a crude grep. The estimate also assumes that, just because a function is mentioned in a regression test, the function should be counted as "tested". Both bias towards an increased percentage, so the 10.3% value should be taken with a generous pinch of salt :)
Yes, that seems extremely high. There is over 12000 APIs in Wine and I cannot believe we have tests for 1200 of them. I would be surprised if we did have tests for 120 of them.
Tom wrote:
Well I was going to ask for what need's to be done in order for Wine to become 1.0.0 .....
For what 1.0.0 is, see the section about Wine 0.9.0 at the following URL: http://www.winehq.com/about/index.php?contrib
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
On Tue, 3 Sep 2002, Francois Gouget wrote:
On Mon, 2 Sep 2002, Paul Millar wrote: [...]
Its difficult to gauge a percent-completeness for the rolling regression testing. I'm quite happy with the functionality as it stands now (although I've got a few ideas for improvements). Its been quite stable (apart from some problems with thread deadlocks) for quite a while now, so I'd say its probably around 90% or so.
Just to be clear, 90% might be accurate for the "testing framework", but certainly not for the completness of the tests.
Certainly.
Even the framework needs some more components, see bugs 526, 527, 528, 529 and 530. (making progress on 526 and 527)
Ok, still work to be done there. But when I said 90%, I was referring specifically to the automated testing (ie WRT).
Yes, that seems extremely high. There is over 12000 APIs in Wine and I cannot believe we have tests for 1200 of them. I would be surprised if we did have tests for 120 of them.
Is there an easy way of calculating how many Windows APIs are implemented in Wine (ie excluding internal functions) and to produce a list of them ?
---- Paul Millar
On Tue, 3 Sep 2002, Paul Millar wrote: [...]
Is there an easy way of calculating how many Windows APIs are implemented in Wine (ie excluding internal functions) and to produce a list of them ?
Check out: http://fgouget.free.fr/wine/winapi_stats-en.shtml
It needs some updating, in particular I believe the command to use now is something like:
./tools/winapi/winapi_extract --stub-statistics 2>&1 | tee winapi_stats.txt | winapi_stats >winapi_stats.html
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
On September 1, 2002 07:27 am, tom wrote:
Known ToDo's will be next on my list after ** WE ** get this up to date..
Having the status done is great, having a list of TODOs (for items that are
70%complete) of what needs to be done to make them 100% complete
would be fantastic.
We can enter bugs for these in Bugzilla, and semi-automate the status tracking this way. This is also a great way to (1) spread the intimate knowladge that only a few people have about these subsystems, and (2) focus development and getting more people to help.
Dimitrie O. Paun wrote:
On September 1, 2002 07:27 am, tom wrote:
Known ToDo's will be next on my list after ** WE ** get this up to date..
Having the status done is great, having a list of TODOs (for items that are
70%complete) of what needs to be done to make them 100% complete
would be fantastic.
We can enter bugs for these in Bugzilla, and semi-automate the status tracking this way. This is also a great way to (1) spread the intimate knowladge that only a few people have about these subsystems, and (2) focus development and getting more people to help.
Well I was going to ask for what need's to be done in order for Wine to become 1.0.0 ..... But after reading over the last years worth of WWN it seem's everytime this is brought up a nice FLAME WAR starts up .
So not to start a flame war just yet ....... should ToDo's be
70%complete) of what needs to be done to make them 100% complete OR What are the ToDo's to make a 1.0.0 release
Tom
P.S on the part about ( getting more people to help ) Good Luck !! I ask on the user list for help and one guy said he would ...He has not done any thing so far.. And this is a (( non programer )) thing that people can step up and help out on. I guess I could consider this as help as now I only have my own self in my way :)
On September 2, 2002 02:30 pm, tom wrote:
Well I was going to ask for what need's to be done in order for Wine to become 1.0.0 ..... But after reading over the last years worth of WWN it seem's everytime this is brought up a nice FLAME WAR starts up .
Well, these are different things.
The Wine 0.9 and 1.0 tasklist has been discussed at WineConf, and they are documented somewhere (does anyone have a link to them?). However, these are quite different from the 100% complete list, since Wine 1.0 will (hopefully) be released _before_ a lot of the components are 100% complete.
In other words, the Wine 1.0 tasklist answers the question: "Alexandre, what do we need to do to have Wine 1.0?"
The 100% complete tasklist answers the question: "<devname>, what is left to do to complete component X?" where <devname> is/are the developer(s) who have intimate knowledge about component X.
Now, talking about 100% complete, we should define a little better what we mean by this percentage. I suggest that it estimates the completeness of *documented* features, since the undocumented ones are simply gagable. This being said, a component reaches 100% complete status when it implements all documented features.
-- Dimi.
Dimitrie O. Paun wrote:
Now, talking about 100% complete, we should define a little better what we mean by this percentage. I suggest that it estimates the completeness of *documented* features, since the undocumented ones are simply gagable. This being said, a component reaches 100% complete status when it implements all documented features.
I slightly disagree. 100% should, indeed, mean "everything is implemented". 80%, however, should not mean "80% of the functions are implemented". If anything, it should mean "80% of the functionality is implemented". I also think that this should be scaled according to how frequent a certain function is called. For example, a function that requires months of work to implement, but is only used by 1% of the programs, cannot drop the support precentage by 80%, even if it is that amount of work.
"95% of the job requires 5% of the work", also known as the 95/5 rule.
Shachar
On September 3, 2002 11:17 am, Shachar Shemesh wrote:
Dimitrie O. Paun wrote:
Now, talking about 100% complete, we should define a little better what we mean by this percentage. I suggest that it estimates the completeness of *documented* features, since the undocumented ones are simply gagable. This being said, a component reaches 100% complete status when it implements all documented features.
I slightly disagree. 100% should, indeed, mean "everything is implemented". 80%, however, should not mean "80% of the functions are implemented". If anything, it should mean "80% of the functionality is implemented".
I don't understand then on what you disagree, even slightly. All I said is that we should gage the *documented* features, not the undocumented now. The percetages < 100 are a gut feeling anyway, no point in making to stringent rules about them. That being said, I agree they should try to estimate the amount of functionality completed that is used by the majority of programs that are of widely used.
-- Dimi.
Dimitrie O. Paun wrote:
I don't understand then on what you disagree, even slightly. All I said is that we should gage the *documented* features, not the undocumented now. The percetages < 100 are a gut feeling anyway, no point in making to stringent rules about them. That being said, I agree they should try to estimate the amount of functionality completed that is used by the majority of programs that are of widely used.
Ok, I agree then.
-- Dimi.
Shin
The 100% complete tasklist answers the question: "<devname>, what is left to do to complete component X?" where <devname> is/are the developer(s) who have intimate knowledge about component X.
Now, talking about 100% complete, we should define a little better what we mean by this percentage. I suggest that it estimates the completeness of *documented* features, since the undocumented ones are simply gagable. This being said, a component reaches 100% complete status when it implements all documented features.
well, # of documented APIs is not the only aspect to be taken into account. you have stuff like: - configurability - scalability - speed to look after. As of today, most of those items are not looked into (not for the 1.0 target), but it doesn't mean work isn't needed more over, don't forget that : # of implemented API -------------------- # of documented API is an evolving target, as the documented APIs evolve over time for example, the file I/O stuff can be considered over 90% for Wine 9x (except the SMB stuff), while it way lower on a NT perspective.
IMO, the % is more an indication of what users could expect for a module: < 25, forget about using builtin 25/50 : very low usage, may work in some rare cases 50/75 : good basic capabilities, may work for mainstream application 75/100 : solid implementation, bugs remaining
A+
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech -
Francois Gouget -
Paul Millar -
Shachar Shemesh -
tom -
Tony Lambregts