a few comments...
- 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
interprocess messages should be fine now (even if all the interprocess object sharing isn't over yet) DDE is being worked on, so I don't think you should keep the item
- Native Alsa support
- Could it offer capabilities that OSS does not offer?
[snip]
- Anti-rational: Alsa includes an OSS compatibilty mode that seems to work pretty well
ALSA is needed when you need proper full duplex capabilities however, only ALSA 1.0 should be supported (0.5 and 0.9 shouldn't, except if 0.9 interface turns out to stay the one for 1.0)
- aRts support
- ESounD support
I think it would be a too high task to implement all the drivers... there's quite some activity right now on linux audio to ease this a bit. let's see where stuff like JACK will go
- Move the winsock16 code to wsock32
more generally, it would be a good thing to be able to tear 16 bit code away from wine (with a configure switch). This would be a must-have for embedded wine. Not really fun to do.
- 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.
do you have a precise example for this one ? this is more a bug than a big thing to do. from the debugger stand point, you could add: - (re)implement function calls from interpreter - add 16 bit trap support - write a transformer to make MSVC .DBG files from wine's .so files (&stabs) so that standard windows debugger can handle native DLLs - implementing imagehlp (or debughlp) would also be appreciated
- 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)
winedbg never had support for the C++ ABI (neither from GCC nor MSVC). So GCC 3.0 shouldn't be an exception regarding the debugging format, it seems more (but I didn't install nor looked closely at it) that gcc chooses which debug format to use instructing gcc with -gstabs (or -gstabs+) instead of -g should ease the issue
some other items to look at: * make the server a linux kernel module (has been discontinued) but could provide some performance enhancements
A+