Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135128 times)

Description:

0 Members and 3 Guests are viewing this topic.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #449 from previous page: December 09, 2019, 04:18:26 PM »
It is clearly a legal necessity, since code has been trickling down from OS4. Right?
Only under the premise that Cloanto & Hyperion don't find an agreement, or Cloanto wins a case.


Nothing wrong with that per se, but by nilly-willy pulling in OS4 components, the legal situation of the code gets even more entangled.
It depends. It is already complicated with the 3.1 code alone, and it unclear to me in how far this could be released to the public either. Besides, just using 3.1 only for 3.1.4 development wouldn't have made it much simpler. It is Hyperion, after all.

Unlike 3.9? Really. I don't find 3.5 and 3.9 to be very "radical" compared to 3.1, nothing fundamental was changed. With 3.2 there will be quite a few fundamental changes though, like system-startup, loading kickstart components from disk and setting up various devices pre-boot.
The GUI changed with 3.9 due to reaction, and it was the first Os that was 68020 only. 3.2 goes into a different direction.

And this bewilders me - IDEFix97 is named this for a reason - it came about in 1997 - it is more than 20 years ago. And support in other operating systems came along within a few years. And as it turns out, OS3.9 and OS4 also has had support all along... so, is it really experimental?
You surprise me. 3.1.4 has the same sort of "support" for it, as the scsi.device is based on the 3.9 version. Believe there must be reasons in 3.9 *NOT* to enable it by default. As the code I posted shows, it was probably due to an agreement between H&P and Oliver Kastl. The technical reason is likely that, without connecting a second drive, the gates of such adapters may be floating, and then may read whatever was on the bus, so the detection is unreliable and may return false positives.

One way or another, I do not know, and I haven't tested, and what has not been tested does not work.


And refrain from using emulators as test cases?? This is _exactly_ what makes WinUAE so extremely useful, it has pretty much accurate emulation of _tons_ of Amiga hardware - and then the OS developers refuse to touch it? I find this ridiculous!
In this case? Not at all. WinUAE is certainly fine as far as high-level emulation is concerned, but otherwise, it depends very much on models of the hardware that may or may not reflect reality. As for example for the four-way adapters, I'm quite sure it emulates them fine in so far as it makes the detection code happy, but that's not quite what I need. I don't need to test the code in the easy cases. I need to test it in real life, with the effects you get then - such as reading all sorts of nonsense if there is no drive connected.

Just to give you an idea: We couldn't test CDFS audio support either because WinUAE does not emulate it properly, but we had beta testers that could perform the testing. And CDXL support is still missing from it because we cannot test properly.

Yes, it means sometimes that features will go due to lack of hardware. If I get hands on the hardware, I can add support, but only then. As soon as it goes down to the real hardware level, emulation is a fairly bad advice.

Regarding the Reaction classes, I have two issues
* they are not the most efficient, nor the visually prettiest, often looking out of place
It is not efficient because boopsis are not efficient. They use a smalltalk-like dispatcher mechanism where every item on the hierarchy compares a method ID against the methods it supports, so one big lookup per level. The boopsi hierarchy can be pretty deep, so a lot of such dispatcher mechanisms are nested to each other. This makes it inefficient.

Yes, we know, and that's why the GUI is gadtools at this moment. So, it's a complexity that does not matter for you, or for any low-end machine, because it is not used. However, why is it so bad that reaction is delivered, as an option?

* more importantly - they are now considered Hyperion property and part of the "arsenal" against a better future.
Again, why all this hate against Hyperion? The same could be said about Cloanto. Both are commercial enterprises, and want to earn money, in one way or another.


No, "anyone free to have whatever anyone wish" is what I would prefer.
Ah, so once again: What is so bad about shipping Reaction? Don't use it, you're fine. You have a political agenda, and its against this agenda, but I'm talking about the technical aspects.


Old bugs that are _well known_ - which makes a huge difference.
Oh, really? So what's so great about knowing that graphics may trash my memory, and that trackdisk may trash my memory, and there is nothing I can do against it? This does not make me feel very comfortable.

Quite the reverse: With 3.x, such bugs will be addressed, and whatever bugs I get aware of. So what's better? An old rotten os, or one that is receiving updates?


And again I recommend to make a release candidate or two available in the wild for public testing at least for a month or two before burning and selling kickstart chips - it would _REALLY_ help a lot.
Yeah, right... so how would that work as commercial product? Not at all... So once again: Whoever wants to help testing is welcome, but no, it makes no sense to release ROMs to the public because then there is not much of a product left that can be sold.

I do not mind rebooting, I don't know why so many care so much, makes me wonder if their systems are so unstable that boot time is so important.
But you are not the only user. You are one of many users, and there were many voices that rebooting is troublesome. Not for me either, but that is not quite the point.


For me it is more important that systems are easy to debug, that they don't do unexpected things (like picking up some random ROM component from a filesystem that owner is using as download area)
There is nothing "random" at all. What is better? Not to upgrade components if you boot from another location, say a floppy? Or take the updates from another partition? You can easily "prevent randomness" by placing the right components into the boot volue.

Well, if you know different, then please feel free to elaborate.
No, I DO NOT know. That is exactly the point. I do not make promises I cannot hold, so I don't make any. There may or may not be an update, but it all depends on the spare time of the developers.

Necessary? Not at all - cool, but not necessary. But that was not what I was writing, was it - I was writing that what is presented here, with this 3.2 line, is much more of a change over 3.1 than what OS3.5 and 3.9 ever was.
No, not really. It is just a different direction. 3.9 was supposed to target "higher end machines", hoping for more to come. This did not become true. 3.2 is a different direction. Target all the hardware that is out in the wild, but do not add features that add complexity.


The "GUI" was not changed in 3.9 either, less so, as it was still good old 3.1 Intuition.
It changed pretty much for me.

Now we have Intuition.library v45 - based on original sources and rewritten from scratch, as the OS4 advert says... :)
I don't know which intuition Os 4 has, but the one we have has still all the original comments in it and is hence based on the original. It is just a very elaborate port of the greenhill C source of intuition, which could not compile "as is" on SAS/C due to some features the SAS does not offer.

Nothing - I welcome this. Too bad it will be entangled with Hyperion legalese.
And what's the "bad" part about it? This is exactly your problem. Hyperion is a commercial enterprise, Cloanto is another. If it would be under Cloanto, it would be "entangled by Cloanto legalese".

Well, I prefer this turned off, as it does not fit with my "workflow" where I often push windows to the screen border, or resize against a screen border. I would very much prefer to set qualifier that I can hold if I wish to drag windows off-screen. Also, without being able to have windows larger than screen, I really see very little use for it at all.
I may have forgotten that v45 implements a certain "resistance" of windows getting moved out of the screen. So you have to "push a bit harder" to move them.


It makes just as much sense as development of a retro-os on an original outdated CPU - sensewise, OS3 and OS4 are in the same boat.
I don't really see that. Os 4 started as obsolete Os on new hardware, hoping for more to come. At this time, the hardware is old, unpopular, expensive and outdated, without ever reaching the market penetration. 68K hardware is old, but has a history - like an oldtimer - that is worth preserving. The difference is the software collection - there is much more 68K software than PPC software that makes the 68Ks worth using.


And nothing prevents you. The point of AROS was to scratch an itch, not to offer a product, nor to please anyone else but the developers themselves. Not like your work has much more point.
Which itch? "We cannot do an Os either?" Yes, I see that, but what's the point?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #450 on: December 10, 2019, 05:04:43 AM »
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".
 
The following users thanked this post: Tygre, rxxic

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #451 on: December 10, 2019, 05:15:33 PM »
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.

 
The following users thanked this post: Tygre, rxxic

Offline rxxic

Re: Os 3.2 development preview
« Reply #452 on: December 10, 2019, 08:10:45 PM »
All the news about OS3.2 are exciting. It's very welcome you are heading towards eliminating as many bugs as possible in the OS! Thanks a lot for the passion and taking the time to develop and also posting the "Explanation Episodes"! :) :)
Are you developers hoping to get to a stage where will OS3.x be considered "completed" one day or will most or almost all the functionality of v3.9 be implemented (without wanting to step on anybody's toes, only those features which you developers deem to be sensible and worth implementing--of course)? And maybe possibly reach close to OS4 functionality (for those classic machines with more powerful expansions and/or vampires)? Well, the answer to this question might as well be something which is discussed internally in the dev-team, and is rather kept hidden 'till the time is right. ;)

Here a couple of questions regarding some features of which I not even know if it's possible to implement at all:

- I was wondering if it is somehow possible to change how the Pointer is rendered on some Screen Modes.
For example when using Multiscan the "Hi-Res" Pointer has right proportions. Using PAL Hi-Res interlace and the setting "Low-Res" pointer in pointer prefs, renders a huge Pointer; the "Hi-Res" setting in the latter preference editor, display a distorted pointer. Kind of ugly. I would love it, if it had the proper proportions instead.

- enhancement for “copy”, add a "pattern" option. So “copy PAT=#?.info ALL sys: TO backup:icons/“ wold be handy to use.
- Scroll wheel inversion, for those using a mouse with a scroll wheel and spoiled by a fruitOS
- For the Workbench, change "Delete" keyboard shortcut from RAmiga-D (yes, it's really "Delete" and sadly not "Duplicate") to RAmiga-Backspace and/or RAmiga-Del. To have a little more consistency with the shortcuts of the rest of the system. What does the Style guide say about it?
- Have the possibility to change the icon type in the WBInfo window. e.g., from "Project" to "Tool". Actually the RAWBInfo is really useful! :)
 

Offline Tygre

Re: Os 3.2 development preview
« Reply #453 on: December 10, 2019, 08:16:01 PM »
And secondly, "bullies"? I suggest you read yourself up on what "bullying" actually means and perhaps look up "sycophancy" while you are at it.

@kolla Please do so yourself for a refresher and also look at the definition and symptoms of a "chronic complainer"...

That must be really tough. ::)

Offline Minuous

Re: Os 3.2 development preview
« Reply #454 on: December 10, 2019, 10:47:04 PM »
@rxxic:

Well, don't throw away your OS3.9 CD just yet; not every tool will be as feature-complete as H&P's equivalents, so some components from OS3.2 will be better to be overwritten with OS3.9 components.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #455 on: December 11, 2019, 06:24:09 PM »
Are you developers hoping to get to a stage where will OS3.x be considered "completed" one day or will most or almost all the functionality of v3.9 be implemented (without wanting to step on anybody's toes, only those features which you developers deem to be sensible and worth implementing--of course)?
Well, what's "complete" then? It's probably "complete" when everybody lost the motivation to continue working on it. Whether someone will pick up to re-implement the reaction prefs is hard to say. I believe we should continue shipping the gadtools preferences for a while as the intention is not to exclude particular machines. However, that should not preclude us to implement additional alternative programs users may install instead.

And maybe possibly reach close to OS4 functionality (for those classic machines with more powerful expansions and/or vampires)? Well, the answer to this question might as well be something which is discussed internally in the dev-team, and is rather kept hidden 'till the time is right. ;)
Who can say? Actually, I don't think we would be able to re-implement everything from Os 4 as we have much less powerful machines available.

- I was wondering if it is somehow possible to change how the Pointer is rendered on some Screen Modes.
For example when using Multiscan the "Hi-Res" Pointer has right proportions. Using PAL Hi-Res interlace and the setting "Low-Res" pointer in pointer prefs, renders a huge Pointer; the "Hi-Res" setting in the latter preference editor, display a distorted pointer. Kind of ugly. I would love it, if it had the proper proportions instead.
This is pretty much a limitation of the graphics system, both the hardware and the actual implementation of graphics.library. Graphics.library has to be replaced at some point, but this is a major task.


- enhancement for “copy”, add a "pattern" option. So “copy PAT=#?.info ALL sys: TO backup:icons/“ wold be handy to use.
I can keep this as a feature request, though you can probably create a script nowadays that does that with list and lformat. Actually, the shell is not very powerful - it should at least include better means for iteration.

- Scroll wheel inversion, for those using a mouse with a scroll wheel and spoiled by a fruitOS
The native hardware does not have input for scroll wheels, though some USB stacks send the right events. However, it also takes programs to handle these events. It is not simply a matter of the scroller as it is not directly the receiver of the events, but the window the scroller is in is. Thus, it would require to upgrade programs using scrollers to make use of these events.


- For the Workbench, change "Delete" keyboard shortcut from RAmiga-D (yes, it's really "Delete" and sadly not "Duplicate") to RAmiga-Backspace and/or RAmiga-Del. To have a little more consistency with the shortcuts of the rest of the system. What does the Style guide say about it?
My style guide says that we shouldn't change such traditions lightly.

- Have the possibility to change the icon type in the WBInfo window. e.g., from "Project" to "Tool". Actually the RAWBInfo is really useful! :)
Frankly, the info window should not replace an icon editor. There are specialized programs to modify icons in all possible ways. Arguably, the included icon editor is a very primitive one.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #456 on: December 11, 2019, 06:36:04 PM »
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.
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #457 on: December 11, 2019, 08:35:20 PM »
Thanks for the datatypes updates!   Is text search possible for AmigaGuide?   
WAV and AIFF datatypes on Aminet don't seem to work on 3.1.4.   Any likely hood of including some updated sound WAV / AIFF ones in the future?
 

Offline Johan Samuelsson

  • Full Member
  • ***
  • Join Date: Sep 2002
  • Posts: 243
    • Show only replies by Johan Samuelsson
    • http://www.ponnyslakteriet.com/uprough
Re: Os 3.2 development preview
« Reply #458 on: December 11, 2019, 10:01:45 PM »
@Thomas thanks for all your replies and updates.
Did you miss my question?

”Hi! Would it be possible to implement an option to hide .hidden unix files?
It’s very annoying these days working with files on a usb stick that came from a mac etc. So much clutter.”
.\\\\ Spot / Up Rough Soundsystem //.
check it ---> http://www.uprough.net
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #459 on: December 12, 2019, 05:07:10 AM »
Thanks for the datatypes updates!   Is text search possible for AmigaGuide?   
No, no updates there.
WAV and AIFF datatypes on Aminet don't seem to work on 3.1.4.   Any likely hood of including some updated sound WAV / AIFF ones in the future?
They do work, but only for 8 bit samples because this is all the hardware can do.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #460 on: December 12, 2019, 05:07:56 AM »
”Hi! Would it be possible to implement an option to hide .hidden unix files?
No.
 

Offline my_pc_is_amiga

Re: Os 3.2 development preview
« Reply #461 on: December 12, 2019, 07:11:33 AM »
They do work, but only for 8 bit samples because this is all the hardware can do.

I'll have to check more but I seem to be getting "Unknown data type for <filename>" for both a AIFF and WAV file.

I was trying the versions here:
https://www.stephan-rupprecht.de/
 

Offline Gulliver

Re: Os 3.2 development preview
« Reply #462 on: December 12, 2019, 07:41:39 AM »
They do work, but only for 8 bit samples because this is all the hardware can do.

I'll have to check more but I seem to be getting "Unknown data type for <filename>" for both a AIFF and WAV file.

I was trying the versions here:
https://www.stephan-rupprecht.de/

To make that particular wav datatype work on any 3.x version of AmigaOS you also need to use his sound.datatype v41.
 

Offline rxxic

Re: Os 3.2 development preview
« Reply #463 on: December 12, 2019, 08:40:47 AM »
Are you developers hoping to get to a stage where will OS3.x be considered "completed" one day or will most or almost all the functionality of v3.9 be implemented (without wanting to step on anybody's toes, only those features which you developers deem to be sensible and worth implementing--of course)?
Well, what's "complete" then? It's probably "complete" when everybody lost the motivation to continue working on it. Whether someone will pick up to re-implement the reaction prefs is hard to say. I believe we should continue shipping the gadtools preferences for a while as the intention is not to exclude particular machines. However, that should not preclude us to implement additional alternative programs users may install instead.

And maybe possibly reach close to OS4 functionality (for those classic machines with more powerful expansions and/or vampires)? Well, the answer to this question might as well be something which is discussed internally in the dev-team, and is rather kept hidden 'till the time is right. ;)
Who can say? Actually, I don't think we would be able to re-implement everything from Os 4 as we have much less powerful machines available.
Well then, I suppose it's "completed" when it will not be possible to add functionality without excluding some machines.
Quote

- I was wondering if it is somehow possible to change how the Pointer is rendered on some Screen Modes.
For example when using Multiscan the "Hi-Res" Pointer has right proportions. Using PAL Hi-Res interlace and the setting "Low-Res" pointer in pointer prefs, renders a huge Pointer; the "Hi-Res" setting in the latter preference editor, display a distorted pointer. Kind of ugly. I would love it, if it had the proper proportions instead.
This is pretty much a limitation of the graphics system, both the hardware and the actual implementation of graphics.library. Graphics.library has to be replaced at some point, but this is a major task.
That's a pity as it is one of the most prominent every-day visual things which catches the eye!
Quote
- enhancement for “copy”, add a "pattern" option. So “copy PAT=#?.info ALL sys: TO backup:icons/“ wold be handy to use.
I can keep this as a feature request, though you can probably create a script nowadays that does that with list and lformat. Actually, the shell is not very powerful - it should at least include better means for iteration.
yes, a two stages script is ok, you are right, one to create the subdirectories and one to copy the files itself.
The above example I posted would not work anyway as there is a need for an additional optional keyword (e.g. MULTIPLE) in order to tell "copy" to create the subdirectories as well. Else the files will probably all be copied to the directory given as argument, possibly creating naming conflicts.
Quote
- Scroll wheel inversion, for those using a mouse with a scroll wheel and spoiled by a fruitOS
The native hardware does not have input for scroll wheels, though some USB stacks send the right events. However, it also takes programs to handle these events. It is not simply a matter of the scroller as it is not directly the receiver of the events, but the window the scroller is in is. Thus, it would require to upgrade programs using scrollers to make use of these events.
Oh dear, this is complicated and updates for old software are highly unlikely to happen. Thanks for explaining this. I take back my proposition.
Quote
- For the Workbench, change "Delete" keyboard shortcut from RAmiga-D (yes, it's really "Delete" and sadly not "Duplicate") to RAmiga-Backspace and/or RAmiga-Del. To have a little more consistency with the shortcuts of the rest of the system. What does the Style guide say about it?
My style guide says that we shouldn't change such traditions lightly.
looks like my suggestions are very too much influenced by other OSs. I apologise. However, I still think it is a good idea to have the delete/backspace key do what it is usually associated with.
Not trying to force your decision here at all, but if this change was going to far, many of those ones concerning consistency should be discarded too.
And window dragging beyond the screen corner is weird to Amiga OS too. Or the new options in the early-boot to update some ROM modules from disk. Or kind of eliminating AUX.. I'll stop, it starts to read a rant. ;)
Quote
- Have the possibility to change the icon type in the WBInfo window. e.g., from "Project" to "Tool". Actually the RAWBInfo is really useful! :)
Frankly, the info window should not replace an icon editor. There are specialized programs to modify icons in all possible ways. Arguably, the included icon editor is a very primitive one.
Yes, you are right here too, it was just a matter of being handy, probably only personally to me; because I am the lucky one here, encountering icons with the wrong type associated to them surprisingly often.

I might in this regard have a little bug to report for IconEdit. I can reproduce this on a vanilla 3.1.4.1 and also 3.1.4.1 plus the latest BestWB v1.3. If I try to exchange the images of the AWeb icon included in the official AmigaOS 3.14 IconPack (Masons)--the Keyboard-shortcut is RAmiga+e--it will not do it. This happens with all new official multicoloured icons so far. The images of the 1992 4-col icons do swap.
I managed to swap the images of the new official Mason icons for 3.1.4 with the OS4 IconEditor however. :)
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #464 on: December 13, 2019, 06:19:01 AM »
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.
 
The following users thanked this post: Tygre