At 04:50 PM 5/12/00 -0700, you wrote:
>I think we definitely want to make a 1.0 release.
<snip begin of plan>
> correct interfaces between dlls
> - dlls only use exported APIs
I looked at having the commctrl functions call a variant of DialogBox, but I
could not find an easy workaround for 16 bits resources
I am curious about the way you think resources should be handled.
I was thinking of 2 possible ways :
- duplicate the resources to have a set of 16 bit resources beside 32 bits. That
may be the only way if you want to implement a complete separation 16/32 in the
manner that D.O.Paun was describing.
- have some code to convert the 32bits resources to 16 bits; I was thinking
to have the necessary code in a separate module (a helper dll) so it could be used
throughout Wine.
I don't find any of these ways very attractive.
What would be best ? Or am I on a wrong track altogether ?
<snip end of plan>
This seems a very ambitious plan.
I don't see how all this could be finished before 2002 at best.
If so, there is a possibility to have a 'moving target' effect, for example, if Ms
merges its OS at some point, full Unicode support will probably become
mandatory...Is it not a risk to want that much, given that a 'stable'
Wine could bring more corporate support ?
Gerard
