RE: [AD] Proposal to drop DOS port from Allegro 4

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Chris La Mantia writes:
> There seems to be little point in removing support for a 
> functioning, stable platform;

Exactly! I don't understand the logic of dropping it at all:
even if some people don't use it, others do, and it seems like
a very poor idea to impose just one idea of "how things should"
be on all the rest of the world.

Maybe we should drop the Windows port too, since many of the
developers prefer Linux? (and let's face it, DirectX causes
a lot of problems with switch modes and surface locking that
could be removed if we didn't bother to support it). Or maybe
it should be Windows only, since after all, Linux has a very
small userbase in comparison? Both clearly ridiculous ideas:
all of these ports are useful to some people, and even more,
the combination of all platforms together is much greater
than the sum of it's parts.

> As long as DJGPP is supported, there are likely to be enough 
> DOS developers to make the effort worthwhile.  

What effort? Do nothing, and the DOS support continues. The
effort would be if someone was to sit down and remove it all :-)

> Although there may be support for dropping DOS among the 
> Allegro developers, who mostly seem to be Linux users

I'd suggest that this is not so much an indication of lack
of interest in the DOS version, as that the DOS version is
already perfect (or as near as makes no difference). Hence
the DOS people are all off using Allegro in work of their
own, while the Linux and Windows users are far more likely
to run into trouble areas, hit the mailing lists, and then
get involved in working on the lib to fix things that aren't
currently working quite right.

> In other words: I suggest we keep DOS support as-is for 4.0, 
> depreciate it in 5.0 for any new features that are too 
> difficult to implement for DOS, and consider complete 
> non-support only for version 6.

Why even then? I think this whole idea represents a very
deep-seated and fundamental misunderstanding of how open-
source development works. People get involved in projects
like Allegro because they find it kind-of-useful but are
annoyed by some aspects of it, thus they spend time
improving the things that they find annoying. There needs
to be some central coordination to keep an overall focus,
but things only ever get done because somebody cared
enough to do them.

Taking things out of the project is not helpful, but just
undoes much work that other people have cared enough to do.

The really silly thing about this whole discussion is that
it is a non-issue: the DOS port works, and nobody has yet
come up with any actual solid technical reasons as to why 
it should be removed (ie. a feature that clearly belongs
in Allegro, and that DOS cannot support, and that cannot 
be exposed only on platforms that do support it). In other
words removing the DOS version would do nothing to improve
life for the Windows and Linux users, but only hurt the
DOS users for no purpose.

DOS support does not need to be depreciated or dropped: if
nobody maintains it, this will just stop working (as for
instance the Watcom port didn't even compile for a year or
so, and the BeOS port was completely non-functional for
a long time). As long as the code is there, anybody who
does want to use it can fix it. I'm betting that if this
ever stops working, you will pretty quickly find out that
there are a hell of a lot of people who will very quickly
be happy to fix it, and the only reason you aren't hearing
from them at the moment is that everything works fine, so
they have no need to get involved.

Regardless, open source works by putting the code out there 
no matter what state it might be in, and letting anybody
who cares do whatever is needed to make it work.

As for the "but DOS is holding things back" argument, I
would like to point out a few things:

- So are the Windows and Linux ports. All platforms have
quirks and oddities, and some things are difficult that
would be easy on others. Have a look through the code
sometime: every platform has some nice things and some
nasty/complex things, DOS no more or less than the others.

- DOS is actually far more sophisticated than a lot of
the interesting platforms in the world (PalmOS, GBA,
Xbox, the mobile phones of a few years from now). If you
design Allegro in such a way that it cannot run on DOS,
it won't be able to run on any of those either, which
would be a shame to me at least. Remember that the world
is a much larger and more varied place than whatever
platform you currently happen to be running on your 
desktop PC.

- Not all environments are equal, but that doesn't mean
you can't support them. Try to design a nice API that
abstracts common features across all platforms. Where
no such abstraction exists, add caps flags so that apps 
can query what features are available and adjust 
themselves accordingly, if they wish to use those 
features in at least a semi-portable way. This is 
nothing new to any major API: witness scroll_screen(), 
gfx_capabilities, create_system_bitmap(), 
SWITCH_AMNESIA, retrace_proc, acquire_bitmap(), etc.

Some (scroll_screen(), retrace_proc) are nice features 
that are only possible on some platforms (in that case
DOS supports them while Windows does not). Others
(SWITCH_AMNESIA, acquire_bitmap()), are nuisances that
are forced by flaws in one platform. Programmers on
other platforms can choose to leave them out, or to
insert these calls in the interest of portability,
and have them perform noops on platforms where they
are not relevant. These things represent huge
differences in the fundamental assumptions made by
one platform vs. another, but can (with a bit of 
work by smart developers) be encapsulated to the
point where most people need not worry about them.

Dropping an entire platform strikes me as a very poor
solution, especially given that all the really difficult
design work has already been done! (mostly on the 
conductors list during the early days of the Windows 
and Linux ports).



-- 
Shawn



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/