Denys writes:

>Back to PhotoShop.  PhotoShop...
>definitely was written for MacOS and the port to Windows was less than
>good.  This is also the reason Apple marketing misleads when they only
>refer to a very specific PhotoShop function to "prove" MacOS to be so much
>faster than Windows.  PhotoShop was optimized for MacOS and was fairly
>crippled when brought over to Windows.  It uses none of the multimedia
>capabilities of Windows and Intel.

This hasn't been true for, oh, about seven years. Photoshop was
completely rewritten for the Win32 platform (that is, Win95). The program
has a platform-neutral core, and uses plug-ins to access all of the Intel
processor's various attempts at multimedia extensions, as well as x86
workalikes' proprietary extensions such as AMD's 3DNow!.

Photoshop does assume a high level user sophistication; it's definitely
not for beginning or casual use. It can appear very unfriendly if you
don't know what you want to do.

>I can have all of them running simultaneously, run
>some games, be connected to the Internet, have a mail client running,
>develop in Visual Studio, be watching a DVD movie, and still have room for
>more stuff.

I'm not sure I want to use any of the software Denys is developing using
Visual Studio while he's watching a DVD movie and playing computer games.

>Since the late 1990s, there has been no
>reason, no software reason to buy a faster processor, because there is
>simply no software that demands higher performance than late 20th century
>computers.

Well, there ought to be.

Now that the users don't need all the cycles, developers should take
some. Use Java or other language systems that do real-time assumption
checking and have usable exception architectures. Write code that
monitors data structures for corruption. Make the OS start validating all
parameters to all system calls. Bring back Pascal's range declarations,
and put in some run-time checking this time. Force bounds checking on
array accesses. Use garbage collection rather than manual memory
allocation/deallocation.

Those cheap cycles can be used to make systems more robust and reliable.
Of course, then your programs won't benchmark very well against programs
that don't put in all that extra work. If your program scrolls from top
to bottom of a thousand-page document in 1.5 seconds and a competitor's
does it on 0.75 seconds, you bar is going to look pretty wimpy in the bar
chart. Maybe we need better benchmarks.

The MacOS has (or had) something called "the monkey" in its developer
kit. This was a little routine that ran at random times (based on
hardware interrupts) and queued random events for the system to process.
Ideally, your program could run for days with the monkey running. Maybe
something similar could be used in software reviews: a random-event
stress test with a nice bar chart of time-until-crash, "longer bars are
better."

-- Bruce


--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback AT optc.com                |     -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *