In a message dated 12/01/05 12:45:10 GMT Standard Time, [EMAIL PROTECTED] writes:
> > (...) > >Only problem here is that if an existing program is called with the home > >dir on the stack - the program will not tidy up the stack correctly since > >it does not know to remove the extra bytes.... (I think though could be > >wrong here) > I think my recent programs do clear anything on the stack since I set the bootom to (A6,A5). > Well the first thing the prog would have to do would be to precess the > string > anyway, and copy it somewhere safe... > > >However, how would a program aware that the home dir might be higher up > >the stack cope with this - for example, some programs MAY require an empty > > >string to be passed as the command string. Guess if there is a special > >identifier word before the home dir string, this would overcome this > >problem. > > Simple: > > word length of command string (may be 0 if no command string) > command string > word length of home dir (may be 0 if no home dir) > Anything new on the stack woould have to be after the channel IDs and the proper parameter string. It would be in the space between (A7) + C + P and (A6,A5), where C is the space taken by channels ( word at A7 * 4 + 2) and P is the space taken by the parameter string ( word at (A7 + P) * 1 + 2 + 1 if the position is odd). Any new item can thus easily (?) be detected by new programs and will almost certainly be ignored by old ones. > > > But really, putting this after the command string is a nono unless you solve > > the problem for compiled progs! > > Wolfgang > _______________________________________________ I would imagine that OPTION_CMD$ in Turbo TK code does just take the parameter string and not any extra bytes following it on the stack and so existing (and new) Turbo compiled programs should still work. George _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
