New improved intuition.library version from the Kickstart 3.1

[itix]

>OS 3.5 introduced GlowIcons (which I already had in NewIcons format)

NewIcons is just an unofficial "hack and patch" based on tooltypes, whereas GlowIcons is a proper upgrade to the icon system, the two are not at all equivalent.

Not really hack and patch. NewIcons just replaces original icon image with image encoded in tooltypes. It is slower but works and is quite clean. Glowicons append IFF ICON chunk to end of icon file. Users dont really care how icon data is stored.

>The more recent releases have no big API updates anyway

Yes they do, obviously you haven't read the autodocs.

I did. New calls in Exec are not important. Improved printer.device is useful only to few application developers who want to support printing and it is probably enough if you support Turboprint. Icon.library changes -- not very useful to average developers. Me being MUI developer I dont have to deal with icon.library except when using GetDiskObject() to get proper app icon and icon.library new API was probably meant to support future 3rd party WB enhancers (?). Workbench.library changes are nice, OpenWorkbenchObject() is one of few new API calls I have ever used.

ClassAct is avaibale from Aminet and had they chosen to use MUI instead it would have not made any difference.

[OlafS3]

@psxphill:

>>Not that there is anything sacred about Commodore.

>In terms of Provenance there is.

I suppose you think that an Amiga Technologies (Escom) A1200 is not a real Amiga then? Or that eg. a ZX Spectrum +3 isn't a real Spectrum, etc. because Amstrad had bought Sinclair. With that Ship of Theseus analogy, that was about whether it was still the real thing after every single component in it had been changed. OS3.9 is a big upgrade with lots of new features, but of course not every single byte in it is different from OS3.1.

>If it's not in ROM then it's taking up RAM.

I should point out that OS3.1 and even earlier versions used SetPatch to patch the ROM.

@wawrzon:

>im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way.

You seem to be suggesting that there are no regular users left in the community, only programmers. But I think the majority of Amiga users are still non-programmers. Maybe we should have a poll about this.

>finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.

I've programmed for all these systems, so I believe I qualify...granted that for OS4/AROS there are other users that help with testing etc. Several of my programs are available for AROS x86. The rest would also be available, except for the fact that AROS is missing ReAction. How is software supposed to get ported to AROS when AROS lacks basic functionality that is part of the OS (not even undocumented functionality!) that the application absolutely depends upon? (In the interests of fairness, I should point out that both MOS and OS4 are missing some OS3.9 functionality too, but AROS is missing the most though.)

@BSzili:

>I don't understand why people are so fixated on the fact that AROS strives for 3.1 compatibility. This doesn't mean that they won't implement anything beyond V40.

Well, we've been waiting 15 years already...maybe if we wait another 15 it will have complete V45 support...? *Then* there might be a reason to switch to AROS...

If you talk about X86 or ARM branches maybe, I do not think that they ever tried to implement everything (or could because much is closed source including Reaction), on the other side they added lots of features never part of 3.1., including some of the patches, 3D and many others.

But again this thread is about 68k so we talk about Aros 68k where you can add almost everything (similar to the PPC platforms) so again what features are missing. I want 1. and 2. and 3. and 4. then I can say it is possible or not (in my experience). You only talk in generalizations that are not true.

[itix]

> I don't see the relevance of whether the ROM upgrade is performed in
 > firmware or software.

 If it's not in ROM then it's taking up RAM.

Memory is cheap. I had 64MB on my A1200 and there was always more than needed. But having ROM is advantage because to replace ROM libraries you had to reboot. It is annoying because even with 3.1 booting was taking quite long.

If there was 3.5/3.9 ROM chip with BVision support in boot menu it could have been much much better... dont you hate it when it stops booting and you dont have TV near? Sometimes I was thinking my Amiga 1200 was better without those stupid complex expansions. Just vanilla Kickstart 3.1 and Miami + ethernet card, simple 68030 accelerator and small HD, Workbench on 640x256 screen.

[wawrzon]

@wawrzon:

>im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way.

You seem to be suggesting that there are no regular users left in the community, only programmers. But I think the majority of Amiga users are still non-programmers. Maybe we should have a poll about this.

i am talking to you, among other contributors to this thread, i assume most of whom have some programming experience. in fact its me, who is basically a plain user, occasional but rather incompetent tester and have been trying to make few simple ports to amiga.  i agree that most of the plain users who just sometime play a game do not count much in this case even if they could actually motivate aros68k development if there were any.

>finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.

I've programmed for all these systems, so I believe I qualify...granted that for OS4/AROS there are other users that help with testing etc. Several of my programs are available for AROS x86. The rest would also be available, except for the fact that AROS is missing ReAction. How is software supposed to get ported to AROS when AROS lacks basic functionality that is part of the OS (not even undocumented functionality!) that the application absolutely depends upon? (In the interests of fairness, I should point out that both MOS and OS4 are missing some OS3.9 functionality too, but AROS is missing the most though.)

okay, but in case of aros you even could substitute missing components of the system on which your software relies if you really wanted. you dont have such a possibility on closed source alternatives.

so to exemplify and invert your reasoning, you who blame aros developers for the state of aros, namely not working enough or fast enough for you are actually even more to blame if you dont even contribute. aros developers are the same situation as you, making it in their free time, working on what they have fun working on. neither you nor them are on any duty.

[Minuous]

>Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1. After all, 3.1 is even included on the CD, so it's just a matter of replacing files. I'm really trying to understand your reasoning but it doesn't seem consistent. It seems to be that if OS3.5/3.9 was almost the same as OS3.1 it would be OK (like an Escom A1200 compared to Commodore A1200) but since it is a significant upgrade, it's not OK? What about Amiga Walker, would that have been a real Amiga if released?

>The AmigaOne isn't an Amiga though.

Well, I'm certainly no OS4 fanboy, and it's tangential to the issues at hand, but IMHO an AmigaOne is a real Amiga, it's just not a "Classic Amiga". Which is why we have the term. It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

>the only parts that rely on Reaction in OS3.9 are the preference programs - is the API of OS3.9 open enough to allow third party prefs programs to be written?

There are other parts: some that spring immediately to mind are AWeb and various items on the Workbench menus (eg. "Execute command...", "Information...", etc.). As to preferences files, they are mostly just IFF files and are mostly documented, eg. Report+ can interpret most of these files.

>After they died there haven't been anyone who has been universally agreed upon to hold all the rights to the fallen empire. If someone had stepped in and taken command then I would have agreed.

Escom bought everything important. IIRC they bought everything except some trademarks and patents.

>True(partially), but then again the 3.5/3.9 releases didn't really update the ROM parts much so not so much of a upgrade to the ROM contents?

Quite significant upgrades to the ROM-based components actually.

>The Amiga being what it is is also more vulnerable the more of the code that lives in ram instead of rom, but I'm not suggesting to limit updates because of that.

That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.

[olsen]

Not really hack and patch. NewIcons just replaces original icon image with image encoded in tooltypes. It is slower but works and is quite clean. Glowicons append IFF ICON chunk to end of icon file. Users dont really care how icon data is stored.

I doubt that. The size of icon files directly affects how quickly Workbench reads directories, and even under optimal conditions things aren't so nice to begin with. Due to how Workbench is designed, and how the icon file layout looks like, there is no clean way to provide for caching, and even changing one small aspect of an icon (say, a tool type) requires that the entire file is written back to disk; prior to icon.library V44 this would amount to a series of individual Write() calls with no write buffering whatsoever.

I added an icon.library API for streamlining snapshot operations (which ends up modifying the icon file on disk) but for all other operations things are not really sunny.

The NewIcons text encoding/decoding of the image data contributes significantly to the time it takes to read/store an icon on disk. Also, the NewIcons patches have to hide the encoded image tool types from display, which again burns CPU cycles. This stuff adds up. It works, but sacrifices are being made on your behalf.

With icon files you have a choice between a bad solution and a worse solution. The icon image chunk appended to the icon files by icon.library V44 and beyond is an optimization. It reads more quickly than the NewIcons encoding of the image data (remember, prior to icon.library V44 this data was read by a series of individual Read() calls), and it takes up less space in the file. In this context I consider the new icon file format a bad solution, and NewIcons a worse solution.

Bottom line is, icon I/O operations are expensive and how Workbench reads icons adds insult to injury. The modified icon file format attempts to remedy this.

[biggun]

Stupid question.

What is wrong/bad about the original Icon format?

Of course with just 2 planes Icons look not so impressive.
But with 3 planes like in MagivWB the Icons look already quite cool.
I would imagine that a 4 planes MagicWB+ might even look nice.

[stefcep2]

I use PeterK's icon.library on a 68060 and CV 64 A4000 with Kens PNG icons.  Any slow down if its there is neglible.

TBH its all eye candy anyway.  The icon is supposed to be a pictorial representation of the file- you are supposed to know what it is without looking at its name.  I find I rarely do that, and the icon is nothing more than the place I click- which I could do just as well in 4 colors, maybe even better.

[OlafS3]

>Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1. After all, 3.1 is even included on the CD, so it's just a matter of replacing files. I'm really trying to understand your reasoning but it doesn't seem consistent. It seems to be that if OS3.5/3.9 was almost the same as OS3.1 it would be OK (like an Escom A1200 compared to Commodore A1200) but since it is a significant upgrade, it's not OK? What about Amiga Walker, would that have been a real Amiga if released?

>The AmigaOne isn't an Amiga though.

Well, I'm certainly no OS4 fanboy, and it's tangential to the issues at hand, but IMHO an AmigaOne is a real Amiga, it's just not a "Classic Amiga". Which is why we have the term. It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

>the only parts that rely on Reaction in OS3.9 are the preference programs - is the API of OS3.9 open enough to allow third party prefs programs to be written?

There are other parts: some that spring immediately to mind are AWeb and various items on the Workbench menus (eg. "Execute command...", "Information...", etc.). As to preferences files, they are mostly just IFF files and are mostly documented, eg. Report+ can interpret most of these files.

>After they died there haven't been anyone who has been universally agreed upon to hold all the rights to the fallen empire. If someone had stepped in and taken command then I would have agreed.

Escom bought everything important. IIRC they bought everything except some trademarks and patents.

>True(partially), but then again the 3.5/3.9 releases didn't really update the ROM parts much so not so much of a upgrade to the ROM contents?

Quite significant upgrades to the ROM-based components actually.

>The Amiga being what it is is also more vulnerable the more of the code that lives in ram instead of rom, but I'm not suggesting to limit updates because of that.

That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.

It was already written a number of times here but I repeat it

AWeb does NOT need Reaction, it needs Classact and both Classact and AWeb work perfectly on Aros 68k. But you seem not to react on the comments of others

[guest11527]

That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.

LoadModule and MuProtectModules exist.

[guest11527]

Stupid question.

What is wrong/bad about the original Icon format?

It is really an ad-hoc solution and was not designed for extensibility. I.e. it is four colors only (two bitplanes), and no chance to add it with functionalities beyond those originally intended. Ideally, the original icon file should have used some kind of extensible file format, e.g. IFF (ignoring the fact that IFF came actually later.)

For me, the original four color icons always worked "good enough", but arguably, it's really not an up-to-date look.

[Minuous]

AWeb does NOT need Reaction, it needs Classact and both Classact and AWeb work perfectly on Aros 68k. But you seem not to react on the comments of others

I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.

What is wrong/bad about the original Icon format?

The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.

[biggun]

You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

But this is normal - right?

AMIGA OS as it also needed extra stuff to be added to become useable.
This is why they made those packs with text editors and DPaint and such.

Isn't this the same with Linux for example?
Also Linux as it - is just a Kernel.
All the programs in Linux are gnu tools and do actually not belong to Linux.
So people/companies took time and effort to bundle them all together into a working useable distribution.

[OlafS3]

I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.



The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.

You install a distribution (OS3.5/3.9) and then compare it to a backbone that is aiming to reimplement 3.1. API and not suited for users and then make your judgements? I have shown you screenshots of 68k software running on it no reaction from you.

AmigaOS is not in development anymore, 3.9 was the last update and then there will be no updates in future. 4.X is another branch for me because it needs completely different hardware. So if anyone wants development then there is only one potential chance.

And to make some comments about what you wrote about X86... there IS a working emulation in AROS but only in certain distributions (Icaros Desktop and Aeros), not in nightly builds. They are for testing for developers not users. 68k emulation runs in a kind of box with UAE, integrated but not the same as on MorphOS or AmigaOS. I do not know when you last checked it but it seems to be very long ago or you have just looked at a nightly build (that has no 68k emulation integrated).

"no reason for any 68K user to bother with AROS: it's slow, missing features and ugly."

Really? Who has said that before? It is slow? Where and when? On real hardware yes, that was this discussion about, on emulation (what certainly most use today) no. Missing features? Which? I work for a couple of years on my distribution that is based on Aros 68k, which features are missing? As I explained before distributions are for users (not nightly builds). Ugly? Really? How that? Show me a example of that? I have a nice RTG 24bit background from Wawa, use Magellan as Desktop Manager and support almost any GUI technology inside that was ever available.

[wawrzon]

It is really an ad-hoc solution and was not designed for extensibility. I.e. it is four colors only (two bitplanes), and no chance to add it with functionalities beyond those originally intended. Ideally, the original icon file should have used some kind of extensible file format, e.g. IFF (ignoring the fact that IFF came actually later.)

For me, the original four color icons always worked "good enough", but arguably, it's really not an up-to-date look.

i must admit, that also for my taste the most inspiring amiga icons were probably all in the genuine icon format. this might not be the reference for good one, but as you see even ms returns to simplistic graphics and its suits them better. i dont ever remember a new- glow- or png- icon to be particularly recognizable nor stunning. im not sure if giving icon designers more options adds up to the overall aesthetics, unique characteristics and ergonomy of the system. sometimes less is more.

[wawrzon]

I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.



The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.

as you yourself rightly observe aros allows to detach amiga scene from parent enterprises who proved to be untrustworthy one after the other. secondly it allows to preserve the code base, which even if thor and olsen claim to have at hand, well i don intend to be rude, but everybody can be hit by bus and then his work will be lost unregarded good intentions. and last but not least it allows to fix and extend functionality, support more different probably cheaper and more economic platforms, therefore allows for variety of choices, which looks like an important issue in an individualistic society. i think its worth it. but its everybodys own choice.