Wine Tasklist - wine-devel

24 Dec 2001


      Hi,
I would like to establish two Wine tasklists in Wine's bugzilla.
 * the first list would contain the items listed in my previous 'Call
for Volunteers' emails. This would make it easier to keep track of
these tasks.
 * the second list would contain more complex and general items like
'DCOM support'.
For the first list, refer to my previous 'Call for Volunteers'
emails. I think I will start it from there and we can update it after
that. For the second list, I included a first draft below. I would like
your comments on it, especially with regard to the status of some of
these items, and suggestions if you see missing items.
I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There
may be some overlap but I think the intent is different.
 * My intent with these two new tasklists is to advertise what we want
to do to potential contributors. So the idea is to then add a page to
the WineHQ web site that would list all the ways one can contribute to
Wine: maintaining an application entry in the Application Database,
helping users on the mailing lists, buying Wine based applications, and
of course contributing code. And for this last item, these lists would
provide a good starting point, both for developpers with little time and
for developpers who want to invest themselves more heavily in Wine.
 * Then unlike the 1.0 and 1.x tasklists, these new lists would not be
tied to a specific Wine release or date.
I hope to produce a draft of this web page in the coming days. In the
meantime let me know if I missed things in the list below. For each item
I tried to indicate the rationale behind the task, and point to the
corresponding bugzilla report if there is one.
Wine tasklist
-------------
* Make the registry loadable on demand
   - when working from a Windows partition the registry is big.
   - this causes wineserver to allocate a lot of memory
   - this has a big impact on startup times
   - a 'database' based registry may be more robust
* Rasterizer
   - to paint into a DIB we have to copy the IB contents into an X
     bitmap, call X functions to modify the bitmap, often only to have
     to copy the result back to the DIB when the application tries to
     read it. Imagine it for eash SetPixel operation!
   - a rasterizer would be able to perform these operations directly on
     the DIB and thus provide better performance, at least in some
     situations.
   - it would also provide better color accuracy: the X server often
     only supports a few bit depths so that if the application works on
     a 24bpp DIB but the X server is in 16bpp mode, 3bits are lost per
     color component.
* Cross process messages
   - used by many applications
   - needed for DDE (bug 95)
   - Alexandre, you worked on this recently, right? Is this working now?
   - See bug 93
* Out of proc COM
   - Needed for Installshield 6
   - Would probably help with at least some functionality of a host of
     other applications
* DCOM support
   - same as out of proc COM but network transparent
   - should be interoperable with Microsoft's implementation so that, in
     a company setting, processes running in Wine can connect to servers
     running on whatever Windows server are present.
* Better multi-user support
   - how to get per-user registry files
   - how much per-user setup is really necessary?
     (create a '.wine' directory, create per user registry files, who
     does that, ...)
   - is it possible to share a single read-only 'c:' drive? What do
     we need to get parity with an NT environment?
   - is it possible to share a read-only 'system.reg' file?
   - what is the impact of a 'load on demand' registry? Could we share 
     a single registry server?
   - what would be necessary to share a single
   - there are many options that need to be investigated and
     documented...
* UNC path handling
   - for drives '\.\e:', devices
   - for network paths
   - there's been a patch related to this recently but I believe it does
     not cover all cases
   - integrate with Samba to handle network UNC paths
   - provide a way to mount/unmount drives at runtime, especially 
     network drives. One should be able to disable this in the config 
     file (for security reasons).
   - Support for 'persistent' mounts... will require modifying the way w
     specify which drives are mounted where.
   - provide an applet to mount/unmount drives while Wine is running.
* Native Alsa support
   - Alsa is the future of sound in Linux: should be integrated in 2.5
   - Could it offer capabilities that OSS does not offer?
   - Other platforms may not support Alsa any time soon so we must keep
     OSS too
   - Anti-rational: Alsa includes an OSS compatibilty mode that seems to
     work pretty well
   - see bug 324
* aRts support
   - On an OSS system when the aRts daemon is running Wine cannot access
     the sound device
   - aRts makes it possible to send the sound other the network. This
     kind of functionality is great for a thin-client environments:
     setup a server and have the sound sent to each terminal ("You've
     got mail" ;-). Supporting aRts in Wine would let it integrate
     perfectly in such an environment.
   - this could either be native support, or making Wine compatible with
     artsdsp. The current problem may be related to the -Bsymbolic link
     option.
   - see bug 325
* ESounD support
   - Same thing as for aRts
   - see bug 326
   - Making Wine compatible with artsdsp may also make it compatible
     with esddsp (and vice versa).
* Write a regedit replacement
   - used by some installers to create registry keys
   - we can limit the functionality to just that although since Wine has
     a registry we should probably provide a tool to browse/edit it.
   - will be more important once we have a database based registry for
     the load on demand functionality
* Write a regsvr32 replacement
   - used by some installers
* Fix the desktop mode
   - If a process running in desktop mode start another, the new 
     process creates a new desktop
   - the background is black
   - one cannot start a specific application in desktop mode. You have
     to modify the config file.
* Compile with STRICT on
   - better type safety
   - reveales all the 16/32bits hacks
   - see bug 90
* Dll separation
   - to allow us to swap native dlls in and out with less problems
   - to make the dlls more independent of each other and make it easier
     to treat them as independent projects
   - see bug 96
* HEAP_strdup* removal
   - Alexandre said some day that they will go away
   - Part of the dll separation?
* Move the winsock16 code to wsock32
   - winsock16 is more related to wsock32 than to ws2_32
   - ws2_32 is the new API. This would leave us with a clean 32bit
     implementation of the new API that is not encumbered with 16bit
     hacks.
* Check .spec file completeness
   - we need complete spec file to know where we stand
   - determine what's new in WinMe, Win2000, WinXP
   - check that the ordinals/absence of ordinals is correct
   - I have scripts that can be used as a starting point
* Winedbg expression handling
   - when modifying the contents of a variable there can be mixups where
     the debugger modifies its own memory instead of that of the
     debugged process.
* Winedbg g++ 3.0 support
   - The debugging format and the ABI changed in g++ 3.0 and winedbg
     does not support the new ABI.
   - This prevents debugging of C++ Winelib applications
   - This is especially troublesome for MFC Winelib applications
   - Eric, you worked on this recently, do you know if this is a thing
     of the past or is it possible that there are still problems (I did
     not test recently)
* Better memory allocator
   - some memory allocation/release patterns cause the current allocator
     to be relatively inefficient
   - see threads on wine-dev (Ove/Gav hit this problem)
* Winelib richedit support
   - one of the things needed by MFC
   - the API seems at least partly supported, but the headers are very
     incomplete
   - see bug 330
* Visual C++ project support
   - make it possible to generate a Winelib project from a Visual C++
     project
   - this should be done by extending winemaker
   - see bug 61
* Specify how to compile and package the MFC
   - many applications use the MFC. To make Winelib useful it is
     necessary to make it easier to compile the MFC and MFC-based
     applications
   - winemaker has some support for the MFC. But it makes suppositions
     about how the MFC were compiled (library names, etc.). So it is
     necessary to document how to get something that works well
   - see bug 110
--
Francois Gouget         fgouget@free.fr        http://fgouget.free.fr/
                              145 = 1! + 4! + 5!