[ I somehow forgot to mail this... ]
On Wednesday, June 21, 2000, Eric Pouech <[EMAIL PROTECTED]> wrote:
> >
> > WINE USER'S GUIDE
> > For the day-to-day user; maintaining Wine on your system. How to
> > configure the basic services, like fonts, printing, multimedia.
> perhaps what's missing is the point of administrating Wine (like instaling
> Wine on a multi-user system), which lays across the here above two points
I'm not sure I follow.
> > WINE APPLICATIONS GUIDE
> > For dealing with specific applications.
> >
> > WINE PORTING GUIDE
> > For developers trying to migrate their apps to UNIX, using Wine.
> I find the title misleading
> there are two topics to be covered
> - porting apps from Windows to Unix using Wine (which is not IMO wine porting
> guide)
> - how to port wine to other systems than the ones already supported (linux, freebsd,
> partly Solaris...) (which shall be named Wine Porting Guide, and belongs to next
> section)
Right, I overlooked that. What title would you suggest for the
Windows->UNIX migration guide?
> > WINE DEVELOPER'S GUIDE
> > ======================
> >
> > I. Architecture
> > 1. The Wine Server
> > 2. DLLs in Wine
> > 3. Drivers
> > 4. The Kernel
> > 5. The graphics subsystem
> > 6. OLE Support
> > 7. Unicode
> 1/ you seem willing to mix USER and GDI support into the graphics subsystem
> may be there's a need to split that a bit (particulary for the link between
> USER and WM...)
"Naive" would probably be a better word than "willing". (c: I'm
honestly not sure what the best way to organize this section is, and
would like to spark some more discussion about it.
> 2/ 16 bit support, thunking, DLL pairs is also a must have IMO
Oops, missed that one, thanks.
> 3/ file systems too (but they can be part of kernel)
Yeah, that's the problem...where do you draw the lines?
> anyway, we may have issues with the above layout because the subjects are
> not orthogonal. we can either take the Windows point of view (how is this
> peculiar DLL implemented) or take the Wine components one by one
> I'd favor to stick to Windows' components (because wine tries to mimic them
> anyway). lastly, Wine server is IMO part of Kernel (or is the way Wine
> implements part of the kernel)
I guess it really depends on what the goal of the Architecture section
is. Do we want to express how Wine itself works? Or do we want to
focus on how Wine copes with implementing the Windows system?
John
--
[EMAIL PROTECTED] http://www.gnome.org
[EMAIL PROTECTED] http://www.worldforge.org
