wine users - Aug 2001 - Horses for courses - why not Wine 3.11, Wine 95, Wine 98, Wine NT etc.?

Having unsuccessfully browsed around the Wine FAQ for an answer, forgive my
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 fairly
stringent guidelines/administration as to when a shared code line should be
split off into a target-specific variant.

The user of Wine would then opt to use the 'highest' level of
compatibility
required for their application.

Regards,

Mike Whittaker

PS. the mailto links on the winehq.com pages don't work - not even
'postmaster', which RFC822 (?) says always should !

I would agree, 16bit apps don't work well on Win95 yet wine trys to make
them
work allong with every thing else. I would at least break it into
Wine9x/NT/2k and Wine3.11. As far as I can see the apps that don't work in
NT/2k don't have that much hope for working in wine so there would only
need to be 2 real divisions.

You might have mor luck on the wine.devel forum though, it's on the wine
news server.

Mike Whittaker <mikewhittaker@zdnetonebox.delspam.com> wrote in article
<9mivcl$npu$1@sp15at20.hursley.ibm.com>...
> Having unsuccessfully browsed around the Wine FAQ for an answer, forgive
my
> 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
fairly
> stringent guidelines/administration as to when a shared code line should
be
> split off into a target-specific variant.
> 
> The user of Wine would then opt to use the 'highest' level of
compatibility
> required for their application.
> 
> Regards,
> 
> Mike Whittaker
> 
> PS. the mailto links on the winehq.com pages don't work - not even
> 'postmaster', which RFC822 (?) says always should !
> 
> 
> 
> _______________________________________________
> wine-users mailing list
> wine-users@winehq.com
> http://www.winehq.com/mailman/listinfo/wine-users
> 
> 
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

Bill