Development updates

[4pLaY]

Another component: Intuition.

First, as already said, intuition OpenScreen() uses now the new graphics.library AllocBitMap() tags-based interface to allocate bitmaps from graphics, or from the graphics system, which is RTG friendly as all the missing parameters such as the target display ID are passed in.

We have two new intuition functions, namely ShowWindow() and HideWindow() which, well - as the name suggests - make an entire window visible or invisible. It can be used for iconification purposes. The functions are also present in AmigaOs 4.0, at the same LVO vector offsets, though the Os 4 implementation was rather hacky (not to say borken). Actually, someone took the code from my "tech demo" I made for the V45 layers library in 2002 or so and integrated exactly that code into intuition, though this was never considered to be the correct design for it as it did not integrate into the intuition state machine. It now does.

Concerning iconification, intuition gets a new first class citicizen window gadget you can request to get added to your window, and this is the iconification gadget. WFLG_ICONIFY enables it. If the user presses on the gadget, intuition sends an IDCMP_CLOSEWINDOW with a "CODE=1" instead of CODE=0 to the application, which can then react accordingly. All the system tools, preferences, utilities and the console window use it to iconify themselves on the workbench.

Off-window screen dragging was refined as windows show now a slight "persistence" to be dragged out of the screen. It can also be turned off in the icontrol preferences (though, I wonder, why would you want to turn it off...)

The frameiclass got another mode, namely "CONTEXTFRAME", which is the double-outlined frame with a headline on top. It is used quite a lot by the preferences editors, and gadtools. Which also means that the preferences will now lack some of their decoration if run with intuition v40.

We also made a slight change in the menu rendering. Mutual exclusive menu items are no longer rendered with a check-mark, but with a round circle - filled or unfilled - so they remind users a bit of the radio buttons - or look close to them. This makes it a lot easier to spot such items, and it should be quite immediate how they operate. The checkmark remains to be used for the "on-off" items.

Finally, intuition can now be expunged from memory, i.e. can be told to vanish. This is mostly useful for System-Startup where it is used to either update intuition to a new version, or downgrade it to v40 for the CGfx users.

[4pLaY]

Another day, another component. Or some of them, in a bundle. Math libraries.

3.1.4. created the "magic math libraries" that rebuild themselves if a FPU becomes available later in the livetime of the system, .e.g. through setpatch, though there was still something odd about them: The rounding convention.

The math libraries (singbas, doubbas and the corresponding "trans" libs) all follow a "round towards zero" strategy in software, and similarly, set the FPU - if present - to round in the same direction. This gives consistent results, though it is - as far as the math is concerned - not ideal as it will loose precision.

3.2 changes that and follows a strict "round to even" rounding policy, which is a better and more precise rounding mode. It means that it tries to round to the nearest number if rounding is required, and in case of a tie, it rounds to the next number with the LSB set as zero. It can then be shown that under such conditions the output of the computation is identical to the output that had been obtained by computing with infinite precision, followed by round-to-even, which is a nice result. IOWs, you cannot possibly round better.

There is one exception, and that is the "convert float to int" function of the math libraries. They continue to round to zero. There are two reasons for that: First, because the C standard says so, and second, because some programs depend on it, for example the (really naive) floating point to text conversion (i.e. "printf %g") of the Aztec compiler.

Now, it seems easy just to configure the FPU such that it follows a different rounding convention. While the math libraries certainly do that, all the CPU only implementation *also* has to change, and this was a tremendous task. So every function in the "bas" libraries was touched, and the code to adjust the digits for rounding was modified to implement a proper "round to even" strategy. Multiply, add, subtract, division, square root.

The libraries were then verified for correctness by the "Paranoia test", which is a numerical unit test that checks for corner cases of the implementation, and checks for proper rounding. Again, running a test sounds harmless, but bear in mind that the test is in C, is compiled with SAS/C, and SAS/C does not support IEEE single precision numbers. So, the first step was to get the test working on the ieeesingbas library, and then to get the libraries working correctly, which took another two weeks of work.

Final result now: While the old libraries returned an "acceptable result" with some "numerical flaws" due to improper rounding, the new libraries pass all numerical tests with "excellent". So, no numerical flaws left in the math department, and the CPU output is identical to the FPU output.

mathffp (math.library and mathtrans.library) remain in the sad state they have been before. Unfortunately, there is little we can fix here because the number format is just broken. There are no infinities, there are no NaN ("not a number"), there is no gradual underflow (no "denormalized numbers"), so for any kind of numerics, stay away from this math library.

The only reason why it is still in ROM despite its sad state is that some software may depend on it early on booting (still to be available), but mathffp is one of my prime candidates to be thrown out in the future. It's bad numerical quality, beyond fixing. The code quality is fine - hand optimized assembler, coming directly from Motorola - but that doesn't help if it doesn't compute right.

[4pLaY]

More news, today on the workbench.

First, a couple of bugs we had discovered. In case you have an assign that, for some reason, became part of the hidden device list, the workbench would show and hide this assign "as if it would be a device" every second, so it would pop up, then vanish, then pop up again. This happened if you used the HappyEnv-handler, had ENV: removed from the workbench, but then changed that to an assign later on (probably because RAM: can handle this smoothly now anyhow and the Env-Handler is no longer needed).

Then, if the workbench was reopenend, the repositioning of the "left-out" icons was not quite correct as icons were placed such that they became visible, but the icon text was potentially not, i.e. it could happen that the icon text was beyond the edge of the (smaller) new screen.

Concerning re-opening the workbench, there is another small change in IPrefs which lists now the titles of the windows that block the workbench from re-opening. This is hopefully more useful than to say "please close all windows", without knowing what the windows are.

Another bug was which devices the workbench scanned for inserted disks as the logic is here quite strange. The workbench makes a list of devices (not volumes) at start-up time, but this list is never refreshed later on. That is, if you mount a device later, you'll get a volume icon for the device, but the workbench does not show the device icon if the device is not formatted - so it depended on the mount time of a device whether the workbench checked or not. This changed now, the workbench also adds new devices it discovers during its running time.

We also had bugs in displaying the file size of files larger than 2GB in the "view by file name" view. They were also sorted incorrectly if you sorted by size. Strange, I would have believed I fixed all these signed/unsigned bugs in 3.1.4, but this one was left over.

We also have new features as the window title bar can now be freely configured, including a couple of strings that list free memory, graphics memory (as before), version, revision, CPU model, largest free memory block, percentage of free memory, FPU model, MMU model, and probably some other things I forgot.

[4pLaY]

More components: Commands in C.

As said before, the C: commands now respect the error output, so you can redirect errors to a separate file with "*>". By default, ">" redirects both, error output and regular output, to avoid compatibility problems, but you can separate the error messages out.

The LIST command: Well, lists the directory contents. A couple of fixes and changes:

- If the list command found a directory name that looked like a wildcard, it took this name as wild card to match for listing its contents. This is really a bizarre bug that was caused due to the way how list handles its recursion.
- Speaking of recursion, "list" allocated its stack for directory recursion for unknown reasons from MEMF_CHIP, not MEMF_ANY.
- LFORMAT did not prepare its output in a way that is compatible to the shell syntax. That is, if directory or file names were found that contained asterisks or quotes, those asterisks or quotes are now escaped if lformat prints the arguments within quotes.
- It is unfortunately a bit more tricky with file names listed that contain wild cards, i.e. file names that contain # or ? because *some* AmigaDos commands *do* parse wildcards, and some *do not*, so list cannot really guess for which sort of command the output shall be formatted. I'm still looking for a solution for this. There will probably be a command line switch to escape wildcards optionally.
- The LFORMAT keyword accepted %s for the file name, but not %S. Otherwise, all format options are case insensitive, but %s was not.

Then, we have one new command line argument for list, namely "FLAT". If this is given, then LFORMAT does not enter a directory if the given argument is a directory.

[4pLaY]

Another component.... C:Copy

C:Copy had one issue in 3.1.4. namely that it did not release its copy buffer. We fixed that, of course. There is another interesting bug that is older and goes back to 3.1 times, and one new feature.

The bug is that if you copy directory "a" to a directory "b", then "copy" tried to carry over the creation date from "a" to the destination if the "clone" option was used. Strangely, due to some kind of mixup, it did not set the creation date of "destination/b", but "destination/a", i.e. with the file name of the source carried over. For a recursive directory copy, it is almost always the right thing to do, but not so for the topmost level if the target directory gets a new name. The problem went unnoticed because "copy" never tried to report an error if this file date adjustment did not work.

Another related aspect was that "copy clone" only tried to adjust the creation date, but not the protection bits or file note of directories, that is "copy clone" did not carry over all metadata for directories. The reason might have been that protection bits mean nothing on directories - in fact, early v34 FFS implementations did not even fill them in and showed nonsense on a "List" for them, so this might be a feature that came into FFS later and that was forgotten to add when porting the BCPL code to C. Though I'm speculating.

A new feature is the "FORCE" keyword which will forcibly overwrite the target, even if it is write or delete-protected, similar to the FORCE keyword of "Delete".

[4pLaY]

Some other changes of C: components:

- Conclip was updated for the new con-handler features. Once loaded, CON:-windows can be iconified, and icons can be dragged into them.

- IPrefs allows now the scaling the image, or centering it, or tiling it. Scaling comes in two quality factors. IPrefs shows all the names of all windows that block the workbench from being closed, making it easier to identify components that are "in the way". IPrefs also reads the configuration for the workbench title string, and the workbench flags, such as windows can be dragged out of the screen.

- mount comes with an additional keyword "SHUTDOWN" that requests a file system or a handler to go away. This does not remove the mount entry, but the running task. "mount df0: shutdown" thus makes the df0: floppy go away. The next "list df0:" restarts the handler process again.

- assign prints the list of volumes that have been "denied" if assignwedge is running.

- version had a bug that could run into an endless loop because the algorithm to detect a version-indicator ("$VER:") was broken. No new features here, though.

- SetPatch includes now a workaround for programs that do not check the return code of AllocEntry() correctly. It seems plausible that AllocEntry() returns NULL in case of failure, but it does not. It returns with the passed in memory list with bit 31 set. This patch identifies most popular cases of failure and avoids crashing programs. Unfortunately, a common source of failure were erratic functions linked in through amiga.lib.

- SetDate gets a new keyword "FROM" that copies the date over from another file.

- The CPU command is now able to detect the F6 erratum of the 68060 and identifies the Apollo FPGA.

- adddatatypes had a bug carried over from the 3.9 code that could trigger a hit in some area of the datatypes.library when finding a suitable datatype for an unknown source.

- changetaskpri  can now also change the priority of a cli process by name, not only by its "process ID".

- the same goes for "break", which also accepts the name of a CLI process to stop.

[4pLaY]

Datatypes: Yes, some news here, too.

First, a general comment. Pretty much all datatypes - except those already included in 3.1.4 - had a race condition in the library handling and could crash the machine if memory run out. It is a pretty unlikely condition under which this happens, but still, let's get things right.

The text.datatype allows now searching. It is based on the Os 4 code, but we had to make a couple of adjustments. The search window is now gadtools based (following the general guideline of 3.2), and certainly font-sensitive (as all new gadtools GUIs). It also works a little bit nicer for searching upwards and downwards. There were also a couple of race conditions in searching that could create chaos due to the lack of proper mutex protection.

Scrolling the text window also created some defects if parts of the window were occluded while scrolling. Actually, the window refresh code was not quite right.

The ascii.datatype did not handle the "reverse on/off" CSI sequence correctly. This bug was reported here.

We have one bug fixed in the picture.datatype that could crash if some of the properties of the picture were set in the wrong order while loading a picture into it.

Then, there is one new/old datatype, namely that for bmp pictures (windows bitmap). Actually, there is not much of the old code left. The new bmp datatype supports all sorts of bitmaps, 1 bit, 4 bit, 8 bit, Os/2, Windows, palette based, high-color, true-color, compressed... Thus, support for bmp should be pretty complete now.

[4pLaY]

Another day, another component: The window class

This is a reaction class, and a representation of an intuition window. The class implements message handling, refresh and iconification, on top of the boopsi system.
The 3.9 preferences are based on the window class. The window class we have here is based on the Os 4 (v50) class, though with a couple of fixes:

*) As for all boopsis, the library open/close code had a race condition that could crash the machine in rare circumstances.
*) window iconification is now based on the native intuition window flag, and no longer on a custom gadget.
*) the busy-pointer is now the native intuition busy pointer and no longer a custom pointer.
*) the window backfill hook could crash in some situations
*) message handling had a race condition that, under rare circumstances, could have made the class loop forever, and it might have
forgotten to reply some messages, causing memory holes.

Thus, mostly bugfixes, though the class itself is quite a bit shorter now because code that was part of the class moved into intuition, and it was also
recompiled with somewhat better compiler settings.

[kriz]

Really nice update !! In Depth stuff !!