@Chris
OS4 developer and beta tester here. !!
This 3.12 version now works, no more DNS errors like the 3.11 release.

@rjd324Quote:

The question I have is why do you even have APPDIR mounted if it's so awful ?

Just move the icon from DEVS/Dosdrivers to STORAGE/DosDrivers and
the awfull thing goes away, and I don't have to listen to your pointless whining anymore.

@white

What you prefer to do is unimportant, but what you have shown in the example
is totally broken and cannot work with the appdir-handler ever.

I am the person that actually wrote the APPDIR handler, so I have to let you
know that adding a path is simply not optional, it will never work with any
APPDIR: device reference, regardless of whether you think it does, or want it to.

The point of APPDIR is to provide the APP with the DIR it is located in,
thereby removing the need to specify a fixed static path to where the program
may not even be anymore.

So when you do a DIR listing of APPDIR: specifying anything other than
the single names shown, ie; "APPDIR:xyz" will not match anything in the
list and you will get; "Unknown command".

Whether the program you are having trouble with, is using some other fallback
or global path or current directory, I do not know, but those APPDIR: paths
in your config are not going to help find anything.
Fixing those may just make all your problems disappear.

@white

I noticed that there is a problem with the config example.

All the lines referencing APPDIR: are not valid... eg:
sPlayer = "APPDIR:Amiga:Utilities/FFmpeg/Generic/ffplay"

Appdir: replaces the path and only the executable file needs to
be specified, so the example above should simply be:
sPlayer = "APPDIR:ffplay"

The only requirement for using APPDIR: references, is that the executable
file needs to have been run at least once, for it to remember where the
path was. Or just doing a "version" once on that file is enough also.

@elfpipe
The developer list will do, i've seen emails from you there recently.
Ask the list maintainer for beta list access.

@MichaelMerkel

Actually this discussion should be on the hyperion beta list.
What it's doing here, I have no idea.

@elfpipe

Those are the latest beta release versions, they work here fine.
Also, you didn't mention the elf.library version.
And, you don't need a serial hookup, just type "dumpdebugbuffer" in a shell.
You can also flush the debug buffer with the "Clear" argument.

@elfpipe
ram-handler.kmod 54.26 requires a reasonably recent V54 dos.library for
the best results, it also requires V54.1+ of Exec if you want to have access
to the ExtMem features.

As Joerg indicated, the dos.library mounts all the RTF_AFTERDOS modules,
so if RAM: is not mounting, it can only be that the module is not being loaded
from the kickstart directory (check your kicklayout), or, there is something
failing during initialisation of the ram-handler itself.

Luckily, all failure points in ram-handler will print a message to the serial port using
IExec->DebugPrintF() in the form of like; "[RAM] Cannot allocate blabla...."
that sort of format, so check your serial debug by typing "dumpdebugbuffer"
in a shell.

Also, if you set the exec debuglevel to 5 (or higher), you will always get a
message in the serial debug; "[RAM] Handler has started successfully....".

@elfpipe
ramlib.kmod has nothing to do with the ram disk, that's for loading disk
based libraries and devices for Exec.

ram-handler.kmod is the filesystem that handles the RAM: volume.

dos.library handles calls to all filesystems and handlers for application requests,
if there was anything wrong with it, you'd soon be in deep trouble everywhere,
it would be quite obvious, you probably wouldn't even be able to boot up.

elf.library is responsible for loading PPC elf format file (executables) into
memory and that is likely an issue if you are using beta releases,
it could be executable specific if one was put together differently.

Revert to the last "official" elf library and other components and do a cold boot
to see if your issues fo away.

If you provide version numbers, we may be able to help you further,
but I would most strongly suggest you don't play mix-n-match with early
releases of kickstart components, as they may be release dependant on
each other and some may not work at all.

@salass00

You are totally right, I havn't looked at that function for ages.
If the 'task' argument is the same as the calling task, it always does
a Reschedule(), so the priority change kludge is unnecessary.

What's wrong with just using the existing priority and adding or subtracting one to it for the first call.

ie;
BYTE oldpri = SetTaskPri(task,  (task->tc_Node.ln_Pri - 1) );
SetTaskPri(task,  oldpri);

By the way, APPDIR can also be dismounted on request.
In a shell, type; Dismount APPDIR:
It will dismount nicely.

@rjd324
Of course you can disable it simply by moving the APPDIR icon (via workbench)
from the DEVS/DOSDRIVERS drawer to STORAGE/DOSDRIVERS drawer
and then doing a reboot.

Don't edit the startup-sequence as you mentioned, just leave it as it was
so you can still get it auto-added to the path when required.

If you want to mount APPDIR afterwards, you can just double click on the
icon in STORAGE/DOSDRIVERS yourself, or in a shell, type; Mount APPDIR:
(Note the colon on the end).

@xenic
The problem is that "standards" are a constantly moving target.
We try to be consistent, but sometimes people just do what they want without
understanding the ramifications. Other times, things are imposed on us.

Back in V1x and V2x, people used 256 byte buffers for paths and 32 byte names,
and when someone made a filesystem that could handle larger names,
the old software broke.

Then later on in V3x, software started to max out the data structures that were
in use at the time, like a FIB (FileInfoBlock) and it could hold 107 byte names,
so software started making their name buffers 108 bytes and 256 bytes for paths,
that worked until someone decided to use ExAll().

Exall() could effectively provide limitless length names, but due to the usual
short-sightedness of the time, they left file sizes unexpandable past 4 gig.
Now people tended to limit buffers to 256 byte names and paths in their software.

Then I came along and messed up the party by creating a non-broken API and
allowing effectively limitless names, but kept them to 255 bytes, a length only
imposed on me by legacy BSTR (BCPL strings) interoperability when using older
filesystems, but paths are now effectively limitless too.

This is where, decades ago, I decided to finally add defines to the DOS includes
to try and limit the number of people "doing their own thing"(tm) by actually
having some sort of "official" definition to reference, hopefully to limit the
amount of pre-broken software being written. Those set names to 255 bytes and
paths to 1024, this worked quiet well until the target moved again.

The discrepancy between the relatively common 1K and the 4K lengths defined
in dos.h is because I have since added UTF-8 compatibility and new filesystems
can and do store UTF-8 encoded names, the problem with UTF-8 is that the number
of bytes that represent a "character" can be between 1 and 4 for some languages.

So, the old 1K is now bumped to 4K to handle a UTF-8 worst-case situation and
the growing availability of resources. So as long as you are not a Klingon,
it probably won't matter.

However, I would implore everyone to simply define all your buffers with the
DOS include values, as CLIB/NewLib just uses the DOS calls internally, and
the CLIB/NewLib legacy includes should just reference the DOS include values too.

Though this is of little help to the getcwd() bug..

Not quite 10 years yet, 3 months to go...
I still have the email in my "things to do when bored out of my mind" folder.

I havn't forgotten, I just hate messing around with GUI's so much that I would
rather have a colonscopy instead, if I had a choice.

* kas1e <kas..@...>
* Sat, 18 Aug 2012 20:50:54 +0400
* Subject [os4-beta] small suggestion about snoopy

Yours as well as Alexandre B and Phillipe F emails are still in there.
I will likely do something soon, now that you have reminded me that I have
been so tardy.

@samo79
Unfortunately that is not going to help.
Just compiling it on to start up on OS4 is not enough to make it work.

The basic problem is that this program only patches the 68K interface,
not the PPC interface, therefore it won't see or log any PPC calls.

The second issue is that this kind of "interface hugging" program can never
be kept up-to-date unless it's done by the developers that are creating the
new stuff, and deprecating the old, otherwise you would always be playing
a game of catch-up to keep it in sync.

Also, there are more than 100 new OS4 calls than were available in V40.
Some old calls are simply not called anymore, like the FIB examination functions,
the old calls are only there for legacy program support.

Adding the new PPC interface calls are not going to fix it completely either,
because the packet monitor won't work unless you add all the new packets to
the internal table.

That's not going to be easy either as there are 64 bit dospackets types
available for use by DOS packet handlers now.

Then there's the problem that any new filesystems don't even use DosPackets
anyway, so it still won't work unless it's just a plain packet handler like the
launch-handler or aux-handler etc... You won't see VP filesystem calls like
those from the new ram-handler or env-handler or any NGFS or FUSE volumes.

It could be fixed, but it's a lot of work for little or no gain as Snoopy already exists
and is up to date with the latest function calls. And it works for 68K calls too.

Firstly, you cannot use the new OS4 AnchorPath definition if you expect this to work on OS3 (68K),
Incase you are using the OS4 includes, you will need to declare the USE_OLD_ANCHORPATH definition
BEFORE including the OS4 dos/anchorpath.h include file, or anthing that may inadvertantly include it,
(if that is what you are using) to make absolutely sure you are using the old 68K definition that
OS3 DOS expects internally, otherwise you will crash your brains out.

So do this before including anything, (it won''t hurt for OS3);
#define USE_OLD_ANCHORPATH
#include dos/anchorpath.h

The line; "struct AnchorPath *myAnchor __attribute__ ((aligned));"
is pointless, the pointer alignment is unimportant, it's the memory it points to that must
be aligned to a 4 byte address, so lose the "__attribute__ ((aligned));"

OS4 is backwardly compatible to OS3 methods, OS3 is NOT forwardly compatible.
So to get the backward compatibility, you need to use "backward" methods everywhere.

The OS4 AnchorPath call in AllocDosObject() is not available on OS3 so it can't be called,
otherwise it will simply assume you are using the new structure definition, because you are
obviously running on OS4, so it may not work as intended and may do OS4 initialisations on
the OS4 structure it allocates that won't end up in the right places for OS3 structures.

So just use this OS3 method for both systems, and it will work;
myAnchor = AllocMem( sizeof(struct AnchorPath),MEMF_ANY|MEMF_CLEAR);

That way, you won't get OS4 confused into thinking you have the new OS4 structure definition
which automatically happens when you use OS4's AllocDosObject().

AFAIK, the malloc() call you are using does not appear to guarantee longword alignment either.
I never used it, so i'm not sure what the various clib releases do, so to be safe, i'd use the
exec AllocMem() and FreeMem() functions instead to guarantee longword alignment on both systems,
those work and do guarantee longword alignment.

Also, for your sanity, add some error checking and test your return codes, it is possible for
a memory allocation to fail you know.

@kas1e
struct AnchorPath myAnchor;

Is not an acceptable way to allocate space on the stack for an Anchor or FIB or anything that requires longword alignment,
regardless of whether it's 68K or anything else, you are still going to trash memory,
(except on OS4 where you get the warning and it does a workaround to prevent memory trashing.)

The reason here is that the Anchor has a FileInfoBlock (FIB) embedded inside it.

When old or new DOS calls an old style packet FileSystem with the fallback (or in the V40 68K case, the only) Examine() call,
it has to pass the FIB as a BCPL pointer;
It makes the BCPL pointer (BPTR) with the macros in dos.h MKBADDR() and converts it back with BADDR() to a CPTR (c-pointer) again.

The problem occurs due to the conversion of a non-longword C-address to a BPTR and back again to a CPTR.

EG:
CPTR 16: MKBADDR(16)=4 -> BPTR BADDR(4)=16 (OK)
CPTR 18: MKBADDR(18)=4 -> BPTR BADDR(4)=16 (FAIL)
CPTR 20: MKBADDR(20)=5 -> BPTR BADDR(5)=20 (OK)

As you can see, the middle one (non longword aligned) results in the filesystem writing the FIB data 2 bytes before the storage area,
thereby corrupting whatever is behind the storage area in memory, or on the stack in this case.

The D_S macro will work well enough to prevent this memory trashing problem.

As far as these MatchXXX functions go, they are still supported in OS4 and have been recently updated with macros in dos/anchorpath.h
to also handle 64 bit file sizes and all new extended features like multi-assignments and long names.

@rjd324
Also, make sure you have S:startup-sequence 53.12 as it changed in the way the appdir: path was added.
For example, it used to just be on the end of the "Path" line, now it is no longer there but instead has its own area just before the "LoadWB" line as;

Assign >nil: exists APPDIR:
if NOT WARN
Path ADD APPDIR:
endif

The reason it was done like this is to allow people that have the SDK installed to get the APPDIR: path always at the very end, and to also provide a test so that you don't get a pester-requester, if you happen to turn it off.

Enjoy...

@Raziel
It's more likely there is an Open() file which has not been closed.
If you have the OS4 SDK installed, there willl be an assignment of SDK:
in there is a C directory in which you will find a program called
"FileHandleScan", it takes one argument, the disk volume.

In a shell, try; FileHandleScan SYS:
for the boot volume, or replace SYS: with an actual volume name.

Or, no volume name to check every volume for all open files.

You can send the output to a log file; FileHandleScan >ram:openlist

If someone has left a filesystem lock on something, you're out of luck,
There was a 68K program called "Scout" that poked around with the
filesystems internal lock list, it may still work for this, but anything else will
likely crash badly, as the OS internals have changed a lot since then.