Recent Posts

Pages: 1 ... 8 9 [10]
91
General Chat / Re: The situation
« Last post by wawa on October 18, 2019, 01:55:43 AM »
from what i remember when m68k target was introduced and jason and toni picked up the task, which was when i got into aros, it was a general consensus that this task is approved and it should have been completed earlier, except there were no skilled developers to be found till then. in my eyes that means that abi v1 has been declared a valid target, but well, i have not red the dev ml prior to that.

nevertheless i dont remember that much of disagreement what concerns the way forward, but then i might be wrong. certainly though i didnt have an impression that it was just a single persons initiative.

92
AROS Software Development / Re: File Manager
« Last post by miker1264 on October 18, 2019, 01:51:53 AM »
I'm miker. It will be an interesting journey trying to get DM2 to work on AROS. It will also be fun to see what OS 4 can do as well. I'd especially like to look at one of those PowerIcons in my hex editor to see what they are made of. It's all interesting.
93
AROS Software Development / Re: File Manager
« Last post by magorium on October 18, 2019, 01:39:42 AM »
fwiw: i could have sworn there was a 64 bit version of dopus on their build-server (back then). At least there used to be a v1 version (so that only the (address)pointers would have been affected).

In case not, making it 64 bit aware would be a problem for almost any piece of software and requires the painstaken process of reviewing/overhauling the code.

as ar as my recollection goes bszili, deadwood, miker (is that you?) and our russian friend (sorry forgot his name) used to work on (old) dopus.

DM2 would be fun to run as well of course  :)
94
General Chat / Re: The situation
« Last post by magorium on October 18, 2019, 01:31:41 AM »
@wawa
Finally a more constructive post from your hand. Thank you for that, although there seem to be some misconception. fwiw: a misconception that was explained on the old aros-exec forums many times.

let me start by writing that
1. this is as far as my recollection goes. It might be wrong, in which case feel free to correct me.
2. i'm generalizing which does not imply i'm addressing individuals.


Quote
ok. afair, at some point the developers consensus has decided that there is going to be abi v1 in particular in order to close tha gap of the source compatibility with the genuine amiga os, that abi v0 has left open. work has been put into this, introducing new platforms such as m68k along the way, which was actually part of the pursuit, because it allowed cross testing behaviour of the binaries with the platform of reference.

There once was a project named AROS which aimed to be(come) a reimplementation of the amiga OS. Progress was made, milestones reached and the project grew (and had a lot of discussions of what would be the correct way to continue).

At a certain point in time it was decided to make it as api compatible as possible, so that old sources could simply be recompiled and run on AROS

In that period it was the believe that whatever AROS tried it would become (almost) impossible to ever make it binary compatible with amiga 68k. One of the main restrictions being the kickstart (how to ever fit AROS kernel in there).

So development went on and api compatibility was not so strict back then (why bother factor). Whenever there was a better way to implement things it was implemented that way (neverminding the api compatibility let alone abi compatibility).

Of course this causes problems being source-compatible so api compatibility was becoming a more serious issue. Things were fixed to overcome that.

Winding forward fast there was one certain individual who said: shite on that, i want AROS to be binary compatible as well. And so he did.

But right before that point (regular) AROS was both abi and api incompatible to 68k amiga. The only way to solve was to create a new abi and 'break' things. Better clean up things (add incompatibilities between abi's) and so it went.

One problem remained and that was that in those days there was a distro and software base for the existing api/abi rendering it incompatible with whatever changes where necessary for Jason to reach his goal.

So things began to split (further) between abi's.

On one hand you need your userbase to have proper feedback/advertisement and on the other hand you want to move on as quickly as possible in order to reach certain goals.


Quote
i think, this has not only influenced low level parts of the system but also userland such as mui/zune. i remember a lot of issues with that back in the day when for instance afaos was designed and differences in behaviour of mui and zune have made special zune versions necessary at times. many apps are dont work right on zune to this day, but it has definitely improved.
It has improved but it is still not compatible. never mind the newer versions, which opens another can of worms.

Quote
now, i understand that part of improvements gone into that effort, because of its duration, have been, for the time being, interim so to say, made available for the public of a stable while obsolete declared abi platform.
Only certain individuals declared it obsolete. If you truly use AROS as your daily driver and develop for it then you can see the incompatibilities and inconsistencies. They are still there.

Quote
i also understand that some developers have become weary of the slow progress and tend to re-declare the obsolete abi v0 valid target and rather try to gather an application pool around it.
Also here only certain individiuals have made it as such.

Picture a whole userbase who enjoy AROS (using old abi) and people using software, running into bugs and reporting them. They are the users that enable a developer to receive (meaningful) feedback about their progress (at least in case a developer is interrested in receiving such feedback).

Quote
but then, why to introduce a binary incompatible platform as a base for that. where is the advantage?
Exactly. Why would you introduce a new abi and add all kind of (new) features that weren't part of the original definition of the OS to begin with ?

Because it is fun, and it is the R in AROS.

And to contrary believe i do support going v1 and 64 bit asap. Unfortunately for me, that ship has sailed many moons ago (*).

The practice is that it is unstable (abi/api changes) so not interresting for me as 3th party developer, many (old) flaws that (still) also exist in v0 that aren't addressed and new features are introduced that are buggy (comes with the territory) and we are still talking about the same missing features.

what i would have expected (ignorant me) is a (proper) round-up for v0 and leave it at that. Fix things when reported and when possible and keep it stable. That leaves room for v1 and 64-bit to mature in its own space and time (and also learn from the reported issues of the old ABI and make things better).

imho better would be to swith to v1 abi (also for v0) and start a new branch for all new features like smp and whatever. That way you would have a 'stable' versions that is api/abi compatible to 68k and in case new features are required (for example because new hardware like vampire can only be supported by such support) could then be backported to the 'stable' branch.

It would allow for the existing software base to exists (without the need for recompilation) and be extended when necessary.

imo that is what deadw00d is/was trying to accomplish with his backport as much as possible, albeit using a different naming scheme and skipping a step/branch.

So, imo your post tells thing a bit in a topsy turvy manner  :)

(*) i used to use AROS in a 24/7 environment using my own custom build and own custom software. So i could not afford to recompile my entire software base over and over again and get blocked by (missing and/or changed) features. Since then i've migrated because it was becoming obvious to me that things were going into a dead end street.

Although i tend to agree with miker1264 that discussing the merits of v0 and v1 does not matter much. It is simple: if you do not care for your existing software to run anymore then it is pretty easy to be happy with using v1. Otherwise you are more or less condemned to use an old(er) abi.

Officially killing off the old abi (or preferring one over the other) isn't going to change that for a bit. What does matter though (and imho) is the way you handle that and how you treat your userbase. Keep in mind that my software has its own userbase for which i'm accountable.

I would say, travel back in time and become a MacOS user so you can experience that feeling fully at first hand.
95
AROS Software Development / Re: File Manager
« Last post by miker1264 on October 18, 2019, 01:29:09 AM »
If anyone is interested here are some customization instructions that shows some of what DM2 can do as a file manager.
96
AROS Software Development / File Manager
« Last post by miker1264 on October 18, 2019, 01:26:43 AM »
This may be controversial for some but I ordered an Amiga OS 4.1 FE install disk and it arrived in the mail yesterday. I will attempt to use an OS 4 version of DiskMaster2 to see what it can do. For the immediate future I need a File Manager for AROS 64bit for file and icon operations and file transfers. DiskMaster2 can be easily configured and maybe easily ported to AROS.

For a while I tried to imagine what changes or additions were needed to make Magellan use Dual Listers which I prefer over two single listers. That option isn't even a possibility for AROS 64bit. Magellan doesn't work there and Scalos doesn't either, just Wanderer. Then I discovered DM2.
97
General Chat / Re: The situation
« Last post by wawa on October 17, 2019, 11:58:51 PM »
ok. afair, at some point the developers consensus has decided that there is going to be abi v1 in particular in order to close tha gap of the source compatibility with the genuine amiga os, that abi v0 has left open. work has been put into this, introducing new platforms such as m68k along the way, which was actually part of the pursuit, because it allowed cross testing behaviour of the binaries with the platform of reference.

i think, this has not only influenced low level parts of the system but also userland such as mui/zune. i remember a lot of issues with that back in the day when for instance afaos was designed and differences in behaviour of mui and zune have made special zune versions necessary at times. many apps are dont work right on zune to this day, but it has definitely improved.

now, i understand that part of improvements gone into that effort, because of its duration, have been, for the time being, interim so to say, made available for the public of a stable while obsolete declared abi platform.

i also understand that some developers have become weary of the slow progress and tend to re-declare the obsolete abi v0 valid target and rather try to gather an application pool around it.

but then, why to introduce a binary incompatible platform as a base for that. where is the advantage?
98
General Chat / Re: The situation
« Last post by nikos on October 17, 2019, 11:17:19 PM »
There are things broken in AROS64. Maybe Deadwood will fix it. I guess he don't want to spend all his time to fix others bugs. I think he is kind of finished with that. Just like Neil seams to be. That is maybe why he got his stable branch. He is the only of the main Devs. that show up here.
99
General Chat / Re: The situation
« Last post by miker1264 on October 17, 2019, 10:57:31 PM »
It's good to discuss important matters. But discussing the merits of ABIv0 or ABIv1 won't change much. AROS 64bit needs software. So start building and making and compiling! That will change things.

AROS has many things going for it that are very attractive. It can run on many different platforms as native or hosted. AROS Hosted on Linux works REALLY WELL. The only other OS hosted on Linux Is Mac OS X. That works well too. Darwin is Linux.
100
General Chat / Re: The situation
« Last post by magorium on October 17, 2019, 10:41:36 PM »
... just im not sure what fud am i spreading.
If you understood the consequences of your words:
Quote
im fully aware of the differences and that you are not dedicated to abi v1. but right now i think the code might have moved too far apart to back port stuff from v1.
That would imply that the work deadw00d put into his list of changes between the abi's (and how to fix certain hickups when you backport) has no meaning at all (at least not to you anymore, as you imply).

fwiw: icaros is based upon this works for many moons now. That also means that if it wasn't for the backport that icaros would have been on hold for several years now. (if you count back from today).

I'm not implying it is still possible to maintain the backport(although deadw00d himself made his comments about that so you can decide for yourself) but taken another remark from your hands:

Quote
actually im not in a position to comment on this, but from my private pov abi v0 is "feature complete" and can be used "as is" completely fine. its also fine when people are fixing it up or contributing to it, if they wish, and they do. personally, i was involved with v1 from the start since m68k is my main area of interest.
of course you are entitled to your own pov, but imo it is wrong. As a devloper of 3th party application i can tell/proof your wrong on many occasions. The situation woul;d have been much worse if the backport wouldn't exist.

To make sure i write it again: current icaros is based on this work and new versions of icaros (whether you consider it a good or bad things that new v0 AROS distro versions are distributed or not) can only exist because of that.
Pages: 1 ... 8 9 [10]