Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

AROS 64-bit 2026.09 Development

Last updated on 7 hours ago
N
ntromansVeteran Member
Posted 3 days ago
Had another try with the copy/overwrite/ test, setting flags from icon/informtaion and launchign Format from its icon; all the same rsults I'm afraid. On the othe rhand, update went smoothly, no issue booting, so all else seems good.

Re. USB audio, is it now possible to try to get udio output through a USB device of is this still still WIP?

Cheers,
Nigel.
D
deadwoodAROS Dev
Posted 3 days ago
Thanks for the tests Smile

usbaudio should now be working. I don't have hardware to test it but Kalamatee says it works for him. Please try it.
T
TelematixJunior Member
Posted 3 days ago
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.
aha, miker1264, ntromans
N
ntromansVeteran Member
Posted 2 days ago
Just had a crash with Wanderer triggred by closing a window - please see attached.

Cheers,
Nigel.

P.S. Just ordered a USB audio adapter to try. It includeds a microphone input; I'm really hoping recordign can be supported.
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 2 days ago
That looks like some sort of memory corruption. What were you doing in Wanderer prior to having this crash?
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 2 days ago
In Deadwood, I noticed the system freezes when I run GCC from the shell and try to copy and paste into the editor using the Amiga + C or F12 + C keys.

This problem only occurs the first time you try to copy; if it doesn’t happen the first time, it won’t happen again.

Unfortunately, this doesn’t happen every time, so I need to test whether the same thing happens with Build as well.

In this regard, I'd like to ask if it would be possible in the future to enable the Shell to perform a “Copy” operation using the mouse.
D
deadwoodAROS Dev
Posted 2 days ago
Does it have anything to do with running GCC before it? Or simply copying any text from Shell can lead to freeze.

With regards to mouse:

I just did:

type s/startup-sequence
marked text with mouse
selected copy from menu
opened edit
selected paste from menu

Text was pasted into editor. See screenshot.
You do not have access to view attachments
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 2 days ago
The problem only occurs on AROS One. If I use the drop-down menu, everything works, but if I use the pop-up menu, it doesn't work. In some cases, I even get a Guru error, see the screenshot. I need to look into this.
You do not have access to view attachments
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 2 days ago
I deleted the icontrol.prefs file and then created a new one.
It seems the problem has gone away; perhaps the icontrol.prefs file belonged to an older version of AROS One. I'll keep testing to see if it comes back.
N
ntromansVeteran Member
Posted 2 days ago

deadwood wrote:

@deadwood - That looks like some sort of memory corruption. What were you doing in Wanderer prior to having this crash?


Just closing a set of drawer windows - the crash happened on closing the last one open. OWB and a shell was open too (I'd just used wget in the latter to download the MorphOS prefs panel image to ram: ).

Cheers,
Nigel.
Edited by ntromans on 03-09-2026 07:08, 17 hours ago
D
deadwoodAROS Dev
Posted 1 day ago
@ntromans

Similar crash has been reported by @retrofaza. If you figure out a way to trigger it in a predictable way, let me know.
T
TelematixJunior Member
Posted 14 hours 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
M
miker1264Software Dev
Posted 14 hours 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.
D
deadwoodAROS Dev
Posted 14 hours 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.
C
coffeecatJunior Member
Posted 7 hours 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:


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:


#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:


#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, 7 hours ago
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.