@ChrisH
Seglist sizes dont HAVE to be multiples of four, but they were and are
still maintained that way in OS4, I also made it so DOS won't actually
recognise them as valid unless they are.

I had to deal with loading hunk files about 14 years ago.
If I remember correctly, the hunk size is always stored in longwords,
but it's also a bit screwy in that the longword size only occupied the
low bits 0-29 and they used the upper 2 bits for the memory type flags.

So, when you read in the file to get the hunk size and memory type,
you had to basically do this;
ULONG bytesize = (longwordsize << 2);
ULONG memflags = (longwordsize >> 29);
And that ladies and gentlemen is why segments are also longword multiples.

As I said, I have maintained this quirk in OS4 seglist segments too,
see AllocSegList() autodoc.

@ChrisH

I'm not going to argue online with you anymore about what is in seglist[3].
If it's not working for you, you ARE doing something wrong.

seglist[1] is the dos klib seglist, it has nothing to do with application
code, so please stop trying to grasp at straws.

Check your seglist scanner parameters, some seglists can have
a fake length, do a signed check for multiple of 4 and not negative,
also check for nonsence segment lengths.

Also, do propper error checks, they are not optional, don't assume processes,
it could be a task and you would end up reading random memory.


I also have the actual original 68K source code for V40 DOS,
so i'm not making this stuff up.
If even that is not enough to convince you that I do know what I am
talking about, here is the source code that launches new processes,
see it for yourself.

From CreateProc() :

/* CNP_ActiveCode sets up a0/d0 and calls seglist in segarray[3] */
if (!AddTask(&(np->pr_Task),(void *) CNP_ActiveCode, (void *)
deactcode))
{


And here's CNP_ActiveCode in 68K ASM, read the comments at the
end of the lines, if you can't read 68K assembly code;

_CNP_ActiveCode:
MOVE.L SysBase,A6
MOVE.L ThisTask(A6),A6
MOVE.L pr_Arguments(A6),A0 ; argument parameter (NULL if no args)
MOVE.L A0,d0 ; registers other than a0/d0 are free
BEQ.S noargs ; if a0 is NULL d0 is 0

;-- warning! this uses 2x stack!!!!
move.l a0,d3 ; save in d3
BSR @strlen ; (a0) - length returned in d0
move.l d0,d4 ; length
; d3 is already pr_Arguments
move.l pr_StackSize(A6),D2 ; in bytes
move.l pr_SegList(A6),D1 ; segarray (BPTR)
asl.l #2,d1 ;BADDR
move.l d1,a0
move.l 3*4(a0),d1 ; Segarray[3], the seglist we should use
bra _RunCommand ; returns to DEACT
[...]

@ChrisH

Check your code, something is wrong with it.

The dosextens file shows the cli structure.
-> BPTR cli_Module; /* SegList of currently loaded command */
it is never anything else.

Make sure you follow the example and check the pointers, it will work
for OS3 and earlier releases, I actually rewrote the DOS library for
OS4, so I know how it works and I know what OS3 compatibility is there.

segarray[3] is the only one you can use that (currently) stays the same in
OS4 and OS3, the others are for things like the shell-segments (2),
one BCLP startup and one C startup, as well as the ram-handler
and con-handler segment and the default filesystem segment,
so don't mess around in there, some of them have disappeared for OS4,
like the ram-handler segment, as the startup methodology has changed
and the default filesystem (FFS) may not even be loaded now, also,
I have reused some old slots for other purposes, like segarray[2],
this was something completely different in OS3, so heed the warning.

For OS4, use the API functions exclusively for structure member access,
segarray[3] may even go away in later releases.

The segarray in the process structure has only one field that is
of interest to you, that being segarray[3]. The others are for
other external resident modules that DOS uses, (or zero).

segarray[3] is the seglist for the process code.
However, if that process is a shell process, that seglist would of
course be for the shell handler itself when the new process was created,
and not any current command, so, to prevent the resident shell handler
being unloaded, the shell startup routine always clears segarray[3].

Therefore, to get the seglist for a program currently running in a
shell process, you need to look in the cli structure field cli_Module.

This code should also work all the way back to OS2 or even before.

===================================================

BPTR get_current_seglist( struct Process *proc )
{
BPTR result = 0;

#ifdef __amigaos4__
result = IDOS->GetProcSegList(proc,GPSLF_RUN);
#else
if( proc->pr_Cli )
{
struct CommandLineInterface *cli = BADDR(proc->pr_Cli);
result = cli->cli_Module;
}
else
{
BPTR *segarray = BADDR(proc->pr_SegArray);
result = segarray[3];
}
#endif

return(result);
}

===================================================

Disclaimer: I wrote this without checking for typos.

@ChrisH
Well, the name is pretty-well self-explanatory.

But it's probably not of much use for the casual programmer,
it's mainly for diagnostic/monitor tools and for the USB stack to
determine how many open files are still open on a given volume,
so it doesn't try to pull the rug out from underneath the filesystem
when someone wants to "safely" remove a USB stick or such like.

Previously there was no system-friendly way to determine how
many files were still open on any given volume, now it's easy.

Even Greater:

http://blog.hyperion-entertainment.biz/?p=1001

@zzd10h

You'll find out soon, very soon....

Well, you might as well start doing it now, as you come across all the places where the limitations are.

Actually you need to suppoprt filenames up to 255 bytes.
And DOS paths up to 1000 bytes long.

Please read the first chapter of the latest dos.doc autodoc.

Don't use strncpy(), it doesn't guarantee nul-termination,
you want to use strlcpy() instead.

The best you can do to find out which process called Open(), the filehandle will indicate this in the filehandle->fh_OpenerPID, use this in conjunction with the IDOS->ProcessScan() function.

However, as Chris has mentioned above, the fh_OpenerPID is the openers pid, nothing more, and if that filehandle is passed into (for example) CreateNewProcess() or System() and a new process is using it, you won't know.

So, what exactly are you trying to do, and why do you need this information, there may be a better way to do it.

Quote:

Well, in that case, if you can't remove anything because it might cause problems, then I would respectfully suggest that you absolutely must -not- add something wrong that would make the situation worse.

As I said, using DosControl() in this manner is completely wrong !
Please read the autodoc again. It's the primary interface for the DOS prefs tool, not for applications to mess with flippantly.

If you want to leave the old code alone so as not to cause porting problems, then all you needed to do is this;

#ifndef __amigaos4__
DOSBase->dl_Root->rn_Flags|=RNF_WILDSTAR;
#endif

Setting this flag does nothing under OS4 anyway, but there is no struct DOSBase definition, so you need the 'ifndef' .

Doesn't anybody read the autodocs anymore.. ?

DosControl -- Set or obtain global DOS PREFS values. (V50)

This function provides a single method for reading or
setting various features available in the V50+ dos.library.

This is the primary interface for the DOS PREFS tools, which uses this
function to implement the users prefered default settings.
It is therefore recommended that applications use this function only
to read what the user has chosen and not to flippantly override them.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you must change any values, read the previous setting and restore
it after you have finished, you should never permanently change the
users prefered settings without expressly having permission to do so.

Please just remove this stuff (below) and let the user decide
what they want, with the DOS prefs tool.

#ifdef __amigaos4__
    DosControlTags(DC_WildStarW, TRUE, TAG_END);
#else    
    DOSBase->dl_Root->rn_Flags|=RNF_WILDSTAR;
#endif    

The dvp_Lock is the directory relative reference lock,
if you are not using a relative access, such as a VOLUME:
or DEVICE: root reference, it will be NULL.

You need to use an Assign, PROGDIR: CURRDIR: or APPDIR:
reference for dvp_Lock to be non-zero.

3.5 grand for some bells and tinsel, jeez, what a complete
waste of resources.

That money would be far better going towards something
usefull like someone to port CUPS or some other printing
system to bring us into the modern era.

Even a couple of new filesystem ports, just something
that is not so utterly pointless.

The stack cookie usage documentation can be found in
the IDOS->FindSegmentStackSize() autodoc.

The cookie for 25K must be like this;
USED CONST TEXT cookie[] = "$STACK:25000";

Steven Solie's "Ranger" tool has the info in the
[DOS]->[Process]->Stack line.

It is quite possible for me to add a command parser for the
mailto protocol in launch-handler, with separate %tokens
for the different components, so the individual programs
differences can be catered for, but at the time there was simply no
call for anything more elaborate than starting the client
and passing the email address.

Also, as "broadblues" indicated, there is no reason you
can't simply execute a Shell or Arexx script from the URL prefs,
I already use a shell script to start the new beta version
of TimberWolf, as it must be started from a script ATM.

It's a tad off topic, but here's what I use for that...

Copy between the ==== lines below and paste it into
notepad, save the file as S:TW and set the "+s" bit by
typing this in a shell; protect S:TW +s


;======================================
.bra {
.ket }
.key "OPTIONS/F"
;$VER: Start Timberwolf script 53.1 (20.02.2012)

stack 50000
if exists ${appdir/timberwolf-bin}/timberwolf
cd ${appdir/timberwolf-bin}
run Execute >nil: <nil: *>nil: timberwolf {OPTIONS}
else
RequestChoice ERROR "Can't find Timberwolf Dir.*NPlease start it from icon at least once." GADGETS=OK
endif
;======================================


Then create a new entry for the required protocols
(www,http,https) in the URL prefs and put "S:TW"
(without the quotes) in the client path field.
Give it the name TimberWolf in the client name field,
and the appropriate commandline format like the others.

Enjoy...

At the moment URLOpen simply passes your command line to
the client as is.

The individual client must accept the keywords you use
as a command template and the commands must be formatted
the same way you would use it as a shell command that
calls ReadArgs() to get the arguments parsed.

If the client does not respond when invoking it from a
shell, then urlopen can't use it.

Try typing; Appdir:SimpleMail ?
to see what option it supports, I don't have it here to
see, however, I did a quick test with YAM with the
following line works;

urlopen mailto=info@example.com subject="The subject" attach=temp:domains.html

PS:
YAM doesn't appear to have a "Body" keyword, but it does
have a "Letter" keyword, however it doesn't appear to work
on the version of YAM I have here for some reason.

Unfortunately, that book is considerably out of date
with the current evolution of AmigaDOS, it is of very
limited value, maybe if you want to stay with OS1,2,3 68K
versions it may have enough info to be somewhat usefull.

Things move on and with the next SDK you will be quite
surprised how much new and detailed information is now
included for AmigaDOS, and how much of the "mystery"
element is now resolved.

I have spent a considerable amount of time addressing
the lack of programmer documentation and cleaning up the
huge amount of "mystery" and "magic" required to understand
the basic workings of the dos.library.

I have also addressed much of the extensive complexity of writing
filesystems for the AmigaOS too, details will be released
in the next public SDK.

The shell is a handler, DOS starts up a process for it
and sends it a startup packet, just like any other
handler, and CON: is also a handler that starts up when
you try to do; IDOS->Open("CON:///"...).

Opening "CONSOLE:" simply means the IDOS->Open() function
will fetch the CON: handler port from pr_ConsolePort
of that shell process and send it another open request.

I'll tweak the autodoc...