🚀 go-pugleaf

In article <525@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>*** FLAME ON ***
>
>> has anyone looked into the way that GEMDOS manages memory? 
>> ...
>> does anyone have any idea where GEMDOS keeps its list?
>
>PLEASE don't go around publishing internal addresses like this requests,
> ...
>The correct procedure in this kind of situation is to say, "Gee, Atari,
> ...
>I know we won't always have a fix for the problem by next week, but
>f**king around with GEMDOS' internal structures will cause more trouble
>than it's worth.
>
>*** FLAME OFF ***
>

Get Real Alan.

Although I agree that programs should not muck with undocumented internal
structures, real users have to make the trade off between something which
works now but breaks later and something that's broken now but will work
someday.  If the only workaround is to hack internal data structures, than
hack the data structures, and document what you did.  I the user will decide
which course I want to take.

***  FLAME ON  ***

Putting operating systems into ROM puts the onus of responsive bug fixing on
the vendor in a major way.  I suspect that Atari is giving very low priority
to fixing existing bugs in order to get new products out. This is not how you
meet the onus nor is it how you establish repeat customers.

There are currently many 'well known' bugs in the ST software and no sign of
a ROM upgrade.  I stand unimpressed, and unlikely to be a repeat customer
regardless of the wiziness of any new product offering.

***  FLAME OFF  ***