@madmonkey

Can't the same be said for MUI?

Well i think the point would be to have a bundle that allows for LLM's to have a reference for things they do not 'know' from their training, avoiding hallucination of APIs that don't exist, and knowledge of new APIs for which there wasn't much training material to work from or for third party APIs to be more readily in scope of the LLM. For example Claude knows AmigaOS 3.1 very well and 4 quite well. But does it know anything about additions in OS3.2, or how to use AmiSSL? No it does not. Using continue.dev should fix that. and it needs to be constantly reminded to use latin1, C89 etc and not veer off into assuming POSIX and more is acceptable.

Great timing!

Does anyone think it would be a useful idea to create a continue.dev package for AmigaOS SDKs? Is anyone interested in collaborating in making one?

@joerg

Could an AI agent help?

This thread is a great example of the barriers to entry for Amiga development.

The OS4 SDK that's available is great in terms of a one click install everything. The new OS3 NDK would do well to take lessons from that.

Trouble is, once you start to use it you discover that it's massively out of date, you don't have the new, working versions of lots of stuff, have wrong header files and so on, and to get the newer ones you have to be on the insiders clique of OS4 beta testers, sign an NDA/non aggression pact etc.

OS3 the problem is different - you either have to source a pirate copy of SAS/C, put up with ancient GCC or get VBCC installed and configured. Even then, everyone installs everything in different places on their work: drives so forget about collaborating with other people. No one in Amiga land seems to have heard of 'configuration management' and I don't just mean svn/git I mean Developer eXperience.

Or, as Hans says, you're stuck with building everything yourself using cross compilers and other things one shouldn't have to fuss with.

Back in 2003 I tried to use clib2 for 68k as it was at the time, together with GCC, actually GCC3 or 4 IIRC since 2.95 was too old to work with the Python code base, to update Amiga Python from Irmen de Jong. I got part of the way but it was just too much debugging the toolchain and not enough working on the actual port I eventually gave up. Here in 2025 the situation has hardly improved!

@Tuvok Well even on OS4 the challenge is the same. If you want multibyte characters everywhere, you're going to break everything. If you want UTF8 just in filenames and your text editor and the font engine (and your browser, which tend to handle text and fonts independently anyway), there are ways to do it that feel kludgy but will work for the most important use cases. And those ways are to do what Windows 95 had to do with 8.3 names.

It was Symbian not Nokia but same difference

@Chris thanks for the OS3/4 discrepancy list! Is that complete as far as you know (not counting new subsystems that don't exist at all like application.library)

@LiveForIt tell Camilla, she's open to feedback, or write a plugin https://gitlab.com/boemann/texteditfiletypeplugins - i think the plugins only do syntax highlighting now, but perhaps you could suggest how she can extend it also for indentation, which would be relevant for Python also. If it's not a problem in her view for TextEdit, surely it would be for her IDE project. I'm sure she'd also be interested in discussing how UTF8 could be supported and your expertise on that topic.

@Chris again. I'd argue RoadShow doesn't need any of those things, as when will you ever not be using an Amiga on a LAN behind a router which in turn is behind a NAT. I doubt an Amiga will ever be used in a configuration that needs IPv6 directly And it's a huge effort - did you know Microsoft bought their IPv6 stack from Lancaster University because they'd waited too long to write their own? Or that Symbian OS's was written entirely by Nokia taking about 1200 man years?

@Tuvok Unfortunately adding utf8 support is not simple. When Symbian switched from single byte characters to double and variable byte characters, they completely broke backwards compatibility, only source compatibility was retained. @LiveForIt can explain it better than I can I'm sure, he's a subject matter expert. I think the best we could hope for would be a hack like the old FAT long file names - using the Comment parameter or a TOOLTYPE to store a utf8 name, which would then only be shown cosmetically in apps that supported it, Workbench or ASL. The true file name would still be used for everything else. And even then you won't get CJK, Arabic, Hebrew, Thai, Devanagari, Emoji etc.

Love hearing all the ideas and wishlists ! Keep going!

Resurrecting my thread, with a slightly different angle - what's missing from the core OS (3 or 4) in 2025? Not counting defacto core OS add-ons like AHI and P96

Here's a starter for ten:

1) A multimedia framework like QuickTime - although OS4 almost has it through the va library suite

2) A MarkDown format rich text datatype

3) A mDNS stack on top of Roadshow

Great news thank you. Finally the investment in funding Jacek is paying off.

I think Camilla is the best person to ask and she only hangs out on discord and amiga.org and also the https://developer.amigaos3.net/ forum AFAIK

any new news on cinnamon writer?

What do you mean?

@white you seem to have completely misunderstood my message

@balaton

The OP obviously

it would be awesome if you could provide a linux VM image with QEMU all configured correctly and all one has to do is drop in your own OS4 licensed copy ISO to make it work.

I think youtube long since retired their RSS feeds, same with Twitter. Anything that depends on Shockwave i.e. Flash would also be long dead.

Now that AI coding technology is here maybe someone can write a new RSS reader for Amiga!

HD6450 works fine but... it's a passive cooled card why you even have a fan on it??

totally agree with @PJS on the amiga way of window management, with a couple of caveats:

- There's never been a true standard for Zoom behaviour - some (typically fixed size windows, like Calculator) minify to a title bar (in which case why not just iconify), others toggle between two different user set sizes i.e. the current size and the previous size, others toggle between 'current size' and 'full size'. Of course, since it's up to the software to decide what to do with the zoom event there's no way to retrofit a different solution. but it would be nice to set some guidelines for how it *should* be done albeit there's not much new software coming out these days...

- Thanks largely to MUI, for better or worse, Iconify became a defacto standard, I think because of MUI but not a standard set by cool people like Martin Taillefer, RJ Mical or Dale Luck, so it's always felt a bit awkward. However it has been adopted in OS4/3.2 formally as a thing. At least the behaviour is obvious and consistent - hide the window, make an AppIcon on workbench. Open the appicon again - unhide the window. I'd like to see other apps able to 'hook' into appicon to replace/augment the workbench functionality so i can send iconified apps to a dock instead for example.

For me arguably the zoom, depth and iconify gadgets would benefit from an overhaul and consolidation. zoom to title bar is not really any different from iconify is it? i mean, if you make an app zoom to title bar only, like calculator or iconedit, what you're really saying is 'get this out the way'. While depth gadget would benefit from some screen management features like 'move to pubscreen' not that public screens were ever properly implemented either...

Having said that it's not as if other platforms do it better. Even the one you'd expect to do it best (Mac) has problems still. While close and iconify are consistent, it's green 'zoom' button is a mess, so much so they added a whole submenu to it in recent releases...

especially if dragging an icon onto it did a move/copy same as the window does, sure why not.

Although, iconify in general needs a rethink, it's a bit of a mess.