Welcome, Guest. Please login or register.

Author Topic: How to move AROS forward  (Read 30484 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Belial6

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 568
    • Show all replies
    • http://www.glasshead.net
Re: How to move AROS forward
« on: July 28, 2008, 06:23:50 PM »
"I'd be happy if they did break compatibility and provide a sand-box for old apps. While they're doing that, they might as well break other stuff to allow SMP, and to lock off user programs from accessing OS structures. "

I agree with you.  Of course this brings the conversaton back to the forking argument.  The point of not breaking compatibility is so old software could continue to run.  Right now, we have to rely on AInc to run most old software because they own the Kickstarts.  My primary interst in AROS is that I keep hoping that it will eventually get reported to the 68k, and we could finally get rid of AInc.  

I guess the way I see it is that for any old software, I want to be able to run it on my MiniMig, one of it's successors, and maybe UAE.  For new software, it doesn't matter if we break compatibility with the old API.

To answer the original questions:

1. Can it be done?
Yes.

2. Can it be done elegantly?
Sure, if Aros was ported to 68k so that we don't have to go to AInc to get kickstarts, and UAE were integrated so that it worked out of the box using that port it be plenty elegant.

3. Should it be done?

That is the question.  I would say it would make sense, but that the 68k port is far more important than it is given credit for.

 

Offline Belial6

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 568
    • Show all replies
    • http://www.glasshead.net
Re: How to move AROS forward
« Reply #1 on: July 29, 2008, 08:00:48 AM »
Quote

now this assembles to:
0x10011101120313

that's our actual binary executable for our mythical computer there.

Now, suppose I write a program (for a version of this computer with more memory and some I/O capability) which stores a user password. This will be done by using two four-bit 'bytes' per character, so we'll use ASCII. Only we're going to use ROT-n to encode the passwords so they can't be as easily read. Arbitrarily, the program has selected -21 for the offset, n, so each letter has 21 subtracted from it's ASCII value before storage. So if the user enters password "#l|l}n~" we get 0x10011101120313 as the encoded password.


That would be a cool 'Demo' challenge.  Make programs that are actual sentences in ascii, but do when run as code, do something... or nothing, but don't crash.