EVERY ONE here should read the post Shawn Hargreaves posted to the AD list. (as I don't have time... I can't copy it here, becides Im at school
Bob? Peter? Could you?

I'm not Bob nor Peter, but I'll post it here anyway

quote:
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

I hope this can end the discussion on the possibility to remove DOS support, so we can discuss more on the real topic of this thread (how should look and the features of future Allegro)
[ December 03, 2001: Message edited by: lillo ]

quote:What effort? Do nothing, and the DOS support continues. The effort would be if someone was to sit down and remove it all :-)
I don't believe that some people truly understand what Allegro 5 is going to be. We're not talking about a minor update and adding new features. We talking about a complete and total rewrite of the entire library. No stone will be left unturned. That means that support for any OS will require specific code and API design choices.
And therein lies the problem: specific code and API design choices. Why should I, as a Windows programmer targeting decent computers (those with video acceleration and a processor somewhere above 300MHz) have to have my API hamstrung by DOS support? Not only that, doing stuff in DOS is not particularly easy. I would rather get my Allegro 5.0 in a year or so than wait 3 years just so the developers can add DOS support.
quote:1. decent driver support for OpenGL & networking
2. decent share libraries support
3. native multithreading
#1 is easy. Just don't support those functionalities on DOS. Cause init_network and init_opengl or whatever to return errors.
#2 is even easier. Just link statically.
#3 could be slightly more difficult. Either handle it the way SDL handles the same problem on MacOS9, or handle it by integrating the Palantir source code, or write our own DOS threads support for Allegro.
Let's take #1. If the DOS port of Allegro 5 doesn't support these, then what separates Allegro 5 DOS from Allegro 4 DOS? Nothing. The new features of Allegro 5 will not exist for DOS. Therefore, what is the point in wasting the Allegro developer's time in creating Allegro 5 DOS?
As for #3, writing a thread library is certainly not easy. Which brings me back to one of my earlier points: Why should we spend precious Allegro developer time creating the DOS port when it takes a disproportionate amount of time more to create the DOS port than any other?
In conclusion, DOS developers: stick to Allegro 4. Why is it completely unacceptable for DOS users to stick with Allegro 4? You haven't upgraded your OS from DOS for 7 years even though better alternatives have been avaliable. Is not upgrading your game library from Allegro any more different? You have made the conscious choice to use an antiquated OS. Therefore, you must suffer the consequences of having to use antiquated library (or, at least, libraries that aren't actively adding new features).

quote: Can we please lose the inter-underscore sytle of Allegro function/variable names? I think that Allegro is the only library I know of that promotes using underscores in functions and variable names.
Not true. Have a look at libc and stdc++, possibly the most important and prominant libraries every built, which use the allegro_underscrored_style_function_names

My current stake on the DOS port is that it can stay as long as it doesn't get (too much) in the way.

Perhaps strider's idea can be extended a little more so accomodate multiple monitors/displays, and multiple windows at the same time.

Huh?

I don't get it. DOS stays in Allegro 4 whether you like it or not. We're not going to remove a fairly large chunck of code from Allegro mere days before it is released!

We are, however, discussing the future of Allegro in the 2-5 year time-frame. Allegro DOS may or may not stay around by then. If suddenly company X releases OS Y which does everything Windows does (except for DOS) but better, everyone switches, and there's no one left to use DOS, then kepping Allegro DOS around doesn't make much sense.

That scenarios isn't likely to happen in the near future though, so Allegro DOS will most likely stick around for a while longer.

A total rewrite of allegro for 5.0? When was that discussed? I thought it was just to clean up the api? For most things all that requires is a feature added/changed (8bit palettes) or changing the order of some arguments.. (blit vs. draw_sprite)
I don't think its in Allegro's best intrest to be rewritten, heck It was just rewritten to support the driver model.. which of course allows all of the current ports to exist. In my view Allegro is almost perfect, there are really only a few 'diry' parts that need to be cleaned up a bit.
One thing I was thinking was to get rid of the END_OF_MAIN nonsense... and do what all the other 'self respecting' libraries do, they have a 'allegro_main(int, char **)' like function that gets called from the real main in the users executable. Just a thought.

Allegro 5 is about a complete redesign of the API. Cleaning it up is just a baby step. The inside of it is all going to change. And, we're talking aboutboth ripping out the internals and redesigning the API interface.

hmm, so you say you are droping DOS becuase it is antiquated, and you don't care about supporting the DOS user-base that was the original home for Allegro and what made it popular in the first place, and yet you want to keep it in C, an antiquated language, instead of moving to C++ which allegro would benefit as much from as dropping DOS.

Sounds like somebody is playing favorties.

matthew: I tried repeatedly to add it in the graphics section, but nothing ever came out of it...

FBlend can be downloaded here

People on the forums are a lot more open minded than those on the mailing list. I posted a email with the subject title of "Proposal to drop DOS from Allegro 4" it was supposed to be Allegro 4 or 5, but I got basically flamed in a "polite" way by everyone. I didn't read all of Shawn Hargreaves' reply, but I wouldn't be surprised if he even flamed me since Allegro is his baby so to speak.

It's not going to be dropped because Shawn won't allow it so we might as well just drop the subject of removing the DOS port.

OK, that's somewhat silly and quite untrue. It isn't like C++ is so vastly superior to C that to not use C++ will cause actual damage to the library. Either C or C++ is a perfectly viable option. AllegroGL will not be harmed in any way by either choice. Multithreading is legitimate regardless of whether it is programmed in C or C++. Certainly, not using C++ will not limit the avaliable visual, audio, control, or file handling features of the library. The best C++ could do is make a slightly nicer interface to them.

The reasons for scapping DOS support are that it limits what the library can do. DOS doesn't have multithreading support, therefore the developers will have to write it, thus keeping them from more important work besides implementing something as complex as a good schedualer. Accelerated OpenGL doesn't exist in DOS, so either it is relegated to a plugin (which, as we have already seen, doesn't work too well), or time must be spent in development to allow for a software implementation of OpenGL.

[ December 03, 2001: Message edited by: Korval ]

but isn't windows built on DOS? Just like C++ is built on C? And name me one pure C compiler....i can't think of one. Almost every compiler people use for C devolopment is a C++ compiler that they are using for C. Does that not make C antiquinted and stuck in only for backwards compaitbility? Like for example, you don't see a visual C compiler, nor a borland C compiler (at least not still being upgraded or produced..yes you can use the old Turbo C, but that's still a 16bit compiler...not really up to date, eh?).

I think I have a right to call C support anituqauted since C isn't supported anymore other than as a subset of a C++ compiler.

And why can't these people just use the 4.0 allegro then? What I'm saying is that the silly DOS arguement works both ways. I'm not saying drop C from Allegro, I'm saying to stop acting like hypocrites.