Call for Volunteers (Re: Newbie work?)

[Francois Gouget]

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 at free.fr        http://fgouget.free.fr/
    I haven't lost my mind, it's backed up on tape around here somewhere...