Horses for courses - why not Wine 3.11, Wine 95, Wine 98, Wine NT etc.?

Bill Medland medbi01 at
Thu Aug 30 08:47:11 CDT 2001

Mike Whittaker <mikewhittaker at> wrote in article
<9mivcl$npu$1 at>...
> Having unsuccessfully browsed around the Wine FAQ for an answer, forgive
> asking
> this directly !
> Wouldn't it make a certain amount of sense to have separate Wine projects
> with
> partially shared codebases, to realise compatibility with the different
> flavours of Windows ?
> [I have not inspected the codebase, so excuse me if this is already the
> case.]
> In this way, you are not aiming at a continually moving target, and the
> feature set for the now-legacy Win 3.11, 95 and 98 should be fixed.
> In addition, discontinued features or APIs could then be deleted from
> support in newer platforms.
> There would then be two components of Wine development effort:
> 1. to ensure 'absolute' compatibility with existing platforms
> 2. to extend for developing/unfinished platforms
> Obviously the codebase should be set up to allow code which is partially
> shared between targets on a file-by-file or subsystem basis, and some
> stringent guidelines/administration as to when a shared code line should
> split off into a target-specific variant.
> The user of Wine would then opt to use the 'highest' level of
> required for their application.
> Regards,
> Mike Whittaker
> PS. the mailto links on the pages don't work - not even
> 'postmaster', which RFC822 (?) says always should !
> _______________________________________________
> wine-users mailing list
> wine-users at
Are you aware that the current design creates a single product that can be
configured with a command line option or config file option to emulate a
particular version?  Rather than separate projects with shared code or even
separate compilations with different #defines the code tests the
configuration variable and behaves appropriately.

Of course the real problem is in knowing where the behaviour differs


More information about the wine-users mailing list