Re: Source files?

[rubywand@aol.com]

In article <58nmdm$1m9@news.ysu.edu>, be404@yfn.ysu.edu (Adalbert Goertz)
writes:

>
>What are source files? How to use them?
>I find a number listed at  ground etc.


     A source file for, say, a game program is the stuff typed-in by the
programmer to write the game. Usually, source code is text. It may be in
plain TEXT file form, an Appleworks wp file, etc.. Sometimes, the text is
saved in a TEXT file but is compressed or encoded in some special way.

     The idea is that a programmer can type-in program statements,
display, edit, polish, add REM style comments, etc. using an editor with
lots of nice features (like Find-Replace, Cut & Paste, ...).  If the
program is supposed to be in Pascal, the source text will contain Pascal
statements; if it is a C program, it will have C statements; if it is a
assembly language program, it will have assembly statements; etc. .

     To get the program to run, the source file must be processed by the
language system (e.g. ORCA/Pascal, Merlin 8/16+, ...).  Usually, the
source code is compiled and you get some kind of Object code file. GS
language systems can produce files which can be executed under the
language's Shell, launched from the System 6 Finder, started under ProDOS
8, BRUN under DOS 3.3, etc..

     After trying out a program, the programmer can make changes to the
program by editing the program's source. Since only the source code has
the program statements in easily readable form, one must, usually, have
the source in order to track down and fix program bugs and add new
features.

     To some extent, Assembly Language programs are an exception to the
'you need the source code' rule. There are utilities which can translate
raw machine code into assembly Text complete with named variables and
named address references. The resulting source code can be loaded-in and
edited by Assem Language systems like ORCA/M and Merlin.

     To use source code files discovered on sites like Ground, it helps to
have some idea of the language system the programmer used. The explanation
for this is that source files will include special directives and
references to code libraries which will, often, be specific to a
particular C, Pascal, etc.. Some source files may be readable only via the
Editor included in a certain language package.

     If the source is plain TEXT, you can view it and get some idea of
what's going on. A source file will, usually, have some comment indicating
that the program is an ORCA/C, etc. program. Even better, there may be a
READ.ME text file which supplies information about the source files in a
folder.

     Any program source file you can view has some value. At worst, you
will have a program, resource, or set of routines that may need some mods
to work with your favorite version of a language. At best, you will be
able to load it right into your ORCA/Pascal, etc. Editor, peruse it,
diddle it for the features you want, compile it, and convert it to the
form you like. 


     Usually, it turns out that the major barrier to getting something out
of source code is lack of thorough documentation. Programmers seldom
comment their work in great detail. Even those who make the effort will
end up omitting explanations of items which are "obvious". Making
something like, say, an in-development GS adventure work will take some
study and experimentation.

Rubywand