🚀 go-pugleaf

saj@chinet.chi.il.us (Stephen Jacobs) writes:
>In article <1252@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes:
>>actually, darek mihocka and myself have ... disassembled ...

>This is what serious developers do ... to
>check EXACTLY what TOS would do in a given situation (and any commented 
>source, no matter how 'ugly', beats a disassembly).

The fallacy here is that you think we want you to know EXACTLY what TOS
would do.  Publishing the source would make it impossible to change it,
because people would start relying on accidental side-effects of
operations.  When that happens, we can't change the code without
breaking those programs or maintaining those previously-accidental side
effects.  This is a maintenance nightmare.

Take this example: if you had source for the original Fsfirst call,
you'd have seen that the only error it can return is EFILNF, file not
found.  You might have used that knowledge in your code somehow.  In
TOS 1.4 and beyond, Fsfirst can return EPTHNF, *path* not found.  I
consider this an improvement. If your code was expecting either success
or EFILNF, and gets neither, how will it behave?

In an extreme case, you might have seen that there was a bug in Cconout
when stdout is redirected to a file; the HIGH byte of the argument is
written to the file, not the low byte, or something like that. This is
a bug, not a feature, but if you take advantage of it we can't ever fix
it without breaking your program.

Finally, take Malloc: you would know that Malloc uses OS POOL to keep
track of memory, and that two successive Malloc calls are likely to
result in two contiguous blocks of memory.  People have in fact taken
advantage of this, and the result is that we can't ever fix this
brain-damaged approach to memory management.  We're straitjacketed by
the tricks people pull; imagine how much worse it would be if the whole
OS were open to that kind of scrutiny!

You needn't tell me that UNIX source is available (if you pay for it).
UNIX is different, because (A) it was designed better, so people don't
have to resort to these tricks just to do ordinary things, and (B)
people on UNIX systems don't come from a tradition of 8-bit
game-machine programming, where the first question they ask is, "Where
can I POKE to change rez?"

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt