Dave P writes:

<>
> However, I am happy to open and manage, or let others open and manage a
> full open source project to create a QDOS/SMSQ-like OS on the ARM
> platform. The hardware is cheap, fast and available right now. It has a
> future.
>
> If anyone is interested in a major project like creating a whole new OS
> based on the best of SMSQ's ideas, fixing all of the weaknesses etc, they
> should let me know.
>
> So you know what I picture:
>
> * compact, extensible, modular OS (like RISC OS)
> * built in resources for screen/window handling
> * built in filing system common to all media
> * device independence philosophy
> * incorporate fixed drivers for hardware
> * modular expansion system
> * support for languages, notably including a very SBASIC-like one.
> * Easily accessible, logical OS calls.
<>

Im sure there would be nothing like creating ones own OS, incorporating all
the best features of every other OS one has known and cramming it with all
the new features one hankers for.

However, as far as Im concerned, there are some fundamental problems with
your proposition. QDOS, SMSQ/E and variants (lets call them all Qdos for
short) are written in a very specific machine language for a very specific
CPU architecture. This permeates the design at every level. There are, of
course, many excellent features of Qdos that are independent of the
underlying language and architecture, but I dont believe it is possible to
divorce the overall design from that and still call it Qdos. The result
might be better, faster and more amenable to future development, but it
wont be Qdos. Thats the first problem.

The second is that over the years almost every program written for Qdos,
relies on the above in various ways. There are hundreds of machine code
extensions and indeed programs written entirely in assembler, that make use
of the OS and the underlying design parameters.

So why restrict the development of a new OS by trying to keep it compatible
with what could only amount to a fraction of the software currently
available for it? Better to throw it all out and start from scratch! But
then the playing field would be wide open and swathes of Qdos users would
abandon ship and go elsewhere, while the new OS would have to work very hard
to gain new adherents.

It may have been a fundamental mistake to have tied Qdos so closely to the
fortunes of one particular CPU architecture. However, had Motorola
succeeded,
and the cloners too had done for the MC68 series what they did for the
flawed and quirky i86 series, then Qdos would have had a very good chance to
be where Windoze might be in 5 years from now, as it takes full (well,
quite a lot, with the potential for more) advantage of the raw processing
power of a very powerful (by design) CPU.

AFAICS, there are only three ways a Qdos platform can develop: 1) a better
MC68-type chip, 2) using a chip with MC68k microcode emulation, 3) MC68 CPU
emulation on some other, powerful CPU. There is still some movement in the
first field, the second has never been tried, and the third is doing quite
nicely, I think, although it can never be 100% satisfactory.

Since software writers for Qdos can no longer hope to catch up with the
mainstream, option 3 suits me best, as I get the best of both worlds and
everything I need from a computer, without the need to maintain a second
physical machine. And our small community is spared most of the hassel of
having to write or maintain drivers for all kinds of devices (another major
obstacle!)  All we need are more and better tools and toys for the system we
already have and to continue to develop that system as far as we can. That
is, IMHO, where we should expend our programming efforts.

For sentimental reasons, I believe there is some justification in developing
real hardware platforms for Qdos systems too, but a reality check forces me
to conclude that due to the lack of resources we would be better off to
concentrate on evolutionary developments rather than revolutionary ones.

Per



_______________________________________________
QL-Users Mailing List

Reply via email to