AROS ABIv11 64-bit 2026.09 Development: AROS FORUMS

AROS ABIv11 64-bit 2026.09 Development

Last updated on 7 hours ago

deadwoodAROS Dev

Posted 7 hours ago

@aros-sg

Looking at code I don't see how this can be stable, unless it defaults to running all tasks on same core. Does it?

For example there are certain (legal/documented/official) ways to do things that require Forbid()/Permit() protection. Like closing window safely if msgport is shared among multiple windows. Like Zune/MUI is doing for example in workbench/libs/muimaster/classes/window.c. If the Forbid() in there only blocks tasks on 1 core, but not all cores, then that code is not safe in SMP as Intuition InputHandler (input.device task) from other core could still send messages to the port.

Also task exit code/procedure often relies on Forbid() to block all tasks from running. Otherwise it is not safe.

It would be best if you take it up with Kalamatee. He is not a member of this forum though. He can be reached via linen/slack channel. You can find links to this channel in developer section of www.aros.org.

Edited by deadwood on 09-09-2026 00:43, 7 hours ago

aros-sgJunior Member

Posted 1 day ago

#19

Quote

you can also try SMP - just to see how it works.

Looking at code I don't see how this can be stable, unless it defaults to running all tasks on same core. Does it?

For example there are certain (legal/documented/official) ways to do things that require Forbid()/Permit() protection. Like closing window safely if msgport is shared among multiple windows. Like Zune/MUI is doing for example in workbench/libs/muimaster/classes/window.c. If the Forbid() in there only blocks tasks on 1 core, but not all cores, then that code is not safe in SMP as Intuition InputHandler (input.device task) from other core could still send messages to the port.

Also task exit code/procedure often relies on Forbid() to block all tasks from running. Otherwise it is not safe.

1 user reacted to this post

sonountaleban

Amiwell79Distro Maintainer

Posted 1 day ago

#18

after the update I haven't noticed any issues

2 users reacted to this post

aha, deadwood

deadwoodAROS Dev

Posted 2 days ago

#17

@Amiwell79, @terminills

I moved your posts to a new thread. This thread will be locked right after release in a few days.

deadwoodAROS Dev

Posted 3 days ago

#16

Yes, standard version is correct for comparison with this release. If you have time you can also try SMP - just to see how it works.

1 user reacted to this post

Argo

ntromansVeteran Member

Posted 3 days ago

#15

deadwood wrote:

@deadwood - Thanks for the tests and I'm glad it worked eventually for you!

When you have time, could you try ABIv1 nightly build and see if the behavior is the same?

I was going to ask if a comparison would be useful

. I'll give it a try on ABI1; I presume the standard version rather than SMP?

Cheers,
Nigel.

deadwoodAROS Dev

Posted 3 days ago

#14

Thanks for the tests and I'm glad it worked eventually for you!

When you have time, could you try ABIv1 nightly build and see if the behavior is the same?

ntromansVeteran Member

Posted 4 days ago

#13

Latest update installed to my i5 laptop; no issue with boot or starting OWB.

My USB audio adapter arrived in time to try with the new release. It's recognised bu Posiedon, bound to usbaudio.class and is visible in AHI prefs. Unfortunately, it fails to produce an audio output on pressing 'Play a test sound', with Trident reporting an endpoint stall. It's the same behaviour in both USB2 and USB3 ports. I've attached the Trident log in case that is of any help.

Cheers,
Nigel.

Edit: More tests:

If the device is plugged in before boot into a USB2 port, it works.

If the device is plugged into a USB2 port after boot, it does not work.

With USB3, neither plugging in before or after boot works.

Saying that, that fact it works at all is really good news. No need to stress if a laptop has supported audio or not, since if the latter there's now the USB audio option.

Edited by ntromans on 05-09-2026 19:34, 3 days ago

3 users reacted to this post

Argo, deadwood, retrofaza

You do not have access to view attachments

miker1264Software Dev

Posted 4 days ago

#12

@tom1000

Welcome! I'm glad you successfully installed your AROS test system. :-)

It took me a month to setup my 64bit cross compiler on Ubuntu 24.04 but I think I'm a slow learner!

I also purchased a Raspberry Pi 400. It arrived a few days ago. I look forward to compiling some of my own software to test on AROS Pi.
That's what I call it, for lack of a better name. I have some small graphics programs that I'm going to re-write and compile for Amiga 68k using the same code for AROS. I'd like to compile them for Raspberry.

I suppose they are written in BOOPSI code. It's the traditional Amiga code that uses intuition windows, menus & Datatypes to use for graphics ops.

Anyhow, that's a long-worded "Hello'.

Edited by miker1264 on 05-09-2026 13:23, 4 days ago

4 users reacted to this post

aha, tom1000, Argo, Bohun

deadwoodAROS Dev

Posted 4 days ago

#11

Great to see you picking up development! I actually prepared a setup to coding agents that might be intersting for you, check it here: https://arosworld.org/infusions/forum/viewthread.php?thread_id=1933&rowstart=0#post_11881 It using diffent coding agent (opencode) but must of the things are transferable to Claude Code I think. Good luck with your coding endevour!

2 users reacted to this post

tom1000, terminills

tom1000Newbie

Posted 4 days ago

#10

FWIW - i don't know if this is interesting to the group but i'm pretty happy i just got an AROS environment running on Linux x86_64 using github/deadwood2 setup and Claude directing me. I have a Workbench window!

I was an old time Amiga user and came across a video AROS on a RPi3 last week. That prompted me to investigate more. I always wanted to write a BOOPSI program, and now I can, and I'll be able to use a coding agent to help too. Wow - This is cool.

6 users reacted to this post

retrofaza, Deremon, Bohun, miker1264, terminills, Argo

deadwoodAROS Dev

Posted 4 days ago

And here is Release Candidate 1! It has been a long road but we are almost there!

IMPORTANT:

Unless a critical issue is found, these exact builds will become the official 2026.09 release.

Any new, non-cricital issues will be handled as update package later. I will keep these builds here for around a week so that anyone has time to try them out.

Final update for 20250418-1 that upgrades it to 2026.09:
https://axrt.org/download/aros/v11/AROS-20250418-1-U4-any-x86_64-update.zip

New release of SDK:
https://axrt.org/download/aros/v11/SDK-202609-RC1.zip

If you want to install SDK, just delete/rename your existing Development directory and use the one from archive.

System and contrib builds:
https://axrt.org/download/aros/v11/AROS-202609-RC1-pc-x86_64-boot-iso.zip
https://axrt.org/download/aros/v11/AROS-202609-RC1-linux-x86_64-system.tar.gz
https://axrt.org/download/aros/v11/AROS-202609-RC1-any-x86_64-contrib.tar.gz

Fixed in RC1:
- Usability improvements to BoingIconBar (retrofaza)
- Fixed alpha rendering in Dtpic.mui (retrofaza)
- Wanderer: Ask "overwrite" followup fixes (Telematix)
- ca-bundle.crt updated (enbewu)

6 users reacted to this post

amigamia, sonountaleban, Amiwell79, retrofaza, Argo, Deremon

deadwoodAROS Dev

Posted 5 days ago

SDL2 is also there, see: https://github.com/aros-development-team/contrib/tree/master/SDL2. SDL2 is soemthing that is available in both.

1 user reacted to this post

coffeecat

coffeecatJunior Member

Posted 5 days ago

In mainline, I see SDL3, but I don't see SDL2; In AROS One, I see SDL2 but not SDL3. Which one to target?

ntromansVeteran Member

Posted 5 days ago

Telematix wrote:

@Telematix -
Telematix wrote:
@Telematix - Thank you very much for the tests.

Yes, there was an error moving files related to the protection bit. When the user declined to unprotect a file the move stopped.
There were also a pair of bugs and they have been hunted down, I'm testing the new version and hope to have it merged soon.

Here it is.
It should not fail, but please, let me know if you find a case.

Installed and looks to be working absolutely fine

Many thanks for this; that particular bug has been an ittitation for a while now and it's great to see it squished.

Cheers,
Nigel.

3 users reacted to this post

Argo, Telematix, deadwood

deadwoodAROS Dev

Posted 5 days ago

@coffeecat

Thanks for reporting both issues!

ca-certificate - good catch! I'm just in process of building the release so I will update this immediatelly at my side, but please submit a PR for https://github.com/aros-development-team/AROS

openssl - I need to understand context better. Are you building openssl from here https://github.com/aros-development-team/contrib (because my contrib only has openssl 1.1.0h) against (1) https://github.com/deadwood2/AROS or (2) https://github.com/aros-development-team/AROS?

If (1) then yes, you are correct and such change is needed because of split of file descriptors between C library and network stack.

if (2) then I don't know. The network stack was recently updated and from what I saw a bridge library has been introduced to make C library and network stack file descriptors uniform (these changes are not yet synchronized to my tree). What this mean is that possibly the original POSIC code may already work in this scenarion and no changes to patch are needed.

1 user reacted to this post

Argo

coffeecatJunior Member

Posted 6 days ago

Not sure if it's the right thread or even forum but:
ENVARC:SYS/Certificates/ca-bundle.crt - does anyone maintain this? I see the certs are quite outdated (as in 8 years) - would a refresh-patch be okay? Any preferred way to do it?
Are patches to OpenSSL welcome? Any rules for committing them?

The AROS port in contrib/development/libs/openssl builds and links fine, but a TLS client handshake fails. SSL_connect() returns an error and tls_validate_record_header reports:

Code Download source



wrong version number

At the same time, fragments of the executable may appear on stdout.

The problem is not in TLS itself.

On AROS, sockets come from bsdsocket.library / AROSTCP, and bsdsocket descriptors are not C library file descriptors. They use a separate descriptor namespace.

In include/internal/sockets.h, AROS currently falls through to the generic POSIX definitions:

Code Download source



#define readsocket(s, b, n) read((s), (b), (n))

#define writesocket(s, b, n) write((s), (b), (n))

#define closesocket(s) close(s)

#define ioctlsocket(a, b, c) ioctl(a, b, c)

This means OpenSSL passes a bsdsocket descriptor to libc.

If libc resolves the same integer as a DOS file handle, the TLS ClientHello gets written to a file, and the supposed server response is read back from it. That explains both the invalid TLS record header and executable bytes appearing on stdout.

The fix is to keep socket I/O inside bsdsocket.library, as the existing AROS port already does elsewhere:

Code Download source



#elif defined(OPENSSL_SYS_AROS)

#define ioctlsocket(a, b, c) IoctlSocket((a), (b), (char *)(c))

#define closesocket(s) CloseSocket(s)

#define readsocket(s, b, n) recv((s), (b), (n), 0)

#define writesocket(s, b, n) send((s), (b), (n), 0)

#define writesocket_ex(s, b, n, f) send((s), (b), (n), (f))

This should be placed before the final #else in the readsocket / writesocket block of include/internal/sockets.h.
recv() and send() are the bsdsocket implementations, so the descriptor stays in the correct namespace.

The existing openssl-4.0.1-aros.diff already modifies this file to avoid including <poll.h> on AROS, so this can naturally extend the same patch.
With this change applied, bss_sock.o builds cleanly, and a TLS 1.3 client handshake against a real HTTPS server succeeds on AROS x86_64.

Have I read something wrong?

Edited by coffeecat on 03-09-2026 16:45, 6 days ago

deadwoodAROS Dev

Posted 6 days ago

If you are looking for ISO it's 20240518-1

https://axrt.org/downloads-aros-64bit

You need to install it and then apply the U3 update that is on the same page.

Alternativelly grab D05 ISO from this thread. The upcoming 2026.09 release will be 99.9% same as D05.

1 user reacted to this post

miker1264

miker1264Software Dev

Posted 6 days ago

Which is the most current but stable release of x86-64 ?

I'd like to setup a 64bit test system in the new VMWare but it's much faster and easier to customize the current version than install a distro.

TelematixJunior Member

Posted 6 days ago

Telematix wrote:

@Telematix - Thank you very much for the tests.

Yes, there was an error moving files related to the protection bit. When the user declined to unprotect a file the move stopped.
There were also a pair of bugs and they have been hunted down, I'm testing the new version and hope to have it merged soon.

Here it is.
It should not fail, but please, let me know if you find a case.

You do not have access to view attachments

You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.

Moderator: Administrator, Moderators

Users who participated in discussion: deadwood, AMIGASYSTEM, ntromans, retrofaza, Amiwell79, miker1264, Jeff1138, arosbeginner, Telematix, ncafferkey, sonountaleban, aros-sg, coffeecat, tom1000

Search AROSWorld

AROS ABIv11 64-bit 2026.09 Development