Re: Randy's inherent hate of Apple IIs

[nathan@visi.com (Nathan Mates)]

In article <6a478o$b4m@gap.cco.caltech.edu>,
Todd P. Whitesel <toddpw@ugcs.caltech.edu> wrote:
>>   Read the MIME manpage sometime for laughs. "Uuencode had too many
>>variants, so we wanted to create a standard." Now every mailer and
>>every webpage has their own 'standard' of mime. I think the cure is
>>worse than the disease here. :)

>Hmm again. Might there be a "MIME Haters Handbook" somewhere?  Years
>later, however, MIME has become synonymous with email attachments
>but that's about it.

   I've seen 'format of the revision number' MIME headers from all
sorts of $#@*(# mailers (if there is a RFC, they sure can't be
bothered to read or adhere to it) Also used in all web servers *and*
clients in deciding how to send files to the other end. By default, it
sends files in ascii mode, and not every filetype is 'registered' with
it-- so folks have to tell their sysadmins *and* all users to add .SHK
to the mime configs if you want a snowball's chance in hell of getting
a file uncorrupted over the net. 

   First off, it's MUCH easier to assume binary xfers by default and
twiddle ascii text into the local cr/lf format than it is to
unscramble a binary file that got asciified. Then there's that whole
problem of getting everyone remotely associated with the download to
agree (by doing lotsa work) on how files of certain types are to be
sent. Some kind of DNS-style periodically updating database (with
expire times set to weeks or something to lower net traffic) woulda
saved more trouble.

>Sorry, I wasn't talking about the reverse-engineering part. I was talking
>about the central architecture of the games themselves, where you control
>all the source code and the people who wrote it are probably still working
>for you. I should have instead focused on the real advantage that most
>embedded systems have: when you've got all the source code, you can fix
>anything you need to on _your_ schedule, not someone else's.
 
   All the source code? Hah. Unless you're one of the top 5 developers
or a first party title, you're pretty much required (symbol dumps from
binary are requested at submission time) to use certain libraries from
some console game makers on the 'next generation' (32+ bit) systems.
[Or DirectX from MS, same deal. Sega Saturn was the most hackerish and
let you hit the hardware directly, but is now essentially dead for
reasons I can go into later.]

   We (maybe some of the huge companies do, can't say) don't get
source to those libraries. Even if you know of memory trashing in a
library or general bugs & flakiness and report it, no guarantee it'll
be fixed when you need to ship. I can agree with some of the reasoning
behind requiring the manufacturer's libs (which mostly deal with
compatability with future hardware, even though some internal revs of
the current hardware from company ABC don't work with older games
despite the libraries :), but we're still forced to have a few rounds
of undebuggable libraries. Even if the library 'works', the
documentation may be unclear (if I pass X,Y and a pointer to scratch
ram to this function, how much ram do I need to give? X*Y? A*X+Y? Etc)

Nathan Mates
--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places? -R.A. Heinlein