Hello!

I would like to continue using programs that utilize arp.library .-) That works for programs that only use the FileRequester. However, unfortunately programs using ArpExit "hang". That function builds a code fragment on the stack to close DOS and from there(!) it calls DOS/Exit. The code fragment on the stack *is* executed as I could verify with my old monam2. But it seems Dos/Exit doesn't terminate the program. Should that work or is that function not implemented?

The thing is that dos/Exit() is not implemented at all. It is documented to be used by BCPL only (and BCPL is not supported in MorphOS).

Here's a relevant part of the dos autodoc:
Quote:

However, since it apparently seems to have some other uses, I'll look into implementing this for future MorphOS release. If you really MUST have this for 1.4.5 too, I could hack some small patch that adds it. Stay tuned.

Quote:
Download it from: exitpatch.lha

Hmm.. And some people talk about MorphOS not been developed

Quote:
That does explain the seen behaviour. Funny that ARP (the AmigaDOS Replacement Project) used a BCPL function ;-)

Quote:
I didn't know that passage but then I never looked it up anyway.

Quote:
As mentioned earlier arp.library/ArpExit uses it. I don't know if that qualifies as "other uses".

Quote:
I am impressed! I didn't expect such a fast response. IMHO your patch looks fine. I have to admit that I thought about similiar code myself. Maybe its better to replace the Exit() call within arp.library with your patch code. That should work as well on all systems. What do you think? Apperently nobody missed Dos/Exit function so far.

And one technical question about your patch: Does clearing cli_Module works as well? Then run won't be needed.

Quote:
Would work assuming you can somehow fit the code in there.

Quote:
It does work. I was in a hurry so I wouldn't bother with such details.

Updated the program a bit:

Quote:

Download it from: exitpatch.lha

[ Edited by Piru on 2006/3/31 20:09 ]

Quote:
I can since years ago I "rewrote" arp.library to make it V37+ and 68060 compatible. Thus I can easily correct ArpExit. I should have done that in the first place since the original code always looked questionable.

Quote:
Thanks for confirming that. Meanwhile I already tried It myself. I took the liberty to modify your program myself. It was the first time I "wrote" and build a MOS program. I always wanted to know how to write a MOS program without startupcode. I am really surprised how easy it is. Its very similiar to AmigaOS/68k.

Quote:
Sorry to ask the obvious (I am a MorphOS newbie :): what is the difference between __amigappc__ and __abox__? When I modified exitpatch 1.0 I added both symbols to be on the safe side ;-)

Quote:

__amigappc__ used to be the old identifier, which at some point in time (shortly after 0.4 iirc?) was deprecated in favor of __abox__, at the same time other stuff also changed names, like libamiga/stubs.a etc, this was mostly a political statement based on certain turmoil that was quite prominent at the time (and still somewhat even today)...

..in short; today you should just use __abox__...


- CISC

@ munk

Are you Gunther Nikl, the author of at least 20 fine utilities stored in Aminet?

Welcome to our community, you will see that it is very friendly and full of people ready to (remember and) appreciate a good programmer like you.

And you are even the unknown author of Aminet:util/libs/arp40_2.lha [arp.library 40.2 (7-Feb-1993)]?

Wow! That was essential for me at the time for A4000 compatibility and because some ARP commands were not yet available as DOS commands at the time.

Can you make available a copy of the emended arp.library if you really create it? There is still use for it within WinUAE...

[ Edited by DoctorMorbius_FP on 2006/4/3 18:00 ]

Quote:
Yes, thats me but I never counted my AmiNet uploads ;-)

Quote:
No, that one isn't from me. At that time I used a 68030 and there the original arp.library worked fine. When I upgraded to an 68060 arp.library didn't work any more, thus I fixed it myself. Later I learned that this could have been fixed by the 68060.libray and AFAICT the C= 68040.library has a fix for this arp.library problem.

Quote:
Seems I should upload it to AmiNet but I don't know when that will be.

Quote:
That explains why old GCC diffs (like the ones available on Martin Bloms site) reference libamiga.a and libamigastubs.a. I just noticed that VBCC/MOS does have a libamiga.a .-)

Quote:
Thanks for these valuable information. It looks like you should switch mpega_libmad to use __abox__ then ;-)

Quote:

Heh, indeed... ;)

..a minor heads-up is worth noting here though, be careful when stripping binaries, some old versions of strip (like the old 68k hosted one, or maybe even Blom's?) might not preserve __abox__, additionally the ld in the current SDK doesn't either if you strip during linking, so don't do that. ;)


- CISC

[ Edited by CISC on 2006/4/4 9:50 ]

Quote:
Thanks for the heads-up. Yes, the MorphOS binutils patches from Martin Bloms site don't preserve __abox__. Most available binaries are probably based on the patches from his site. I already noticed these problems and fixed them for my builds, thus using -s when linking does work here :-)

I noticed another binutils bug: the morphos ld sorts flavours _before_ arguments are examined. I fixed that but now I have problems with -noixemul and -mbaserel32 (the wrong libc.a is used). Ah I see it - its a clash between multilib and flavours. It seems removing "-fl libb[32]" from LINK_SPEC does fix that. I wonder if MOS GCC shouldn't drop MULTILIB and use the m68k-amigaos way of multilib-ing. However, that works only for libgcc.a. Thus its probably not an option...

As long as you get the order right it's not really a problem, however you should generally avoid using ld directly when linking...

..anyway, we're getting awfully off-topic here now. ;)


- CISC

Quote:
I always use the proper frontends unless I am hacking the tools :)

Quote:
Right. Whats a better place for such topics?

@ munk

Thanks for your kind reply.

(Try the Aminet full text search engine by Chris Hodges, putting your name in it. You will see all your contributions as well as all the archives where you are mentioned. It's a long list.)

(I used Xoper very much...)

Quote:

Just a new thread would do, though usually MDC is the preferred place...


- CISC

Quote:
It list everything where my name is in, thus its a bit misleading.

Quote:
It works on MorphOS and currently I am using it quite frequently :)

Quote:
I am not (yet) subscribed there, this I would prefer this forum.