Re: [dvd-discuss] Bunner wins DeCSS trade secret appeal

["John Zulauf" <johnzu(at)ia.nsc.com>]

Noah silva wrote:
> 
> Well my personal guieline for what constitutes a program is simple, I
> divide it into three areas:
> 
> a.) Data (Gif files, text files, wavs files, etc.)

With block based encoding schemes like MPEG this line gets a bit fuzzy. 
Much of the stream is "motion compensation" which is effectively a
series of block blit (or texture map) instruction -- move these pixels
from this area to that area.  In order to do this block blits
efficiently on a graphics accelerator you must interpret these commands
in to real graphics primitives -- but the closer the real graphics ops
match the motion compensation instruction stream the more efficient the
process.  This make (at least this intermediary step) look a lot more
like a program than data.  It certainly goes beyond the mindless -- set 
output level, repeat -- of a CD ROM stream.


> b.) Scripts (VBA, Javascript, shell scripts, DOS Batch files, etc.)
> c.) executable code (ELF executables, .EXE files, etc.)

Given software based processor emulators, and HW implementations of
virtual machines (BASIC, Java etc.) -- I don't see that b.) and c.) can
be cleanly delineated.  One processor's executable is another
processor's script -- to be interpreted by the emulator, code morpher or
whatever.

> 
> But still, if a file contains instructions that can be executed on the
> hardware (a general purpose processor) (wether or not they use an
> operating system), it is a "program" in a real sense.  

This seems an arbitrary distinction.  Are DSP's "general purpose
processor"'s?  Are programmable network switches?  Where does one draw
the line?

> If the
> "Program" requires a run-time system other than the operating system
> (meaning excel, paradox, lotus notes, etc.), it may not be a program.
> 
> In my definition, the C code isn't a program until it's compiled.

I think you'd be alone in that assertion.

> 
> This definition has kept my IT department off my back for a while.  (I
> have to explain why I need "real" programming languages instead us using
> excel, etc. for everything).

The answer doesn't have to do with ontology, but productivity.  The fact
is that different tools are better for different uses.  I've used Excel
for interesting and complex problems. When then underlying basis
function of the problem is the spreadsheet (essentially an acyclic
dependency graph) -- why reinvent that functionality?  I've written
report-extraction tools in Perl -- why reinvent the laziness of $_   and
=~  ?  I've written make systems in Gnu Make, and allong the way
graphics and animation tools in Fortran, C, and C++'s.  When a system is
not easily represented in an extant targeted language, like Excel or
Perl and the complexity and difficulty exceed the performance and
maintainability thresholds of DOS or bash -- then it's time for a
compiled language.

But they are ALL programs.

.002 in respectful disagreement