Assembly and Cracking From the Ground Up
An Introduction by Greythorne the Technomancer

Program Development
(In Any Language It Works the Same Way)



A Long Time Ago
In a Galaxy Somewhere Nearby

Someone invented the flowchart. This device was a nasty little tool that required college level classes to write, let alone understand, and resulted in nothing better than a spaghtti mish-mash when it was used to direct the way a program was to be written.

Also A Long Time Ago
In the Land of Interactive Fiction
(Which Might as Well be In Some Far Off Galaxy...)


Someone else realized that simple box diagrams showing your location in a fantasy text adventure allowed for quick and easy mapping - which would allow you to play the game even years later without really missing much of a beat, considering the simplicity of squares, a few lines, and a simple description per box)

More Recently
In the Land of Common Sense
(Which Tends Not To Be So Common...)

Some smart individual realized that computers didn't have to be quite so confusing. They are bad enough by themselves without some fool creating the world's worst roadmap to add to the frustration.

Hence Comes IPO
Along with Simple Box Diagrams
For Easier Program Planning and Development
(It's about damn time someone tried to make it less of a mess)



What Is IPO?

It Means: INPUT - PROCESS - OUTPUT



It is by far the simplest, most usable format for program planning ever developed. It took forever for people to get the idea that complexity does not necessarily translate to mean "better". (See any text on RISC computer architecture vs. the old CISC standard and you will get the idea if you haven't been exposed to it yet.)

How it works is kind of neat really, all you have to do now is start with a basic plan... All programs have some degree of Input (from user or device or program), Some amount of Processing of that input, and some type of Output, which could be displayed to the user or sent to a device suce as a printer or even back into the program for further contemplation.



Knowing this, we can develop all programs and parts of programs with some mutation of this in mind.

Here's more of a description of a typical program.

INPUT tends to include these steps:

1) Read the command line to see if any special arguments might be present
such as a filename or a command directive such as this example of doing a standard wide directory of all existing text files. The argument /w and the *.txt must be read and parsed by the program rather early on.

dir /w *.txt

2) Read data from a previously saved CONFIG file such as a joystick.cfg or somesuch

3) Ask the user to type something such as a name or place (anything really)

4) Read incoming data from a scanner, a video camera, or any other device present on the system (though for this lesson we will not be getting much into this since it is a bit advanced for a beginner's text)

PROCESSING involves whatever is done to alter or manipulate the INPUT that we have already received, such as sorting the data, applying math to it, or whatever. This is the bulk of the actual program.

OUTPUT is much like the INPUT phase in reverse. Here is where we save our current configuration, display any messages to the user, execute a print job, or send a data stream the the next program in the pipeline (which will read this program's output as it's own input, which is quite efficient by the way)

I have been programming in one language or another for over 15 years (I am not really all that old either), and lost track of program code, what I was doing, and direction to follow to get to a completed product countless times. Doing this type of program planning and placing little comments all over your code are the only way to guarantee that what you learn or write will be of any use at all to you in so much as even a week or a month down the road, let alone years later when you realize (and yes you will) that you really needed that sorting algorithm you wrote but can no longer use it or even understand it now. If it were not a problem, I would not even have written this section of the tutorial. With that, use this as a guideline (I will continue to use this through the programming part of the lesson regardless) for every program you write and every subroutine that you put within it.

You will be so happy you did.



+gthorne'97