Also I'm thinking about starting an additional section for 'hard(er)' projects that would significantly improve Wine.
Maybe it could also list projects that are already underway and for which help would be appreciated (DCOM?, STRICT handles?). I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter.
Easy: Medium (I expect these would take longer or be a bit harder) * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple. Eric Pouech seems to be working on this. I did not check if his pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to.
A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila
On Wed, 29 Aug 2001, Eric Pouech wrote:
Also I'm thinking about starting an additional section for 'hard(er)' projects that would significantly improve Wine.
Maybe it could also list projects that are already underway and for which help would be appreciated (DCOM?, STRICT handles?).
I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter.
True. Btw, I'm currently working on the winsock headers :-) The goal is to: - make winsock.h independent from config.h (because one should not need all sorts of autoconf checks when using Winelib) - make winsock.h compatible with the msvcrt headers (which they currently are not, very unfortunately) And as I was working on this I found other issues. Some of them have been resolved and I sent patches already. Status / todo: - because winsock.h and winsock2.h were relying on the Unix headers they were quite incomplete. So I have been adding the missing items and it seems complete enough now. - the new winsocks.h will have a USE_WS_PREFIX feature similar to that of the msvcrt headers. - it's sometimes a bit hard to get them to work with both the Unix C headers and the msvcrt ones, especially when it comes to u_{char,short,...} types and select, FD_XXX. But it seems to work now - the ws_sockaddr_ipx structure is wrong, it does not match what is in windows. Also most of our code seems to assume that the Unix sockaddr_xxx and the windows sockaddr_xxx have the same binary layout. Except for ipx but there what does not help is all these checks are done all other the place in HAVE_IPX ifdefs. So I'm going to try and clean this up, but this is not yet done. - Alexandre pointed out to me that it might also be a good idea to reorganize wsock32, winsock and ws2_32. Specifically winsock should go with wsock32 since they both implement the winsock 1 API. And all 16 bit code would then be removed from ws2_32. - Also, we could try to implement wsock32 entirely by calling ws2_32, and not use sockets at all anymore. This would actually help me as the current situation (wsock32 uses both the Unix socket headers and ws2_32) causes me some trouble. The main problem seems to be WsControl... My other big project is a revision of the command line parsing, and I intended to post a patch for review yesterday but I broke the code at the last minute and did not find any time to look at what went wrong.
Easy: Medium (I expect these would take longer or be a bit harder) * Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple. Eric Pouech seems to be working on this. I did not check if his pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to.
My interest in pedump is mostly as a tool I could use in winemaker to find out which dlls are imported by a dll or an executable, so that I can know what I should link the winelib version with. If this works it would be a first step. Later I guess I could do something ala specmaker / call it to generate a librarie's spec file. But this is for much later. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
participants (2)
-
Eric Pouech -
Francois Gouget