@salass00 Thanks. I now realise my very stupid mistake; my code was missing the "&" before the "vtag". Also seems to work for FTP Mount & RAM handlers.
I will now try to do same functionality without OS4-specific calls.
To get the seglist pointer on older AmigaOS you have to read it from proc->pr_SegList. Note that pr_SegList unlike what it's name implies is not just a pointer to a seglist.
Instead it's a BCPL pointer to a SegArray which looks something like:
I already have had Mason make a network drive and drawer 16x16 pngs for me. Before I went any further with more images and names I was just trying to get a feel for what people think it should be.
I started a new thread.
Workbench Explorer - A better way to browse drawers
To get the seglist pointer on older AmigaOS you have to read it from proc->pr_SegList. Note that pr_SegList unlike what it's name implies is not just a pointer to a seglist.
My implementation is a little different, since I based it upon your OS4 code.
Specifically, since you used GPSLF_RUN with GetProcSegList(), which the auto-docs say is obtained from process->pr_CurrentSeg, I used that to get the first seg list. If I fail to find $VER: in that, then I get the next seg list from it's header.
So I don't touch the pr_SegList array. I'm not sure what effect, if any, it might have.
Specifically, since you used GPSLF_RUN with GetProcSegList(), which the auto-docs say is obtained from process->pr_CurrentSeg, I used that to get the first seg list. If I fail to find $VER: in that, then I get the next seg list from it's header.
The pr_CurrentSeg field is only available in AmigaOS >= 4.0 as stated by comments in <dos/dosextens.h>.
@salass00 Thanks, now fixed. And this time actually compiled & tested for OS3, rather than just testing "OS3 code" on OS4!
BTW, I assumed that after getting the first seglist in the segarray, I could get the next seglist from the current seglist's header, rather than looking at the segarray again. Does that sound reasonable? (It seemed to work in my quick test anyway...)
To identify the segments that a particular process uses, you must use pr_SegList. pr_SegList is an array of longwords with its size in Seg_List[0]. Other elements are either zero or a BPTR to a SegList. CreateProc() and CreateNewProc() create this array with the first two elements of the array pointing to resident code and the third element, being the SegList, passed an argument. When a process terminates, FreeMem() is used to return the space for the pr_SegList.
As far I understand they are separate seglists and you want the third one (sa->SegLists[2]), but I could be wrong as the documentation is not very clear to me.
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.
@colinw Thanks for your code... but it doesn't work for me :( .
On AmigaOS4, it crashes at "cli->cli_Module;". It seems that "cli" is not a valid pointer (but not zero either). I don't know what happens on AmigaOS3, since it doesn't get called in my test cases.
On AmigaOS3, segarray[3] gives a seglist, but no $VER string. Where-as my old code used segarray[1], which results in a different seglist, and leads to a valid $VER string.
On AmigaOS4, segarray[3] does give a seglist (with a $VER string). While segarray[1] is NULL. So this bit does work.
@salass00 Quote:
As far I understand they are separate seglists and you want the third one (sa->SegLists[2]), but I could be wrong as the documentation is not very clear to me.
To avoid confusing anyone, the "third one" would be sa->SegLists[3], not sa->SegLists[2] as you wrote (since sa->SegLists[0] is the array size rather than a seglist BPTR).
@thomas Sorry for being thick, but what were you trying to demonstrate with your code?
Edited by ChrisH on 2016/5/23 21:19:15 Edited by ChrisH on 2016/5/23 21:23:26 Edited by ChrisH on 2016/5/23 23:08:34
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.
Edited by colinw on 2016/5/24 0:44:53 Edited by colinw on 2016/5/24 0:46:35
To avoid confusing anyone, the "third one" would be sa->SegLists[3], not sa->SegLists[2] as you wrote (since sa->SegLists[0] is the array size rather than a seglist BPTR).
No, it wouldn't because I defined the "array size" as a separate ULONG field in my SegArray structure.
Of course if you use a BPTR array rather than defining a structure like I did then the third seglist will be at array index 3.
HOWEVER, after a bit of further experimentation, I found that segarray[3] does find a $VER for the DF0: filesystem. Just not for the RAM handler, nor the virtual filingsystem provided by E-UAE.
OTOH, segarray[1] reliably finds a $VER for all three test cases. Don't ask me why!
@thomas I had more time to think about your code. I added your extra checks to my (previously crashing) code, and it no-longer crashes.
Where it USED to crash, it now reports "No task in port" for the SFS filing system. I don't understand what "(port->mp_Flags & PF_ACTION) == PA_SIGNAL" is doing, so perhaps you can explain why this check is needed for your code to work?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
