The correct version.library 53.18 is the only dependancy.
Are you sure ?

Type the following line in a shell and hit enter, and show what it says;
version file sys:libs/version.library

Also, do the same for sys:c/date and sys:prefs/time and show what it says.

1) "update.amigaos.net" needs to be enabled.

2) You must have a hyperion account to sign-in with your login details.

3) You must have already installed the libs:version.library 53.18+
with the last update 2 + hotfix available for download from
the hyperion website; hyperion-entertainment.com

Watch out with using %d with IDOS->Printf(), it doesn't work.

All VARARGS68K arguments are padded to 32 bit wide and means
you should use (long) %ld formatter instead, no matter what the argument width is.

Same goes for even one byte arguments, you would use %lc instead of %c

Basically what is happening is this....

A shell runs in its own process, when you start a program from that shell
process, the program uses the shells process to execute, the shell code
goes to sleep during the program execution, when the program ends,
the shell code resumes and is ready to take another command line.

So, when the program is being executed, it's apparently allocating a signal,
such as would happen if the program was to allocate a message port or
other such activity during its operation.

However, the program is exiting without freeing all the resources it allocated,
so the shell notices this and posts the message because as the shell process
is continually reused by subsequent programs, it will eventually run out of
signals to allocate (only 16 user signals available) and all sorts of bad juju
will happen if that occurs.

So, yes, the program being run is doing something it shouldn't when it exits
in an unexpected way.

@trixie

The support that I indicated uses the V54 utiliy.library UTF-8 <-> UCS4
Unicode conversion functions. The filesystems can't open disk based
libraries (like locale.library) for obvious reasons, so the required functions
for handling UTF-8 and Unicode were added to utility.library so to be
available early for other kickstart modules.

As far as DOS goes, it does not actually assume any encoding other than
checking for a few characters in the low 7 bit ascii (<127) which also map
to the same unicode values. DOS has to occasionally look for \n \r : /
(newline, carriage returns, colons and slashes) for its normal operation,
so it doesn't make assumptions about anything else anymore, so it can
transparently handle UTF-8 encodings now.

@ChrisH

Yes, 107 bytes was the limitation imposed by the FIB (FileInfoBlock) structure,
so, some older filesystems couldn't really support more. (79 for comments).

Since there is a second antique limitation, specifically caused by the use
of BCPL strings used mostly with the older DOSPackets, supporting a
single object name or comment string that is longer than 255 bytes is
problematic. DOS paths are not an issue of any length.

So, since I can't fix everything in one go, I decided that a minor limitation
of 255 bytes for an object would be ok to also maintain DOSPacket
compatibility and also bring us into a more modern era. (at least for now).

Therefore for OS4, and for the recent support of UTF-8 encodings,
the current defined recommended values to support are at the top of the
latest dos/dos.h include file. These are defined as;

MAX_DOS_FILENAME 255
MAX_DOS_COMMENT 255
MAX_DOS_SOFTLINK_TARGET 4000
MAX_DOS_PATH 4000

The last two were increased from 1K due to the recent support of UTF-8
encodings in DOS and some filesystems, as the worst case unicode
UTF-8 encoding requires 4 bytes in some Asian and other languages.

The latest NGFS filesystem, the RAM handler, the ENV handler and the
FUSE filesystems (where supported) are able to work with these values.

The dos.library has a queery function; IDOS->FileSystemAttr() that can
be called to queery individual filesystem limitations.

@Deniil

You are correct, the emulator specifically uses the ST_xxxx defined values
for the fib_DirEntryType, with it being left as zero only if it's none of the
known defined types, after that is done, fib_Obsolete = fib_DirEntryType
for old application compatibility.

The only way you can get any other value from fib_DirEntryType is if
the dospacket was actually supported by the handler and it set that value.

The DOS emulation is generally invoked when the original handler
responds with a failure code and the secondary error code
ERROR_ACTION_NOT_KNOWN, then the new calls are used and the
FIB content initialised as best as possible from the ExamineData,
because of the old FIB structure limitations, the name will be truncated at
107 bytes, comments truncated at 79 bytes and file sizes are clamped
at 0xFFFFFFFE (4GB) regardless of how much larger they are.

Conversely, if using the new DOS calls with an old handler, they won't
understand the new dospackets and will respond with the same error codes
as mentioned above. When that happens, the new DOS calls will fallback
to trying the old FIB style function calls internally, this implies the same
old limitations if this occurs.

So the moral to this story is that whenever possible, use the new DOS calls
and support the new dospackets (or vectorport calls for filesystems)
so that you won't be hit with a bunch of compatibility penalties.

Very little remaining in the OS still calls the old (FIB based) DOS functions
anymore, so supporting them is quite pointless if they can be upgraded
for the new ExamineData based functions instead.

APPDIR: is a virtual volume full of softlinks, it's virtual because it doesn't
physically exist on a real disk anywhere, just like RAM: and ENV: filesystems.

APPDIR: contains only softlinks that point to various locations on the media,
it means that any application that has been run at least once,
will have an APPDIR: entry created dynamically that allows you to find it
and other applications anywhere simply by refering to "APPDIR:foobar"
where "foobar" is the name of the program.

APPDIR: is NOT an assignment, even though it may initially appear to work
like one, an assignment is something else more limited and completely
different that allows you to create fixed references to somewhere else
on a disk. APPDIR: works across any number of disks and can reset
itself to new paths automatically, it does not require manual intervention
unlike assignments, which have to be manually created in your startup
-sequence or user-startup files.

The contents of the ENVARC:AppDir/ are just environmental variable files
that store the paths for the handler to build the APPDIR: virtual disk of softlinks.
The appdir-handler maintains those environmental variables automatically,
it also flushes entries that no longer exist or have invalid paths, once every two months, it flushes unused entries once a year.

APPDIR: has been built into dos.library and mounted on boot, since version
53.25 (2009-06-06).

@nbache

Good eyes.
Yes, the ReadArgs() template for OWB and Odyssey is a bit wonky
compared to other clients. It doesn't work if you use the URL= keyword,
the others do.

I've updated the default config files to have these...


ClientName="Odyssey" ClientPath="APPDIR:OdysseyLauncher2"
CMDFORMAT="*"http://%s*""

ClientName="IBROWSE" ClientPath="APPDIR:ibrowse"
CMDFORMAT="URL=*"http://%s*""

ClientName="AWEB" ClientPath="APPDIR:AWEB"
CMDFORMAT="URL=*"http://%s*""

ClientName="NETSURF" ClientPath="APPDIR:NETSURF"
CMDFORMAT="URL=*"http://%s*""

@328gts
The middle one, you are missing a double quote after the first asterisk.

@mritter0

Also, why would you want to run c:List ?

You're writing a real program, do it yourself, there's even example
code with IDOS->ExamineDir(), then you can format it and filter it
and do all that other neat stuff too.

A program that just runs other programs is just a "toolbar" basically.

I agree entirely, but I didn't write the prefs editor program.

Internally, the quotation semantics are required because the functions used
require them, both in the applications that use ReadArgs() to parse the
commandline parameters and the prefs editor and handler to parses them.

So, if you want to do an enhancement request for prefs/URL to remove the
outer quotes in the GUI, then I would have no problems simplifying what is
shown to the user. (Or other enhancements).

The keyword is incorrectly outside the format string itself.

You have; CMDFORMAT="*"http://www.%s*"" UseExistingTab

It must be part of the format string but outside the quoted URL part,
so the keyword must be between the two " " at the end, like this...

You need; CMDFORMAT= "*"http://www.%s*" UseExistingTab"
At least a single space between the format and the keyword is also required.

Same goes for the other protocols, the part fed to the browser must
be entirely in quotes, so the browser sees it as a single string regardless
of content, and subsequently so must be the entire string for ReadItem()
to get it out of the file, hence the asterisk infront of the inner quotes to
make ReadItem() happy.
The asterisk stops the following quote being acted upon by ReadItem().

It works well Chris, thanks.

I don't mind the name as is, however you could call it "OdysseyLauncherOS4"
if you want it more specific for your target audience.

Programs don't invoke C:URLOpen, they make direct calls to the URL:
device which is maintained by L:launch-handler.

C:URLOpen is just for use in shell scripts, or as a default tool for a
workbench project icon on HTML files, as a handy way to access URL:

See launch-handler documentation for more info.

Do you have any local structures defined in your program (without packing)
that are referenced outside of your own code,. (ie; by system functions) ?

The reason I mention this is because if you look at the OS4 includes,
you will notice that there are blocks like this in the include files;

#ifdef __GNUC__
#ifdef __PPC__
#pragma pack(2)
#endif
#elif defined(__VBCC__)
#pragma amiga-align
#endif

If you have mixed size members (or <32 bit sized members) in locally
defined structures, the alignment padding can differ and some members
of the structures may not be where you think they are, because of the
invisible alignment padding being added.

There are several things you can do to determine this, but what I would
really like to know is.... Why ?

If you know what it is that is "easily fixed" if you could detect the OS4
68K emulator, would you mind telling us, what it is that makes the
OS4 68K emulator somehow incompatible with your 68K app. ?

To me, it initially sounds like some "side effect" is being exploited,
that either doesn't exist anymore or is no longer supported on OS4,
or the OS4 68K emulator has some compatibility limitation that could
perhaps be fixed.

Trying to write apps that need to use work-arounds, doesn't sound like
a robust methodology to me.

There is a 60 second wait after the parent tries to exit, before posting the
requester, if one or more children have failed to exit.

The parent process is suspended until all children exit, and that can also
be forever.

All operating system components use the "BumpRev" command,
it should actually be in your distributed SDK installation, ( in sdk:c )
it creates the correct format for all types of version strings in the
(name)_rev.h file for C language. The file is simply included in the
source code and contains pretty well everything you will need for
version tags, resident version strings or anything else.

Here are the contents of the ram-handler_rev.h file for the ram-handler,
you simply use the definition you require in the source code file;

=======================================================
#define VERSION 54
#define REVISION 12
#define DATE "21.9.2015"
#define VERS "ram-handler 54.12"
#define VSTRING "ram-handler 54.12 (21.9.2015)\r\n"
#define VERSTAG "\0$VER: ram-handler 54.12 (21.9.2015)"
=======================================================