Hyperion: "Halloween special double-treat for the Classic AmigaOS"

[Gulliver]

Finally, I doubt the wisdom in including such a large (it's one single file), complex assembly language implementation in the operating system. It's bad enough that we have to deal with the FFS and the scsi.device driver family, and even dos.library. There is a place for assembly language code in the operating system, but in my opinion the solution should match the problem at hand in terms of complexity and maintainability.

In the end who cares about maintainability when you havent released a single patch to fix all the shortcomings of icon.library in more than a decade.

Maintainability is of no use if no one maintains it (which is pretty much what you did). Which is casually the opposite of what PeterK has been doing for a couple of years, despite it is in assembler, despite he had no sources to start with, despite he hadnt earn a dime during that process, and despite he added lots of advanced features to it, he still maintains it and takes care of any bug reports.

Of course, using assembler, does not apply in all situations, like components which have been actively maintained by Thomas Richter. But in the particular case of icon.library, PeterK`s solution is indeed much better in both features and performance than your own implementation of icon.library 45.x which has been unmaintained for more than a decade.

Assembler is not the best solution, but it is certainly better than unmaintained,  buggy and slow C code.

[kolla]

The workbench.library/icon.library combo has, in my opinion, hit the wall so hard by now that it's coming out on the other side. The way in which workbench.library and icon.library interact with directory scanning is something I hesitate to call a self-inflicted injury.

One of the many examples of something that would be better to reimplement from scratch - though that would most likely also mean incompatibility with lots of existing "bedroom" software. Likewise, con-handler vs. console.device vs. shell, would be great to have that mess cleaned up.

[kolla]

Maintainability is of no use if no one maintains it

Exactly, maintainability also means availability.

[kamelito]

Exactly, maintainability also means availability.

Apple was working in secret on an X86/X64 version of Mac OSX since the beginning it was not available yet it was maintained...
It was probably a mistake to do not update the 68k branch as it is where most users are. We also know that the so called Classic users, the hardcore one will never take the PPC route. Jedi tricks do not work on them.
Better later than never though.

Kamelito

[wawrzon]

@thor, olsen

alright, sounds like you are stepping in right direction. even if the build system relies on particular versions of make and more than one compiler the sources are not available for, it is fine as long as binaries are freely available to all invloved.

i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.

[olsen]

One of the many examples of something that would be better to reimplement from scratch - though that would most likely also mean incompatibility with lots of existing "bedroom" software. Likewise, con-handler vs. console.device vs. shell, would be great to have that mess cleaned up.

The workbench.library/icon.library combo has resisted change for almost 30 years.

By now I am inclined to accept that it cannot be changed, only replaced by a solution that is API-compatible with it.

As long as workbench.library/icon.library continue to exist and are maintained, they will suck up developer effort best spent somewhere (make that "anywhere") else, just like space vacuum acts as a heat sink.

If you get too close to it, you will be sucked into creating enhancements which only burden the already over-overloaded architecture. My (so far) final contribution to this series of unwisely chosen enhancements was the Workbench ARexx interface.

By comparison the console.device/con-handler/shell combo seems charmingly 'whacky' and ultimatively redeemable

We shall see...

[olsen]

i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.

Call me uncharacteristically optimistic. I believe that changes made to the AmigaOS V40 code will be beneficial, although they are likely to be considered too little, too late.

The work that went into making the AmigaOS 3.5 update was intended to open up the platform by introducing new APIs, so that developers could build upon them, and by integrating functionality into the operating system which up until then had to be added through patches, which were fighting among each other for control.

In my opinion, this is the direction in which future development work should continue.

It won't be terribly exciting (excitement is something you would be well-advised not to seek in software development), but it seems reasonably likely to succeed to me at advancing the state of the Amiga operating system and getting more Amiga developers involved. It must be considerably less fun to "play" with what was last updated and polished in 1999.

[guest11527]

By comparison the console.device/con-handler/shell combo seems charmingly 'whacky' and ultimatively redeemable

It's really bad enough. Moving the history handling into the console still seems somewhat logical, but the whole idea of having the TAB expansion handled in the console is ultimately broken, even more so for job control. Luckely, there are enough precautions taken to get rid of this nonsense in ViNCEd, and finally move that code where it belongs - the Shell namely.

CON: is just a very thin interface layer around the console.device. Or rather, should be.

[wawrzon]

Call me uncharacteristically optimistic.[...] getting more Amiga developers involved.

thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.

[Pgovotsos]

thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.

You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.

I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.

This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?

These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.

Try saying "Thank you" instead to these guys.

If you have issues about the source code, take it up with the rights holder, please.

[klx300r]

+ infinity :hammer:

[wawrzon]

You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.

I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.

This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?

These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.

Try saying "Thank you" instead to these guys.

If you have issues about the source code, take it up with the rights holder, please.

yawn.. its not a complaint. i wrote that im fond of what olaf does, simply it wont lead far, i fear, given the circumstances. there is nothing in your post that wouldnt be obvious to almost anybody here, if you are being just grateful and you dont have anything to add, then its fine too.

[ssolie]

It's really bad enough. Moving the history handling into the console still seems somewhat logical, but the whole idea of having the TAB expansion handled in the console is ultimately broken, even more so for job control. Luckely, there are enough precautions taken to get rid of this nonsense in ViNCEd, and finally move that code where it belongs - the Shell namely.

CON: is just a very thin interface layer around the console.device. Or rather, should be.

Tony has a couple of nice blogs on his adventures in this area:
 http://blog.hyperion-entertainment.biz/?p=1220
 http://blog.hyperion-entertainment.biz/?p=1227

[Pgovotsos]

yawn.. its not a complaint. i wrote that im fond of what olaf does, simply it wont lead far, i fear, given the circumstances. there is nothing in your post that wouldnt be obvious to almost anybody here, if you are being just grateful and you dont have anything to add, then its fine too.

You really do only see what you want to, don't you? It's such a shame that your reality isn't a happier one. TTFN

[apa]

You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.

I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.

This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?

These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.

Try saying "Thank you" instead to these guys.

If you have issues about the source code, take it up with the rights holder, please.

+Word!! Thanks to ALL updating the code for out beloved platform, in whatever way. Of course Hyperion should have some pocketmoney if they update it, now and then. I would also like to see it open sourced one day, but I'm not sure that is a silverbullet. We got AROS already and anyone feeling that they would like to contribute are free to do so there. And Olsen, Thomas et al, please continue sharing as much nuggets and insights as you do into the code and history of it - have you considered blogging about it now and then.

[guest11527]

Tony has a couple of nice blogs on his adventures in this area...

That's really only the internal design of the console.device. FYI, ViNCEd works completely different from that and has two internal representations of lines: A "packed" line where each line is broken up into "words" that share the same attributes, with blanks in between, and an unpacked version with a one-byte glyph and a two-byte attribute per character in the line. Whenever the cursor enters a line, this line is unpacked, the user makes edits, and when the cursor leaves the line, it is packed again.

The internal representation is all fine, but the problem is how the console interacts with the shell. ViNCed somehow "hijacks" the CLI structure of the I/O streams that reach the handler, and from that "guesses" (it's a bit better than this, but let's make it simple) what the corresponding CLI is, from there figures out what the path is, and from there runs the TAB-expansion, and from there places the expansion back into the window. Actually, a separate side-thread is responsible for that.

It works, but the bad part about is the lack of isolation. Essentially, the console has to mess with data structures (the CLI) it should really not care about. The CLI structure is frozen, so nothing bad can happen, but it's still not how it is supposed to work. The shell should care about its own structures, and do the expansion, and the console should inform the shell when the user needs an expansion.

On the ViNCEd side (not the "ROM console") everything is there to support such an improved operation, but from the Shell side it is not.