[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on ProDOS SmartPort drive remapping
"mdj" <mdj.mdj@gmail.com> wrote in message
510c80ca-4a35-4c6c-9ff9-4398e93c8958@s8g2000prg.googlegroups.com">news:510c80ca-4a35-4c6c-9ff9-4398e93c8958@s8g2000prg.googlegroups.com...
> mdj@bob:~$ /bin/true --version
> true (GNU coreutils) 5.97
>
> Careful what you wish for - if a program that does *nothing* successfully
> can reach version 5.97, who knows how far AlphaPrint can go ...
I'm guessing that the 5.97 version number is related as much to the GNU
coreutils as anything, but it reminds me of a funny story from my IBM
mainframe days.
IBM had a program called IEFBR14, which was basically a NO-OP program useful
for reasons which are too esoteric to discuss here.
The name pretty much described the program. It consisted of one line of
assembler which generated two bytes of executable code:
BR R14
This basically meant "return to caller", since by convention the return
address on entry is stored in register 14.
This incredibly "complex" program still managed to get a bug report raised
(and accepted) against it!
The problem was that also by convention a program's return code should be
loaded into register 15, but in IEFBR14 it still contained the value on
entry, which just happens to be the program's entry point address! So the
do-nothing program was always reported as ending with an non-zero error if
anything checked the return code! (The fix doubled the size of the program
to four bytes! Register 15 was cleared before returning.)
--
Peter Watson
-- Write to MS-DOS disks on the Apple IIgs?
-- Impossible! ;-)