Just as a frame of reference, you should know that we're writing this editor's note about six days after the presidential election. We had planned to run a fawning salute to the new commander in chief, hoping that he actually reads developer magazines and will grace us with some unspecified favors. However, a week later we have no idea what the outcome will be.
      So you probably think that we're setting you up for some really stale jokes, but nothing could be farther from the truth! We're actually setting you up to expect a really poor editor's note effort this month, so that any glimmer of info you get will be appreciated. And speaking of appreciating the small things, we're introducing two new features this month.
      The first is a yearly index. 2000 was MSDN Magazine's best year ever! (And our first year ever, if you want to get technical.) We've received many requests for an annual index of our articles. After page 128 of this issue, you'll find the MSDN Magazine Index for the year 2000. You'll be able to detach it from the magazine and look up articles and read their abstracts.
      We're also introducing a second change this month, designed to make our magazine easier to read and use. Our articles now have running page tags (called "running feet" in the publishing biz) with each piece. We realize that if you open up the magazine somewhere in the middle, it's often hard to figure out where you are. This small stylistic change will help you know at a glance exactly which article you've landed in.
      Both of these changes are based on consistent feedback from readers like you. Of course, we didn't speak to all our readers, but we have been talking to small groups for the past year. If you have a question or comment for us, or even a suggestion you'd like to see implemented, please write us at mmeditor@microsoft.com. As we've seenâ€"both in the magazine business and in a presidential electionâ€"a small group can influence big changes. By the wayâ€"if you do want your vote to count with us, make sure to punch out at least two corners of your e-mail, and vote for only one idea at a time. Thanks!
      Okay, you were right after all. We did go for the stale jokes.
      For the past two months, we've brought you some fascinating anecdotes about the early days of computing, sent in by readers. We just got the newest pre-beta build of Visual Studio .NET, and it once again set us to thinking about the war stories we've received since we first asked about your experiences. So one more time, by popular demand, here are a few more old-timer stories.

      In September 1958, I took my first programming course at the University of British Columbia. The computer used was manufactured by the Alwac Corporation, Hawthorne, CA. It was called the ALWAC III-E. During this course, I had experiences similar to David Shillito's work with a Flexowriter, which was used as both input to, and output from, the Alwac III-E. Also, Julius Ivanyi's experiences with an early rotating drum memory device brings back "fond" memories to me. A brief description of the ALWAC III-E's configuration follows.
      Memory Unit: The magnetic drum had 256 channels (tracks) of general storage, plus four channels of working storage, plus four arithmetic registers (A, B, D, and E). Each channel had its own Read and separate Write head, so there was no physical movement of heads. Each general and working storage channel stored 32 words. Each register consisted of one word. Each word consisted of 34 binary bits, segmented as an overflow bit, a sign bit, and 32 bits for alphanumeric and instruction usage.


      Logic Unit: Performed all operations on data between the drum storage, registers, and input-output with the Flexowriter.
      Flexowriter: Used to type programming instructions and data to punched paper tape for input to the computer, either directly from the Flexowriter or a High-Speed Punched Tape Console.


      Control Panel: Contained control switches (toggle and rotary), and banks of lights that displayed memory addresses and instruction codes. To view the content of a register or storage word, console switches were set, and the binary bits displayed on an oscilloscope.
      Oscilloscope: The contents of a word was shown as a ragged wave form, with 1-bits having higher peaks than 0-bits.
      Other: Magnetic tape and punched card devices were also available for the ALWAC III-E, but I don't remember whether the University had them or not.


      High-speed Punched Paper Tape Console: Paper tape read at 150 characters per second and punched at 50 characters per second.


      As I recall, the computer was fairly reliable, with infrequent need for attention to replace a vacuum tube, or other part. However, it was very noisy, due mainly to the constant clatter of magnetic switching relays, directing the movement of data between the general and working storage areas of the drum. Paper tape reading and punching also contributed to the noise level.
      Now, the real interesting and challenging part of working with the ALWAC III-E. The computer I used had no symbolic programming language such as an assembler, or higher level business or scientific method of coding. Although an "Assembly Program 1" became available soon after my course had finished, I never had the opportunity to use it. All coding was done at virtually the binary bit level. I say "virtually" because by a clever method of combining four binary bits together, coding was actually done using hexadecimal notation. To my knowledge, the use of hexadecimal notation did not again appear until the advent of the IBM 360 in 1964.


      It was the programmer's responsibility to plan for and keep track of exactly where every piece of data was stored on the drum. Each instruction code was one hexadecimal digit, and two, three, or four instructions could be packed in one word. The number of instructions in any given word depended on whether or not the instructions required a drum address.


      Coding was done on a form that was laid out with eight rows of four storage words each, for a total of 32 words per form. Each row consisted of two parts. The upper part was used to code the hexadecimal instructions, addresses, and data. The lower part was used to record, as best as possible, the intent of the hexadecimal code above. This layout was no coincidence, since each channel on the drum contained 32 words of storage. While a program might occupy, say, 37 channels of general drum storage, only four of those channels could be loaded into the four working channels, and their contents (instructions and data) freely accessed. You can imagine that a good deal of application design went into planning exactly how the 37 general channels could be copied back and forth to the four working channels during the processing of the application. This work was done on what was called a Flow Sheet, which listed each general storage channel number, and which working channel it would be occupying during processing. Following this was a verbal description of the processing being done in that channel, including loading other general channels into the remaining working channels, and when to transfer activity to another working channel.


      Coding was transferred to paper tape via the Flexowriter, which produced both a printed and punched paper tape copy of the coding. The content of a coding form was typed starting with the number of the general channel where that data was to be stored. Then the content of the eight rows of four words each was typed as eight lines of hexadecimal digits. Each line consisted of the four words consisting of eight hexadecimal digits, separated by one space from the next word. All coding forms were typed one after another on a continuous length of paper tape. Any data required by the program was typed following the last coding form.
      During the course, my project was to find the "Position and Magnitude of the Absolute Maximum Moment in a Beam for a Series of Moving Point Loads." I must report that this project turned out to be too big for a neophyte programmer with limited access to the computer to complete in a 10-week course. However, I became hooked on computers, and eventually changed careers from engineering to computing and information management.

      I can't set a new recordâ€"Julius Ivanyi is older than I amâ€"but I do have some other memories to share.
      I built my first computer "fragment" in 1967. It was a relay-based 4-bit full adder. It was for a ninth grade science project. I had to lend a book to my science teacher so that he could grade my project!
      In the early '70s, I had the opportunity for three weeks one summer to work on IBM's first personal computer. It was a model 1130, the size of a large desk, with (essentially) a Selectric typewriter as an input/output device. It had something like 16KB of memory and a single cartridge disk drive that could hold a few megabytes of data. There was a FORTRAN compiler, an assembler, a linkage editor, and an APL interpreter. It was a fascinating personal computerâ€"except that it probably cost the earth in those days. I have no idea what such a computer would have been worth. Sadly, I probably threw out the old manualsâ€"I'm sure they would be a hoot to look through now!
      I have many more memories of the "bad" old days of computers, in case you are planning any more articles about those days.

      OK, I can't top 1959. I started in 1961, and SOAP meant something a little different than it does these days. There was an assembler for the IBM 650 called the Symbolic Optimum Assembly Program. The 650 was a drum machine and it made a difference where the next instruction was on the drum. The rule of thumb was five instructions away, but SOAP knew about instruction times and could optimize the placement of instructions on the drum.