Acolyte of the Butterfly
Posts: 139 from 2008/7/22
FIXED: The Workbench disk image was not bootable
How incompetent can the guys at Hyperion be to not realize that the Workbench disks they are making aren't bootable?!?Quote:
FIXED: The installation script could wrongly copy the contents of the Install disk into FONTS:
"Could wrongly copy"? What does that mean? Sometimes it correctly installs the files and other times it copies them all to the "Fonts" directory/drawer?
Hyperion is such an embarrassment and crippling boat anchor for the Amiga community. Unfortunately, Ben Hermans will probably never give up control of the AmigaOS ip, to allow any more competent person/company or the community itself, to push it forward more quickly and with better quality control.
Olaf Barthel has provided an explanation of what went wrong and gave some insight into the build process."If there are similarities, I expect they resulted from changing what used to work back in 1994 and finding that subtle problems slipped through the testing process.
In the case of this Workbench/Kickstart 3.1 update, the changes made were deliberately kept small so as to reduce the risk of breaking anything. That was the plan, but what caused the troubles was for one part the build process itself, and the subtleties of writing installation scripts.
The build process cranks out ready-made Kickstart ROM images and a set of drawers whose contents correspond exactly to the Extras/Fonts/Install/Locale/Storage/Workbench disks. In order to create those disks, the respective contents are copied to RAD: and the result then goes into an .adf image, one disk at a time. The Install/Workbench disks are special in that they both need to be bootable (they have been since the original 1994 release), and that the respective disk boot blocks need to be installed manually (ever tried "install rad:"?). Lack of automation of this process kept the Workbench disk from being bootable (the A4000T has its own issues with the Workbench disk; see below).
The contents of the Workbench disk set in this update are peculiar in that their contents were slightly rearranged so as to make one single set which can be used both on the A4000T and all other Amiga models. Because the A4000T does not have workbench.library in ROM, Commodore shipped a special variant of the Workbench 3.1 installation disk set, and that wasn't going to fly.
Making an installation disk set which works with all Amiga models resulted in disk space constraints, i.e. you can boot off the Install disk, but due to Workbench disk lacking the workbench.library, booting from it is not an easy option on the A4000T. Something had to give
What broke the installation script, which ended up copying the contents of the Install disk to the newly installed Workbench "fonts" drawer, was a change made so that you could more easily install everything from a single disk: just copy all the disk contents into drawers on the installation medium, set up assignments to those drawers and launch the installation script: no more prompting to insert a disk.
Because the Installer tool allows/needs very strict control over whether installation is permitted from an assignment rather than a volume, this caused trouble with the "Fonts" disk. If the Fonts disk was not present, then the installation script would copy the contents of the drawer which "FONTS:" was bound to. Because there is no "fonts" drawer on the Install disk, the "FONTS:" assignment was bound to the root directory of that disk (this is what the boot process does by default), and hilarity ensued... How do you fix that? You can actually test if "Fonts:" is an assignment, and you can test if that assignment refers to the boot disk's root directory. If so, then you can tell the Installer to prompt for the Fonts disk to be inserted and the assignment to be ignored. Even back in the day there was little love for Installer scripts. Now you know why.
Bottom line is: you will likely miss something important if you change anything at all, no matter how little the change was"Link