Amiga OS ? Let's do it !
Maarten Ter Mors
So we want a new Amiga OS ? Let's start to do something about it then. I
suggest we try to get as many people together, committed to make this thing
happen. I want to hear people volunteer for :
=================================->
1) PROGRAMMING. Not the first point by accident. Of course this is going
to be the major chunk of work, so we need everybody who is enthusiastic about
this and who can work in a team (essential bit, that !). I think everyone can
take part, no matter how much or how little programming experience they have.
It's just important that everyone involved should be willing to listen to the
other members of the (hopefully large) development team to correct bugs, adapt
things to fit better with other parts of the OS, and so on.
On the subject of programming, there are a couple of things we need to agree on
:
1.1) LANGUAGE. I think it's essential that we use ONE programming
language (preferably even one compiler) for all our code and that it shouldn't
be assembly either. Why ? Well, with the current development in processors, I
think it would be unwise to stick with the 68000-line of processors, or with
any other, for that matter. Should the RISC Amiga appear, or should we want to
run our newly-made OS on a PowerMac, all we would need on the other platform is
a compiler for that particular language and off we go. I propose C or C++, but
that's because I use the former myself and so I'm prejudiced :-) Other
suggestions are welcome.
1.2) LICENSE. All the programmers involved should agree to donate their
code to the good cause and they should not expect to make any money from the
new OS. Every active member will have to sign some sort of document that
shows their agreement to this.
The copyright of the OS would lie best, I think, with the entire group and not
with the individual (like 'OpenWindow() and CloseWindow() Copyright Joe
Bloggs', 'CreateMsgPort() and DeleteMsgPort() Copyright Irving Gould' etc.).
This would make it easier to sue MicroSoft if they decided to nick (part of)
our OS. However, I'm no legal expert, so maybe I'd better shut up and let
someone with a degree in law shed some more light on the subject. 1.3) THE
WHEEL. I don't know about you, but re-inventing wheels is not one of my
favourite pastimes. We should use as much existing material as possible and,
while we're at it, incorporate as many useful utilities into the new OS as
possible (KingCON, Toolsdaemon and a DoubleSpace-like system based on XPK
libraries spring to mind), whereas other things are fine as they are (ARexx,
for example, works fine as an external program). Also, we want the people who
have made so many essential enhancements to the existing Amiga OS already in on
this : Dave Haynie, Nico François, Mike Sinz, Olaf Barthel, Johnatan Potter, to
name just a few, we need you here !
=================================->
2) COORDINATION. This is another tough cookie. One person, or better still,
a small group of people (say five) should direct the development process and
tell people what to do and what not to. This doesn't mean they would be in
charge of the operation in the sense that they would be the bosses and
everything they wanted would happen, it's just that they will keep track of
developments, avoid people from programming in opposite directions or working
on the same thing independently, etc. The coordinators would also be the ones
to take action in the form of officially releasing versions of the OS, giving
out information to the media (see below), sue MicroSoft :-) and so on. They
can't do this with just the five of them, they have to rely on the services of
: 2.1) LEGAL ADVISORS. We're likely to need more than one of these, since there
are different laws in different countries. We don't want to do all the work
just to have it taken away from us by some big company. 2.2) THE MEDIA. It
is important to keep people informed what's happening, so we need to have a
link to the things people read. Can we count on Amiga Report ?
2.3) THE TESTERS. Very important group this, and a very big one too. In my
own programming experience, I have found that a 100 K program can hold more
bugs than there are stars up in the sky (this may have had something to do with
my programming skills :), so a complete OS will probably contain as many as the
number of times actors say 'f*ck' in the movies these days. The programmers
will do some testing of each other's work, of course, but real alpha- and beta
testing is a job in its own right sometimes and that's where the testers come
in. The coordinators will gather all the bug reports and pass them on to the
programmer(s) who are likely to be responsible. Anybody with an Amiga can be a
beta tester, so volunteer now !
=================================->
3) RESOURCES. Obviously, we'll need computers. Everybody has his/her own
Amiga to develop or test on, but that's not enough. We need a WWW site, with
(as someone else proposed) two entries : one for the general public to browse
and keep in touch with the progress and one for the developers/testers
themselves, to submit new material or retrieve it. We need a newsgroup, or
preferably even two or one and a mailing list. One newsgroup is for general
discussions about the OS, suggestions from the rest of the Amiga community etc.
The other newsgroup (or the mailing list) is for dedicated discussion between
developers, the coordinators and maybe the testers. This is public, of course,
since we're not working on anything secret here, but people who have no real
business there but to read are strongly urged to stay out of the discussions,
especially since they will not be that meaningful to people not involved in the
project anyway.
So what I want is someone who has a large system connected to the Internet,
that can handle the considerable amounts of data involved in this sort of thing
and preferably independent (i.e. it cannot be restricted by a university's
management or by the president of the company you work for). He or she will
become the project's distribution manager, who will handle the technical side
of the newsgroup(s), mailing list(s), WWW pages, FTP requests and so forth.
=================================->
Unless I forgot something very crucial, in which case you must remind me at
once, this is about it. We can use the support of everybody, as long as he or
she is enthusiastic about the Amiga and concerned about its future. We can use
the aid of companies to sponsor our efforts in any possible way, but bear in
mind that it's mainly going to be a charity effort to save the Amiga and
nothing profitable such as buying the marketing rights to sell the OS when it's
finished.
Oh, we need a name :-) Actually I liked Phoenix, but I think there's a clone
BIOS by that name. Any ideas ?
G'bye then,
/|/| ___ /|/|
/ / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
-- Via Xenolink 1.95, XenolinkUUCP 1.0
Chris Hall
: Okay, enough talk, let's get on with it !
: So we want a new Amiga OS ? Let's start to do something about it then. I
: suggest we try to get as many people together, committed to make this thing
: happen. I want to hear people volunteer for :
Since I'm the one that started the other thread about it, of course you can
count me in.
: 1) PROGRAMMING.
I'm not a great programmer but I'll learn.
Anyone want to jump in on this also? I know a unix programmer that has
showed some interest in it.
: 1.1) LANGUAGE.
The best choice right now is GNU C because it's available on most
platforms. We need the ability to cross compile it on different machines.
: 1.2) LICENSE.
It should be modeled on the GNU license. Except that the group should
have control on who distributes it to keep it intact. Some money from
commercial distribution should go to help with administration costs.
: 2) COORDINATION.
Again, I can help with this part.
: 3) RESOURCES.
The resources of Dark Horizon BBS (A4000/030 w1.7gigs of storage) is
available. Unfortunatly it isn't directly connected to the net.
Anyone with a stable & fast net site want to help out with this one?
: =================================->
: Unless I forgot something very crucial, in which case you must remind me at
: once, this is about it. We can use the support of everybody, as long as he or
: she is enthusiastic about the Amiga and concerned about its future. We can use
: the aid of companies to sponsor our efforts in any possible way, but bear in
: mind that it's mainly going to be a charity effort to save the Amiga and
: nothing profitable such as buying the marketing rights to sell the OS when it's
: finished.
I don't think we need to look at it as a charity effort but an effort to
build a new home for us all.
Something you overlooked is source code to start with. I think the 680x0
mach would be good for that. Mach has most of what we are looking for in
a OS, we could adapt it to fit the Amiga library system.
The GUI for Tejas should be something like a mix of Intuition and X11.
: Oh, we need a name :-) Actually I liked Phoenix, but I think there's a clone
: BIOS by that name. Any ideas ?
I suggested Tejas (Native American for Friend) at the start of other thread.
Chris
___________________________________________________________________
Chris Hall | "Trust me - my whole case hinges on
<ch...@clover.cleaf.com> | proving you're a dork."
Sysop of |
Dark Horizon BBS | Defence Lawyer Kryten
903-832-6214 |
___________________________________________________________________
Branko Collin
Maa...@aobh.xs4all.nl (Maarten Ter Mors) writes:
>
>Okay, enough talk, let's get on with it !
>
>So we want a new Amiga OS ? Let's start to do something about it then. I
>suggest we try to get as many people together, committed to make this thing
>happen. I want to hear people volunteer for :
>
>=================================->
>1) PROGRAMMING. Not the first point by accident. Of course this is going
>to be the major chunk of work, so we need everybody who is enthusiastic about
>
a new OS may be completely different from anybody else's. Most of the new
developer's group's discussions about how you should implement a new
feature will change in a flamewar about why you should implement
something. Amiga and Mac both have OSes with a very strong (and good)
philosphy behind them, that's why I like these computers.
>On the subject of programming, there are a couple of things we need to agree
>on:
>WHEEL. I don't know about you, but re-inventing wheels is not one of my
>favourite pastimes. We should use as much existing material as possible and,
>while we're at it, incorporate as many useful utilities into the new OS as
>possible (KingCON, Toolsdaemon and a DoubleSpace-like system based on XPK
>libraries spring to mind), whereas other things are fine as they are (ARexx,
>for example, works fine as an external program). Also, we want the people who
your OS ought to look like, but otherwise you might end up with a
very messy (and therefore user-unfriendly and crash-prone) OS.
Good luck with your project!
.......................................................................
. Branko Collin . 'WHOP .
. . whisssssCRAC! .
. // u24...@vm.uci.kun.nl . THUMPA THUMPA' .
. \X/ bco...@mpi.nl (work) . Meccano - Gilette .
.......................................................................
Jeff Hildebrand
I think you may be a jumping a little ahead. I really think you need
to put together the coordinating committee first, before you start talking
programming or Mach or languages... After you have someone to coordinate
it, then write a specification for the job. A really well done spec can
reduce the effort by an order of magnitude easily. And make the spec
cover the requirements for documentation and testing as well as programming.
This helps make the programmers see the big picture and can avoid a lot
of bugs.
I wouldn't mind getting involved to the level of helping people coordinate
and clarifying my ideas of development (to whatever extent it helps). But
I'm in a grey area as to what my employer allows me to do, programming wise,
so I would avoid that just to be safe...
Byron Montgomerie
: : So we want a new Amiga OS ? Let's start to do something about it then. I
: : suggest we try to get as many people together, committed to make this thing
: : happen. I want to hear people volunteer for :
: Since I'm the one that started the other thread about it, of course you can
: count me in.
: : 1) PROGRAMMING.
: I'm not a great programmer but I'll learn.
: Anyone want to jump in on this also? I know a unix programmer that has
: showed some interest in it.
Before you start coding you have to do planning and layout. You won't be
coding for quite some time yet.
: : 1.1) LANGUAGE.
: The best choice right now is GNU C because it's available on most
: platforms. We need the ability to cross compile it on different machines.
How about stick with just Ansi C? Don't some programs compiled with GCC
(amiga version) require a library at run time? If not, go for it.
: : 1.2) LICENSE.
: It should be modeled on the GNU license. Except that the group should
: have control on who distributes it to keep it intact. Some money from
: commercial distribution should go to help with administration costs.
Hmm, is this going to be free or not? If not then anyone who participates will
want to be paid.
: : 2) COORDINATION.
: Again, I can help with this part.
What do you think will be the time frame for all of this? Will it be completed
in one year, two? Will the amiga be a player then? Or is this an amiga
project at all?
: Anyone with a stable & fast net site want to help out with this one?
: : Unless I forgot something very crucial, in which case you must remind me at
: : once, this is about it. We can use the support of everybody, as long as he or
: : she is enthusiastic about the Amiga and concerned about its future. We can use
: : the aid of companies to sponsor our efforts in any possible way, but bear in
: : mind that it's mainly going to be a charity effort to save the Amiga and
: : nothing profitable such as buying the marketing rights to sell the OS when it's
: : finished.
: I don't think we need to look at it as a charity effort but an effort to
: build a new home for us all.
: Something you overlooked is source code to start with. I think the 680x0
: mach would be good for that. Mach has most of what we are looking for in
: a OS, we could adapt it to fit the Amiga library system.
: The GUI for Tejas should be something like a mix of Intuition and X11.
Design the GUI under the assumption that the user is lazy and impatient and
will likely be able to catch any quick and dirty code you try and slip by. :)
Don't be swayed by the elegance of your own code, what the user has to deal
with is what matters. To quote a prevalent ad over here, try and give the
user the 'most for the least'. Heh :)
Recommended reading: "The Feeling of Power" by Isaac Asimov (Short Story).
: : Oh, we need a name :-) Actually I liked Phoenix, but I think there's a clone
: : BIOS by that name. Any ideas ?
How about PITS? Stands for Pie In The Sky. :)
Regards,
BM
Terrance Richard Boyes
: 1) PROGRAMMING. Not the first point by accident. Of course this is going
: to be the major chunk of work, so we need everybody who is enthusiastic about
: Unless I forgot something very crucial, in which case you must remind me at
: once, this is about it. We can use the support of everybody, as long as he or
Just that system specification, analysis and design will take up more time
than programming. Coordination will be a nightmare, but good luck.
--
,=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=.
| Email:) t...@tezboyes.demon.co.uk + do what you say say what you think + |
`= Warning Random Fortune Sig follows -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-='
Radioactive cats have 18 half-lives.
Chris Hall
: Before you start coding you have to do planning and layout. You won't be
: coding for quite some time yet.
And before that, you have to get people interested in helping.
: Hmm, is this going to be free or not? If not then anyone who participates will
: want to be paid.
Yes, it would be free on the net and boards but I'm talking about companies
that sell it on CD and supply it with computers. The costs would be to
cover an organzation like CATS. The ones that would maintain the
standards, supply developer info, etc. It wouldn't be a profit based
organization.
Imagine where the Amiga would be now if Commodore had sold all their hardware
divisions, downsized to just a hardware/software Amiga development company
and sold manufacturing rights to other companies.
: What do you think will be the time frame for all of this? Will it be completed
: in one year, two? Will the amiga be a player then? Or is this an amiga
: project at all?
Or even if it will get off the ground. It depends on how many people
would show enough interest in helping out. Yes, this would be an Amiga
project, it would just take the Amiga to the next step in evolution.
Chris Hall
Patrik Kudo
MTM> =================================->
MTM> 1) PROGRAMMING. Not the first point by accident. Of course this is going
I'm in on this part... Have done quite some programming.
MTM> =================================->
MTM> 2) COORDINATION. This is another tough cookie. One person, or better still,
If you need more people, you can count me in too
MTM> G'bye then,
MTM> /|/| ___ /|/|
MTM> / / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
MTM> -- Via Xenolink 1.95, XenolinkUUCP 1.0
/Patrik Kudo - e93...@e.kth.se
Frank Meijer
you want, but why bother about a new OS when the future of the
hardware itself is still far from sure?
Just my $0.02,
...Frank
---------------------------------+------------------------------------
Frank Meijer - Ottawa, Canada | These opinions are mine, just mine.
work: mei...@bnr.ca | Tiuj-cxi opinioj estas nur miaj.
play: ab...@freenet.carleton.ca | for (i=0; i<numop; i++) mine[i]=1;
---------------------------------+------------------------------------
Christoph Feck IRZ
I started searching voluntieers for this project in a german
amiga newsgroup, and thus this mailing list was created.
But most (if not all) people on this mailing list just tend
to hang around to "see what they are doing there".
If I now would post this address I could imagine that the
list gets 1000s of subscribers, but no-one really would DO
something.
I hope there are people out there who WANT TO DO make this
"dream" possible, those people can subscribe to this list.
PS: I have started rewriting Intuition, but without a new
layers/graphics/gadtools/prefs/datatypes etc. this will
be a joke.
3k// Christoph Feck, TowerSystems - Custom Class Design
\X/ Amiga - Intuition inside.
Jeff Hildebrand
: I probably missed the beginning of this thread, so flame me if
: you want, but why bother about a new OS when the future of the
: hardware itself is still far from sure?
: Just my $0.02,
That is just one of the questions that the group proposing this
needs to answer. There are as many answers right now as there
are people willing to get involved.
Chris Hall
: I probably missed the beginning of this thread, so flame me if
: you want, but why bother about a new OS when the future of the
: hardware itself is still far from sure?
Well with a new OS, we would have source to port it to new hardware and
put in some upgrades along the way. Also, no company could cause these
problems for us like these again.
Chris Hall
Akke Monasso
On January 20 '95 you wrote to All:
MTM> So we want a new Amiga OS ? Let's start to do something about it then.
MTM> I suggest we try to get as many people together, committed to make this
MTM> thing happen. I want to hear people volunteer for :
MTM> On the subject of programming, there are a couple of things we need to
MTM> agree on : 1.1) LANGUAGE. I think it's essential that we use ONE
MTM> programming language (preferably even one compiler) for all our code and
MTM> that it shouldn't be assembly either. Why ? Well, with the current
MTM> development in processors, I think it would be unwise to stick with the
MTM> 68000-line of processors, or with any other, for that matter. Should the
MTM> RISC Amiga appear, or should we want to run our newly-made OS on a
MTM> PowerMac, all we would need on the other platform is a compiler for that
MTM> particular language and off we go. I propose C or C++, but that's because
MTM> I use the former myself and so I'm prejudiced :-) Other suggestions are
MTM> welcome.
Ah! A very nice idea indeed. But if a new OS is going to happen, we should try
to make this thing as universal as possible. For one I think it might be a good
idea to separate the software completely from hardware. And guidelines like the
Mac!
Here are a few suggestions, they are very forward, but hey! Do it good or don't
do it at all!
- intermediate code: do not write for a real CPU, but a virtual one.
Write small and fast runners for the actual CPU's.
- object orientation of the OS: hardware and services are delivered by objects.
If the hardware exists then it is used, if not it can be emulated. The
application does not have to know.
The user chooses which service-class is installed.
- Use existing standards, for example SCREEN IO in postscript.
UNIX was started as a public domain OS. Maybe we can initiate something
simular. But before that can happen, a structure must be defined in which the
creativity of all programmers can be integrated conform specs. This structure
does not, in my opinion, has to take hardware limitations into account, because
this will catch up. It should be OPEN.
Ciao,
Tom
New!! E-Mail: ak...@grafix.xs4all.nl
... What's the point of being grown up if you can't act childish?
-- Via Xenolink 1.95
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
> : So we want a new Amiga OS ? Let's start to do something about it then.
> I : suggest we try to get as many people together, committed to make this
> thing : happen. I want to hear people volunteer for :
CH> Since I'm the one that started the other thread about it, of course you
CH> can count me in.
Great ! That makes four of us, me included :-)
> : 1) PROGRAMMING.
CH> I'm not a great programmer but I'll learn.
Well, I must admit I'm nothing fancy myself as far as programming goes, but I
also know that there is no better way to learn than to work together with other
people on a project. That's why I thought we'd work in teams : a team that
does Intuition and the look of the GUI (gadtools, ASL), another team tackles
the Exec kernel, there's a team for DOS, a team for the hardware-specific
things like trackdisk, parallel, serial, SCSI and so forth.
CH> Anyone want to jump in on this also? I know a unix programmer that has
CH> showed some interest in it.
We can use all the help we can get ! We won't be able to re-do an entire OS
with half a dozen people :-)
> : 1.1) LANGUAGE.
CH> The best choice right now is GNU C because it's available on most
CH> platforms. We need the ability to cross compile it on different
CH> machines.
Yes, GNU C had crossed my mind also. The other possibility, which I actually
preferred, was SAS/C, but unless SAS decides to start a huge sponsoring effort
(hello, SAS ? :-) we're not going to be able to supply everyone with the same
system. SAS has the same advantage as GNU in that it's availible for more than
one platform.
> : 1.2) LICENSE.
CH> It should be modeled on the GNU license. Except that the group should
CH> have control on who distributes it to keep it intact. Some money from
CH> commercial distribution should go to help with administration costs.
I'm not too familiar with the exact contents of the licence agreement (it's the
stuff I never read when I install a new program :), but since I'm going to
plunge into GNU C, I'll look into it.
> : 2) COORDINATION.
CH> Again, I can help with this part.
Excellent. That makes two people (you and me) who can do a little programming
and handle part of the coordination, one dedicated programmer and one person
who has computers with a direct connection to the net.
> : 3) RESOURCES.
CH> The resources of Dark Horizon BBS (A4000/030 w1.7gigs of storage) is
CH> available. Unfortunatly it isn't directly connected to the net.
That's allright, I think it's a good thing if we have a couple of support BBS
systems worldwide as well, for people who don't have access to the net. I
should be able to talk my own sysop into becoming support BBS.
CH> Anyone with a stable & fast net site want to help out with this one?
Don't worry, I already got an email from someone who has just the system we're
looking for, with a VERY fast link :-)
> : =================================->
> : Unless I forgot something very crucial, in which case you must remind me
> at : once, this is about it. We can use the support of everybody, as long
> as he or : she is enthusiastic about the Amiga and concerned about its
> future. We can use : the aid of companies to sponsor our efforts in any
> possible way, but bear in : mind that it's mainly going to be a charity
> effort to save the Amiga and : nothing profitable such as buying the
> marketing rights to sell the OS when it's : finished.
CH> I don't think we need to look at it as a charity effort but an effort
CH> to build a new home for us all.
Um, yes. Sounds better, doesn't it ? :-) What I meant by 'charity effort' is
that nobody's likely to make any money out of it. However, if you look at it
this way, you could see it as an investment in the future.
CH> Something you overlooked is source code to start with. I think the
CH> 680x0 mach would be good for that. Mach has most of what we are looking
CH> for in a OS, we could adapt it to fit the Amiga library system.
I'm not familiar with Mach (the first time I heard about it was less than a
week ago in this very thread), but I agree with you that it would be quite easy
to have a place to start. This also goes...
CH> The GUI for Tejas should be something like a mix of Intuition and X11.
...for user interfaces. I think we need, first of all, to take some leaves out
of the books of the many PD library add-ons that make the lives of programmers
so much easier, before we start from point zero and go about the task of
redesigning the entire Intuition/Gadtools lot. I think we should take the best
parts of all interfaces (Intuition, X11, EGS, MUI, whatever else you can think
of) and blend them into something that looks slick and not like things have
been bolted on with a DIY kit. I personally prefer a workstation-like look.
> : Oh, we need a name :-) Actually I liked Phoenix, but I think there's a
> clone : BIOS by that name. Any ideas ?
CH> I suggested Tejas (Native American for Friend) at the start of other
CH> thread.
Hmmm, keep it in the nomenclature of Amiga, you mean ? Well, to be honest with
you, Tejas reminds me of Taos, the place Marshall Sam McCloud came from (if you
don't know what I'm talking about, don't worry - I always watch ancient series
on TV :) and it looks like 'Texas'. Nothing wrong with Texas, but people will
think it a strange name for an OS until they see it's actually Tejas, after
which they will say 'Hmm, what does that mean ?'
I like the way it connects to 'Amiga' though. But meanwhile, how
about...er...Laura ? We don't have a custom chip by that name yet, do we ?
G'bye then,
/|/| ___ /|/|
/ / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
Maarten Ter Mors
Re: Amiga OS ? Let's do it ! too !
>> Okay, enough talk, let's get on with it !
>> So we want a new Amiga OS ? Let's start to do something about it then.
>> I suggest we try to get as many people together, committed to make this
>> thing happen. I want to hear people volunteer for :
>> =================================->
>> 1) PROGRAMMING. Not the first point by accident. Of course this is
>> going to be the major chunk of work, so we need everybody who is
>> enthusiastic about
BC> Your first point should have been philosophy/goal. Your reason for
BC> making a new OS may be completely different from anybody else's. Most of
I thought the goal was pretty much outlined in the previous discussions, but
maybe I was wrong. The spirit is 'if nobody's going to resurrect the Amiga,
let's do it ourselves !' Amiga users are generally a very devoted bunch and
they would hate to see their favourite machine go down the drain. Especially
for serious applications, the OS is what makes the Amiga the machine it is -
and that can be saved.
BC> the new developer's group's discussions about how you should implement a
BC> new feature will change in a flamewar about why you should implement
BC> something. Amiga and Mac both have OSes with a very strong (and good)
BC> philosphy behind them, that's why I like these computers.
I'm not too afraid of flame wars. It's not like someone's going to say : 'We
do it this way and no differently.', but everyone will have his or her say and
if a new feature is to be implemented, we can discuss that like adults. I
don't think there's any need to get angry with each other over a difference in
opinions. If we can't even sort things like that out, then I think it would be
unwise to even think about making a better OS. I do think about it though,
seriously, and I'm sure we can solve disputes as they arrive.
>> they are (ARexx, for example, works fine as an external program). Also,
>> we want the people who
BC> Again, this is nice if these programmes stick to your philosphy of how
BC> your OS ought to look like, but otherwise you might end up with a very
BC> messy (and therefore user-unfriendly and crash-prone) OS.
We'll make them stick. That's the big advantage of making a new OS : you can
integrate everything with no need for add-ons that are hacked into the system.
The art of the matter is making it fit in seemlessly, which is easier when
you're starting all over than when you have to fit it in at a later date.
And one thing we will be weary of, is that we don't make it messy - that's the
last thing we need. That's why the idea is to prevent people from programming
in their own directions and it's the coordinators' job to make sure everything
stays tidy and fits in.
BC> Good luck with your project!
Can we count on your support ? :-)
Maarten Ter Mors
Re: Amiga OS ? Let's do it ! too !
JH> From: jr...@space.honeywell.com (Jeff Hildebrand)
JH> TO: Chris Hall, Maarten Ter Mors ...
JH> I think you may be a jumping a little ahead. I really think you need to
JH> put together the coordinating committee first, before you start talking
JH> programming or Mach or languages... After you have someone to
JH> coordinate it, then write a specification for the job. A really well
JH> done spec can reduce the effort by an order of magnitude easily. And
JH> make the spec cover the requirements for documentation and testing as
JH> well as programming. This helps make the programmers see the big picture
JH> and can avoid a lot of bugs.
Of course we need a battle plan before we actually get started. It's not like
the coordinators tell the programmers : okay guys, go out and rewrite Exec in a
fortnight. But on the other hand, I'd like to know if we can count on enough
support from the Amiga programming community to make it worthwhile. I don't
want to come up with a detailed proposal that has taken hours of work, only to
find we only have five dedicated programmers to carry it all out.
Here's how I had pictured it in my head : first, we see how many people are
interested. This step has already been taken in fact, although I intend to put
up some more posts in other groups, c.s.a.programmer might be a good idea, as
well as in FidoNet groups. Then, when we've found people willing to form the
coordinating committee, we form it and set some wheels in motion. We start up a
mailing list, sent to all those who responded, with a brief introduction what
we're going to do, etc. We ask everyone to send in opinions, suggestions on
what should and shouldn't be in the new OS - except for the obvious things, of
course.
Subsequently, the coordinators put their heads together through email/telephone
contact/IRC chat/whatever and, after a number of hours' hard work, come up
with a detailed proposal, outlining exactly what we want to achieve. This will
be posted to the mailing list and the developers have another chance to
respond. With their input, the coordinators update their plan accordingly and,
unless there are real objections, that second version will be the storyboard
for the new Amiga OS. It's only then that we start to write the code.
JH> I wouldn't mind getting involved to the level of helping people
JH> coordinate and clarifying my ideas of development (to whatever extent
JH> it helps). But I'm in a grey area as to what my employer allows me to
JH> do, programming wise, so I would avoid that just to be safe...
So I can add you to the coordinating committee ? That would mean the count is
up to three.
Dean Smith
no existant. I have never been able to afford the Docs. The docs for this new
OS must be made readily available so more people can code for it, and we will
all need copies of the old os code and docs. I think we
should use an object orientated programming language, with data hiding etc.
My vote would be for C++.
Also , and I know how big a change this will mean to exec, it HAS to have
memory protection and TCP buitin. Also full RTG posibly like X11.
I know the memory protection will cause a problem on 680ec30 and below but
the OS needs it, even if it is only as an option.
--------Dean Matthew Smith, Department Of Computer Science--------- 0 0 ----
---------------University of Warwick, Coventry CV4 7AL------------- | ----
------ ph...@csv.warwick.ac.uk dea...@dcs.warwick.ac.uk----------- \_/ ----
Martin Vilcans
>Okay, enough talk, let's get on with it !
>So we want a new Amiga OS ? Let's start to do something about it then. I
>suggest we try to get as many people together, committed to make this thing
>happen. I want to hear people volunteer for :
>=================================->
>1) PROGRAMMING. Not the first point by accident. Of course this is going
>to be the major chunk of work, so we need everybody who is enthusiastic about
.
.
.
>=================================->
>2) COORDINATION. This is another tough cookie. One person, or better still,
.
.
.
>=================================->
>3) RESOURCES. Obviously, we'll need computers. Everybody has his/her own
>Unless I forgot something very crucial, in which case you must remind me at
>once, this is about it. We can use the support of everybody, as long as he or
What about people working on the most demanding phase of any bigger software
development project - specifications and design? Although we already have
an OS that can serve as a 'prototype', some more thought is needed before
sitting down to write code.
Just my 2c.
--
Martin Vilcans, mar...@lysator.liu.se, phone +46-13-261340
Jeff Hildebrand
: JH> I wouldn't mind getting involved to the level of helping people
: JH> coordinate and clarifying my ideas of development (to whatever extent
: JH> it helps). But I'm in a grey area as to what my employer allows me to
: JH> do, programming wise, so I would avoid that just to be safe...
: So I can add you to the coordinating committee ? That would mean the count is
: up to three.
Sure.
(I posted here rather than just using e-mail because I figure we want
people on the net to know how this is shaping up and to see what level
of support looks like so we can attract more people.)
N.W.H. Mailer
built in. This will make things much easier for Amiga net users. IMHO,
everything should be designed with a very much plug-and-play solution in mind.
***********************************************************
/\/ icholas /\/\ ailer - eng3...@leeds.ac.uk
University of Leeds & Koeksuster Publications
***********************************************************
Tom Hayko
>O, MY GAWD ! It can't be Branko Collin, who writes to All ?! And it's abo
>Re: Amiga OS ? Let's do it ! too !
> BC> Your first point should have been philosophy/goal. Your reason for
> BC> making a new OS may be completely different from anybody else's. Most
>
>I thought the goal was pretty much outlined in the previous discussions, b
>maybe I was wrong. The spirit is 'if nobody's going to resurrect the Amig
>let's do it ourselves !' Amiga users are generally a very devoted bunch a
>they would hate to see their favourite machine go down the drain. Especia
>for serious applications, the OS is what makes the Amiga the machine it is
>and that can be saved.
I think what Branko means here is that you need to come up with a basic idea
behind the OS. The idea behind AmigaDOS is that it should be small and quick,
the idea behind Unix is that you have a whole bunch of tools that you can
connect because everything is just a file, the idea behind WindowsNT was to
build an OS that would hurt DEC. Something like the spirit of the OS needs to
be figured out. Without something like this, the OS that is produced will
just be a mismash of ideas that don't really sync up.
Tom Hayko
tjh...@io.org
PS. I think that a good suggestion is to follow the original idea behind
AmigaDOS.
PPS. I be willing to help (don't know how much help I'll be) if the 'spirit'
is right.
Val Kartchner
Maarten Ter Mors <Maa...@aobh.xs4all.nl> wrote:
>Of course we need a battle plan before we actually get started. It's not like
>the coordinators tell the programmers : okay guys, go out and rewrite Exec in a
>fortnight. But on the other hand, I'd like to know if we can count on enough
>support from the Amiga programming community to make it worthwhile. I don't
>want to come up with a detailed proposal that has taken hours of work, only to
>find we only have five dedicated programmers to carry it all out.
Don't underestimate what can be done by five dedicated people. Linux was
written by *one* programmer, Linus Torvalis (sp?). The original Amiga OS
(without DOS) was written by *two* people (one on Exec and one on Intuition).
The ***IMPORTANT*** thing to do to make these five programmers productive
is to have a management team which will handle the interaction with the
users and stay out of the way.
If there are more than a few programmers, the overhead due to coordination
will overwhelm the project and we'll either get bloatware (e.g.: MicroSloth),
or nothing at all.
This is advice from a programmer who has programmed in teams.
--
|================= #include <stddisclaimer.h> ================/// KB7VBF/P11 =|
| "AMIGA: The computer for the creative mind" (tm) Commodore /// Weber State |
| "Macintosh: The computer for the rest of us"(tm) Apple \\\/// University |
|=== "I think, therefore I AMiga" -- v...@cs.weber.edu ====\///= Ogden UT USA =|
Jon M. Taylor
with the Amiga Linux port instead of starting from scratch? Linux is
quite a bit better than even the Amiga's OS in many respects. It can
certainly be made to fit in well with the Amiga hardware and take full
andvantage of it (probably even better then AmigaDOS can). A hell of a
lot has already been done on the Amiga Linux port already, and this would
seem to me like the logical path to take. I'm sure that an emulator for
existing programs (basically the equivalent of WINE for Intuition) could
be coded, and even many hardware-bashing programs could be run as well.
The current Amiga OS is nice, but it is really not in the same league as
Linux. I guess if you are looking to SELL this new OS then you couldn't
use Linux (which is GPL'd), but that seems like a stange thing to do.
-Jon
Pascal Eeftinck
> O, MY GAWD ! It can't be Jeff Hildebrand, who writes to All ?! And it's about
> Re: Amiga OS ? Let's do it ! too !
> Of course we need a battle plan before we actually get started. It's not
> like the coordinators tell the programmers : okay guys, go out and rewrite
> Exec in a fortnight. But on the other hand, I'd like to know if we can
> count on enough support from the Amiga programming community to make it
> worthwhile. I don't want to come up with a detailed proposal that has taken
> hours of work, only to find we only have five dedicated programmers to carry
> it all out.
Well, so far we've only got a handful of people. But here's one more: I am
willing to help with both coordination and programming. I've got some
experience with SDM (the System Development Methodology) too, and that might
help a bit. I won't take it all on my shoulders though ... :)
> Here's how I had pictured it in my head : first, we see how many people are
> interested. This step has already been taken in fact, although I intend to put
> up some more posts in other groups, c.s.a.programmer might be a good idea, as
> well as in FidoNet groups. Then, when we've found people willing to form the
> coordinating committee, we form it and set some wheels in motion. We start up a
> mailing list, sent to all those who responded, with a brief introduction what
> we're going to do, etc. We ask everyone to send in opinions, suggestions on
> what should and shouldn't be in the new OS - except for the obvious things, of
> course.
These are indeed the first actions that should be taken. It will also tell if
it's possible, since such a task requires a lot of resources, especially a lot
of competent people to do the job. This will ofcourse also require an
extensive database of all the people working on the job, which should be
accessible through several ways. (IRC, mailing list, FTP site).
As far as ideas about a new OS go, I've got several myself already. I also
have some ideas about what can be done, can't be done, should be done or
shouldn't be done.
One of the most important things is that the new OS shouldn't be hardware
specific, that is:
- The CPU isn't that important, only a small part of the code should be CPU
specific, and the whole system should support this idea. In specific, we
should gather information regarding different processors to spot any
differences about things that can't be done on certain processors, thus we
would be able to eliminate all the things that wouldn't work or make only
the processors that do support the things we need a target. (I am still in
favor of the 680x0 series though).
- All parts of the system should be modular, thus not require any specific
hardware setup. If 8 or 24 bit isn't available, emulate it. If a faster
serial port is available, make it possible to use that instead. And so
on ...
> Subsequently, the coordinators put their heads together through email/telephone
> contact/IRC chat/whatever and, after a number of hours' hard work, come up
Make that a *lot* of hours work ... :(
> with a detailed proposal, outlining exactly what we want to achieve. This will
> be posted to the mailing list and the developers have another chance to
> respond. With their input, the coordinators update their plan accordingly and,
> unless there are real objections, that second version will be the storyboard
> for the new Amiga OS. It's only then that we start to write the code.
Note that this alone will take a lot of time ...
> So I can add you to the coordinating committee ? That would mean the count is
> up to three.
Maybe four now? :)
And I'm sure more will follow soon, when the word gets out. How about
somebody writing an article for Amiga Report?
> /|/| ___ /|/|
> / / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
Regards,
Peter van Campen
[Stuff about new OS deleted]
Count me in as a programmer, I'm more of a hardware-banger so I
could do the serial, MIDI, etc. stuff.
We need a lot of info about everything, how about setting up
a BBS or site with lots of texts, old CBM developer info, etc. ?
It could also function as a preview exchange.
Matthias Meixner
: Hello Maarten!
: On January 20 '95 you wrote to All:
[...]
: Here are a few suggestions, they are very forward, but hey! Do it good or don't
: do it at all!
: - intermediate code: do not write for a real CPU, but a virtual one.
: Write small and fast runners for the actual CPU's.
That sounds like emulating this virtual CPU and that's very slow. Therefore I would
suggest generate binary coded assembler for such a CPU and translate this
on load-time to the native machine code of the used CPU. No, that's not the same
as the above, since it differs in the handling of data and jump-labels. In machine
code you cannot distinguish between code and data, whereas in this binary coded
assembler, you would be able to distinguish and therefore you could translate it
to the native machinecode instead of emulating the CPU.
: - object orientation of the OS: hardware and services are delivered by objects.
: If the hardware exists then it is used, if not it can be emulated. The
: application does not have to know.
: The user chooses which service-class is installed.
: - Use existing standards, for example SCREEN IO in postscript.
Or create new ones :)
I don't think, that postscript for SCREEN IO would be such a good thing.
OK, it would be nice to have it as an option, BUT there should be easier ways
of setting some pixels on the display.
: UNIX was started as a public domain OS. Maybe we can initiate something
: simular. But before that can happen, a structure must be defined in which the
: creativity of all programmers can be integrated conform specs. This structure
: does not, in my opinion, has to take hardware limitations into account, because
: this will catch up. It should be OPEN.
Maybe one could place it on a MACH-kernel, which was designed to be a kernel for
several operating systems, even for running several ones on the same machine at
the same time.
: Ciao,
: Tom
: New!! E-Mail: ak...@grafix.xs4all.nl
: ... What's the point of being grown up if you can't act childish?
: -- Via Xenolink 1.95
--
- Matthias Meixner
-----------------------------------------------------------------------------
Uebrigens: Nachts gehen Sonnenuhren nach dem Mond ...
Matthias Meixner
: Um, maybe I'm missing something here, but why not just help out
: with the Amiga Linux port instead of starting from scratch? Linux is
: quite a bit better than even the Amiga's OS in many respects. It can
It lacks many features of the Amiga OS and it is too complicated for the
average user.
It is missing:
- multiple Screens
- ARexx (Rexx)
- locale
- assigns
- shared.libraries (OK, it may come with dynamic link libraries, but with these
it is not possible to change the linkage on runtime, what is used e.g. by
the xpk-package:
That's what the xpkmaster.library does:
sublibbase=OpenLibrary(name,0);
open the library whose name is stored in the variable "name" and use
this one for packing
Therefore not even the name of the shared library is known at compile-time !)
- preferences
- different file-systems
- devices
And it was never meant to write a new operating system for the existing amigas,
but for another platform. And this OS should be source-code compatible
(up to a certain degree) with the other amigas, that you should be able to just
recompile your sourcecodes for the new machine.
(At least this is my understanding of writing a new "Amiga-compatible" OS).
: certainly be made to fit in well with the Amiga hardware and take full
: andvantage of it (probably even better then AmigaDOS can). A hell of a
: lot has already been done on the Amiga Linux port already, and this would
: seem to me like the logical path to take. I'm sure that an emulator for
: existing programs (basically the equivalent of WINE for Intuition) could
: be coded, and even many hardware-bashing programs could be run as well.
: The current Amiga OS is nice, but it is really not in the same league as
: Linux. I guess if you are looking to SELL this new OS then you couldn't
: use Linux (which is GPL'd), but that seems like a stange thing to do.
: -Jon
--
James Cooper
In article <3g415j$1...@csusac.ecs.csus.edu>, tay...@ecs.ecs.csus.edu (Jon M. Taylor) writes:
> Um, maybe I'm missing something here, but why not just help out
>with the Amiga Linux port instead of starting from scratch?
Maybe because not everyone likes UNIX?
Personally, I'd rather have AmigaOS than UNIX any day of the week. The
Amiga OS is small, fast, and has lots of features. It would be nice to
have a few changes, but there are several UNIX things I would HATE to
see in there, the least of which is that ?#*&#^ case-sensitive naming...
What's the difference between
foo.c
foo.C
Foo.c
FOO.C
?
On the Amiga, none. On UNIX, those are 4 separate files...
--
---------------
Jim Cooper
(ja...@unx.sas.com) bix: jcooper
Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!),
and not necessarily those of my employer.
Remember, "Euphemisms are for the differently brained."
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
CH> It would be nice if everyone that had patched or replaced sections of
CH> the OS would come together and just pool what they have. The system
CH> would be well over halfway done. Exec, Intuition and Graphics libraries
CH> have been patched by a number of users, replacement devices (serial,
CH> disk, etc.) exist, other libraries and system tools have substitutes. If
Wouldn't it be a good idea for everyone involved in the project to email the
author(s) of their favourite bit(s) of system replacement, asking them to
either join the team or at least donate their sources to the good cause ?
CH> everyone would at least replace one part (tool, lib...) of the WB disk,
CH> we could whip up a new set of WB disks in a couple of months. No more
CH> having to worry if coping them is legal or what. It would be free for
CH> all. A byproduct would be full docs in text files so someone could put
CH> them in a guide file for online help. Also, support for data types
CH> could be put on disk so that all kick37+ users could take full
CH> advantage of the new disks.
I think we should start on the new OS as in Kickstart and the new OS as in
Workbench at the same time. As you stated, not much manpower is required to
put the best bits & blobs of PD together to make a new workbench. Things like
the prefs editors (for which there are no substitutes in the PD to my
knowledge) and the datatypes would have to be programmed additionally, but
that's relatively simple.
However, first of all we need to know exactly what we're doing. As you will
probably have noticed by now, I reposted the original 'Amiga OS ? Let's do it
!' article to many other groups and my sysop's now down in the bomb shelter,
hiding from the projected flow of mail that will produce. Every day more and
more people are sending me emails saying they're in on this and after the new
posts, there will (hopefully) be a lot more. When we have enough support to
say 'okay, let's take on the task' then we can decide on what interface
(-library) to use, which we eventually incorporate in the new KS of course.
CH> I've scanned through the AmiNet and found replacements for most of the
CH> system tools. The only problems with them is that they don't exactly
CH> work like the ones from C=. If the authors of them would just make
That's no problem in its own right. They don't have to work exactly like the
ones from C=, they should just work /alike/. Use the same look & feel, the
same general lay-out and approach, etc. Prefs editors, for example, don't even
HAVE to be downwards compatible ; if you rewrite IPrefs, that problem will be
solved.
CH> them work exactly like the ones from C=, compile them with "Contributed
CH> to PD WB by <name>" in the embeded copyright strings, included source
CH> and a small man file. The man file should be formatted like in the
^^^^^^^^
and in AmigaGuide format, of course.
CH> I do think that some other utilities (without source when the author
I personally think having the source with it is very important, because we
should be able to adapt the WB software to new evolutions in the other parts of
the OS. Not to mention porting it to another platform. But I agree that if
the choice is between software without source and no software at all, then in
nine out of ten cases we should chose software.
CH> requires it to be private) should be included with it, if their
CH> respective authors would allow it. XPK, Term, XPR, XEM, ReqTools, and
I had thought XPK in the role of a DoubleSpace-inspired system, with its own
standard Prefs editor and so on. I don't know if you've heard of Disk Expander
(a UK product), but that's basically a graphical front-end to the XPK
libraries. Something like that would be a doddle to make.
As for Term, I don't know. It's a great program and I use it myself on the
rare occasions that I still connect to a BBS on-line with great joy, but it's
also rather, well, bloody huge. It's got about three million options, which is
great for people who want to be able to customize everything (me :-), but not
something you bundle with an OS. You said it yourself, it would involve XEM
and XPR libraries to go with it etc., etc. I'm sure we can offer a
readily-installed version of term separately, that is fit to be used with our
WB, but I'd keep it separate.
CH> other non-disabled tools should be included in the base PD WB disks. It
CH> would be nice if Lha & Zip were contributed to it also. The only
CH> problem is Lha, which is partially disabled. Most of the above is
CH> standard on most Amiga users systems.
Maybe we can talk Stefan Boberg into making a basic, no-frills, FreeWare
version of LHA to go with the system ?
CH> In a new system, you wouldn't need Toolsdaemon because it's functions
CH> could be designed into the new Workbench. Imagine Workbench with
Er...that's what I meant, really :-) The same with KingCON ; we just replace
the CON-Handler with the KingCON handler and we add the possibilities of
Toolsdaemon to the WB menustrip. The Toolsdaemon prefs editor (gee, I keep
talking about prefs editors today :) is something we could keep, though.
G'bye then,
/|/| ___ /|/|
/ / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
AM> Ah! A very nice idea indeed. But if a new OS is going to happen, we
So er...we can count you in ? :-)
AM> should try to make this thing as universal as possible. For one I think
AM> it might be a good idea to separate the software completely from
AM> hardware. And guidelines like the Mac!
That is indeed the line of thinking we have taken. The plan is to choose a
standard look and feel (nobody knows for sure what it's going to be like, but
everybody has a preference and the trick is to combine all those into a design
layout) and make all programs conform to that.
AM> Here are a few suggestions, they are very forward, but hey! Do it good
AM> or don't do it at all!
We sure wouldn't be wasting our time, so you're damned right we're going to get
it right :)
AM> - intermediate code: do not write for a real CPU, but a virtual one.
AM> Write small and fast runners for the actual CPU's.
The plan so far is to write the main chunk of the OS in a common language, most
likely GNU C++, that is easy to port. Then, when we really start porting,
hardware specific bits will be coded in assembler for the specific platform, to
get the best speed.
AM> - object orientation of the OS: hardware and services are delivered by
AM> objects.
AM> If the hardware exists then it is used, if not it can be emulated.
AM> The
AM> application does not have to know.
AM> The user chooses which service-class is installed.
Hmmm, good idea, I hadn't thought of that. My only fear is that a lot of time
and effort will be spent on writing the emulations. For example, a DSP
emulation.
AM> - Use existing standards, for example SCREEN IO in postscript.
Standards is what it's all about these days. It would be stupid to introduce
new, proprietary data formats, which would only stand in the way of the
integration and acceptation of our OS.
AM> UNIX was started as a public domain OS. Maybe we can initiate something
AM> simular. But before that can happen, a structure must be defined in
AM> which the creativity of all programmers can be integrated conform specs.
AM> This structure does not, in my opinion, has to take hardware limitations
AM> into account, because this will catch up. It should be OPEN.
This is what will happen. As soon as enough support has been gathered, the
coordinating committee (also being formed) will mould all ideas, suggestions,
designs, existing bits of programs we can use, and so on into one such
structure.
Maarten Ter Mors
about Re: Amiga OS ? Let's do it ! too !
> : Unless I forgot something very crucial, in which case you must remind me
> at : once, this is about it. We can use the support of everybody, as long
> as he or
TRB> Just that system specification, analysis and design will take up more
TRB> time than programming. Coordination will be a nightmare, but good luck.
Coordination may not be easy, but it must surely be a very stimulating task, to
see all the pieces come together one by one, eventually forming a complete
system. And if the task should grow over our heads, we will just have to make
sub-committees for analysis, etc.
Maarten Ter Mors
about Re: Amiga OS ? Let's do it ! too !
> : Anyone want to jump in on this also? I know a unix programmer that has :
> showed some interest in it.
BM> Before you start coding you have to do planning and layout. You won't
BM> be coding for quite some time yet.
We are aware of the fact and planning WILL be our first step. I'm sorry if I
gave the impression to want to charge into this like a loose bull with my post,
this will not be the case. For one thing, I don't make a very convincing bull
;-)
> : : 1.1) LANGUAGE.
> : The best choice right now is GNU C because it's available on most :
> platforms. We need the ability to cross compile it on different machines.
BM> How about stick with just Ansi C? Don't some programs compiled with
BM> GCC (amiga version) require a library at run time? If not, go for it.
Not anymore, I thought, or else only if you used the stdio features (correct me
if I'm wrong, GNU C programmers), which will not be in an OS anyway.
> : : 1.2) LICENSE.
> : It should be modeled on the GNU license. Except that the group should :
> have control on who distributes it to keep it intact. Some money from :
> commercial distribution should go to help with administration costs.
BM> Hmm, is this going to be free or not? If not then anyone who
BM> participates will want to be paid.
It will have to be free, I think. It would be a task that's nigh on impossible
to let everyone have the money that he deserves, especially because in whatever
project, there are always people who do more than others and, to be fair,
should be paid in the same proportions. But since that is impossible to
measure, it's got to be free and nobody will get anything.
> : : 2) COORDINATION.
> : Again, I can help with this part.
BM> What do you think will be the time frame for all of this? Will it be
BM> completed in one year, two? Will the amiga be a player then? Or is
BM> this an amiga project at all?
Shall I tell you the truth ? I really don't know. The replacement WB Chris
was talking about could be done by summer and perhaps we could have a really
basic OS done before the year is out, but on the other hand it may take half or
twice that time. I really don't know. But the point is to build our own
Amiga-like OS, so that by the time the Amiga is no longer a player
hardware-wise, we can just carry on to newer hardware and take the OS with us.
Jeff Qualls
would suggest a totally new OS that is merely inspired by AmigaOS
rather than an improved clone of AmigaOS. Of course, this new OS should
run on current Amiga HW.
I wouldn't even mind if much software would no longer work if some
of the major players on the Amiga (NewTek and Softwood in particular)
were involved in some way and agreed to recompile (if that is all it
would take) their code for the new OS.
If C++ or C, preferably C++, is to be the language, and if it is to
be a really new OS, then I would lend my help. I am a rather good
programmer, but would rather help in initial design activities.
Jeff Qualls
Naarok
> Subsequently, the coordinators put their heads together through email/telephone
> contact/IRC chat/whatever and, after a number of hours' hard work, come up
> with a detailed proposal, outlining exactly what we want to achieve. This will
> be posted to the mailing list and the developers have another chance to
> respond. With their input, the coordinators update their plan accordingly and,
> unless there are real objections, that second version will be the storyboard
> for the new Amiga OS. It's only then that we start to write the code.
This idea sounds intriguing, and I'd be willing to support both Coordination
and programming. But I think there might be some misunderstanding of the scale
of this project. The comment that a detailed proposal could be had after a
number of hours of hard work is a fantasy. I've gone through producing some
Software Requirements Documents. As an example a group of five people working
diligently in the same room for 6 hours a day took a week to come up with a
specification of a much smaller project. With this, where it is unlikely
people will be face to face (ie. no drawing on blackboards to illustrate your
point), with hundreds of suggestions for things to do coming in. The time
frame will be more like 6 hours a day for a month.
--
He meant well, John Zittlau
or at least, Zit...@bode.ee.ualberta.ca
He meant something!
Soenke Tesch
: Frank Meijer (mei...@bnr.ca) wrote:
: : I probably missed the beginning of this thread, so flame me if
: : you want, but why bother about a new OS when the future of the
: : hardware itself is still far from sure?
:
: That is just one of the questions that the group proposing this
: needs to answer. There are as many answers right now as there
: are people willing to get involved.
A new OS could hide the hardware completely from the software. OK, AmigaOS
already does this, but the new OS should do it on a _very_ low level to also
allow games to use these interfaces.
bye, Soenk.e
Soenke Tesch
: : JH> From: jr...@space.honeywell.com (Jeff Hildebrand)
: : JH> I wouldn't mind getting involved to the level of helping people
: : JH> coordinate and clarifying my ideas of development (to whatever extent
: : JH> it helps). But I'm in a grey area as to what my employer allows me to
: : JH> do, programming wise, so I would avoid that just to be safe...
:
: : up to three.
Four. Add me too!
bye,
Soenk.e
btw: How many ppl did they have 198? at Amiga Inc??
Chris Hall
: Maybe because not everyone likes UNIX?
: Personally, I'd rather have AmigaOS than UNIX any day of the week. The
: Amiga OS is small, fast, and has lots of features. It would be nice to
: have a few changes, but there are several UNIX things I would HATE to
: see in there, the least of which is that ?#*&#^ case-sensitive naming...
I hate that on unix. Another thing I want to keep is the Amiga's pattern
matching convention. It should be built into the shell but it's much
better at discribing what files you want or don't want.
Chris Hall
Cedric Beust
: What's the difference between
:
: foo.c
: foo.C
: Foo.c
: FOO.C
:
: ?
:
: On the Amiga, none. On UNIX, those are 4 separate files...
This is a feature, not a bug :-)
If you want to compare Unix and AmigaDOS, this is the wrong
place to start with, IMHO. I don't like the Amigados mixed case
behavior, it reminds me too much of MS-DOS (e.g. : port all your
.C C++ files to AmigaDOS and suffer).
Furthermore : smart shells will make this transparent with the
TAB completion... I don't see a real interest in preserving the
case if it is ignored by the system (worse : it is not
completely ignored, try to open "Graphics.library"...).
Something to remove if ever a future OS sees the day.
Cedric
Jean-Alexis Montignies
: If you folks who wish to make a new OS really start doing it, then I
: Jeff Qualls
I agree with you, a brand new OS would be nice, with keeping some advantages
of the amiga OS: fast, very efficient task switching (nearly real-time),
Another characteristic of the AmigaOs is that it is customisable, noother
system has so many parameters the user can adjust, or so many tools the
user can add to the system to change some behaviours.
The file systems are good also (compared to unix ones)
One thing i'd like to have in this new system is object technology. I think
it is the tendencies for the following years, everybody is going objects.
NextStep was the first and it is great but is too heavy, based on Unix
and not enough customisable.
I'd like that a really object oreinted language such as SmallTalk, Eiffel,
or (my preffered one) objective-C was used for this new OS.
Jean-Alexis
MetalReign
:diligently in the same room for 6 hours a day took a week to come up with
a
:specification of a much smaller project. With this, where it is unlikely
:people will be face to face (ie. no drawing on blackboards to illustrate
your
:point), with hundreds of suggestions for things to do coming in. The time
:frame will be more like 6 hours a day for a month.
You could scan in drawings and tag them to your messages.
Christopher Naas
>PS: I have started rewriting Intuition, but without a new
>layers/graphics/gadtools/prefs/datatypes etc. this will
>be a joke.
I am *very* interested in this project, but alas, if all correspondance is in
German I will be unable to do anything. My knowledge of German is very
limited.
__ __
/_ /_ /\ Christopher Naas · Amiga Developer · Fusing the clear threat! ·
__/__//_/ EMail: chri...@powertech.no · Amiga 4000/040 Black Tower ·
Jon M. Taylor
Matthias Meixner <mei...@rbg.informatik.th-darmstadt.de> wrote:
>Jon M. Taylor (tay...@ecs.ecs.csus.edu) wrote:
>: Um, maybe I'm missing something here, but why not just help out
>: with the Amiga Linux port instead of starting from scratch? Linux is
>: quite a bit better than even the Amiga's OS in many respects. It can
>
>It lacks many features of the Amiga OS and it is too complicated for the
>average user.
I don't consider Unix to be any more complicated than AmigaDOS.
I suppose it depends on what you are used to.
>It is missing:
>- multiple Screens
It is on the PC, because the GFX hardware there does not do
display coprocessing. However, there is no reason why this could not be
added to the Amiga Linux. It is *not* going to be a stright port of PC
Linux (though it pretty much is now). The Linux people are aiming for
more and more device/system-independence, primarily done throught the
/dev directory. In principle, every bit of hardware on the Amiga should
be useable by Amiga Linux in at least the same way as the current Amiga
OS uses it.
>- ARexx (Rexx)
I recall seeing mention of a REXX for Linux out there somewhere.
If not, there certainly is a UNIX REXX in existence, and porting should
be fairly easy. I prefer Perl, but to each his own.
>- locale
I'm not entirely sure about what this is (dodges flames). If it
is an "internationalization" option, that is being added to Lunix as we
"speak".
>- assigns
>- shared.libraries (OK, it may come with dynamic link libraries, but with these
> it is not possible to change the linkage on runtime, what is used e.g. by
> the xpk-package:
I believe that ELF will givs this capability. Already there (on
PC Linux, anyway).
>- preferences
?? not quite sure what you mean here... if you are referring to
being able to change system configuration via a program, Linux has
considerably more of that than AmigaDOS does.
>- different file-systems
Already there.
>- devices
The /dev directory is supposed to hold a "device file" for
everything on the system. On the PC, you can access the serail and
paralell ports, display (text and GFX), disk, tape, CDROM, network,
mouse, keyboard, joystick, et. via this directory. It may not be there
yet on the Amiga Linux (as I recall, they are developing off an older
verion of PC Linux), but in principle you could do everything that the
devices.library does with this.
>
>And it was never meant to write a new operating system for the existing amigas,
>but for another platform. And this OS should be source-code compatible
>(up to a certain degree) with the other amigas, that you should be able to just
>recompile your sourcecodes for the new machine.
Hmmmm... frankly, I wouldn't count on a major hardware shiftt for
at least a couple of years. Also, I don't understand the urge to
recreate The Amiga OS. It's certainly nicer than Windows or even OS/2 in
many ways, but it really is not a modern OS. It has no MP or VM, and
those are 2 of the three things (MP, VM and preemptive multitasking) that
any OS should have nowadays. I like the Amiga, but the OS is too
nonstandard and archaic for me.
>(At least this is my understanding of writing a new "Amiga-compatible" OS).
If people have written decent code, portability should not be a
big deal under Amiga Linux. A decent massager to convert library and
device references would take care of most of the problems.
Hardware-banging code would not port anyway.
[ Soapbox mode ON ]
I guess I am biased here. I really like Linux and I like what it
stands for - an OS written not to sell hardware or advance propriatary
ideas, but simply to do the job of an OS in the best way possible. There
are attempts underway to port Linux to just about every platform in
existence (SPARC, Amiga, Atari ST, Alpha, RS3000, 680x0 Macs, PPC macs,
VAX, PA-RISC are the ones I know of). I would hope that the Amiga
community could help advance the free-OS movement and the
platform-independence of Linux. If you see something in the Amiga OS
that you don't see in Amiga Linux (screens, copper, etc), pitch in and
help code the support for it!
[ Soapbox mode OFF ]
-Jon
Michael van Elst
>- multiple Screens
it has RTG and multiple screens. It does not have draggable screens.
>- ARexx (Rexx)
>- locale
>- assigns
environment variables can do the same.
>- shared.libraries (OK, it may come with dynamic link libraries, but with these
> it is not possible to change the linkage on runtime, what is used e.g. by
> the xpk-package:
of course it is possible.
>- preferences
lots of preferences.. no special GUI editor for these though.
>- different file-systems
It has quite some filesystems: MinixFS, LinuxFS, FAT-FS, Iso9660, ...
>- devices
Of course it has device drivers, even run-time loadable ones.
Regards,
--
Michael van Elst
Internet: mle...@mpifr-bonn.mpg.de mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
FM> From: mei...@bnr.ca (Frank Meijer)
FM> I probably missed the beginning of this thread, so flame me if you want,
FM> but why bother about a new OS when the future of the hardware itself is
FM> still far from sure?
Well, actually, that's just the point :-) The OS is the Amiga's main feature
these days : while the hardware is still very nice and good enough for most
people today (including myself), it's not up there with the absolute top in
technology anymore and, to all likelihood, it won't be for some time, maybe not
ever (sob).
But even if the hardware goes down, we would still have the OS, the OS we
rewrote ourselves and of which we have all the source availible. We could port
this to a different hardware platform, recompile all the old software (and
leave the door open for new programs, of course) and pretend nothing ever
happened.
Chris Hall
: Hmmmm... frankly, I wouldn't count on a major hardware shiftt for
: at least a couple of years. Also, I don't understand the urge to
: recreate The Amiga OS. It's certainly nicer than Windows or even OS/2 in
: many ways, but it really is not a modern OS. It has no MP or VM, and
: those are 2 of the three things (MP, VM and preemptive multitasking) that
: any OS should have nowadays. I like the Amiga, but the OS is too
: nonstandard and archaic for me.
: I guess I am biased here. I really like Linux and I like what it
: stands for - an OS written not to sell hardware or advance propriatary
: ideas, but simply to do the job of an OS in the best way possible. There
: are attempts underway to port Linux to just about every platform in
: existence (SPARC, Amiga, Atari ST, Alpha, RS3000, 680x0 Macs, PPC macs,
: VAX, PA-RISC are the ones I know of). I would hope that the Amiga
: community could help advance the free-OS movement and the
: platform-independence of Linux. If you see something in the Amiga OS
: that you don't see in Amiga Linux (screens, copper, etc), pitch in and
: help code the support for it!
If you like Linux, great, you don't have any problems because it's
portable. Some of us like the Amiga's native OS and thing the same thing
about Linux being archaic and wouldn't want to use it or other OSs. We
want a portable Amiga like OS, something that we feel at home with.
There is room for more than one OS out there.
Chris Hall
Chris Hall
: I agree that we need an OS that it would be _easy_ to add TCP/IP to, but I`m
: not sure it's a good idea to have it built in. TCP/IP over SLIP or PPP hogs
: resources, and many users won't need it. But what we ought to add, is a
: standarized network interface that easily could acommodate both TCP/IP and other
: network protocols. Perhaps we could even manage to hide the network protocol
: totally from the applications...
TCP/IP is the network. SLIP & PPP are just methods of hooking computers
to host machines via serial (dialup) interface to allow them to exchange
IP packets with other machines on the net.
It will be important to include TCP/IP with a future version of it but I
dought it will be in the early versions. It would be nice if AmiTCP could be
included in the system but I can't see that happening since it's
commercial now.
Does anyone know of some programmers that are working on a freeware Amiga
TCP/IP package that could be included with the new system?
Chris Hall
Chris Hall
: Even 6 hours a day for a year is better than watching those funny people at
: C= UK and CIS (?) bidding for the Amiga for the next 10.000 years..
ABSOLUTLY! Is this bidding war ever going to end? Do the liquidators
actually want to sell Commodore's assets? I'm not going to hold my breath!
Chris Hall
Chris Hall
: If you folks who wish to make a new OS really start doing it, then I
: would suggest a totally new OS that is merely inspired by AmigaOS
: rather than an improved clone of AmigaOS. Of course, this new OS should
: run on current Amiga HW.
We need source code to start with. If we replace parts of the current OS
first, we will build up that library of fully tested and debugged code to
work from. After that, starting the new OS (Tejas) would be much
easier.
: I wouldn't even mind if much software would no longer work if some
: of the major players on the Amiga (NewTek and Softwood in particular)
: were involved in some way and agreed to recompile (if that is all it
: would take) their code for the new OS.
The need for commercial code to be recompiled would be a little down the
road but I'm sure when we port to another processor, they will.
: If C++ or C, preferably C++, is to be the language, and if it is to
: be a really new OS, then I would lend my help. I am a rather good
: programmer, but would rather help in initial design activities.
It will be a new OS, we will just have to take the development in stages
to get it finished. If we jump into it all at once, the project will
probably never get done but if we work for a number of smaller goals, it
will be more likely that the smaller stages will get finished.
There will be a major about of inital design that needs to be done while
the system disks are being replaced. A number of things need to be
desided on to choose the right direction that we want to go in so that we
don't put faults that are in the current AOS, in the new one.
One thing we need to deside at first is; "Do we want to replace most of the
current libraries or write new ones that will coexist with them and write
path libraries to redirect old lib calls to the new ones?". A few good
examples:
ASL, should we try to get Nico Francois to add ReqTools to the
project and just write a small ASL.library to redirect the calls to ReqTools?
Also, Workbench and the icon.library, should we just write a new desktop
system? Again with patches to allow old programs to work with the library
calls.
Chris Hall
Chris Hall
: Think of it this way: All tools which create programs for the new OS
: actually create code for a pseudo-CPU, call it CPU-X. Then, on each of
: the machines this new OS runs on, the program loader (equivalent to
: LoadSeg() in AmigaDOS) needs to actually be a translator as well as a
: relocation engine. It would not only move the file from a filesystem to
: RAM, but it would also translate from CPU-X code into the native
: processor code.
: Personally, I would *much* rather see this approach taken than most of
: the others possible. I've seen this done in various manners, such as
: having a Linker on the target machine that does the translation once,
: but unless the LoadSegAndTranslate() function is really too slow to be
: usable, I'd rather not even have that extra step of having to Link a
: program. I'd rather just pop the disk in and run the program, and not
: care that I'm using my Amiga with a 68030, but the program was written
: on a PowerPC based system...
This is definitly the best way to go. Although it can be added at a later
time because you can change the language compilers to compile to the
CPU-X code. LoadSeg could be patched at a later date also. The
LoadSegAndTranslate() function wouldn't really be that slow on faster
processors but on slower processors, you could have the installer program
handle the translation. Another advantage is that object codes is much smaller
than linked code, so distribution archives will be smaller.
Chris Hall
Chris Hall
> Wouldn't it be a good idea for everyone involved in the project to email the
> author(s) of their favourite bit(s) of system replacement, asking them to
> either join the team or at least donate their sources to the good cause ?
Yes, it would.
> I think we should start on the new OS as in Kickstart and the new OS as in
> Workbench at the same time. As you stated, not much manpower is required to
> put the best bits & blobs of PD together to make a new workbench. Things like
> the prefs editors (for which there are no substitutes in the PD to my
> knowledge) and the datatypes would have to be programmed additionally, but
> that's relatively simple.
I'm sure there would be some programmers that are only interested in working
on the kickstart bits.
> However, first of all we need to know exactly what we're doing. As you will
> probably have noticed by now, I reposted the original 'Amiga OS ? Let's do it
> !' article to many other groups and my sysop's now down in the bomb shelter,
> hiding from the projected flow of mail that will produce. Every day more and
> more people are sending me emails saying they're in on this and after the new
> posts, there will (hopefully) be a lot more. When we have enough support to
> say 'okay, let's take on the task' then we can decide on what interface
> (-library) to use, which we eventually incorporate in the new KS of course.
Hopefully your sysop lets you stay involved. :)
> That's no problem in its own right. They don't have to work exactly like
> the ones from C=, they should just work /alike/. Use the same look & feel,
> the same general lay-out and approach, etc. Prefs editors, for example,
> don't even HAVE to be downwards compatible ; if you rewrite IPrefs, that
> problem will be solved.
The shell based commands need to work the same because of existing scripts.
Everything else wouldn't be a problem if it was different.
CH> them work exactly like the ones from C=, compile them with "Contributed
CH> to PD WB by <name>" in the embeded copyright strings, included source
CH> and a small man file. The man file should be formatted like in the
^^^^^^^^
> and in AmigaGuide format, of course.
You can reference a plain text file from an AmigaGuide document. One click
and the user is looking at the man file.
Speaking of AG, a node crunched AG system would be nice. The viewer would
just decrunch the current node. That would same HD space and memory.
Gfx (structured and bmap) support would be nice also.
> I personally think having the source with it is very important,
> because we should be able to adapt the WB software to new evolutions in
> the other parts of the OS. Not to mention porting it to another platform.
> But I agree that if the choice is between software without source and no
> software at all, then in nine out of ten cases we should chose software.
Source is the most important part of the project.
> I had thought XPK in the role of a DoubleSpace-inspired system, with its own
> standard Prefs editor and so on. I don't know if you've heard of Disk
> Expander (a UK product), but that's basically a graphical front-end to the
> XPK libraries. Something like that would be a doddle to make.
I haven't seen Disk Exp., is it a commercial product? I would like to see
direct support in the dos.library for a xpk like compression system. Imagine
having Amiga files wrapped up in a cross between a xpked and IFF file.
> As for Term, I don't know. It's a great program and I use it myself on the
> rare occasions that I still connect to a BBS on-line with great joy, but it's
> also rather, well, bloody huge. It's got about three million options, which
> is great for people who want to be able to customize everything (me :-), but
> not something you bundle with an OS. You said it yourself, it would involve
> XEM and XPR libraries to go with it etc., etc. I'm sure we can offer a
> readily-installed version of term separately, that is fit to be used with our
> WB, but I'd keep it separate.
Some kind of terminal needs to be included with the first release. I just
suggested term because it was the first that came to mind.
> Maybe we can talk Stefan Boberg into making a basic, no-frills, FreeWare
> version of LHA to go with the system ?
Actually, I've had a idea about an archiver system. A modular archiver system
would be awesome for this package. Something like xpk except that is supports
existing archivers for compatibility and has it's own structured archive
format that allows different compression libraries just the way XPK does.
I've see that someone is using xpk for archives now but I haven't found all
the support files yet.
Chris Hall
59532-Richard M Brack(CB2008)000
Michael van Elst <mle...@specklec.mpifr-bonn.mpg.de> wrote:
>In <3g5qsi$1...@rs18.hrz.th-darmstadt.de> mei...@rbg.informatik.th-darmstadt.de (Matthias Meixner) writes:
>
>>- assigns
>
>environment variables can do the same.
but they don't show up in things like file requestors...
Rich...
r...@hercules.att.com
Stefan Payment
to write something under the subject "Re: Amiga OS ? Let's do it !"
this is what I think about it :
CN> >PS: I have started rewriting Intuition, but without a new
CN> >layers/graphics/gadtools/prefs/datatypes etc. this will
CN> >be a joke.
CN> I am *very* interested in this project, but alas, if all correspondance is in
CN> German I will be unable to do anything. My knowledge of German is very
CN> limited.
well. in this case I could help maybe in doing translations from
german to english and vice versa
would delay stuff for a day or so but better than not understanding it at
all ;-)
--
Take Care
Stefan
--------------------------------------------------------------------------
E-Mail:Les...@Fishtwn2.han.de|Realname:Stefan Payment|Voice:+49 4721 65077
runnin on AMIGA1200/030/882/50/2C/6F/428HD/SCSI2 but who cares ? ;-)
--------------------------------------------------------------------------
Stefan Payment
to write something under the subject "Re: Amiga OS ? Let's do it !"
this is what I think about it :
MM> but for another platform. And this OS should be source-code compatible
MM> (up to a certain degree) with the other amigas, that you should be able to just
MM> recompile your sourcecodes for the new machine.
MM>
MM> (At least this is my understanding of writing a new "Amiga-compatible" OS).
jepp but it still should run on Amiga's ehh ? ;-) (I mean existing
ones)
SCNR
--
59532-Richard M Brack(CB2008)000
Chris Hall <ch...@clover.cleaf.com> wrote:
>
>Speaking of AG, a node crunched AG system would be nice. The viewer would
>just decrunch the current node. That would same HD space and memory.
>Gfx (structured and bmap) support would be nice also.
I'd say drop AmigaGuide in favor of HTML. Then develop an HTML IFF standard
so all the HTML files in a document, plus any graphics, sound, etc. can reside
in one physical file. Then maybe this IFF standard can spread to other
platforms since it would be easier to distribute on-line help and documentation
as one file instead of the many that HTML requires now. HTML already provides
more than AmigaGuide, there's no need to re-invent it.
Of course we will also want an AmigaGuide reader for compatibilty reasons...
Rich...
r...@hercules.att.com
Per Jacobsen
> : 1.2) LICENSE.
> It should be modeled on the GNU license. Except that the group should
> have control on who distributes it to keep it intact. Some money from
> commercial distribution should go to help with administration costs.
It should also be readable! I've tried several times, but I get a
headache after the first few lines :)
> I suggested Tejas (Native American for Friend) at the start of other thread.
One problem would be pronunciation difficulties, Amiga is rather simple,
but how do you pronounce Tejas?
J as an H, or D (or the real J sound, ie mine ;)
Per Jacobsen
> CH> 680x0 mach would be good for that. Mach has most of what we are looking
> CH> for in a OS, we could adapt it to fit the Amiga library system.
> I'm not familiar with Mach (the first time I heard about it was less than a
> week ago in this very thread),
Since I'm assuming you are not talking about the Mac(intosh) what is Mach?
> > : Oh, we need a name :-) Actually I liked Phoenix, but I think there's a
> > clone : BIOS by that name. Any ideas ?
How about calling it Miner instead? :-)
> CH> I suggested Tejas (Native American for Friend) at the start of other
> CH> thread.
> Hmmm, keep it in the nomenclature of Amiga, you mean ? Well, to be honest with
> you, Tejas reminds me of Taos, the place Marshall Sam McCloud came from (if you
> don't know what I'm talking about, don't worry - I always watch ancient series
> on TV :)
What! Sam McCloud is a classic! In fact let's call it McCloud ;)
>... and it looks like 'Texas'. Nothing wrong with Texas, but people will
> think it a strange name for an OS until they see it's actually Tejas, after
> which they will say 'Hmm, what does that mean ?'
> I like the way it connects to 'Amiga' though. But meanwhile, how
> about...er...Laura ? We don't have a custom chip by that name yet, do we ?
Or Carolyn after the the old stalwart Mrs. Scheppner :)
Per Jacobsen
Writes to all? Ah, a fidonet user :)
> BC> Your first point should have been philosophy/goal. Your reason for
> BC> making a new OS may be completely different from anybody else's. Most of
> I thought the goal was pretty much outlined in the previous discussions, but
> maybe I was wrong. The spirit is 'if nobody's going to resurrect the Amiga,
> let's do it ourselves !' Amiga users are generally a very devoted bunch and
> they would hate to see their favourite machine go down the drain. Especially
> for serious applications, the OS is what makes the Amiga the machine it is -
> and that can be saved.
But that's not nearly enough! There are a lot of things regarding
input/interface and general design, which has to be agreed on. What is
it supposed to look like? Some people like the look of Scala/Infochannel
I personally hate it, it looks like a box of sweets and is not style
guide compliant. Some like MUI others hate it.
How difficult should the interface be for the user? Some people love
Toolmanager because it offers many things, others are running away
screaming because it's too complicated. The Macintosh simply has a drawer
on the disk, any program you drop into it, appears in the menu.
Do we want that kind of userfriendly ness or is it aimed at unix nerds,
do we require the user to understand 5000 cryptic keywords and oddly
formed manuals?
> BC> the new developer's group's discussions about how you should implement a
> BC> new feature will change in a flamewar about why you should implement
> BC> something. Amiga and Mac both have OSes with a very strong (and good)
> BC> philosphy behind them, that's why I like these computers.
> I'm not too afraid of flame wars.
Be afraid, be very afraid! :)
> It's not like someone's going to say : 'We do it this way and no
> differently.', but everyone will have his or her say and
> if a new feature is to be implemented, we can discuss that like adults.
How nice, naivety still exsists! :-)
Of course the will be arguments about the implementation over different
things, possibly even flame wars. *Especially* if everything (or much)
has been agreed upon before the start. Other wise many people will start
work, all of whom may have slightly different goals, and when they learn
that the project is going in a different direction, it may very well piss
them off.
In many ways a newsgroup dedicated to the design goal creation might be a
good idea. The coordinators could comepose a lenghty design FAQ over a
(long) period of time before actuall programming began.
Per Jacobsen
> Also , and I know how big a change this will mean to exec, it HAS to have
> memory protection and TCP buitin. Also full RTG posibly like X11.
> I know the memory protection will cause a problem on 680ec30 and below but
> the OS needs it, even if it is only as an option.
So here is the first argument, why does it need TCP built in? Waste of
space if you ask me.
Per Jacobsen
> In article <Maarte...@aobh.xs4all.nl>,
> Maarten Ter Mors <Maa...@aobh.xs4all.nl> wrote:
> >I don't want to come up with a detailed
> > proposal that has taken hours of work, only to
> >find we only have five dedicated programmers to carry it all out.
> Don't underestimate what can be done by five dedicated people. Linux was
> written by *one* programmer, Linus Torvalis (sp?). The original Amiga OS
> (without DOS) was written by *two* people (one on Exec and one on Intuition).
And remember Matt Dillon, didn't he used to turn out a new OS every two
weeks? ;-)
Per Jacobsen
> In article <D2yv7...@unx.sas.com> ja...@cdevil.unx.sas.com (James Cooper) writes:
> : What's the difference between
> :
> : foo.c
> : foo.C
> : Foo.c
> : FOO.C
> :
> : ?
> :
> : On the Amiga, none. On UNIX, those are 4 separate files...
> This is a feature, not a bug :-)
But it bugs most of us :)
Per Jacobsen
> In article <3g6tif$j...@clover.cleaf.com> ch...@clover.cleaf.com (Chris Hall) writes:
> >James Cooper (ja...@cdevil.unx.sas.com) wrote:
> >
> >: Maybe because not everyone likes UNIX?
> >: see in there, the least of which is that ?#*&#^ case-sensitive naming...
> >
> >I hate that on unix. Another thing I want to keep is the Amiga's pattern
> >matching convention. It should be built into the shell but it's much
> >better at discribing what files you want or don't want.
> I don't think that the best place for globbing is in the shell - it
What is globbing?
Per Jacobsen
> CH> requires it to be private) should be included with it, if their
> CH> respective authors would allow it. XPK, Term, XPR, XEM, ReqTools, and
> I had thought XPK in the role of a DoubleSpace-inspired system, with its own
> standard Prefs editor and so on.
What would the access overhead be if you don't want to use a compression
scheme at all?
> As for Term, I don't know. It's a great program and I use it myself on the
> rare occasions that I still connect to a BBS on-line with great joy, but it's
> also rather, well, bloody huge.
That's putting it mildly :) It's also bugged or ... I don't know the term
(if you'll forgive the pun) flawed. If I use NComm to download something,
I can enjoy my multitasking computer, doing other things. Writing
something, accessing my disk, I have been compiling stuff and read mail
at the same time! And it does not affect my downloading, buf with Term(!)
if I cough it repots hardware errors and what ever else it can think of.
> It's got about three million options, which is great for people who
> want to be able to customize everything (me :-),
And me! I have yet to be able to do something as simple as sending an
ascii file, works fine in NComm, but just messes us the screen with term.
Of course there are 500 different things which need to be adjusted in term.
> ... but not something you bundle with an OS.
Well, perhaps it would be nice to have an ultra small program, hardwired
for Zmodem/Xmodem/VT102 and thats it. If the user gets interested (the
new users!) the could always download other programs.
> CH> other non-disabled tools should be included in the base PD WB disks. It
> CH> would be nice if Lha & Zip were contributed to it also. The only
> CH> problem is Lha, which is partially disabled. Most of the above is
> CH> standard on most Amiga users systems.
> Maybe we can talk Stefan Boberg into making a basic, no-frills, FreeWare
> version of LHA to go with the system ?
I think he has dropped it, hasn't he? But what about the algorithms in
the program? Are they free?
> Er...that's what I meant, really :-) The same with KingCON ; we just replace
> the CON-Handler with the KingCON handler and we add the possibilities of
> Toolsdaemon to the WB menustrip. The Toolsdaemon prefs editor (gee, I keep
> talking about prefs editors today :) is something we could keep, though.
Did you read my other message about the mac menu drawer? (Good Q, I'm
talking a lot about Macs today :)
If we emulate that, it would mean we have a drawer on the boot
partition WBMenu (perhaps in WBStartup) and any program which is dragged
into that drawer appears in the menu strip. With file notification there
is constant opdate.
This works fine on the Mac, and the user doesn't have to fight with a
config interface.
But, the amiga user says, I don't want to move my programs to that drawer!
Well they use links, and so could we. Dave Schreibers small, but
excellent, WBLink does that. Select a program icon, select make link from
the workbench and a new icon appears next to the original icon, its name
is "Link_To_<name>" then you just drag the link to "WBMenu".
Sounds simple enought, doesn't it?
the Edward Blevins
: > I thought the goal was pretty much outlined in the previous discussions, but
: > maybe I was wrong. The spirit is 'if nobody's going to resurrect the Amiga,
: > let's do it ourselves !' Amiga users are generally a very devoted bunch and
: > they would hate to see their favourite machine go down the drain. Especially
: > for serious applications, the OS is what makes the Amiga the machine it is -
: > and that can be saved.
: But that's not nearly enough! There are a lot of things regarding
: input/interface and general design, which has to be agreed on. What is
: it supposed to look like? Some people like the look of Scala/Infochannel
: I personally hate it, it looks like a box of sweets and is not style
: guide compliant. Some like MUI others hate it.
: How difficult should the interface be for the user? Some people love
: Toolmanager because it offers many things, others are running away
: screaming because it's too complicated. The Macintosh simply has a drawer
: on the disk, any program you drop into it, appears in the menu.
: Do we want that kind of userfriendly ness or is it aimed at unix nerds,
: do we require the user to understand 5000 cryptic keywords and oddly
: formed manuals?
Through appropriate design this could become a non-issue. Even with the
current Amiga-OS, one could theoretically plug in a few libraries and
a WB replacement, then have a completely new interface while still using
AmigaOS. The modularity of design is one of the many things that makes
the Amiga worth imitating in the first place. Right now, it is possible,
but not really feasible. With foresight however we could plan easily to
allow for different GUI's and different CLI's. We know when it comes to
GUI that the Amiga is not as good as it gets, but we like it in spite of
that. If everyone could have the AmigaOS, with their "perfect" interface,
then we could all be happy. We would have to set some constraints , based
on what would "play well with others", but I don't think it would have to
be anything truly style cramping. Why not pave the road for a VR interface
to the OS in the future? The interface can change while still preserving
the "heart" of the OS.
: > It's not like someone's going to say : 'We do it this way and no
: > differently.', but everyone will have his or her say and
: > if a new feature is to be implemented, we can discuss that like adults.
: How nice, naivety still exsists! :-)
: Of course the will be arguments about the implementation over different
: things, possibly even flame wars. *Especially* if everything (or much)
: has been agreed upon before the start. Other wise many people will start
: work, all of whom may have slightly different goals, and when they learn
: that the project is going in a different direction, it may very well piss
: them off.
There is more than one way to skin a cat. I think those of us who like
and use Amigas should know that better than anyone as it relates to
the computing world. Say for example there is a wildcard matching library,
(just an example here, it probably wouldn't have its own lib), using the
standard amiga wildcards and that all programs that do pattern matching
use it, then if someone else hated the amiga wildcards and loved that good
'ol star then by gosh they could change it with a new library. (Actually
as a side note: How about a matching library function(s), that read their
matching rules from a file? Then you could have one library and just
change the settings if you wanted , through some spiffy pref tool, or
via an editor... ?) Anyway.... back to my point. Yes, if it comes down
to an argument between cooperative or preemptive multi-tasking, then we
have a serious problem, but almost anything beyond the basic kernel could
be dynamic. We could make this new OS MORE dynamic than AmigaOS. A changing
OS for a changing world. Heck we could let the user choose which libraries
to use for which program, but have it absolutely uneccesary to do so.
Maybe I am being too optimistic, but why not have an OS that can change
to meet different peoples' needs? The AmigaOS already goes a long way
towards this ideal.
---
thed...@mail.utexas.edu <the Edward Blevins>
Marc 'Nepomuk' Heuler
> I agree that we need an OS that it would be _easy_ to add TCP/IP to, but I`m
> not sure it's a good idea to have it built in. TCP/IP over SLIP or PPP hogs
> resources, and many users won't need it. But what we ought to add, is a
> standarized network interface that easily could acommodate both TCP/IP and other
> network protocols. Perhaps we could even manage to hide the network protocol
> totally from the applications...
Most Amiga network cards come with a SANA-2 driver. Many manufacturers are
out of business. Nobody will recompile the driver software, and often
enough lack of hardware specs will prevent you from writing a new one. So
why not just adopt SANA-2 as standard?
(The following is not to you directly, but to the public audience)
In my opinion, writing a new OS for Amiga does not make sense. It's
AmigaOS that makes Amiga unique, the hardware is outdated. One consequence
of writing a new OS is complete lack of software. Just like with the
network card drivers you won't find software developers enthusiastically
porting their babies to the new OS.
No, you will have to spend man-months in creating a text editor. A
graphics program. An Icon editor. GUI generator. Terminal software.
UUCP, TCP/IP, Mosaic. Fax software. DTP, CAD. Archivers. Backup.
Recovery and virus tools. A shell. Sound tracking software.
Development will take years, but the result is just about what we have now!
An out-dated hardware with a genious OS and very limited software pool.
I think, enhancing the current OS is the way to go. Make your additions
fit the Amiga spirit nicely. Put them into libraries and SetFunction() OS
routines to use them. If kickstart development restarts (when? by whom?)
and incompatibilities are encountered, you can update the patch software,
or - if enough software already adopted the new API - go without it.
Or - if your not happy with AmigaOS - move to another platform. Mass
production hardware is cheaper and more up-to-date. Run OS/2, Linux, or
whatever you favour as UseNet-AmigaOS idol.
Chris Hall
: One problem would be pronunciation difficulties, Amiga is rather simple,
: but how do you pronounce Tejas?
: J as an H, or D (or the real J sound, ie mine ;)
With a H sound. That name is really only a suggestion. I'm sure we'll
think of something better.
Chris Hall
Chris Hall
: Since I'm assuming you are not talking about the Mac(intosh) what is Mach?
Mach is a variation of Unix. It allows you to have different
personalities on top of the kernel. It's used in NeXt Step and the latest
version of OS2. You could have a Mach core with an Amiga personality.
Chris Hall
Chris Hall
: So here is the first argument, why does it need TCP built in? Waste of
: space if you ask me.
TCP is real important if you want it to be accepted in the US. The net is
getting real popular over here. A user will need it if they live in a
area where they have a public internet access or a cable line access.
Chris Hall
Byron Montgomerie
: What is globbing?
Slang for Global regular expression matching. I think. :)
Byron Montgomerie
In a year or two, TCP will be less of a waste of space I think. :)
Regards,
BM
Paul Petershagen
CB> : Foo.c
CB> : FOO.C
CB> :
CB> : On the Amiga, none. On UNIX, those are 4 separate files...
CB>
CB> This is a feature, not a bug :-)
CB>
CB> Furthermore : smart shells will make this transparent with the
CB> TAB completion... I don't see a real interest in preserving the
CB> case if it is ignored by the system (worse : it is not
CB> completely ignored, try to open "Graphics.library"...).
CB>
CB> Something to remove if ever a future OS sees the day.
I think it`s also a feature to choose the case ... If you`ll remove it
dirs will look like ms dos dirs and this is AWFUL. Don`t remove it.
Paul
-----------------------------------------------------------------------------
Usenet: P_Pete...@TOSCHIBO.ruhr.de A4000/030/25/882/50/10/780<>CD32
*PGP Public Key available on request* Only AMIGA makes it possible//
\//
Mike Nielsen
>Maarten Ter Mors (Maa...@aobh.xs4all.nl) wrote:
May I suggest an approach to building the OS, that is to create
it in a fashion which suits object oriented systems, ie treat windows, screens
and what ever else as an object, allowing for increased portability, I'm
working on such a system under Amiga DOS (with mixed sucess).
mike
--
-----------------------------------------------------------------
Michael Nielsen Disclaimer : All these opinions are my own!
Philips Public Telecommunications Systems Phone: +61 3 5743728
Melbourne, Australia Fax: +61 3 5743577
Vidar Hokstad
>
> Vidar Hokstad (vid...@ifi.uio.no) wrote:
>
> : I agree that we need an OS that it would be _easy_ to add TCP/IP to, but I`m
> : not sure it's a good idea to have it built in. TCP/IP over SLIP or PPP hogs
> : resources, and many users won't need it. But what we ought to add, is a
> : standarized network interface that easily could acommodate both TCP/IP and other
> : network protocols. Perhaps we could even manage to hide the network protocol
> : totally from the applications...
>
> to host machines via serial (dialup) interface to allow them to exchange
> IP packets with other machines on the net.
No. TCP (Transmission Control Protocol) and IP (Internet Protocl) are two of the
network protocols, while SLIP and PPP are, like you wrote, protocols to allow TCP/IP
packets to be transmitted over a serial interface. The reason I mentioned the
combination of TCP/IP and SLIP/PPP, is because that is what most "low end"
users will most likely be using/wanting to use if they go online, and
it's for low end machines it will be a "problem".
And the combination (or TCP/IP alone for that matter) hogs a lot of resources. It's
hardly something I'd want to run on my machine as long as I don't have to.
Actually, one of my current projects is to get a group together to finance and run
a fully connected internet site on an Amiga (probably running Linux), and one
of the first things we'll do, is to offer Amiga users to connect with a more
resource friendly (and user friendly ;) protocol implemented as a filesystem.
All that will be needed to set it up, will be to copy the filesystem to L:,, and
the mountlist wherever you want it, and a "mount" command to user-startup,
and optionally a special serial device to DEVS:, and off you go.
> It will be important to include TCP/IP with a future version of it but I
> dought it will be in the early versions. It would be nice if AmiTCP could be
> included in the system but I can't see that happening since it's
> commercial now.
I agree that it might be a good idea to include TCP/IP with the new OS, but not
built into the core of the system. I still believe that what we need is an
uniform network interface API, in the spirit of filesystems etc., which hides the
different network implementations from both the programmer and the user.
That way, people that don't need to use TCP/IP won't need to have it at all.
Vidar Hokstad <vid...@rforum.no>
Jean-Alexis Montignies
: I would like to say that the idea of writing a portable Amiga-OS-like
: OS really appeals to me. I would love to be able to keep the feel of the
: Amiga even if I move to another hardware platform. I would like to
: donate my efforts to this project. I would be willing to do programming,
: help plan, or both. I really hope we can reach a consensus as to what we
: want the new OS to be like. I feel like I should add my two cents about
: what I feel we need (and don't)in this new OS.
: First, some people have suggested just helping with the Linux port,
: but Linux is not very much like Amiga-OS at all, its entire philosophy
: has developed from a different angle. Don't think I have anything
: against Linux, but I prefer the feel of Amiga-OS. Yes Linux can do
: shared libraries (so I have been told), but it is nowhere near as
: modular as Amiga-OS is. Yes it does/(will?) have a GUI ala X, but X
: , although a nice interface (some say) is also not very similar to
: the Amiga way of doing things.
: There are several things about the Amiga-OS that I think would be
: very important to keep in the new OS. Some of these are:
: *Shared Libraries/Modularity
: I think this modularity adds a great deal to the Amiga-OS.
: Has anyone else checked out type1.library from aminet that
: lets one use PS type1 fonts (like CG or bitmap) on the amiga?
: I also like the concept of the kernel as a shared library.
: *Devices handled in a similar manner
: I think it is great that in a properly written term program
: you can use any device that acts like the serial device.
: *Handlers
: I like being able to use a new file-system so easily.
: Or access TCP from the CLI. Or pipe things any number of ways.
: *IPC/ARexx
: ARexx is wonderful, but it does have its limitations. At the
: very least we should keep it. At the best we should improve it
: or move to a new language. How About APerl, or AGEL (GNU Extension
: Language)
: *Datatypes
: Or something similar.
: *Keep it small
: Amiga-OS is still very small and efficient compared to most other
: OS's
: *Logical Assigns
: Not as important on the whole, but overall a great feature
: *IFF file standard.
: Its very flexible.
: *Commodities and the Commodity interface
: Another great example of Amiga modularity.
: *Localization
: Except more so. I know its a shared library, but I think its important
: enough to merit its own bullet.
: *Preemptive Multitasking
: Of course.
: *Integrated GUI AND CLI
: I don't mean to say any given user has to use both, but only
: that both should be available to any user. Nor do I mean we
: should have only one of each.
:
: Also (of course), there are many things that we need:
: *Memory Protection
: Of course.
: *Networking
: Most importantly a good general Networking API, with the specifics
: handled by libraries, handlers, and devices (not necessarily in
: that order). TCP/IP is great but its not all there is.
: *Resource tracking
: Of course.
: *Better icon handling.
: Something along the lines of newicons, whether you like the
: icons themselves or not, it would be nice to have the icons
: adjust to whatever pallete you use and not having to do
: vice versa. Maybe even entirely redesigning the info file
: concept, instead of just having tool,project, etc... you
: could configure it to contain the fields you wanted it to.
What about iff iles for icons ? That is modular enough i think, we should
even use vector graphics, differrent imagery for different pixel ratio,
and so on....
: *Hardware Independence RTG etc...
: The amiga has some of this already, we just need to go all
: the way. This also brings up lots of other points. Should
: we distribute applications as source, have a pseudo ML interpreted
: a by a pseudo cpu on each machine, or what? If the first then
: commercial software would probably end up having a binary for
: each platform, (likely leaving some out) or none at all (no
: support), if the second then we have to suffer much more slowness
: than we would have to otherwise. This needs much more discussion.
: *Better Clipboard support
: I mean some standard way of handling the different types
: of clips, text,graphics,structured drawings(?),anims, etc...
: *Multi-User support & file/process protection
: Not everyone needs this, but it should at least be an
: option for those who do.
Agree, we should support also different users at a time, that is not
only file sharing, but several monitors, several keyboards ...
: *Interchangeable shared libraries.
: Now many programs have a place to chose what device to use
: how about a place to chose which libraries to use. Don't
: like standard intuition handling, get a custom intuition
: library.
: *Better Shell(s)
: The Amiga shell is great (especially with the right additions),
: but it could still use some improvement. One person's ultimate shell
: is another's living hell. Ideally (if one exists) the *main* shell
: should be very configurable, as should the rest of the UI, commodities
: already go a long way towards general UI configurability.
: *Object Orientation (?)
: This seems to be a big buzzword in OS circles these days.
: This good be a very good thing handled properly, or a very
: bad thing if not. In general I think the general modularity
: of the Amiga would fit well into a OO structure, but I
: think we should consider how much this would bloat the OS.
: The main place where this might provide an advantage for
: programmers would probably be in GUI design. This also
: merits MUCH more discussion.
I'd like tu put the stress on this point, because i use NextSTEP
every day, and althougth it's heavy it requires megs and megs of
memory, the responsivity is not quick enough, it is not enough
customizable, it's great because it's OO, and the used language is
not C++, it's Objective C, wich is far more easy to learn, and more
powerfull. Not only the gui are designed with OO, but also all the
data structures of the applications designed OO.
I think a new OS MUST have an OO developement system.
: *Programming Guidelines
: I know we have some, but we would need new ones.
: No hardware banging! Especially once (if?) it actually goes
: multi-platform. But then again, people will always bang the HW.
: Most importantly we need to make plans for the future and build
: allowances for them into the programming guidelines.
: *More User Friendliness and complete Online docs
: There are some things , if only a few, that we could learn
: from the Mac. Virtually anyone can use a Mac, even if they
: have very little understanding of computers. This may not
: be important to some people, but it is important if we ever
: want the market for this new OS to grow.
: I know I have missed things on both lists. but we have time yet.
: In closing I would like to remind all that these are my opinions only,
: and I am not trying to say anyone else's opinions are less valid.
: If you got this far, thank you for for taking the time to read this.
: And to everybody thank you for the time and bandwidth you took reading
: any of this.
: Sincerely,
: ---
: thed...@mail.utexas.edu <the Edward Blevins>
Excuse my english, please, PLEASE ;-).
Jean-Alexis
Jean-Alexis Montignies
: Per Jacobsen (per...@inet.uni-c.dk) wrote:
: Chris Hall
But mach is not efficient as a kernel, and i't based on unix, i want a FAST
system.
Mach will not do it.
Jean-Alexis
A
Vidar Hokstad
>
> Most Amiga network cards come with a SANA-2 driver. Many manufacturers are
> out of business. Nobody will recompile the driver software, and often
> enough lack of hardware specs will prevent you from writing a new one. So
> why not just adopt SANA-2 as standard?
It's a possibility, for sure, but it depends on how SANA-2 will fit in with the
rest. And: Allthough hardware specs. might be hard to get, there's at least
the SANA-2 drivers... I don't think disassembling their code to write drivers
that allows their hardware to work with another system, possibly increasing their
sales, is something many companies will sue over - who knows, they might even
want to help if they're still
in business.
Besides, for the low end, serial or paralell interfaces are probably what will be
used by most people, and for the high end, the number of high quality Amiga network
cards are _low_ - one of the possibilites that this project gives us, is to more
easily migrate to other hardware platforms, or temporarily use other platforms, in
the cases the Amiga hardware becomes to limiting. I'll manage with my Amiga's
for years to come, but the day I have to change, either to a completely different
platform, or maybe to a RISC Amiga if development will ever be finished, I want
that migration to be as easy as possible.
> (The following is not to you directly, but to the public audience)
>
> In my opinion, writing a new OS for Amiga does not make sense. It's
> AmigaOS that makes Amiga unique, the hardware is outdated. One consequence
> of writing a new OS is complete lack of software. Just like with the
> network card drivers you won't find software developers enthusiastically
> porting their babies to the new OS.
Of course we will face lack of software. But remember, every Amiga user already
have AmigaDos - lack of software is no catastrophe, as long as the new OS is designed
so that the two can coexist on the same hardware (I'm not talking about having the two
running at the same time, allthough that would've been nice, only being able to
have both installed), that won't be a big issue.
Then people interested could use the new OS when they write new software, but stick
to AmigaDos when they have to use applications not available for the new system.
> No, you will have to spend man-months in creating a text editor. A
> graphics program. An Icon editor. GUI generator. Terminal software.
> UUCP, TCP/IP, Mosaic. Fax software. DTP, CAD. Archivers. Backup.
> Recovery and virus tools. A shell. Sound tracking software.
Only a fraction of this is things you _need_ to have to get people to start using
the system, and when people start using it, people start developing for it. And if
the system is easy to port to other platforms, the number of possible users and
developers rise accordingly. Especially among people that don't like to be dependent
on their current hardware.
A usable (allthough not _good_ ;) text-editor can be written in days by one programmer
(yes, I've tried). Terminal software, shells etc. likewise. Stuff like UUCP is easy to
port (but of course it will take some time - it's a lot of code to go through) once
you've got a decent C compiler up and going, as there's little platform dependent stuff
in the code, and since it's very modular it's no problems to exchange it part by part
afterward (I'm doing that with my own UUCP setup at the moment).
And a lot of other good PD/Shareware applications come with sourcecode that's
quite easily portable as well. This can be made even simpler by some simple
considerations when creating the new OS: Shared libraries are a must, so an option
would be to write a set of libraries that implements important elements of the Amiga
API as calls to the functions of the new OS, thus enabling more applications to run
after only a recompile or simple changes instead of a complete rewrite.
> Development will take years, but the result is just about what we have now!
> An out-dated hardware with a genious OS and very limited software pool.
No. Development never stops if the platform is due to live on. But a OS that can
be used, allthough it will be for the freaks in the beginning, can be put together pretty
fast once an initial set of specifications are ready. And one of the ideas that
many people have put forward, and that I holeheartedly support, is to ensure
that the new OS can be easily ported to other platforms.
Then, if the Amiga isn't put into production again, and developed further, those who
want to can migrate to new platforms without loosing all their applications, and the
and the features that they love in AmigaDos.
> I think, enhancing the current OS is the way to go. Make your additions
> fit the Amiga spirit nicely. Put them into libraries and SetFunction() OS
> routines to use them. If kickstart development restarts (when? by whom?)
> and incompatibilities are encountered, you can update the patch software,
> or - if enough software already adopted the new API - go without it.
Many peoples are writing patches for AmigaOS, but there's a lot of things that
are _difficult_ to add, to say the least. Try adding decent resource tracking,
memory protection, multiuser support (yeah, we have MultiUserFilesystem, and it's
a _very good_ attempt, but it's not enough) etc. to AmigaOS without breaking
a lot of applications... I *do* hope that this new project will result in
code and ideas that can be used to enhance AmigaOS further, though, as I see no
possible way of migrating completely to a new OS in a short amount of time.
> Or - if your not happy with AmigaOS - move to another platform. Mass
> production hardware is cheaper and more up-to-date. Run OS/2, Linux, or
> whatever you favour as UseNet-AmigaOS idol.
I'm happy with AmigaDos, when I'm comparing it to Windows, OS/2 or the
different UNIX flavors, but I see many features lacking, and I want to continue
using my Amiga. What I want is a new OS that in the beginning can be a supplement
to, and later can replace, AmigaOS, and that have the features from AmigaOS
that I miss in other OS's.
Vidar Hokstad <vid...@rforum.no>
Jukka Aho
> about...er...Laura ? We don't have a custom chip by that name yet, do we ?
I like that name. Been watching Twin Peaks? ;)
Chris Hall
: May I suggest an approach to building the OS, that is to create
: it in a fashion which suits object oriented systems, ie treat windows, screens
: and what ever else as an object, allowing for increased portability, I'm
: working on such a system under Amiga DOS (with mixed sucess).
One that note, let me tell you about an idea I had a few days ago. A
while back, I was planing a software package to do some accounting at
where I work.
The way I was going to do it, is create a program that is somewhat like
DiskManager 2. It would open up a public screen with a borderless
backdrop window, have customizable menus, a rexx interface and various
windows & requestors that could be configured by the applications.
Various programs would make up the whole application. This program's
screen would act as a home screen for the whole super app. I started
wondering what a Workbench/DeskTop would be like if it acted sort of like
that. The idea stuck in my head.
A few days ago, it hit me. Why not replace Workbench with a server system
that would allow you to use various programs and ARexx scripts to emulate
the standard WB enviroment and allow the user to customize it to their
tastes. The server system could have the ability to handle multiple
screens, have different window types (Drawer, menu, dock, listview,
requesters, etc), nameable ARexx ports for different apps, and various other
hooks. A small configurable program could act to control this system for
the WB emulation but it would also be available for use by different
programs such as the accounting system I mentioned above.
This would blow away any other desktop. The Amiga's ability to use
stacked virtual screens would make this a very powerfull tool.
Chris Hall
Patrik Kudo
DS> I would love to help. But I must admit my Amiga OS programming is virtually
DS> no existant. I have never been able to afford the Docs. The docs for this new
DS> OS must be made readily available so more people can code for it, and we will
DS> all need copies of the old os code and docs. I think we
I agree at the point that the docs to the new OS should be PD. That
would surely make it more atractive to code new programs for it. I'm
not sure we will need the old os code. The docs will help, though.
DS> should use an object orientated programming language, with data hiding etc.
DS> My vote would be for C++.
You can do that with C too (I think), and more people know how to
programm in C, so I vote for C. (GNU C is a good choice. Free, and
is available for many diffrent processors)
DS> Also , and I know how big a change this will mean to exec, it HAS to have
DS> memory protection and TCP buitin. Also full RTG posibly like X11.
Memory protection, YES. The other stuff, I'm not sure I know what they
are, but as much as possible should be included, but I do NOT want an
OS that requires 4711 Mb to run (like Windoze :-)
DS> I know the memory protection will cause a problem on 680ec30 and below but
DS> the OS needs it, even if it is only as an option.
I suggest we put as much as posible in to start with, and then, we can
see how big it gets, and take away parts that are not so important.
* Patrik Kudo
Vidar Hokstad
TCP/IP is great for those people that actually needs it, and I agree that it
ought to be included in a new OS, but *NOT* in the in an exec replacement.
First of all, it would be a waste of space for the users that don't need it,
and IMHO the kernal should be limited to features that are _required_ to get
the rest of the OS to run.
Besides, TCP/IP aren't the only network protocols around, and if we add it to
the kernal, we still need network support on an higher level to allow an uniform
interface to other network protocols. So why separate the two? We could still
provide a TCP/IP module as a standard part of the OS, but then people would have
the choice of not installing it if they don't need it.
Vidar Hokstad
Patrik Kudo
CH> Per Jacobsen (per...@inet.uni-c.dk) wrote:
CH> : One problem would be pronunciation difficulties, Amiga is rather simple,
CH> : but how do you pronounce Tejas?
CH> : J as an H, or D (or the real J sound, ie mine ;)
CH> With a H sound. That name is really only a suggestion. I'm sure we'll
CH> think of something better.
I actualy like Tejas
CH> Chris Hall
Patrik Kudo
Glenn Saunders
: I suggest we put as much as posible in to start with, and then, we can
: see how big it gets, and take away parts that are not so important.
Only the stuff everyone will likely use should be hardwired in. The rest
should be optionally loaded in. If we want a bloated but powerful OS
there is already NT. AmigaDOSs greatest strength over other operating
systems is its compactness, and to make it huge for the sake of features
that not everyone will use isn't going to leave it with any advantage over
existing preemptive M.T. operating systems.
the Edward Blevins
: TCP/IP is great for those people that actually needs it, and I agree that it
: ought to be included in a new OS, but *NOT* in the in an exec replacement.
: First of all, it would be a waste of space for the users that don't need it,
: and IMHO the kernal should be limited to features that are _required_ to get
: the rest of the OS to run.
: Besides, TCP/IP aren't the only network protocols around, and if we add it to
: the kernal, we still need network support on an higher level to allow an uniform
: interface to other network protocols. So why separate the two? We could still
: provide a TCP/IP module as a standard part of the OS, but then people would have
: the choice of not installing it if they don't need it.
I agree with you on this one. We should stick with the AmigaOS's theory of
modular design. We should perhaps have a "network.library", that deals with
the lowlevel stuff such as devices and whatnot, then other libraries that
interface the network.library to add TCP/IP, AppleTalk, Novell, or
whatever. The AmigaOS is already very good at modularity, that IMHO is one
of its best points.
: Vidar Hokstad
--
thed...@mail.utexas.edu <the Edward Blevins>
Lars Duening
:glob: /glob/, *not* /glohb/ vt.,n. [UNIX] To expand
special characters in a wildcarded name, or the act of so doing
(the action is also called `globbing'). [...]
Historical note: The jargon usage derives from `glob', the
name of a subprogram that expanded wildcards in archaic pre-Bourne
versions of the UNIX shell.
--
Lars Duening; due...@ibr.cs.tu-bs.de
Christoph Feck IRZ
> Christoph Feck IRZ wrote:
>
> >PS: I have started rewriting Intuition, but without a new
> >layers/graphics/gadtools/prefs/datatypes etc. this will
> >be a joke.
> I am *very* interested in this project, but alas, if all correspondance is in
> German I will be unable to do anything. My knowledge of German is very
> limited.
The mailing list is of course english-spoken, even
most of the current subscribers are german, because
I posted the idea only in a german group...
3k// Christoph Feck, TowerSystems - Custom Class Design
\X/ Amiga - Intuition inside.
Christoph Feck IRZ
> *Memory Protection
> Of course.
Why?
> *Resource tracking
> Of course.
Why?
> *Object Orientation (?)
> This seems to be a big buzzword in OS circles these days.
...as are Memory protection and Resource tracking.
Really, those two things won't gain you anything.
The only need for protection is to make badly coded
software not trash the whole system. But I don't
use badly coded software. Resource tracking is for
lazy programmers. I DO HATE programs which do fopen()
and rely on the OS to do the fclose() itself...
Also remember that adding those two features means
incompatibility to nearly 100% of existing apps.
Bitman
>: Think of it this way: All tools which create programs for the new OS
>: actually create code for a pseudo-CPU, call it CPU-X. Then, on each of
Much of this work is already being done. I recently saw an article on a
system, (TAOS, I think) that handles CPU-independant programs. They
developed a generic language, and _translators_ (not interpreters) that
they claimed were almost as fast as their hard drives. They're targeting
game machines, which means their systems is tuned for performance. Just
like the Amiga!
This could be combined with the Mac's "fat binary" concept, which whould
attach highly-optimized functions to a TAOS program. Thus you could leave
the graphical front end in TAOS, but add number-crunching attachments tuned
for the 68040 or a DSP.
Using libraries for this would be perfect, as it would work fine as an
extension to the current AmigaDOS. It would be somewhat clumsy under the
CLI, but find under Workbench. ie:
run-taos MaxFractal4000
and libraries
taos.library
taos-mc68030.library
taos-ppc601.library
taos-adsp...library
New processor? New library! And you don't lose use of the old processor.
-Bill
/ William R. Zwicky /
/ U of Illinois, Champaign-Urbana /
/ wrzw...@uiuc.edu /
Chris Hall
: Much of this work is already being done. I recently saw an article on a
: system, (TAOS, I think) that handles CPU-independant programs. They
: developed a generic language, and _translators_ (not interpreters) that
: they claimed were almost as fast as their hard drives. They're targeting
: game machines, which means their systems is tuned for performance. Just
: like the Amiga!
: This could be combined with the Mac's "fat binary" concept, which whould
: attach highly-optimized functions to a TAOS program. Thus you could leave
: the graphical front end in TAOS, but add number-crunching attachments tuned
: for the 68040 or a DSP.
: Using libraries for this would be perfect, as it would work fine as an
: extension to the current AmigaDOS. It would be somewhat clumsy under the
: CLI, but find under Workbench. ie:
: run-taos MaxFractal4000
: and libraries
: taos.library
: taos-mc68030.library
: taos-ppc601.library
: taos-adsp...library
: New processor? New library! And you don't lose use of the old processor.
That is how I would like the new OS to be in the long run. It would offer
the best performance, flexibilty and portabilty.
Chris Hall
EriC
>In article <Maarte...@aobh.xs4all.nl>, Maa...@aobh.xs4all.nl (Maarten Ter Mors) writes:
>> AM> - intermediate code: do not write for a real CPU, but a virtual one.
>> AM> Write small and fast runners for the actual CPU's.
>>
>>The plan so far is to write the main chunk of the OS in a common language, most
>>likely GNU C++, that is easy to port. Then, when we really start porting,
>>hardware specific bits will be coded in assembler for the specific platform, to
>>get the best speed.
>But his original point is much better...
>Think of it this way: All tools which create programs for the new OS
>actually create code for a pseudo-CPU, call it CPU-X. Then, on each of
>the machines this new OS runs on, the program loader (equivalent to
>LoadSeg() in AmigaDOS) needs to actually be a translator as well as a
>relocation engine. It would not only move the file from a filesystem to
>RAM, but it would also translate from CPU-X code into the native
>processor code.
>Main Disadvantages: Program load speed would be slower, due to the
>translation step. Also, the resultant code may not be as absolutely
>highly optimized as possible by directly coding for the specific CPU.
>Main Advantages: Complete machine independence. You wouldn't have to
>recompile your code every time you moved it to a new platform. If the
>new platform was running the new OS, your executable would load and run
>with *no* extra time spent!
>Personally, I would *much* rather see this approach taken than most of
>the others possible. I've seen this done in various manners, such as
>having a Linker on the target machine that does the translation once,
>but unless the LoadSegAndTranslate() function is really too slow to be
>usable, I'd rather not even have that extra step of having to Link a
>program. I'd rather just pop the disk in and run the program, and not
>care that I'm using my Amiga with a 68030, but the program was written
>on a PowerPC based system...
>
>--
>---------------
>Jim Cooper
>(ja...@unx.sas.com) bix: jcooper
>Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!),
>and not necessarily those of my employer.
>Remember, "Euphemisms are for the differently brained."
Why not base applications in ARexx using standard shared libraries?
Instant portability with support for the current configuration.
Arexx is able to execute strings as commands recursively, much
like LISP, and can be so closely integrated with the system that the
overhead of using strings is minimized to parsing alone, if done
properly.
Michael J. Bond
> typing test.anim. Less work. I also like the ability to have filenames
> with spaces in them. This is a lot nicer than using virtual spaces with
> "." or "_" in unix. AmigaDOS' filename system is just plain wonderful.
> Like with the Schwartz anims I simply named them what they were:
Errr, yes, Unix is case sensitive, but where did this spaces bit come
from? Unix can in fact have spaces in their file names, in fact they
can have ANYTHING, control characters, hell, one could even put 0xff
in a file name, if you could type it (some shells allow 'quoted
insert'). It is just that in Unix, there is no nice COMMON graphical
interface into the filesystem, so one tends to use things that are
relatively easy to type. So lets stick to the argument at hand
please!!!
And with that, I personally like the extended range of possible file
names.
Mike B
G.A. Rummery
my thoughts and ideas for what I see as a much more realistic and
potentially far reaching alternative.
Writing an OS from scratch would be tough, and somewhat pointless
unless,
a) It could run software written for other more popular OSes (ala OS/2)
b) It was so awesomely good that everyone chose to adopt it despite
the lack software compatibility (ala no OS so far written).
a) holds back your OS, as it would need clunky features to make it
compatible, and b) is just wishful thinking.
The problem holding back computers today is SOFTWARE
COMPATIBILITY. This is caused by the interface between programs and
the OS (in particular the GUI which defines the way in which IO will
be handled), and the fact that this interface is defined by the OS and
is thus non-standard between different OSes. As anyone who has tried
programming under any of the popular OS/GUI combos will know, the
interface is usually a real pain, requiring vaste numbers of quirky
and overcomplex function calls to just set up a window and some basic
IO for your program to use. This is true of X, Windows, and Intuition
(all strictly speaking GUIs, but they're the bit your program
interfaces with the most).
So, those of you discussing writing a new OS would be better employed
designing a set of standard function libraries, and porting these to
all platforms. These function libraries would provide lots of easy to
use features for I/O in place of the hoops you have to go through in
order to program under X or Windows or Intuition. They should also be
object orientated, so the I/O is with devices with certain properties
(e.g. a "slider" device is just a means of receiving a value in a
particular range - this value can come from any source, including
other programs, alternative slider designs etc). Thus GUI features
like sliders and menus or whatever, would just be devices that could
be upgraded or customised to the users content. The same, of course,
goes for the underlying hardware architecture.
The point is, a set of standard, well defined function libraries would
be very useful (like the ANSI C standard libraries of functions) for
allowing easy porting of code, and for saving programmers writing
their own function libraries. If they were powerful and intuitive to
use, and freely and easily available, then they WOULD be used. Thus
half the battle would be won, as the OS/program interface would have
been standardised. THEN a new OS could be written/new hardware could
be designed etc, so long as they provided the standard interface
(hence the reason the function libraries have to be very, very well
thought out and sufficiently abstract that new devices/objects could
be easily incorporated). Software compatibility problems would have
been solved as for Unix machines in the sense that code could be
ported just by recompiling.
The point about a set of standard functions is that no-one in the
business world is going to write them (if you charge for them, then
they just become a toolbox that some people will buy, and others
won't) - to become standard they have to be free and easily available,
as well as completely documented so that if someone decides to
hand-code a machine code version of a function for a particular
platform, then they can do so and release it as a library patch. It
also means that control of the Interface would be in the public
domain, so MicroSoft or whoever would not have such a stanglehold.
So, forget writing a new OS - it won't catch on if it is brand new,
and it won't be an advance if it is compatible with current
code. Also, it is a mammoth job that wouldn't be complete until it was
complete (!), whereas a set of function libraries could be written,
debugged and released one after the other; thus it would be an
on-going process that would build up momentum as it went along.
Gav'
Holger Bettag
Sorry for the long quote, but it explains quite nicely what the following
paper is all about:
ftp to ftp.inf.ethz.ch and get
doc/diss/th10497.ps.gz (there is also doc/diss/th10497.abstract there)
It is a doctoral thesis that explains details of a very powerful concept of
totally hardware independant binaries. Highlights:
- it doesn't rely on any "virtual machine", only the semantic contents
of a program are actually stored
- portable binaries are about half the size of 68K code
- code generation on the fly allows for user configurable level of
machine specific optimization
- on fast machines, code generation on the fly can outperform HD speed,
thus loading the so-called "slim binaries" faster than traditional ones
- the portable Code contains actually more information about the program
than assembly does, so global optimizing could be done even after
compilation (i.e. old software will benefit from new optimizers)
- benchmarks are presented in the thesis, showing that even good C
compilers can be outperformed (both in compiling and execution speed)
- The system has been successfully implemented and tested on two distinct
architectures: 68K and PowerPC
I am in no way affiliated with the author of the thesis, I just found this
paper while netsurfing. The ideas outlined there are simply ingenious.
I also have no idea about the copyright of the above concept, but since it
is a scientific work, you should be free to use it, as long as you don't
make profit of it.
CHECK IT OUT!
Holger
P.S.: Of course I don't speak for the university...
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
[case insensitivity]
CB> Furthermore : smart shells will make this transparent with the
CB> TAB completion... I don't see a real interest in preserving the
CB> case if it is ignored by the system (worse : it is not
CB> completely ignored, try to open "Graphics.library"...).
That's because exec lists are case sensitive (to make the search of them not
quite so hard on the system). I think it would be better to make exec list
searches case insensitive than the other way around !
CB> Something to remove if ever a future OS sees the day.
I couldn't agree less. It's so childish in a computer that you have to say
dIfFiccULT_nAmE_WITh_miXEd_casE.INfO, because in places where you don't have
TAB completion (for example when you're writing a program), you'll get it wrong
four times first.
A computer should be as easy to use as possible and not be stuck on things like
this. When I say 'BOO' to a computer it should jump, but also when I say 'Boo'
or 'bOo' or just 'boo'. Why make things unnecessarily complicated for the user
?
G'bye then,
/|/| ___ /|/|
/ / |aarten |er / / |ors email: maarten....@aobh.xs4all.nl
-- Via Xenolink 1.95, XenolinkUUCP 1.0
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
DS> From: D.S...@dcs.warwick.ac.uk (Dean Smith)
DS> I would love to help. But I must admit my Amiga OS programming is
DS> virtually no existant. I have never been able to afford the Docs. The
DS> docs for this new OS must be made readily available so more people can
DS> code for it, and we will all need copies of the old os code and docs. I
DS> think we should use an object orientated programming language, with
DS> data hiding etc. My vote would be for C++.
Good, welcome on board ! Our most likely language will be GNU C, which also
has C++ built-in.
DS> Also , and I know how big a change this will mean to exec, it HAS to
DS> have memory protection and TCP buitin. Also full RTG posibly like X11. I
DS> know the memory protection will cause a problem on 680ec30 and below
DS> but the OS needs it, even if it is only as an option.
We will try to build it in AND make it switch-off-able for people with no MMU
in their computers.
Keep an eye out for our mailing list, coming to you soon !
Maarten Ter Mors
Re: Amiga OS ? Let's do it ! too !
>> Unless I forgot something very crucial, in which case you must remind me
>> at once, this is about it. We can use the support of everybody, as long
>> as he or
MV> What about people working on the most demanding phase of any bigger
MV> software development project - specifications and design? Although we
MV> already have an OS that can serve as a 'prototype', some more thought is
MV> needed before sitting down to write code.
Did I forget to mention design ? I didn't, did I, not again ? :-))
Anyway, a lot of though will indeed go into design. But first we want to know
how much support we've got to see if it's worthwhile even trying (so far, we're
looking good). So, are you with us on this one ?
MV> Just my 2c.
MV> --
MV> Martin Vilcans, mar...@lysator.liu.se, phone +46-13-261340
Are you sure it's a good idea to publish your phone number on the biggest
network in the world ? You never know if there are maniacs out there with a
strange sense of humour, who will use it to call in the middle of the
night...;-)
Maarten Ter Mors
Re: Amiga OS ? Let's do it ! too !
> : So I can add you to the coordinating committee ? That would mean the
> count is : up to three.
JH> Sure.
JH> (I posted here rather than just using e-mail because I figure we want
JH> people on the net to know how this is shaping up and to see what level
JH> of support looks like so we can attract more people.)
Shaping up is putting it mildly :-) I barely have time to reply to all the
people who emailed me !
Maarten Ter Mors
Re: Amiga OS ? Let's do it ! too !
>> PS: I have started rewriting Intuition, but without a new
>> layers/graphics/gadtools/prefs/datatypes etc. this will be a joke.
CN> I am *very* interested in this project, but alas, if all correspondance
CN> is in German I will be unable to do anything. My knowledge of German is
CN> very limited.
With our project, all correspondence is in English, because we have
participants from all over the world ! :-)
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
SA> I have been working with MUI and Gadtools latly trying to port a
SA> Commercial CanDo application to C++ so I have some basic understading
SA> of how Intuition works and how It might be improved from a programer
SA> POV. I have also developed software using Microsoft Visual Basic & C++
SA> which has a nice (but bulky) way of handleing GUI creation (based on
SA> windows object orentated system)
So that makes you a programmer...
SA> In short, I would be interested in identifying new featues for AmigaDos
SA> that would fill the needs of programers and users.
...an advisor...
SA> BTY I'm also a bit of a graphic designer if you need help in that area
SA> as well!
...and a designer :-) Is it all right with you if I put you on the list of
programmers, with a preference to do the graphical look of the whole thing ?
We're going to have to give the new GUI a nice, new look, you see and we can
use people in that area.
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
> the major players on the Amiga (NewTek and Softwood in particular) : were
> involved in some way and agreed to recompile (if that is all it : would
> take) their code for the new OS.
CH> The need for commercial code to be recompiled would be a little down
CH> the road but I'm sure when we port to another processor, they will.
If we can make an OS, surely we should be able to convince developers to port
their software to another processor ? :-)
CH> One thing we need to deside at first is; "Do we want to replace most of
CH> the current libraries or write new ones that will coexist with them and
CH> write path libraries to redirect old lib calls to the new ones?". A few
CH> good examples:
CH> ASL, should we try to get Nico Francois to add ReqTools to the project
CH> and just write a small ASL.library to redirect the calls to ReqTools?
CH> Also, Workbench and the icon.library, should we just write a new
CH> desktop system? Again with patches to allow old programs to work with
CH> the library calls.
One of the good things about the current AmigaOS is the ability to patch
existing functions in the system with SetFunction(). In the Reqtools example,
we would start by taking over all the ASL calls and redirect them to another
library. In fact, this is already possible with RTPatch.
In the longer run, however, we just replace the entire ASL library with
something that holds all the new features but looks like ASL to the programs
accessing it. And we can of course add all the new features at the back of the
library.
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
>> !' article to many other groups and my sysop's now down in the bomb
>> shelter, hiding from the projected flow of mail that will produce. Every
CH> Hopefully your sysop lets you stay involved. :)
Better still, he's enthusiastic about it and he's agreed to become support BBS
! :-)
CH> Speaking of AG, a node crunched AG system would be nice. The viewer
CH> would just decrunch the current node. That would same HD space and
CH> memory. Gfx (structured and bmap) support would be nice also.
Hmmm...sounds a bit like HTML, doesn't it ? :-)
>> I had thought XPK in the role of a DoubleSpace-inspired system, with its
>> own standard Prefs editor and so on. I don't know if you've heard of
>> Disk Expander (a UK product), but that's basically a graphical front-end
>> to the XPK libraries. Something like that would be a doddle to make.
CH> I haven't seen Disk Exp., is it a commercial product? I would like to
CH> see direct support in the dos.library for a xpk like compression system.
CH> Imagine having Amiga files wrapped up in a cross between a xpked and IFF
CH> file.
Yes, Disk Expander is commercial, which is really scandalous because the real
workings of the program are XPK libraries, which can be had for free. You only
really pay for the GUI.
>> I'm sure we can offer a readily-installed version of term separately,
>> that is fit to be used with our WB, but I'd keep it separate.
CH> Some kind of terminal needs to be included with the first release. I
CH> just suggested term because it was the first that came to mind.
It's also the best and if one is to be included, term is the one. But I say
let's not integrate it into Workbench, just leave it a separate program.
>> Maybe we can talk Stefan Boberg into making a basic, no-frills, FreeWare
>> version of LHA to go with the system ?
CH> Actually, I've had a idea about an archiver system. A modular archiver
CH> system would be awesome for this package. Something like xpk except that
CH> is supports existing archivers for compatibility and has it's own
CH> structured archive format that allows different compression libraries
CH> just the way XPK does.
CH> I've see that someone is using xpk for archives now but I haven't found
CH> all the support files yet.
XPK is another ideal part of our system, of course. In fact, I'd like to
integrate xpkmaster.library completely in the dos.library and make
crunching/decrunching completely transparent, can be turned on and off with its
own prefs editor, for example. I hear there's a new version of PowerData out,
I'll have a look at that also.
Maarten Ter Mors
Amiga OS ? Let's do it ! too !
>> CH> 680x0 mach would be good for that. Mach has most of what we are
>> looking
>> CH> for in a OS, we could adapt it to fit the Amiga library system.
>> I'm not familiar with Mach (the first time I heard about it was less than
>> a week ago in this very thread),
PJ> Since I'm assuming you are not talking about the Mac(intosh) what is
PJ> Mach?
It's an OS kernel, that's all I can tell you. I haven't had the chance to take
a look at the WWW page dedicated to it.
>> CH> I suggested Tejas (Native American for Friend) at the start of other
>> CH> thread.
>> Hmmm, keep it in the nomenclature of Amiga, you mean ? Well, to be
>> honest with you, Tejas reminds me of Taos, the place Marshall Sam McCloud
>> came from (if you don't know what I'm talking about, don't worry - I
>> always watch ancient series on TV :)
PJ> What! Sam McCloud is a classic! In fact let's call it McCloud ;)
Funny, there's also an OS that's really called TAOS ;-) But I don't think
calling it McCloud is a good idea, because you will immediately loose all the
support from cigar-smoking people called Clifford :-)
>> I like the way it connects to 'Amiga' though. But meanwhile, how
>> about...er...Laura ? We don't have a custom chip by that name yet, do we
>> ?
PJ> Or Carolyn after the the old stalwart Mrs. Scheppner :)
Yes, that's an idea. I like having an OS with a female name, because 'Amiga'
is female itself.