Welcome, Guest. Please login or register.

Author Topic: AppShell Appbuilder  (Read 13846 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline olsen

Re: AppShell Appbuilder
« on: July 26, 2017, 08:20:15 PM »
Quote from: Matt_H;828765
I don't think these ever made it out the door. There's some info/code in the Commodore server dump that was circulating a year or two ago. The build of appshell.library in that archive is dated May 13, 1992, so I think this was something that CATS canceled, as opposed to it being ended by the bankruptcy. There's also an older release notes file (May 1991) that makes reference to appshell.library, appobjects.library, prefs.library, and hyper.library.


The AppBuilder/AppShell projects definitely floundered by 1992. If I remember correctly, our lot of commercial Amiga developers heard time and again about a set of powerful tools in development which would ease GUI design and application implementation work, we just had to wait a little bit longer...

One of these was the fabled "ToolMaker". It could be that AppBuilder and ToolMaker were different projects with the same focus, or overlapping focus, which eventually ran aground. Or they could be related.

"ToolMaker" and "AppShell" code survives in the archive, but there is no trace of "AppBuilder" code, only e-mail discussions on the subject remain, which go back to 1990.

Remember, the NeXTstep design and its tools ("Interface builder") had matured quite a bit by 1989/1990 and it got people thinking about object oriented design (SmallTalk style), the idea of frameworks, interactive visual tools for creating applications and their business logic, high resolution displays. Some of these ideas landed in AmigaOS, be it humble (the 2.0 new look, the A2024 monitor), not so humble (AmigaVision) or powerful (the BOOPSI architecture, AmigaGuide), there seems to be a direct influence from the NeXT.

The concepts used by AppShell and AppBuilder/ToolMaker might have sprung from the same source.
 

Offline olsen

Re: AppShell Appbuilder
« Reply #1 on: July 28, 2017, 10:02:32 AM »
Quote from: Matt_H;828825
Did some more digging and found that AppShell was written up in the 1993 DevCon notes. It was to have provided a basic application framework with access to ARexx, AmigaGuide, new IPC standards, prefs, and other elements, the idea being that developers wouldn't have to implement all this stuff manually (incidentally, this also explains the cross references to hyper.library and prefs.library). Moving those functions to a shared library would also cut down on application code size.

That was the idea: we get a framework to build applications upon. In practice, however, we were left to our own devices.

For example, creating a working, consistent ARexx interface for an application is not terribly hard, but if you lack the necessary documentation (Commodore never shipped anything comparable to William S. Hawes' own ARexx manual and developer material, until it was already too late), you're stumped.

Building GUIs on top of gadtools.library was possible, and so was building your own user interface components through BOOPSI. At least the basic tools were available in Kickstart 2.0, whereas in the "dark age" preceding it you had to hand-craft every GUI right down to the look and feel of the building blocks. So, things were easier, but starting with Kickstart 2.0, you still had to hand-craft the GUI, but you no longer had to hand-craft all the building blocks yourself. Visual design tools, or frameworks for programmatically constructing GUIs were still absent then in 1990-1992. AppShell, AppBuilder/ToolMaker, etc. were needed, badly, but they never arrived.

Quote
The notes also confirm that Inovatronics was handling development of AppBuilder, explaining its absence from the Commodore server dump. They also say that Toolmaker shipped in 1992. Maybe I missed it on the Dev CD?

To the best of my knowledge, neither AppShell nor ToolMaker ended up in the hands of the paying 3rd party developers in Europe. No material pertaining to either can be found on the Amiga Developer CD (1992), nor on the more recent Amiga Developer CD compilations (1.1, 1.2 and 2.1).

ToolMaker promised to ease what at the time still required a lot of manual work: building an application from scratch, with a working, powerful user interface.

NeXTstep's "Interface builder" showed how you could do that, and the industry (Microsoft, Apple, IBM, etc.) quickly began adapting its concepts (results started materializing by the mid 1990'ies).

Had Commodore shipped even a modest tool for making this task a little bit easier, it would have resonated in the developer community at the time, on both sides of the Atlantic. As far as I can tell that event never occured. Commodore would have covered it in AmigaMail, for example, yet there is no so documentation.

Regarding that 2016 server dump: absence of material from that archive does not imply that it has been lost, or never existed in the first place ;)
« Last Edit: July 28, 2017, 10:05:12 AM by olsen »
 

Offline olsen

Re: AppShell Appbuilder
« Reply #2 on: July 28, 2017, 11:43:01 AM »
Quote from: kolla;828828
And then, in 1993, came MUI :)


The little acorn from which MUI grew was MagicFileRequester, in 1992. Arguably, the asl.library rewrite of the same year (developer previews were available in the first quarter of 1992) already featured a dynamically generated GUI which took font, screen resolution and window size into account. But MagicFileRequester leapfrogged it with ease :)
 

Offline olsen

Re: AppShell Appbuilder
« Reply #3 on: July 29, 2017, 09:18:49 AM »
Quote from: kolla;828846
Well, today I happily prefer ASL (the OS3.9 one?), lean, fast and to the point.

The asl.library file requester code in OS 3.5 and 3.9 is practically identical. It builds upon the asl.library rewrite which Martin Taillefer performed for Workbench 2.1.

The original asl.library (Workbench 1.4/2.0) is strongly related to arp.library. Charlie Heath, who also contributed to arp.library, wrote asl.library, too. It consists of some 6,500 lines of 68k assembly language code. Incidentally, "ASL" stands for "application support library", and some of its API functionality later migrated to utility.library.

Martin Taillefer rewrote asl.library from the ground up in 'C' (1991). The file requester cleverly mixes asynchronous directory reading with user interface operations, which makes it so fast and responsive. The only drawback was in that the list of file and directory names displayed were stored in a plain doubly-linked list, which was updated and sorted in real time as new entries were added to it.

The file requester would use straight insertion sort (red flag!), which scales very poorly. The more entries were added to the list, the more time was spent on finding the right place to put an entry.

Worst case behaviour would result if the directory entries were added in sorted order. This actually happened with ISO 9660 format CD-ROMs, for which directories are always stored and returned in sorted order. Not only was the CD-ROM drive slow, reading directories caused the asl.library to crawl after only a hundred entries.

This was one of the major reasons why there were so many utilities available in 1991-1993 that would replace the asl.library file requester by something faster (but not necessarily something more responsive).

The poor scalability of the asl.library file requester drove me nuts. I updated it for OS 3.5 by changing how the sorting operation worked. The doubly-linked list operations could not be easily replaced, so I came up with an algorithm which combined the list entries with a binary search tree. This combination speeds up the insertion operation, keeping the effort needed to maintain it sorted very small, regardless of how many directory entries there are (in CS terms: it went from O(n^2) to O(log(n)) complexity).

The same doubly-linked list sort operation, augmented by a binary search tree also wound up in workbench.library, for example.

With this improved list sort operation, the asl.library file requester became consistently both responsive and fast, not just for a limited number of directory entries.
« Last Edit: July 29, 2017, 10:50:28 AM by olsen »
 

Offline olsen

Re: AppShell Appbuilder
« Reply #4 on: July 31, 2017, 10:36:01 AM »
Quote from: kamelito;828871
Reading your statements about linked lists remind me of this talk.  https://www.youtube.com/watch?v=YQs6IC-vgmo  Kamelito


Yes, there are common constraints between the doubly-linked lists described in Mr. Stroustrup's talk and what the ASL file requester has to deal with.

As always, lists such as these work very well if the contents are accessed in sequence, such as in queues or stacks. The scalability issues arise when random access is performed and more than a handful list items are involved. This occurs in the ASL file requester whenever new list items are added, so that the list remains sorted.

Mr. Stroustrup makes a good point that tables tend to make for better performance rather than dynamic data structures such as doubly-linked lists. This advantage becomes even more pronounced if you take the respective memory access patterns into account, which for doubly-linked lists do not play well with the CPU cache.

Sometimes, however, you do not have much of a choice between tables and dynamic data structures. The ASL file requester needs to build the list dynamically, allocating new memory as further entries are added. It is designed to work well enough on systems with very little memory (1 Megabytes of RAM), and preallocating static chunks of memory to store the table and the associated entry data in would not work so well under these constraints (although it would keep memory fragmentation at bay and probably yield better runtime performance).