AmigaOS 3.2 and beyond

[ma693541]

Will the text editor in AmigaOS 3.2 have a option in the menu to import your own programming language syntax plugins? Like the feature in NotePad++.

[boemann]

Originally Posted by ma693541

Will the text editor in AmigaOS 3.2 have a option in the menu to import your own programming language syntax plugins? Like the feature in NotePad++.

Not in 3.2 no. It is part of my long term plan, but I need to be certain that such a developer interface exposes the right amount of things for developers to work with. And I don't have time for that in the coming months. Also we haven't settled on a release plan yet but we can't go on putting features in forever. After a feature freeze we need a substantial amount of time to ensure what we have didn't bring in new bugs. So in essence every time we start making a new feature (by request or because we internally agree there is a need) we are also effectively delaying a release even if we don't have a specific date we see getting pushed. I hope this rationale makes it clear why we can't take on every feature request, and also gives some kind of insight into when we release

[boemann]

Originally Posted by Daedalus

OS 4 works around this by using the zoom gadget with a qualifier (shift). So clicking with shift on the zoom button maximises the window. It works really well and doesn't interfere with existing gadgets, border frames etc

Yes that is a very likely way I'm going to implement it, but I'm still looking into it. An addition to that approach would be a preference option to replace the zoom gadget with maximize, and then have shift+maximize act as the zoom gadget. Then the user can get the default behavior most often used while in either case still having the opposite functionality too.

[Olaf Barthel]

Originally Posted by th4t1guy

To go back to talk about version numbers, I think it's a bit more clear if the version number is kept as 3.1.x instead of 3.x

The reason would be that it seems 3.5/3.9 are viewed more as forks of 3.1. 3.10 or 3.11 would imply that it's built on top of 3.9. 3.2 also seems to imply that it's older than 3.5. But a 3.1.5 would imply that it's built on top of 3.1

How dare you to try and apply logic to this

Seriously, the work that went into what became AmigaOS 3.1.4 and beyond builds directly upon the AmigaOS 3.1 foundations. That is where the numbering scheme has its origins.

The AmigaOS 3.5/3.9 work uses product names which I'm not sure I understand the origins of (but then I must admit that I haven't even been trying during the past 20+ years).

So, please leave it at that. We are trying to make something better out of a neglected Amiga operating system version. This is the biggest overhaul of the entire AmigaOS 3.1 codebase in three decades.

[Olaf Barthel]

Originally Posted by Solskogen

Will you, or are you, talking to the AROS guys? Or are there license issues and/or developer issues with you guys combining forces?

You knew that this answer was coming: it's complicated.

There is enough common ground among the AROS, MorphOS, AmigaOS4 and AmigaOS 3.1.x/3.2 to share ideas or code which could be beneficial for everyone. However, this is offset by what I would frame as lack of trust. Trust is easily eroded and it needs to be earned.

I believe we are not yet making progress with regard to building trust. There is also a certain lack of knowledge on what exactly would be worth sharing in terms of idea or code. Everybody's doing well in their respective domain, aren't they?

And that's before we even get into the murky waters of legal complications.

[kamelito]

There’s better compiler now that produced better code than SAS/C is their plan at one point to use such compilers?

[StevenJGore]

Originally Posted by Olaf Barthel

This is the biggest overhaul of the entire AmigaOS 3.1 codebase in three decades.

I've nothing useful to contribute to this thread, but I just wanted to say a huge thanks for the effort that everybody involved is putting into this.

This thread (and finally having the time to set up my 3.1.4 install properly) is genuinely helping me get through coronavirus isolation!

[boemann]

Originally Posted by kamelito

There’s better compiler now that produced better code than SAS/C is their plan at one point to use such compilers?

It would be a huge undertaking given that compilers are not 100% compatible, and even then there might sneak in some bugs due to sideeffects that some code relied on. Changing compiler has been done before though in the history of the OS, so it isn't impossible.

That said, yeah it would be nice, but it has to be a native compiler. So if people would want to help this along I suggest helping beppo and working on making his gcc work natively on the Amiga. His project is opensource so will help the entire Amiga community. We have talked about this already internally and are willing to help out, but if other people want to help out too it would be much appreciated.

[Olaf Barthel]

Originally Posted by kamelito

There’s better compiler now that produced better code than SAS/C is their plan at one point to use such compilers?

In the long term there has to be a different compiler at the centre of the build process. We are using the tried and tested compilers that were used to build the operating system in the years leading up to 1994 (although Commodore did not use SAS/C until very late, and we're not using that particular version which was current in 1994).

The main reason for sticking with the Lattice 'C' and SAS/C compilers is that they are the best-integrated into the Amiga operating system. That level of integration, with DICE being a contender (it's too old to be useful, unfortunately), is tough to beat. It worked both ways when Commodore was still "in business" and the Lattice 'C' and SAS/C compilers evolved as Commodore shifted to native development, with feedback going from the Commodore developers to Lattice and SAS, Inc.

We have a complete tool chain for these compilers, and that includes QA tools which use the particular debugging information which the compilers produce, as well as a functionally complete (but old) interactive debugger (CodeProbe).

As far as I know, this is not the kind of mix which the other contenders, such as VBCC or GCC can currently offer. I dearly wish this were different because we are boxed in by what the Lattice 'C' and SAS/C compilers allow us to do, and we are fully aware of that.

Code quality is part of what makes a compiler useful, but we need more than quality. We have a well-integrated package, and we need an interactive debugger that runs on real hardware in real time and lets you trace into 'C' source code (showing you context and variable values).

That said, our tentative plans to make a new NDK 3.2 include getting the best possible support for compilers other than SAS/C and tools of the same age off the ground. You should be able to build your software using cross compilers, and the code generation should not drop a random warning at every second line translated because the header files lack polishing.

We dearly want to provide a set of native tools which can be used for Amiga software development. This means making compromises because of the inevitable memory and disk space requirements. It would be great if DICE could be woken out of its 25+ year slumber because it is so well-integrated into AmigaOS, but that's a big wish, I'm afraid

That leaves GCC, and as far as I can tell, the only usable version that is still small enough for smaller Amiga systems is still huge. You can build it natively now, though (using my clib2, for example), and that should account for something.

[Kyle_Human]

If we're going to ask for tall order features for software development, then how about a simple compile time check to see if the program will be font sensitive and allow the user to choose what screen it opens on. If it fails the check then a hatch on the computer should open up and a boxing glove on a spring deliver the developer a knock to the bollocks.

[gulliver]

Originally Posted by Kyle_Human

If we're going to ask for tall order features for software development, then how about a simple compile time check to see if the program will be font sensitive and allow the user to choose what screen it opens on. If it fails the check then a hatch on the computer should open up and a boxing glove on a spring deliver the developer a knock to the bollocks.

Thank you!

[boemann]

Originally Posted by Daedalus

OS 4 works around this by using the zoom gadget with a qualifier (shift). So clicking with shift on the zoom button maximises the window. It works really well and doesn't interfere with existing gadgets, border frames etc.

Done. AmigaOS 3.2 will now have that feature too.

[th4t1guy]

Originally Posted by Daedalus

It's built on top of some parts of 3.9, but is meant as a continuation of 3.1. I don't understand how 3.1.5 implies that it's based on 3.1 but 3.2 doesn't...

I think the problem comes from trying to make the newer versions fit in the context of the existing versions. After 3.2 would it be 3.3? At some point it will collide with 3.5. So you could consider the 3.1 in "Workbench 3.1" to be part of the OS name instead of a version number. Then adding versions after that you get 3.1.x (or even 3.1.x.x, etc.). However, this is all just my opinion.
Whoever writes the code gets to call it whatever they want, so I have no issues with it being called 3.2

[Spacemonkey]

Originally Posted by th4t1guy

I think the problem comes from trying to make the newer versions fit in the context of the existing versions. After 3.2 would it be 3.3? At some point it will collide with 3.5. So you could consider the 3.1 in "Workbench 3.1" to be part of the OS name instead of a version number. Then adding versions after that you get 3.1.x (or even 3.1.x.x, etc.). However, this is all just my opinion.
Whoever writes the code gets to call it whatever they want, so I have no issues with it being called 3.2

I would got to 3.10 after 3.2

[Daedalus]

Originally Posted by boemann

Done. AmigaOS 3.2 will now have that feature too.

Sweeeeet! Thanks

Originally Posted by th4t1guy

I think the problem comes from trying to make the newer versions fit in the context of the existing versions. After 3.2 would it be 3.3? At some point it will collide with 3.5. So you could consider the 3.1 in "Workbench 3.1" to be part of the OS name instead of a version number. Then adding versions after that you get 3.1.x (or even 3.1.x.x, etc.)

Yeah, there's no simple answer to the versioning, since using the third digit (3.1.4, 3.1.5) makes it sound like a minor update when in reality the changes are easily bigger than between 3.0 and 3.1 and thus warrant a major revision bump. The collision is inevitable I guess, but by that point I hope (and at the current pace I don't think that hope's unrealistic) that the features list would beat 3.9 in enough aspect to justify the jump to 3.10

[Rotzloeffel]

Originally Posted by Jope

Screensmenu/window menu? Built in sysihack gadgets? Resize from every edge? :-)

Yes, all of these are implementet…. iconifying Windows, resize from every Edge....

[Olaf Barthel]

Originally Posted by Spacemonkey

I would got to 3.10 after 3.2

We'll paint that bridge, eventually, when we've built it

[Tigerskunk]

Originally Posted by Rotzloeffel

Yes, all of these are implementet…. iconifying Windows, resize from every Edge....

Very nice.. this will be an amazing update. Can't wait.

[E-Penguin]

How about some games? Minesweeper, Solitaire..?

[th4t1guy]

One thing that's always annoyed me with Workbench is how icons tend to pile on top of each other. It seems to happen all the time to me, especially when copying folders/files from PC. It would be great to see the need to run "clean up" and "snapshot" disappear.