Crumb wrote:
@Einstein
AROS does *not have* binary compaibility
AROS m68k should have it.
Does it even exist ?
but when it does (E-UAE)
...or when it does (AROS m68k) :-)
..or when it does (IEUAE/AROS 68k) ;-)
Imagine that I drag an Icon from the host OS desktop to an opus5 window... will it copy the file? I doubt it :-)
Good question, I'm not exactly fluent in workbench.library (or many other system libraries for that matter) but is there any obstacle ? any problems routing (and converting) between "objects" of the host and emulated desktop systems ? there shouldn't be, unless some endian-ness gets in the way.
BTW, have you actually tried OS4/MOS at all? Have you tried "GLUAE"? It's more or less the same kind of launcher the bounty wants to achieve but without the layers patch to show windows with other background.
That's just it, isn't it ?
BTW, a patch exist for EUAE to show the windows on top of Linux ones. Unfortunately it's not very advanced and shows all the windows in the same "layer" so host OS windows can't be between emulated WB windows.
I know, I pointed that out in the news announcement of the assigned bounty ;-)
Now let's suppose EUAE integration gets finished and you decide to use something called AROS2. First of all... why not use a Linux kernel or any other kernel like NewOS? Then you get posix compatibility. But automatically all AROS/AmigaOS devices/libraries become incompatible. Who cares anyway since Linux&GNU already has all the drivers we could want, these are actively developed and it also has tons of interesting libraries?
It would be more motivating for some reason (pride ?) having an "own" kernel, but I won't complain if the dev(s) would adopt a premade one.
As for the rest, actually i don't have some mysterious affection for everything AmigaOS, my ideal OS would be something new, inspired by the simplicity and (the once unique) modularity of AmigaOS, but really revised, I' like a new API that's crafted based on high flexibility and simplicity, that is, the API would not dictate certain things it really should not do, not in 2008+, I already explained what type of filesystem layer I would like to have in robs blog, that was just an example.
You could modify it to get a directory structure similar to AmigaOS, to boot reading an Startup-sequence file, to store commands on /c instead of /bin you could add amiga style path support, you could add a WB like desktop that avoids using XWindows (or maybe not, maybe you want to run all the GUI on top of XWindows).
I know that.
Since we agree amiga apps are old and modern linux apps are more useful and interesting there's no sense in keeping graphics.library. We could switch to Cairo for every graphic operation (switching to Cairo would make sense even on current AROS... intuition/graphics could run on top of it). AHI is also outdated, we could use OpenAL instead of it.
See... amiga stuff and API is outdated... there's little you would reuse on a modern OS.
But that's not up to me :-), besides I already stated *my* perception of amiga-like-ness, so I have no problems adapting to better API, but if some of it could be unique, designed from scratch then why not ?
If I started an amiga inspired OS (note I say amiga inspired and not amiga-like) I would choose a kernel like linux or NewOS and try to adapt existing software to run in a similar way as AmigaOS.
If I did start an OS (hehe), I would not put together premade kernel and modules, but write from scratch, implement new ideas not seen before, I would do that for fun, and to point out to the OS world: look at the power and flexibility of this baby of mine, and I did it all alone! now wouldn't that make the OS more attracting and appealing then just putting premade components together ? But as I said, I personally won't object.
Changing the kernel to keep a directory structure similar to AmigaOS wouldn't be difficult.
My personal perception of amiga "inspired" is not to clone things i regard "amiga like", but to take inspiration by the positive aspects, but most importantly to evolve it to a level that would make a regular user just adore it.
The problem reusing current AROS stuff is that it wouldn't have an easy way to communicate with the new OS. There's no much difference between standard OS libraries/components/devices and third party ones (the exception may be exec/dos/graphics/intuition/layes). That would cause that current AROS sources would be hard to adapt.
Remains to be seen what comes out of it.
When I say Amiga-like I mean OSes that work the same way as AmigaOS. Just like when I say Unix-like I expect the OS to include a set of posix functions, to have similar commands and I expect to code all unix-like OSes in more or less the same way. I'm not refering just to the end-user view.
I understand that, we have different views obviously.
What I'm trying to say is that if you get rid of the amiga/aros API why call your fork amiga or aros? Or why show it as successor of amiga/aros if it's not related to it (just using a similar GUI in the first versions?). GEM and MacOS looked and were used in a similar way but they were not related.
I explained that with the blind cousin analogy above. Anyway, since rob called the possible project "not-AROS" I think that answers your question.
IMHO Rob should fork. But there's little stuff that can be reused. I gave him some suggestion: design a new API and provide a library to be used on new Aros programs written for current AROS. Advice coders to stop using amigaos functions and provide them your functions. It's similar as if we were leaving amigaos and jumping to unix, you would advice coders to start using GeekGadgets. Just like that, he would define functions to do message-passing and other amiga-API stuff and AROS coders could start to migrate their code. Once most of apps and maybe libraries were adapted he would at least have something from AROS to use. Anyway since most of AROS stuff is based on old stuff and old APIs you could perfectly start from scratch changing the intuition/graphics calls by Cairo calls and stuff like that.
Not much to disagree with, only that it would be much (much) nicer with a unique overall design and API.
In conclusion: Fork AROS? Of course, but since everyone agrees that AmigaOS3.1 API is old and outdated why base your new OS on that?
If you've sent him a message I'm sure he got it ;-)
There's MOS, OS4, and AROS.. but wait, AROS is not "amiga" according to many amiga zealots anyway.
For me AROS/OS4/OS3/MOS are "amiga" :-) I may like some solutions more than the others but I like them all.
I was referring to the infamous *zealots* that rather throw themself to the trashcan than thinking with the substans between the ears, it's supposed to be used for somthing beyond eating/s????ing/sleeping and mating.
Users don't care crap about the internals, programmers might, *intelligent* programmers will not.
Intelligent programmers that want to write an OS without the limitations of OS3.1 won't base his code on OS3.1 compatible code.
Copying the source tree for reuse/modification/guidance of API implementaion algorithms is not necessarily *basing* in my book.
Users don't care about internals and that's the reason they shouldn't discuss internals of OSes.
Hence no reason to regard a new OS as *no* "amiga" or whatever, as long as it *feels* like it, and runs apps in an emulation layer with a few resources integrated in the host system.
if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like"
You are right. Other things may look similar or use a similar GUI, but wouldn't be amiga-like. Just like running Amiga-E and a Zune clone on Linux won't make your linux box amiga-like, even if you have put a nice wb-like and even if you rename your /bin as /c and even if you create aliases so you can type "dir" instead of "ls". That's merely cosmetical.
That's *your* perception of amiga-like, mine is a different one, there's no monopoly for the generic word "like" I' afraid, if you don't like it maybe you should seek a better and more descriptive word.
if you happen to *know* that *nothing* in the old API *implementation* can be reused (simetimes with modification) than why don't you just point it to him with *detail*, you seem to care alot i mean
Detailed suggestion:
-take linux/bsd/newos kernel and modify it if you need it
-use as much standard stuff as you can and avoid using OS3.1 code (that means avoid using AROS code)
I asked you to post *detailed* information to *him* that may fork or not fork (=leave)
-change the OS to use a similar structure to amigaos
Anyway, what structure ?
-put EUAE and add a launcher for ADF files (most of people who don't care about OS4/MOS-like emulation integration only remembers playing games on A500 in their childhood and haven't touched an amiga for years so they won't miss any program)
for the 666 time, EUAE does n-o-t, *not*, *NOT*, integrate essential "emulated" resources (windows, screens, some device messages) into the host system, are you and itix still going to claim that an upcoming *integrating*/whatever EUAE is *no different* to standard #?UAE ?
