September 2002 - Wine-Devel

Re: current wine status pr-1

by Eric Pouech

> 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+

Sept. 3, 2002

current wine status pre-2

by Thomas Wickline

Hello, Here is Pre-2 I have made changes from the feedback that I recieved from Pre-1 From now on I will just send a diff from Pre-2 to cut back on Bandwith. Please take a minute and look over it and send me any corrections that may be needed. Bad info is worse than NO info at all.. I know this is a estimate of work done... I would just like for it to be as close as possiable.. Many Thanks to everyone Thomas Wickline Wine status changes from 9-29-01 untill 9-03-02 pre-2 reply to : twickline2(a)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 % 90% Native DLL overrides Documentation = workers = ? % = 95% X11 display/window driver Documentation = workers = ? % = 90% X11 font mapper Documentation = workers = Huw D M Davies % = 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 = workers = Dmitry Timoshkov, Alexandre Julliard % = 90% Unicode support Documentation = workers = Dmitry Timoshkov, Alexandre Julliard % = 80% Dynamic Data Exchange (DDE) Documentation = workers =Eric Pouech % = 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 65% 32-bit 65% Documentation = workers = Huw D M Davies Win32 Console Documentation = workers = Eric Pouech % = 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 = Macadamian % = 95% 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 = Martin Wilck % = 90% ******** http://www.winehq.com/news/?view=121#Winsock2%20Patches also news in #108 ws2_32: WinSock 2 Documentation = workers = Martin Wilck % = 70% ******** http://www.winehq.com/news/?view=121#Winsock2%20Patches also news in #108 wininet: Internet application protocols Documentation = workers = CodeWeavers % = 50% winmm: Multimedia architecture Documentation = workers = Eric Pouech % = 80% Multimedia wave audio Documentation = workers =Eric Pouech % = 100% for OSS Multimedia MIDI audio Documentation = workers =Eric Pouech % = 100% for OSS **Preliminary ALSA support 10% Multimedia joystick driver Documentation = workers = Eric Pouech % = 80% Multimedia CD audio Documentation = workers =Eric Pouech % = 100% MCI (Media Control Interface) drivers Documentation = workers = Eric Pouech % = 60% msacm32: Audio Compression Manager (ACM) Documentation = workers =Eric Pouech % = 60% msvfw32: Video for Windows (VFW) Documentation = workers =Eric Pouech % = 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 = % = 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 % = 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 = Martin Pilka, CodeWeavers % = 100% Wine Launcher Documentation = workers = CodeWeavers % = 60% Re-name to = Wine Unit Testing Framework Wine Regression Test Suite Documentation = workers = Andriy Palamarchuk % = 70% ( 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 update link to: http://www.winehq.com/about/index.php?contrib#active remove WWN #45 Known Remaining: Window management rewrite Wine Unit Testing Framework More DLL Separation Documentation Quality assurance The History of the Wine Project MS is definitely getting nervous 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 should this be removed ???? ----------------- Need to ADD BiDi Documentation = workers = Shachar Shemesh contact = wine-devel(a)sun.consumer.org.il % = 5% individual control status Documentation = workers = Dimitrie O.Paun % = 80% Rolling cvs testing Documentation = workers = Paul Millar % = 90% **Side note... The test its self is 90% done.

Sept. 3, 2002

Re: Compiling Wine gdi dlls under cygwin

by Steven Edwards

--- David Fraser <davidf(a)sjsoft.com> wrote: > I have been trying to compile the wine gdi dll under cygwin. I am using > the 20020804 snapshot > This is part of an attempt to get native Windows applications to display > themselves > in cygwin's X Windows. > I have seen several posts from Steven Edwards and others about compiling > wine under cygwin > So far I have managed to link in all required object files, but still > receive the error below: > > fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' > fu000003.o(.idata$3+0xc): undefined reference to `libwine_a_iname' > fu000005.o(.idata$3+0xc): undefined reference to `libwine_a_iname' > fu000007.o(.idata$3+0xc): undefined reference to `libwine_a_iname' > fu000009.o(.idata$3+0xc): undefined reference to `libwine_a_iname' > fu000011.o(.idata$3+0xc): more undefined references to `libwine_a_iname' > follow Running WINE on Cygwin has kind of been a side project for me so I never reported this problem to the list. I had the same problem a while back and havent had the time to look at it more. If you can make it work I would like to play around with it a little more. Steven __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Sept. 3, 2002

Compiling Wine gdi dlls under cygwin

by David Fraser

I have been trying to compile the wine gdi dll under cygwin. I am using the 20020804 snapshot This is part of an attempt to get native Windows applications to display themselves in cygwin's X Windows. I have seen several posts from Steven Edwards and others about compiling wine under cygwin So far I have managed to link in all required object files, but still receive the error below: fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000003.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000005.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000007.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000009.o(.idata$3+0xc): undefined reference to `libwine_a_iname' fu000011.o(.idata$3+0xc): more undefined references to `libwine_a_iname' follow Some other unresolved references are resolved by auto-import (wine_main_argc etc) and enable-stdcall-fixup (_RELAY_DoCallFrom32Regs) but I can't work out where libwine_a_iname comes from. Basically as I only need the gdi dll I have linked in a whole lot of object files: /graphics/*.c, /objects/*.c, /files/*.c, /loader/*.c, /loader/ne/*.c, /relay32/*.c, /memory/*.c /library/ldt.c, /dlls/ntdll/*.c, unicode/*.c, scheduler/*.c, msdos/*.c, win32/*.c, misc/*.c, if1632/*.c as well as everything in dlls/gdi and subdirs. This is probably a bit ambitious as it's my first attempt at wine development, but any advice?

Sept. 3, 2002

Re: current wine status pr-1

by Shachar Shemesh

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

Sept. 3, 2002

Re: current wine status pr-1

by Dimitrie O. Paun

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.

Sept. 3, 2002

Re: current wine status pr-1

by Shachar Shemesh

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

Sept. 3, 2002

Re: ANSI_CHARSET

by Jeff Smith

>From: Marcus Meissner <meissner(a)suse.de> >To: Francois Gouget <fgouget(a)free.fr> >CC: Jeff Smith <whydoubt(a)hotmail.com>, wine-devel(a)winehq.com >Subject: Re: ANSI_CHARSET >Date: Tue, 3 Sep 2002 09:02:20 +0200 >MIME-Version: 1.0 >Received: from Cantor.suse.de ([213.95.15.193]) by >mc4-f10.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 3 Sep >2002 00:02:24 -0700 >Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201])by >Cantor.suse.de (Postfix) with ESMTPid A471C142DA; Tue, 3 Sep 2002 09:02:20 >+0200 (MEST) >Message-ID: <20020903090220.C30897(a)suse.de> >References: <F155awoeMTVNcBklFJN00020b3e(a)hotmail.com> ><Pine.LNX.4.43.0209022354330.31721-100000(a)amboise.dolphin> >In-Reply-To: <Pine.LNX.4.43.0209022354330.31721-100000(a)amboise.dolphin> >User-Agent: Mutt/1.3.22.1i >Return-Path: meissner(a)suse.de >X-OriginalArrivalTime: 03 Sep 2002 07:02:24.0593 (UTC) >FILETIME=[DB273C10:01C25317] > >On Mon, Sep 02, 2002 at 11:56:49PM -0700, Francois Gouget wrote: > > On Mon, 2 Sep 2002, Jeff Smith wrote: > > > > > ANSI_CHARSET and SYMBOL_CHARSET need to be defined (in >include/wingdi.h), > > > but I have some doubts about the details. > >They are already defined there: > >#define ANSI_CHARSET (BYTE)0 /* CP1252, ansi-0, iso8859-{1,15} >*/ >#define DEFAULT_CHARSET (BYTE)1 >#define SYMBOL_CHARSET (BYTE)2 > >Why arent they in your wingdi.h file? > >Ciao, Marcus _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

Sept. 3, 2002

Re: Ignoring exceptions

by Uwe Bonnes

>>>>> "Fabian" == Fabian Cenedese <Cenedese(a)indel.ch> writes: Fabian> Hi I still try to find the reason for the exception in my app Fabian> while loading an ocx. But I don't seem to make much Fabian> progress. Here is a new trace: Fabian> 08153fd8:Call kernel32.lstrlenA(40791300 "") ret=5f587c81 Are you sure you look in the right place? What you show here is in my opinion some debug trace of the debugger process. Your error should happen much earlier. Run with the additional +seh argument. This is the first thing that triggers, when the exception occurs. But watch out, there are exceptions that the application itself catches. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 3, 2002

Ignoring exceptions

by Fabian Cenedese

Hi I still try to find the reason for the exception in my app while loading an ocx. But I don't seem to make much progress. Here is a new trace: 08153fd8:Call kernel32.lstrlenA(40791300 "") ret=5f587c81 08153fd8:Ret kernel32.lstrlenA() retval=00000000 ret=5f587c81 08153fd8:Call kernel32.MultiByteToWideChar(00000000,00000000,40791300 "",ffffffff,405c45fc,00000001) ret=5f5010de 08153fd8:Ret kernel32.MultiByteToWideChar() retval=00000001 ret=5f5010de 08153fd8:Call kernel32.GetProcAddress(65340000,00000002) ret=5f54db21 08153fd8:Ret kernel32.GetProcAddress() retval=65341408 ret=5f54db21 08153fd8:Call kernel32.IsBadReadPtr(405c469c,00000020) ret=40c27bce 08153fd8:Ret kernel32.IsBadReadPtr() retval=00000000 ret=40c27bce 08153fd8:Call kernel32.IsBadReadPtr(405c467c,00000004) ret=40c27bce 08153fd8:Ret kernel32.IsBadReadPtr() retval=00000000 ret=40c27bce 08153fd8:Call ntdll.RtlSizeHeap(40360000,00000000,403c0850) ret=65f019c3 trace:heap:RtlSizeHeap (40360000,00000002,403c0850): returning 00000020 08153fd8:Ret ntdll.RtlSizeHeap() retval=00000020 ret=65f019c3 08153fd8:Call kernel32.IsBadReadPtr(41986f50,00000020) ret=10214168 08153fd8:Ret kernel32.IsBadReadPtr() retval=00000000 ret=10214168 08153fd8:Call kernel32.IsBadWritePtr(41986f50,00000020) ret=10214180 08153fd8:Ret kernel32.IsBadWritePtr() retval=00000000 ret=10214180 08153fd8:Call kernel32.OutputDebugStringA(405c2154 "Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND ($80020003).\r\n") ret=10215139 08073540:Ret kernel32.ContinueDebugEvent() retval=00000001 ret=404c3ee2 08073540:Call kernel32.WaitForDebugEvent(40615e0c,ffffffff) ret=404c3ef8 08073540:Ret kernel32.WaitForDebugEvent() retval=00000001 ret=404c3ef8 08073540:Call kernel32.ReadProcessMemory(0000002c,405c2154,40615cf4,00000100,40615cc4) ret=404c2e27 08073540:Ret kernel32.ReadProcessMemory() retval=00000001 ret=404c2e27 08073540:Call kernel32.ContinueDebugEvent(08153f20,08153fd8,00010002) ret=404c3ee2 08153fd8:Ret kernel32.OutputDebugStringA() retval=00000000 ret=10215139 08153fd8:Call kernel32.RaiseException(e06d7363,00000001,00000003,405c45b4) ret=10209499 It used to stop right after the RtlSizeHeap function. I don't know why it's later now, but leads me to thinking that it's just accidentally at this place and the reason is much earlier. Anyway, I now have a new message stating an exception (DISP_E_MEMBERNOTFOUND). After looking into MSDN to find out what it means I found this little article: <MSDN> Debugging Output You Can Safely Ignore -- snip -- Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND ($80020003). First-chance exception in TSTCON32.EXE (MFCO42D.DLL): 0xE06D7363: Microsoft C++ Exception. -- snip -- The last two lines are notification that an exception has been thrown because the test container didn't provide a Color property to be read. This is okay, because we've provided a default value for the property. You won't get this error if you use a container that provides the property, such as a Visual Basic application. In Visual C++ version 4.1, the only line I got was a warning about the exception for properties that couldn't be loaded from the container. First-chance exception in TSTCON32.EXE (MFC40.DLL): 0xE06D7363: Microsoft C++ Exception. Depending on how your container handles threads, you may also get occasional messages about threads exiting. You don't need to worry about these, either. </MSDN> It seems to me that it's probably this exception that stops my app. Somehow it is better handled in Windows than in Wine as my app runs in Windows. I also tried a pure VB-app with just my ocx in it. Output looks quite similar. Can anybody with more insight in this matter give me some hints? Thanks (for helping and for reading my long mails :) Fabi

Sept. 3, 2002