Amiga OS refugees

I’m all for compatibility with Amiga applications, but what’s the point of hosted AROS? It would be like running GNOME or Plasma on top of Haiku.

Except the Zune GUI is much lighter than either of the above. Yes.

Deadwood wrote a desktop environment based on AROS called “Ax” for Linux. Only AROS developers have ever used it but it makes a great cross-development halfway point since it works with the full memory protection sandbox that Linux uses with its user-code.

Ok i will taka a look, thanks

I never got a chance to use Amiga OS and I was curious: What are public screens?

3 Likes

If you are aware of the ‘workspace/pager’ concept on various Linux desktop environments, then it’s a bit like that except:

  • each is created by the user and given a name
  • they can be associated by name to one or more applications
  • they are only opened when the application or user requests them to open
  • they don’t have a ‘desktop’ in the background, just an empty screen
3 Likes

Can you explain more properly about namespace collisions between Aros and Haiku and how is it possible to solve it ?

AROS is writren in C so it doesn’t have name mangling like C++. All the identifiers are in either a global or local namespace. Linux is also written in C but luckily, it diesn’t use any of the same names as AROS.

Haiku is written in C++ but still uses some global namespace. If a subroutine in Haiku’s global namespace required the same exact name as a subroutine in AROS, a hosted environment wouldn’t be possible without some workaround. I haven’t tried making hosted AROS work on Haiku yet so it may be possible in the same way as Linux. It actually isn’t likely that AROS would use a subroutine name from Haiku because Haiku’s subroutines are all prefixed with a capital “B”, owing to its BeOS heritage.

Great, thanks for detailed answer, but it seems that another difficulty is that we need to build a 32 bit aros on a 64 bit host system:

also building of 64 bit Aros is also possible:

but in this case the software for 32-bit AROS will not work under 64-bit AROS. 32-bit AROS however perfectly works on 64-bit Linux.

2 Likes

There has been some effort to get 32-bit Haiku to run under 64-bit Haiku. Since BeOS was a 32-bit binary format, old BeOS executables only work on a 32-bit Haiku environment (or an old BeOS release). If you get hosted AROS to work on 32-bit Haiku, that may be sufficient to get it working in the future on all Haiku x86-based releases.

Do we need a 32 bit virtual environment to run 32 bit binaries ? It would be powerful without qemu.

2 Likes

One of the Haiku team is working on running 32-bit Haiku apps on 64-bit Haiku without QEmu.

1 Like

Great, where can we read about the progress on his work ?

I don’t remember which one but there are monthly updates on the blog that shows the team progress.

C doesn’t have namespaces it has name spaces. Different concept entirely. Name spaces in C are all to do with “scoping” specific categories of identifier. C++ has namespaces, which allows module level hiding, like this:

namespace Foo
{
  int x;
}

int x;

::x and Foo::x are different variables, and Foo::x is in the Foo namespace, and ::x (or just x) is in the global namespace.

What C usually does to emulate this is to use scoping prefixes.

The Be API was all in a global namespace, possibly because namespaces in C+ came in to fashion later than the BeAPI was already set in stone. The C++ in the BeAPI is all in the C++ Global namespace because of the… so the :: scope.

Haiku is sort of stuck with that because of compatibility with R5. So, the Be API, using the oldschool pre namespace style, prefixed everything with B (as you mention). This was very common in the 90’s (namespaces might even have not been added to the C++ language at that point.) So other platforms did the same thing…Qt used to use Q. Turbo C++ (OWL) used T. MFC used C. In each API you might have a Button, but BButton, QButton, TButton or CButton is the class name. The BeAPI is a legacy of this time. One thing that Kurt Skauen did with AtheOS was to add in namespaces IIRC.

This is not true. It depends on the Kit. I’m pretty sure a lot of the C functions in Be API have no prefixes. But also be careful. BeAPI apps are C++, and namespace in C++ != name space in C.

What you are also missing is that Headers come in to play. If you don’t include the header with a name clash, you won’t have an issue. So it becomes about structuring you code so that different .c or .cpp files build .o files, and are linked and you try to make sure that the devs in any given .o file do not clash. If you order your headers correctly you can do it.

1 Like