AmigaOS 3.2 released!

[Olaf Barthel]

Originally Posted by Ras Voja

Its bad argument. It is in world of my ZX83, but in 2022 ...
If PFS3 is faster, no validiation and just lacks few tools, waste of time is your choice.

Hey, I'm seriously doing work on an operating system which has its supporters but matters little for the world outside of this community. Some people may consider this a colossal waste of time

Please increase ROM dumped to RAM to 1-4MB and put both in ROM.
AmigaOS supports it.

So much for the software/firmware side. We also need to consider how those not blessed with as much RAM will fare. It's hard, but we also have an obligation to cater for the full hardware platform, down to the most humble configuration.

This is one of the challenges of the current iteration of AmigaOS 3 maintenance/development work. Something will have to give, eventually. Until then we must play with the deck and the rules which were handed down to us.

So for 3.2.2 it will not be much improved nor replaced?
Please, port gparted for 3.3

We don't need yet what gparted has to offer.

Can you include messy DOS beside CrossDOS?
http://aminet.net/package/disk/misc/MSH-1.58

The rules are that if we commit to it, then we will have to support it properly. Including a painful code review and pondering the consequences. It's no fun painting yourself into a corner and to find out very late that you did so without realizing it. You might say, the current state of affairs is an exercise in finding out how large the corner is which still has room to paint in.

As for MessyDOS, colour me skeptical. This code even features large assembly language portions which are a sure sign of trouble ahead. There is no license included and the code is at least 15 years old. Smells very risky to me, and according to the rules we play by, committing to such a codebase would be a major investment. We already have such commitments to ReAction integration, for example, which take up a painful amount of time

That said, if we can find somebody to help us out and integrate it properly, all obligations included, never say never

[Thomas Richter]

Originally Posted by Ras Voja

Should I stress improve RAM: and RAD: and use them as equal and fastest device we have. Today people have 64,128,256 on Angela V4 even 512MB verrry FAST RAM and small apps

Improve on *what* exactly? I mean, if you request features, what are the features?



RAM: and RAD: are fast, but they are two very different things, and they are not the solution for "everything I want to keep in ram". There are other mechanisms to keep things in Ram, and depending on "what that thing is", these other mechanisms may be better suited.



RAM: is a file system of its own. It organizes files, directories,knows the names of the things that are in it. It is aware of the objects it contains.



RAD: is like a blank harddisk without any structure. RAD: needs a file system you put on to organize the files for it. In most cases, it is an FFS you "format" the RAD: with. It is the file system that knows the objects, not the ramdrive.device underheath RAD: consists of. Look at the mount entry for RAD: It does have a mount entry, unlike RAM:



Thus, in case of doubt, RAM: is the faster of the two since it manages its own data. RAD: goes through two layers. The filesystem (FFS) and the actual ramdrive.device keeping the data.

[Thomas Richter]

Originally Posted by Ras Voja

Can you include messy DOS beside CrossDOS?
http://aminet.net/package/disk/misc/MSH-1.58

What does it do CrossDos doesn't? I bought MSH before CrossDos arrived (at 2.1 times, if I recall), but it was even more limited than CrossDos.


Just to name a couple of things, CrossDos does now support long file names, larger volumes, multiple variants of FAT (the skinny and the really fat ones) and also became multi-threaded.


Going through this whole exercise again for just the same file system structure - what would buy that?

[Olaf Barthel]

Originally Posted by Ras Voja

Should I stress improve RAM: and RAD: and use them as equal and fastest device we have. Today people have 64,128,256 on Angela V4 even 512MB verrry FAST RAM and small apps

Of course there are such happy users. But, as I mentioned, we also still cater for those users who expect that Amiga OS will make the most of even modest configurations. Indeed, this is what the operating system is, arguably, designed for.

You can see this tilt towards small memory configurations in the design and implementations of its components, and ram-handler is a good example for this.

Any impression ram-handler gives of being fast is something of an illusion. It only is fast in relation to hard disks and SSDs, and it is only "fast" if it stores a few hundred files, tops, and these files should not be much larger than a few thousand bytes.

Once you cross these thresholds, ram-handler will show how poorly it scales. The basic building blocks of ram-handler are lists of blocks and directory entries. Even FFS scales better on a standard Amiga floppy disk, without even trying.

ram-handler was designed for a system for which RAM: will have filled up long before the scalability issues would become apparent. This is also why it's so (relatively speaking) small. The original ram-handler was barely 24 KBytes of source code (some 850 lines of code). The "modern" ram-handler implementation certainly is larger, but it also does so much more than the Kickstart 1.x version.

ramdrive.device has its own constraints, some of these related to how much memory is available which will not go away after a reboot. For example, one constraint is in that it expects the FFS to be around because ramdrive.device only creates a "skeleton" file system structure which the default file system will then fill in. This is one of the duties of the default file system.

[Olaf Barthel]

Originally Posted by mfilos

Thanks for the reply Olaf! I get it fully now.
Can we have a Ram-Handler module update to try before next update (3.2.2 etc)?

Hard to say at this point. The most recent ram-handler (or as it is known as the ROM module "ram", to its friends, if it had any) is still being tested.

I for one would be happy to see that this round of testing does not reveal another subtle performance issue which went unnoticed since 1989

What I can promise you, however, is that this new version of ram-handler will be faster than any version which ever preceded it, will have fewer bugs than the OS4 version but hopefully no new bugs

[Romanujan]

Have you tried comparing the new RAM disk performance to AmberRAM? Would it be feasible to allow user to create two RAM disks? I always use AmberRAM to move T: out of RAM:.

[Olaf Barthel]

Originally Posted by Romanujan

Have you tried comparing the new RAM disk performance to AmberRAM? Would it be feasible to allow user to create two RAM disks? I always use AmberRAM to move T: out of RAM:.

I am convinced that, without putting it to the test, that no matter which alternative to ram-handler you will try, ram-handler will always perform worse, likely by a wide margin.

The constraints imposed upon ram-handler have not changed, and what it previously could do only poorly is still being done poorly by the current version. However, with all the changes in place due to bug fixes and other surprises, the current ram-handler will do less poorly than its precursors.

[Thomas Richter]

Well, Olaf, I wouldn't be so modest. Actually, I am much more afraid of alternative RAM handlers knowing all the pitfalls (and the long development history of the RAM-Handler). As you know, writing a file system is non-trivial, in particular in regards to ACTION_EXNEXT, for iterating through a directory - and this packet must work, even if the file or directory is erased "under the feed" of the file system through a second process.

I have probably seen too many bad implementations to be confident that anything alternative works a lot better. It may possibly be faster, but likely with more defects than RAM - it is simply too easy to get it wrong. I remember a rather long conversation with Jörg on the ENV-Handler on this topic, and the end result, if I recall correctly, was an "oops!".

..which was actually why this "copy on read" functionality came into RAM, and not into a separate handler. It is just quite error prone to write one, and the RAM construction had at least sufficient time to age and the bugs fixed (at least the most obvious ones) . I personally trade stability to speed any time.

Long story short, there are parts of Tripos legacy in dos that were just ill-designed (or designed without too much thought it seems).

[mfilos]

Ok some more questions concerning MenuTools which I started using (porting my ToolsDaemon menus as we speak):

1. As I edit the file and saving I realized that re-running MenuTools doesn't quit (as most commodities/apps do) and also doesn't show my changes so I have to restart
   Is there a way I can close MenuTools to re-run it and see my changes without restart? (as it's not a commodity, Exchange doesn't work for it)
2. How can I run more than one command per menu item? (I can make a script and then call the script, but I'd prefer a more elegant way). ToolsDaemon for example permits multiple lines per menu item.
3. How can I pass parameters to a menu item? (for example I have an "EDIT Text" menu item that opens my editor and has to pass the filename as parameter). ToolsDaemon uses [], DOpus uses {f} etc.
4. I tried to use quotation marks ("") within a command (for example Echo "This is a test") then I get an error as it's already inside quotations marks. Is there a way I can handle that (using for example wildcards for the quotes)

Last but not least a crazy idea...
I wondered that since MenuTools is text based as well, if I could make it dynamic.
Example would be...

• Header file (with the lines OPTIONS RESULTS and ADDRESS WORKBENCH)
• File1 that has declarations of drawing MenuTitle1
• File2 that has declarations of drawing MenuTitle2
• Footer file (with the line EXIT)

I would make a script where I perform a BOARD detection and if it was possitive then add the MenuTitle2 else not. Script would only need to concatenate Header+File1+File2+Footer and then put it as MenuTools in WBStartup before LoadWB.
(I guess using scripting language inside the Arexx script is out of the question that's why I thought this approach).

I know I sound a bit crazy of thinking that, but I thought it would be nice BEING able to completely disable my VAMPIRE menu title bar with all it's contents if a Vampire Board is not Present (which happens when I change my CF to WinUAE or another Amiga without Vampire)

[indigolemon]

Originally Posted by Ras Voja

very reasonable solutions

honestly

[duga]

Originally Posted by Ras Voja

Should I stress improve RAM: and RAD: and use them as equal and fastest device we have. Today people have 64,128,256 on Angela V4 even 512MB verrry FAST RAM and small apps

AmigaOS 4.1 with a PowerPC processor is even faster.

[Daedalus]

Originally Posted by mfilos

As I edit the file and saving I realized that re-running MenuTools doesn't quit (as most commodities/apps do) and also doesn't show my changes so I have to restart
Is there a way I can close MenuTools to re-run it and see my changes without restart? (as it's not a commodity, Exchange doesn't work for it)

Not really, because not only is it not a commodity, it's not even a program. It's Workbench itself that controls the menus, MenuTools is simply a script that tells Workbench which menus to add. To change a menu item, you first need to remove it with the REMOVE command and then re-add it. The best way however is probably to remove all menus and re-add them all so that the order is kept the same.

How can I run more than one command per menu item? (I can make a script and then call the script, but I'd prefer a more elegant way).

Hmmm, I think that's probably the way to go.

How can I pass parameters to a menu item? (for example I have an "EDIT Text" menu item that opens my editor and has to pass the filename as parameter). ToolsDaemon uses [], DOpus uses {f} etc.

Because you're dealing with the Workbench ARexx port directly, you need to go a little lower level. Essentially, you need to check the active workbench window for any selected icons, then execute the desired command with the list of icon names selected. That might mean just running it once with multiple arguments, or running it multiple times.

I tried to use quotation marks ("") within a command (for example Echo "This is a test") then I get an error as it's already inside quotations marks. Is there a way I can handle that (using for example wildcards for the quotes)

Quotes in ARexx can be a little funny, but there's a logic to them. What you can do is use single quotes to differentiate, for example 'Echo "this is a test"'. Sometimes this might not work either depending on how the command is run, so again, it might help to put what you need in a small script.

I wondered that since MenuTools is text based as well, if I could make it dynamic.
...
I would make a script where I perform a BOARD detection and if it was possitive then add the MenuTitle2 else not.

That should be easy enough to do...

(I guess using scripting language inside the Arexx script is out of the question that's why I thought this approach).

Not at all, the script itself is just ARexx, there should be no problem adding non-menu-specific things there. The only issue that might arise is if an external tool is used to generate the script, it might overwrite your modifications.

[mfilos]

Thanks for the replies Daedalus.

Is there a thorough documentation of MenuTools cause the Help didn't give info and the nice written documentation inside MenuTools (commented body) is only for adding menu items. Nowhere how you remove.
I'd also would be grateful for an explanation about the request of mine about passing parameters cause I didn't understand clearly what you said.

Thanks for your time anyway

[Olaf Barthel]

Originally Posted by Ras Voja

It is, but I am sad you are constantly refusing very reasonable solutions to permanently improve OS

OK whatever you do I ll take it, but I hope you can some of suggestions reasonable for AOS 3.3. And yes, you can go beyond OS 3.5 and OS 3.9, and should. Forget the low ver numbers, irrelevant.

We already left 3.5 and 3.9 behind for good with 3.2.

The changes currently being worked on now bump against ROM space and RAM limitations which did not exist in earlier releases, which is opening up another can of worms. Components which have to be in ROM cannot be dropped or loaded from disk. The ROM is not a boot environment. Existing software and firmware depends upon components being present.

Our challenge now involves finding ways to save to space by optimizing existing code so that it allows other components, which grew because of necessary bug fixes (e.g. ram-handler) to fit and still leave room for further bug fixes.

This is, for now, the measure by which we gauge what is reasonably possible

As for finding a place for existing software, such as PFS3, it has to be done right. For Amiga OS 3.5 and 3.9 both we chose integrating 3rd party solutions rather than bundling them. Anybody can assemble her or his choice of existing components to use alongside what ships as part of the operating system package. But there has to be more than this for a product such as Amiga OS 3.3. For one thing, code review and the changes which are bound to be prompted by it, are necessary. This goes double for older original operating system components which can contain a surprising number of subtle bugs such as ram-handler.

[malko]

Originally Posted by Olaf Barthel

[...] The changes currently being worked on now bump against ROM space and RAM limitations which did not exist in earlier releases, which is opening up another can of worms. Components which have to be in ROM cannot be dropped or loaded from disk. The ROM is not a boot environment. Existing software and firmware depends upon components being present.

Our challenge now involves finding ways to save to space by optimizing existing code so that it allows other components, which grew because of necessary bug fixes (e.g. ram-handler) to fit and still leave room for further bug fixes.

This is, for now, the measure by which we gauge what is reasonably possible
[...]

Thank you for all the work done so far and for the upcoming one !

[Olaf Barthel]

Originally Posted by Thomas Richter

Well, Olaf, I wouldn't be so modest. Actually, I am much more afraid of alternative RAM handlers knowing all the pitfalls (and the long development history of the RAM-Handler). As you know, writing a file system is non-trivial, in particular in regards to ACTION_EXNEXT, for iterating through a directory - and this packet must work, even if the file or directory is erased "under the feed" of the file system through a second process.

Actually, I'm more annoyed than modest with regard to what I found in ram-handler there. After some 20 years of code changes it still contained major bugs going back to Kickstart 2.0 and 3.1 which took a long time to discover. Once you see them, you cannot unsee them again

Then you have to fix them, but the fixes require additional space and that has to be balanced by finding code which can be refactored or rewritten to save some 8-20 bytes here and there until the total of the savings add up. Repeat that as you find more bugs, etc. I have a bad feeling that this is what's in the cards for Amiga OS 3.3 development. It was amazing to discover how much space you can save by reordering variable initializations or dropping unnecessary "case" statements. Refactoring also revealed which code was actually never used.

I have probably seen too many bad implementations to be confident that anything alternative works a lot better. It may possibly be faster, but likely with more defects than RAM - it is simply too easy to get it wrong. I remember a rather long conversation with Jörg on the ENV-Handler on this topic, and the end result, if I recall correctly, was an "oops!".

You made the right call. The only small thing which worries me about it is that there is no safety limit for the size of files which will be transferred into RAM:. If somebody accidentally accesses a file whose size will exceed the available memory by far, ram-handler currently will proceed to read as much as it can before it eventually has to give up. But I do not have any idea how to render this approach safer. Currently, you cannot even stop it.

Long story short, there are parts of Tripos legacy in dos that were just ill-designed (or designed without too much thought it seems).

Nobody could have predicted the longevity of this Tripos branch. As the file system design and certainly ram-handler shows, the original developers were very aware of the constraints of the hardware available at the time. If I remember correctly what "Lion's commentary on UNIX 6th edition" shows, the Unix designers were just as aware as the Tripos designers, but they aimed much higher.

[Daedalus]

Originally Posted by mfilos

Is there a thorough documentation of MenuTools cause the Help didn't give info and the nice written documentation inside MenuTools (commented body) is only for adding menu items. Nowhere how you remove.

Because MenuTools itself isn't really anything more than a simple ARexx script, I guess it comes under the main ARexx documentation. If you open OS3.2's help documentation, there's a section on the Workbench ARexx port. It's fully documented in there. As far as I can tell, it's very close to the OS 3.5/3.9/4.x Workbench ARexx implementation, so the 3.9 manual or 4.1 documentation should also be suitable.

I'd also would be grateful for an explanation about the request of mine about passing parameters cause I didn't understand clearly what you said.

Well, ToolsDaemon and DOpus both take the marker you insert that represents the selected file and do some internal processing and communication with Workbench to provide the selected command with the appropriate arguments. With MenuTools, you're dealing with Workbench directly so you have to do that communication and processing yourself in the script. It's not that difficult, but it's a few lines of code rather than a single placeholder. There are lots of examples around, including the EjectADF and ArrangeIcons scripts provided with 3.2(.1) in REXX:. Check them out and see if you can make sense of how they get the icon names needed.

[mfilos]

@Daedalus
Thanks a lot man. Will definitely give some read


I guess that only me gets annoyed from PFS3's write delay (that FFS and SFS don't have).
I'm a nub at filesystems but always liked that you can edit a file and reboot immediately on FFS/SFS while you have to wait some secs on PFS3 or your changes are lost :/

[Olaf Barthel]

Originally Posted by mfilos

I guess that only me gets annoyed from PFS3's write delay (that FFS and SFS don't have).

Hang on, the FFS and its precursors have a write delay which made the original Amiga file system such a "brittle" choice for use on floppy disks.

The time between the last write command having been processed and the file system flushing the changes to the medium, then stopping the motor, is 3 seconds. This goes both for the original Amiga file system and the FFS.

So, if you want to be reasonably safe, wait at least 3 seconds before you reboot your system. If you restart earlier, the file system processes may not have written back their changes yet.

[mfilos]

Thanks for the clarification Olaf. I certainly didn't know that, but tbh, I haven't actually managed to witness such a problem using FFS these last 2 weeks of using it.
Will keep that in mind for sure though