ddraw: load OpenGL at runtime

Eric Pouech pouech-eric at wanadoo.fr
Sun May 18 08:06:41 CDT 2003


 > So I'm not sure it would be better than the discussions we
> already have on wine-devel.

I'm not at all convinced that we have enough discussions (being on 
wine-devel, or somewhere else).
If I try to schematize the type of discussions we may have, I could 
think of three categories:
A/ evolution of current architecture, setting goals, 
directions/directives...
B/ detailed architecture (interfaces)
C/ implementation details

we already have a good set of type C/ with, for example, patches review 
from wine-patches, and I don't think we need something extra for C/ at 
the moment

B/ is mostly done by, for a given item, by a single person, which 
doesn't give lots of opportunities to be discussed until we reach the C/ 
stage. Failing to know that someone is tackling an issue at this stage 
ends up with people stepping on the other one's toes (read wintab, 
openGL dynamic linking...)

C/ is also little discussed, and it's the area where I think we should 
focus on first. If it works, B/ and C/ would flow more easily. That's 
also the area where Alexandre is mostly welcome (on stage B/ we need 
some other people: for example, Lionel on D3D & OpenGL, Dimi for (some) 
comctl...).

So, when proposing IRC chatting, I was trying to find out some sparkles 
to fire up the type C/ kind of discussion. Again, the way to the 
discussion is just a way, the most important is that the discussion 
takes place (and there is not a single way of doing it)

 From an interaction point of view:
- for C/, peer review is OK IMO, and it can be done with mail, no issue 
here.
- for B/, it will require some material (preview patches...), but in 
most of the cases mail (and its latency should be fine too)
- however for A/ we need both in some cases low latency to agree quickly 
on some directions, and also long latency so that some proof of concepts 
can be derived.

If we should end up with a low latency echange (let's call it that way 
to avoid tools oriented issues), I think we also need a (non exhaustive) 
list of items to be looked at, to be set before the exchange.

I would put:
- wine configuration
- dynamic mount of FS in wine
- package dependency (ie detect available packages at runtime not at 
compile time)
- Win32 / Win16 separation

A+
-- 
Eric Pouech




More information about the wine-devel mailing list