Hyperion announces OS 3.1 update

[guest11527]

That'll screw up all dates that are stored as a 32-bit integer.  I suspect this includes FFS.

No, FFS is fine. AmigaOs was always two operating systems under one hood, the "exec" part, and the "dos/Tripos" part. Surprisingly, as far as time is concerned, "dos" is fine. Its datestamp structure can keep time for a long, long while. Just the timer.device branch is broken, so the conversion between the dos and timer is broken.

[olsen]

That'll screw up all dates that are stored as a 32-bit integer.  I suspect this includes FFS.

The date stamp information used by the FFS, all file systems, dos.library, etc. is genuinely and thoroughly "pre-screwed" already (thank you very much, Tripos). It is good for at least another 5 million years, although I suspect that the time and date conversion inside dos.library will have rolled over several times before the signed 32 bit day counter reaches the ends of its tether

Modern man has been around for only 1 about million years, so I guess we could pin our hopes on other intelligent species to arise and maybe find a fix for that pesky year 5,883,516 problem in what the ancients used to call the one true operating system.

[olsen]

Backticks exists in unix-shells aswell but the gain is that you can nest things with the $(command) syntax. Now you sometimes need to break things up on multiple lines to obtain the same result. I don't think the exact same bash-like syntax would be necessary but I would really like the ability to nest commands if possible!

Something like:
Echo "$(dir $(cd))"
Which is a very bad and useless example but I just tried to come up with something quickly

The basic problem we have with the shell is that it's not designed to be extensible. You cannot currently write a shell script which is able to probe for extended shell capabilities. Mind you, the shell is not an interpreter, and it does not have a consistent language as such. Sure, it's Turing-complete, but that doesn't mean it's useful (your basic Turing machine is Turing-complete, too, but it doesn't do anything beyond that).

If I remember correctly, the complete shell "language", such as the portion which covers variable expansion, escape characters, brackets and other arcana, is still underdocumented to the point that you could drop the letters "der" from that word and still make sense. Let's not put lipstick on that pig just yet

[kolla]

Just port DCL already, hehehe :p

[guest11527]

Mind you, the shell is not an interpreter, and it does not have a consistent language as such. Sure, it's Turing-complete, but that doesn't mean it's useful (your basic Turing machine is Turing-complete, too, but it doesn't do anything beyond that).

If I remember correctly, the complete shell "language", such as the portion which covers variable expansion, escape characters, brackets and other arcana, is still underdocumented to the point that you could drop the letters "der" from that word and still make sense. Let's not put lipstick on that pig just yet

Years ago I tried to cover the syntax of the shell in the Shell.guide that should be part of 3.9, or at least of the shell updates I provide from time to time. Yet, the syntax documented there is rather the consequence of various Tripos legacy functions that are used here and there within the shell, and I try to keep this syntax consistent, even though it is ugly as hell. Unfortunately, nobody really thought of the consequences when implementing this stuff, aparently in a rather ad-hoc way of "ok,works for me".

So for example foo"bar parses as a single token by the dos.library ReadItem(), which is why the shell syntax parser has to follow it. Similarly, foo" is a single token whose last character is a double quote,and so is foo) or (foo, where the bracket is not a separate token, but part of the token. Then, the "*" is an escape character, but only within quotes, and mind you again, an inner quote is not a quote but a literal, so it does not make the star any special.

All this weirdness has several consequences, especially in the low-level "tools" of the such as Execute, which has to insert formal parameters into strings, and depending on whether they are quoted, has to use the escape mechanism of BCPL to get the substitution right. Execute was, therefore, seriously broken up to V45, and probably even there it might have some corner cases I simply failed to fetch. Escaping and quoting *should* work now, but its non-obvious.

Just recently, I found that RequestFile is also broken as it always puts double quotes aruond the selected files. Which is wrong - consider a file that contains a double quote as part of its name, or an asterisk. Select a file named foo"bar, and the result of RequestFile would be "foo"bar", which are two tokens, namely "foo" and bar", and not the desired one token. Oh well...

This is precisely why I prefer *NOT* to extend the shell syntax. It's really not getting any better by adding more rules to the already inconsistent syntax.

[wiser3]

Probably not. By this time, I will be retired anyhow. (-: The problem is that the system time is in a 32-bit integer, in seconds since 1979 or so, which runs out in 2036 if I computed correctly.

So yes, we would need a 64-bit timer device and a 64-bit system time by then.

UNIX worked the same way. So how are they handling this situation?

I would recommend a 64-bit integer accurate to three decimal places instead of just to the nearest second. How many decimal places does the new Apple APFS track seconds? Can't remember off the top of my head.

Deprecate the old 32-bit integer system. Old software using this system after the 2036 roll over will get the wrong date. But at least new software and the OS would be able to track proper dates and times.

[Gulliver]

@olsen
@Thomas Richter

Hi, back again. Here is a list of old bugs/abnormalities, have they been addressed?
Sorry for the long post.


utility.library (bug reported by Peter Keunecke)
===============
There is a potential risk of getting asystemcrash in some rare
cases caused by a dangerous procedure in the ROM-function
CloneTagItems(), which does not switch off the multitasking
during the copy routine. Whenever another task uses
RefreshTagItemClones() or other means to change the source
TagList while the copy is still running, it could happen, that
CloneTagItems runs out of memory and trashes the next memblock.

exec.library (bugs reported by Harry Sintonen)
============
exec/Alert() causes privilege violation trap with 68010+
CPUs if VBR is not at zero and the alert is of DEADEND type (very
annoying bug).

exec/FreePooled() not releasing memory. Empty puddles would not
get returned to the free memory list until the pool was DeletePool()ed
(minor but yet annoying bug).

exec/ReleaseSemaphore() trashing d0/d1/a0 when calling release
without obtain (minor bug, can only occur with misbehaving exec/Alert()
patch).

Missing BOOL return code workaround to exec/CheckIO() routine. The new
code should try to figure out if the caller is going to interpret the result
wrong, and if this is the case, will fix the return code (minor bug).

exec/OpenLibrary() not passing open-version in d0 for LIB_OPEN,
unlike the example sources suggest. (minor bug)

SAD/TURN_ON_SINGLE returning crap as old trace vector address
and SAD/TURN_OFF_SINGLE sending 4 bytes of crap after command DONE.
(minor bugs, as no-one really use SAD)

Return code workaround for old amiga.lib (upto version 40.15)
CreateTask() misinterpreting exec/AllocEntry return code. amiga.lib
V44.1 fixed this bug, but lots of current programs still have the bugged
CreateTask() routine in them. (nasty bug, causes crashes in low mem
 situations)

Workaround for exec/GetMsg() and 68060 CPUs, braindead programs
calling GetMsg() in tight loop would lock up the system. (minor bug)

exec/ReleaseSemaphore() calculating wrong SS_NESTCOUNT when
both Procure() and ObtainSemaphore() were pending for the same task.
(nasty bug)

graphics.library
================
graphics/InitArea() bug, AreaEllipse() crashed if buffer wasn't
explicitly zeroed & maxvectors was limited to 8191.

The SetRGB32CM() AGA OS call doesn't set the lower 4 bits of the
blue component. You can prove this by calling SetRGB32CM() and
studying the blue component calling GetRGB32().

AmigaOS knows three functions in graphics.library that output
chunky pixels to a RastPort: WritePixelLine8, WritePixelArray8
and WriteChunkyPixels. The original versions of these routines
in the KickstartROM are rather slow and have a bug that trashes
the chunky source buffer. (Michael van Elst)

queue-handler (Heinz Wrobel)
=============
Nasty bugs with PIPE:, like loosing characters.

requestchoice (Joerg Riemer)
=============
The description of Requestchoice explains, that  the  secondary  return  
value  will hold the selected gadget number.  but RequestChoice never
returned a corresponding pr_result2 variable.

the reason for that is requestchoice uses the dos function (setioerr) to save
the  selected  gadget  number as the result2 variable.  but due the fact that
the  result2  variable depends on the returncode a program leaves in register
D0, this one never alifes a succesful exit of requestchoice.

during  the  debugging of RequestChoice i found two other hidden bugs.  there
was  some allocated memory never freed on exit and secondly, the dos function
ReadArgs() was not associated with FreeArgs().

version (Frederic Steinfels)
=======
The original c:version command had a nasty bug: If the last
four bytes of a file contained a $ sign, the version command
went into an endless loop.

amigaguide.library (James Jacobs)
==================
A delay is required between the SetAmigaGuideContext() and
SendAmigaGuideContext() calls.

No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.

asl.library 45.4: (James Jacobs)
===========
If you type a nonexistent path into the "Drawer" gadget (eg. SYS:Foo
when there is no such drawer) and then press ENTER, then (after you have
declined any offer to create the drawer), the program which called the
ASL library will crash (suspend/reboot requester) with error $80000005.

dos.library (James Jacobs)
===========
LoadSeg() will always report success on files that are less than 4 bytes
in size, even though the smallest valid executable is 36 bytes. Files from
4-35 bytes in size are still correctly reported as non-executable.

Installer (James Jacobs)
=========
The documentation for the "askchoice" function is wrong. The result of
"askchoice" is returned as a zero-based ordinal integer, not a bit mask.

version.library (James Jacobs)
===============
It doesn't seem to like being closed if some other program still has it
open (very briefly flashes up some guru alert).

[guest11527]

I found the original that should be in the bug db:

Yes, but *this bug* was fixed a long time ago. 1993 in my records. (-: So no worries.

[chris]

No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.

That was only recently fixed for OS4. Hopefully it's an easy one to backport.

There are also bugs in GadTool's image menu functionality (which may be an Intuition bug), which have been fixed in OS4 but existed in OS3 when I was trying to test if I was doing something wrong - and I suspect never worked. I don't see that being fixed though, as it doesn't work at all nobody uses it!

[guest11527]

utility.library (bug reported by Peter Keunecke)
===============
There is a potential risk of getting asystemcrash in some rare
cases caused by a dangerous procedure in the ROM-function
CloneTagItems(), which does not switch off the multitasking
during the copy routine. Whenever another task uses
RefreshTagItemClones() or other means to change the source
TagList while the copy is still running, it could happen, that
CloneTagItems runs out of memory and trashes the next memblock.

This is not a bug. Tags are not shared resources, and if they are, tasks need to use a locking protocol to avoid conflicts when accessing the same resource simultaneously. Taglists are not any different from this.

exec.library (bugs reported by Harry Sintonen)
============
exec/Alert() causes privilege violation trap with 68010+
CPUs if VBR is not at zero and the alert is of DEADEND type (very
annoying bug).

This is hairy and hard to address given that at DEADEND alert time, almost no guarantees can be given. I have this fixed, though I hope the fix works.

exec/FreePooled() not releasing memory. Empty puddles would not
get returned to the free memory list until the pool was DeletePool()ed
(minor but yet annoying bug).

This is not a bug. This is a design decision that puddles stay around and remain available, even if full, for the next allocation to be coming.

exec/ReleaseSemaphore() trashing d0/d1/a0 when calling release
without obtain (minor bug, can only occur with misbehaving exec/Alert()
patch).

This has already been fixed in Os 3.9.

Missing BOOL return code workaround to exec/CheckIO() routine. The new
code should try to figure out if the caller is going to interpret the result
wrong, and if this is the case, will fix the return code (minor bug).

I believe it was me who reported this bug to Heinz, and the v40 workbench was guilty of running into this. Yes, there is a workaround in exec, and a patch in SetPatch.

exec/OpenLibrary() not passing open-version in d0 for LIB_OPEN,
unlike the example sources suggest. (minor bug)

It cannot pass the version number in d0 - where is this nonsense documented?

SAD/TURN_ON_SINGLE returning crap as old trace vector address
and SAD/TURN_OFF_SINGLE sending 4 bytes of crap after command DONE.
(minor bugs, as no-one really use SAD)

SAD is a sad story. Hmm. I might even replace this by good ol' RomWack again. That was actually *a bit* useful.

Return code workaround for old amiga.lib (upto version 40.15)
CreateTask() misinterpreting exec/AllocEntry return code. amiga.lib
V44.1 fixed this bug, but lots of current programs still have the bugged
CreateTask() routine in them. (nasty bug, causes crashes in low mem
 situations)

That's a bug in AmigaLib. There is no workaround in exec. Yes, it is a bug to easily trap into. At worst, I would probably add something to setpatch. At this time, there is no fix.

Workaround for exec/GetMsg() and 68060 CPUs, braindead programs
calling GetMsg() in tight loop would lock up the system. (minor bug)

The fix is in since 3.9.

exec/ReleaseSemaphore() calculating wrong SS_NESTCOUNT when
both Procure() and ObtainSemaphore() were pending for the same task.
(nasty bug)

The fix is in since 3.9.

graphics.library
================
graphics/InitArea() bug, AreaEllipse() crashed if buffer wasn't
explicitly zeroed & maxvectors was limited to 8191.

The SetRGB32CM() AGA OS call doesn't set the lower 4 bits of the
blue component. You can prove this by calling SetRGB32CM() and
studying the blue component calling GetRGB32().

At this time, I'm not touching graphics. Sorry. This code is too messy, and I don't want to make it any worse.

AmigaOS knows three functions in graphics.library that output
chunky pixels to a RastPort: WritePixelLine8, WritePixelArray8
and WriteChunkyPixels. The original versions of these routines
in the KickstartROM are rather slow and have a bug that trashes
the chunky source buffer. (Michael van Elst)

See above. Not now.

queue-handler (Heinz Wrobel)
=============
Nasty bugs with PIPE:, like loosing characters.

The pipe handler has been completely rewritten. The old code was crap. There were a couple of new requirements for the shell and its pipe, so I had to add functionalities anyhow, like proper handling of the broken pipe condition, or unnamed pipe targets.

requestchoice (Joerg Riemer)
=============
The description of Requestchoice explains, that  the  secondary  return  
value  will hold the selected gadget number.  but RequestChoice never
returned a corresponding pr_result2 variable.

This is not really a bug, it is a side effect of how the shell works, but I don't want to change this in the shell. RequestChoice returns now a return code 1 in case it wants to signal that something but the rightmost gadget has been pressed. Besides, you can now set an abritrary variable (not just $Result2) on return, which is far more useful.

version (Frederic Steinfels)
=======
The original c:version command had a nasty bug: If the last
four bytes of a file contained a $ sign, the version command
went into an endless loop.

This must have been fixed already, it works fine here.

amigaguide.library (James Jacobs)
==================
A delay is required between the SetAmigaGuideContext() and
SendAmigaGuideContext() calls.

No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.

Cannot reproduce at this time, sorry. But there is a new version...

asl.library 45.4: (James Jacobs)
===========
If you type a nonexistent path into the "Drawer" gadget (eg. SYS:Foo
when there is no such drawer) and then press ENTER, then (after you have
declined any offer to create the drawer), the program which called the
ASL library will crash (suspend/reboot requester) with error $80000005.

The new version does not seem to have this problem.

dos.library (James Jacobs)
===========
LoadSeg() will always report success on files that are less than 4 bytes
in size, even though the smallest valid executable is 36 bytes. Files from
4-35 bytes in size are still correctly reported as non-executable.

Dos is again one of the components I will not touch at this time. I could create a SetPatch for this, but this does not seem to be serious enough to justify a patch.

Installer (James Jacobs)
=========
The documentation for the "askchoice" function is wrong. The result of
"askchoice" is returned as a zero-based ordinal integer, not a bit mask.

This is a documentation bug. But anyhow, there was and still is enough wrong with the installer which I need to revisit. For example, pattern matching seems to use the wrong style of patterns, and I found a MuForce hit in its internal wirings.

version.library (James Jacobs)
===============
It doesn't seem to like being closed if some other program still has it
open (very briefly flashes up some guru alert).

[/QUOTE]
Yes, this is fixed.

[Gulliver]

@Thomas Richter

Thank you again for taking the time to answer.

I have a couple more of questions:  

1.Will printer.device be 24 bit capable?
2.Is Reaction/ClassAct going to be included?
3.What about DefIcons?
4.AsyncWB?
5.RAWBInfo?
6.Will iconedit support glowicon editing? or will it be the same as 3.1?
7.Will ScreenMode prefs have the "Test" button function like in 3.9?
8.Will WBPattern have a layout option like in 3.9 where it lets you center, scale, tile or scale well the chosen pattern?
9.Mounter tool will be there?
10.A fixed Unarc?

[dannyp1]

Number 7 question above is a good question.

[guest11527]

1.Will printer.device be 24 bit capable?

The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?

At this time, I'm not sure whether I have an updated printer.device, but we most certainly do not have updated printer drivers, so this device is kind of pointless.

2.Is Reaction/ClassAct going to be included?

I do not know. We probably do not have the copyright, I need to check. Did I say that this is a bugfix release, and it is named 3.*1*.4, not 3.*14*? The GUI will be the gadtools GUI.

3.What about DefIcons?
4.AsyncWB?
5.RAWBInfo?
6.Will iconedit support glowicon editing? or will it be the same as 3.1?
7.Will ScreenMode prefs have the "Test" button function like in 3.9?
8.Will WBPattern have a layout option like in 3.9 where it lets you center, scale, tile or scale well the chosen pattern?
9.Mounter tool will be there?
10.A fixed Unarc?

No, no, no no... Please, these are to a major degree third party contributions,and we neither have sources, nor the copyright. To my best of my knowledge, things will continue to work, probably with the same bugs as before, but we cannot ship what we do not have.

E.g. for AsyncWB we already know that it has a problem with showing the drive info correctly on large devices, and without having sources available, it will continue to be broken.

To get updated versions of these programs, please contact their corresponding authors.

Once again: This is a bugfix release of 3.1 which is why it is named 3.1.4. We try to get as many of the existing components on board, but we can surely not simply ship third-party contributions to 3.9 along with it without permission of the corresponding authors.

[Romanujan]

The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?

Probably just about any current printer can be used with a PostScript driver - if you don't mind printing through a PC or RaspberryPi. There are some network printing utilities on Aminet (like http://aminet.net/package/comm/tcp/NetPrinter or http://aminet.net/package/comm/tcp/lpr-dev) - it should be possible to print via properly configured Linux machine.

So I wouldn't remove the printer support.

[kolla]

The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?

Print to network printer or to file, like I always did.

I have a Commodore MIPS 1200P line printer :laughing:

What plans are there regarding prefs apps in general? Just leave them as is? Especially I am curious about workbench prefs, since I get the impression that workbench.library v45 will be used.

[BozzerBigD]

Just use TurboPrint with the best supported printer you can find on eBay and don't let it break down! IrseeSoft will issue more updates one day if we wait long enough and maybe new DENEB USB boards will be given away with breakfast cereal :laugh1: