Welcome, Guest. Please login or register.

Author Topic: AppShell Appbuilder  (Read 13843 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline olsen

Re: AppShell Appbuilder
« Reply #14 from previous page: 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 kamelitoTopic starter

Re: AppShell Appbuilder
« Reply #15 on: July 29, 2017, 08:17:55 PM »
Reading your statements about linked lists remind me of this talk.  https://www.youtube.com/watch?v=YQs6IC-vgmo  Kamelito
 

Offline olsen

Re: AppShell Appbuilder
« Reply #16 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).
 

Offline Matt_H

Re: AppShell Appbuilder
« Reply #17 on: August 18, 2017, 12:53:24 AM »
Did a little more digging and found that AppShell was included on the 1991 DevCon disks which subsequently made it onto some of the Developer CDs. So at least that component was publicly released. Surprised it didn't get any use within the developer community at the time...
 

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show only replies by SamuraiCrow
AppShell Appbuilder
« Reply #18 on: August 18, 2017, 03:55:03 PM »
I suppose these tools would have made a worthy addition to many developer toolkits.  As long as I am thinking of it, I think it would have made AmigaVision a worthy beginner level software toolkit instead of a buggy competitor to Scala if the functionality could be integrated.
 

Offline kamelitoTopic starter

Re: AppShell Appbuilder
« Reply #19 on: December 01, 2020, 09:40:37 AM »
Found this on usenet

“Powerwindows is obsolite. Innovatronics has a new product slated for
release at devcon in Orlando called appbuilder. They have been
working very closely with CBM and although they have been (development
necessary) vague with me about what it actually does, it is supposed
to be for C and other compiled languages what CANDO was for AREXX!”
 

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show only replies by SamuraiCrow
Re: AppShell Appbuilder
« Reply #20 on: December 01, 2020, 01:23:41 PM »
And then, in 1993, came MUI :)
MUI Builder still needs a total rewrite.  It's open source C but not worth fixing.  It's on SourceForge if you want a look.
 

Offline kolla

Re: AppShell Appbuilder
« Reply #21 on: December 02, 2020, 08:47:57 AM »
MUI Builder still needs a total rewrite.  It's open source C but not worth fixing.  It's on SourceForge if you want a look.
I don't often build so called apps using MUI, but when I did, I used MUIRexx :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline trilobyte

  • Full Member
  • ***
  • Join Date: Oct 2006
  • Posts: 210
    • Show only replies by trilobyte
    • http://aaack.org
Re: AppShell Appbuilder
« Reply #22 on: January 05, 2021, 06:43:47 AM »
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.

I was super-curious about these dev tools also.  I asked around at the Amiga 30th in Mountain View in 2015, and if I remember right, I actually got to speak to Randell Jesup and Carolyn Scheppner (and soon after meet Dave Needle).  I don't remember if I got to speak with David Junod!

This was all connected & related to an IFF spec that described UI elements using 32-bit words, similar to classic Mac resource forks, no? 

PowerWindows (as mentioned later in this thread) from Inovatronics was (IIRC) written by Todor Fay, and is also a big part of how Bars & Pipes UI was constructed.
Amiga user since \'96, when I could finally afford one
Commodore 8-bit since before I could tie my shoes
 

Offline merwin

  • Newbie
  • *
  • Join Date: Jan 2021
  • Posts: 1
  • Gender: Male
    • Show only replies by merwin
Re: AppShell Appbuilder
« Reply #23 on: August 09, 2021, 12:11:16 AM »
I am the author of Toolmaker if anyone has any questions.  It's been a long time since I thought about it.
 

Offline kamelitoTopic starter

Re: AppShell Appbuilder
« Reply #24 on: October 23, 2021, 10:15:02 AM »
I am the author of Toolmaker if anyone has any questions.  It's been a long time since I thought about it.

Hello, do you still have the right to Toolmaker? I don't think many people do have this tool.
Why did you wrote it, are the others products at the time not good enough for your needs?
How did it end up in the hands of CBM?

 
The following users thanked this post: gdonner

Offline NinjaCyborg

Re: AppShell Appbuilder
« Reply #25 on: October 31, 2021, 11:26:05 AM »
Can you release it to the public? Do you still have the source?
 

Offline gdonner

  • Newbie
  • *
  • Join Date: Mar 2018
  • Posts: 5
  • Country: us
  • Ancient Amiga User
    • Show only replies by gdonner
    • gregdonner.org
Re: AppShell Appbuilder
« Reply #26 on: April 03, 2022, 12:55:44 AM »
I am the author of Toolmaker if anyone has any questions.  It's been a long time since I thought about it.

Hi Michael,

From a review I read about it, Toolmaker sounds like it has a lot of potential if it could be updated.

If you have no further plans for it, would you consider releasing the source code for it to Aminet?

If not, I certainly understand!
« Last Edit: April 04, 2022, 03:55:52 PM by gdonner »