Re: [cc65] Calling another program: exec() ?

From: Oliver Schmidt <>
Date: 2011-01-24 18:13:17

First of all thanks for all the valuable answers :-)

>> My question is if you think it is appropriate to call that function
>> execl() / execv() or if a proprietary name would be preferable.

> If we can find a behaviour that is portable across all (or at least several)
> major 6502 platforms, I would call it "exec", otherwise I would prefer to call
> it platform_exec or similar.

I see. Gathering the input so far there seems to be a momentum for a
cross-cc65-target but yet cc65-specific function. As the name exec()
isn't occupied yet we should go for that.

Is there a policy in which header file(s) such a declaration would
have to go? Other function available one some (meaning 'more than one
but not all') targets are sometimes replicated in the target header
files and sometimes in central header files but "just" not defined on
all targets - or did I miss something?

> Since for the C64 the BASIC ROM is switched off, and the memory in
> question is occupied by the running program, an implementation would have to
> copy a small loader stub somewhere.

Same on the Apple II.

> Problem is that there is no safe
> "somewhere". Maybe someone has a good idea but all I can think of may collide
> with some sort of other program, customized kernal ROMs or whatever.

Same on the Apple II. There's no bulletproof solution - just educated
guesses what will work on many cases.

>> Does this really make sense? But at least the cc65 desctructors need
>> to be called. Otherwise there would be i.e. dengling interrupt vectors
>> pointing to nowhere - wouldn't they?

> The best idea would probably be to actually terminate the running program and
> run a new one instead, eventually passing some arguments as if they were
> passed on the "command line". This is the easiest and cleanest solution.

That's exactly how I see it too.

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Jan 24 18:13:55 2011

This archive was generated by hypermail 2.1.8 : 2011-01-24 18:13:58 CET