Kickstart 1.3 (v34) Execute without c:run

[matburton]

Hey all,

I'm sorry if I should have been able to Google any of this!

First-up is there a good place to find docs/examples specific to the libraries present in Kickstart 1.3?
I've been using amigadev.elowar.com but there's a lot of 2.0 only stuff in there which I'm getting caught-out by.

Next-up is there any alternative to Execute under 1.3/v34 which doesn't require c:run to be available or run to be resident?

If not is there any way to make run resident using the libraries in v34 before calling Execute if I have a copy which isn't under the c: assign?
(I'd rather not mess with the c: assignment)

There is CreateProc but that looks more low-level and I'm finding it hard to find examples
(e.g. I assume I'd need to use the message port to send the new process some start-up messages and then wait for it's exit code on the port?)

Any hints links appreciated

[Leffmann]

Originally Posted by matburton

First-up is there a good place to find docs/examples specific to the libraries present in Kickstart 1.3?
I've been using amigadev.elowar.com but there's a lot of 2.0 only stuff in there which I'm getting caught-out by.

Do you have access to the Amiga Developer CD 2.1? There's an AmigaOS 1.3 NDK in there with the 1.3 Autodocs. The later versions of autodocs will clearly say what stuff requires v36 etc. though.

Originally Posted by matburton

If not is there any way to make run resident using the libraries in v34 before calling Execute if I have a copy which isn't under the c: assign?

If you have Run available then you should have Resident as well, so just calling

resident run

would make it resident.

You can also do it programmatically by loading the program with

LoadSeg()

first, and then adding its segment pointer to the end of the list at

DOSBase->dl_Root->rn_Info->di_NetHand

.

[matburton]

Hey Leffmann,

Many thanks for the reply

I'll have a hunt for that CD then! The later docs do indeed describe what is and isn't available or different under v34 but it's just a bit time consuming having so much decoy material

Using

LoadSeg

sounds very promising!
I assume if I make it resident by adding it the the list you described I should either:

• remove it from the list if it's still there when my program exits and then call

  UnloadSeg

  ?
• not call

  UnloadSeg

  and just exit?

[Leffmann]

Originally Posted by Leffmann

You can also do it programmatically by loading the program with

LoadSeg()

first, and then adding its segment pointer to the end of the list at

DOSBase->dl_Root->rn_Info->di_NetHand

.

Originally Posted by matburton

Using

LoadSeg

sounds very promising!
I assume if I make it resident by adding it the the list you described I should either:
remove it from the list if it's still there when my program exits and then call

UnloadSeg

?
not call

UnloadSeg

and just exit?

Small mistake: you

LoadSeg()

the program first, then allocate and fill in a

struct Segment

and add that to the end of

di_NetHand

.

You should only edit the list between a

Forbid()-Permit()

pair, and I'm guessing that to correctly remove the program you would unlink it first, then

UnLoadseg()

, and then deallocate the

struct Segment

.

NDK 1.3 download: https://www.dropbox.com/s/5kougfenyw...ndk13.lha?dl=1

[matburton]

Perfect thanks Leffmann

Downloaded the link and those hints should be enough to get me going thanks for pointing out

Forbid

and

Permit

because as a n00b I probably wouldn't have thought about that!

[matburton]

I just got around to trying what Leffmann suggested and it works great

But if I later do

> resident run remove

then the system crashes.
Perhaps this is due to the way in which I've allocated the memory for the

di_NetHand 

entry?
(I don't know if that guess is correct, I'm at a loss)

I used

LoadSeg("run")

and didn't call

UnLoadSeg

at any point.

For the

di_NetHand

entry I used

AllocMem(16, 0)

and I've tried changing the options there to things like

MEMF_PUBLIC | MEMF_CHIP

out of desperation.

Any hints what might be wrong?

[Toni Wilen]

struct Segment needs to be allocated like AllocVec() does (+4 length, first long contains size of allocation, return pointer to allocation + 4).

All dos allocations use this method, it is Tripos internal allocation method.

[matburton]

Many thanks Toni that's solved it

Is it just me or are the 1.3 ROM libraries a bit inconsistent and confusing
(It's probably just me not reading the docs cover to cover)

[hooverphonique]

Originally Posted by matburton

If not is there any way to make run resident using the libraries in v34 before calling Execute if I have a copy which isn't under the c: assign?
(I'd rather not mess with the c: assignment)

Does Execute require Run to be in C:, or just somewhere in the path?

[matburton]

Hey hooverphonique,

So what I understand so far is that:

• In Kickstart 1.3 (and I guess 1.2)

  Execute

  needed run under

  c:run

  and doesn't look anywhere else (might be wrong on this front)
• In Kickstart 1.3.2 (by using

  SetPatch

  like on the Workbench 1.3.2 disk)

  Execute

  would also use the resident run (but run wasn't resident by default I think)
• In Kickstart 2+ I think that

  Execute

  didn't need run anymore? (Not sure on this one though)

If you run

SetPatch

yourself the console output does in fact mention that it's patching

Execute

to use resident run.

I think that

Execute

also doesn't inherit the current directory from the calling app in 1.3 (again might be wrong) which would mean that even if it looks someone else it's probably not going to look where you expect.

I have to admit I've found this all very confusing!
I think I'm half-way down a rabbit hole

[Leffmann]

One more thing I have noticed: when emulating AllocVec and allocating the

struct Segment

, the size must always be padded to a multiple of 4 bytes, or

resident remove

will trash the system. Probably because of all the BCPL legacy stuff in 1.3.

[matburton]

Thanks Leffmann,

I think I got lucky then since "run" as a BSTR ends-up being 4 bytes long

[hooverphonique]

Originally Posted by matburton

Thanks Leffmann,

I think I got lucky then since "run" as a BSTR ends-up being 4 bytes long

BCPL, not BSTR! The legacy OS (Tripos) AmigaDOS is based on, uses BCPL pointers, which means everything must align with 4.

Not sure if you were kidding, though

[Leffmann]

Oh the BSTR is a real thing and another BCPL legacy horror: a BCPL pointer to a BCPL-style string, which has a leading byte to indicate length rather than a trailing null-byte.

[matburton]

Yup I did actually mean BSTR might be the first thing I've got right on my own!

Also, just to be clear for anyone else reading this thread, there is no pointer to a BCPL string here. Instead the structure is of variable length and the string is the tail end of it!

So confusing

[hooverphonique]

Originally Posted by Leffmann

Oh the BSTR is a real thing and another BCPL legacy horror: a BCPL pointer to a BCPL-style string, which has a leading byte to indicate length rather than a trailing null-byte.

I do know about BSTRs (they are used by Microsoft COM), but I didn't know they were related to BCPL - I probably should've guessed though