eric.pouech at wanadoo.fr
Sun Dec 30 16:08:54 CST 2001
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?
> - 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,
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...
quite some activity right now on linux audio to ease this a bit. let's
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
from wine (with a configure switch). This would be a must-have for
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
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
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
some other items to look at:
* make the server a linux kernel module (has been discontinued) but
provide some performance enhancements
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
More information about the wine-devel