PART 9: Silicon Wars: The Return of the Hacker
"A Brief History of Code", by Rudedog Hawkins
PART 9: Silicon Wars: The Return of the Hacker
Now these AI enthusiasts were also the type of hacker that saw the symbiotic relationship between System Specialists and Application Specialists. Most of the time they were one and the same. All software engineers of that day held some interest in AI to some degree. They tinkered and dabbled with the mundane software that could allegedly demonstrate “artificial intelligence” of one sort or another. But, AI software was written differently from most code that was being commercially produced. It was weird and hard to understand on first look. The best of it was designed to operate in an interrupt driven environment, reacting to outside inputs and stimuli. That was what microcontrollers did best, not CPUs. Most microcontrollers had a pin for hardware interrupts. The Intel designs used in the original IBM PC primarily used software interrupts.
By the mid-to-late-80s, Graphical User Interfaces, GUIs were the wild fire in the computer market. Software written for a GUI---whether it was the OS or an application---had to be written a little differently. Instead of running through a set of instructions start to finish, software engineers noticed that the code had to be written so that it waited for the user to do something and react to it. This bore a remarkable similarity AI software, which was also written a little differently.
Some GUI developers began to take a closer look at software architecture of how some of the AI software was written. The interrupt driven environment was a perfect match for the newer GUIs. An interrupt driven environment was designed to be one where the CPU sits idle until it receives an external signal on one of the pins of its’ IC chip, such as on a hardware interrupt CPU. A software interrupt CPU could react to specific instruction being executed at a fixed memory location, so it was thought to be impossible to for it to just sit and wait. Hackers cheated and found a solution. They faked out the CPU by writing OS code to send periodic messages to the OS. The message content was used to initiate the appropriate software interrupt.
A CPU could have numerous interrupt sources. These sources could be a disk drive, the keyboard, the mouse, a serial port, etc. Depending upon what the signal/message is, the CPU will execute one subroutine or another. These subroutines were initially known as interrupt handlers. Interrupts were ideally suited for the multi-taking environment that consumers desired and dreamed of. Today, these message driven interrupts are known as events in .NET.
Interrupt driven microprocessor designs had been around for a decade. They all had interrupts in one form or another. The typical commercial code that was written for them followed the typical procedure-driven patterns of the day. The best AI software did not fit those classic patterns, but it was very good in an environment where it could not be accurately predicted what the program might need to do next. A complete pre-written list of procedures and instructions was out of the question. A program had to be ready for anything the user might do next. It had to react to a variety of inputs that could each vary in a wide variety of ways. Just because it worked well did not mean that it was well written. Procedural code was lacking a bit in its’ capacity to react dynamically to interrupts.
Some computer languages were already starting to incorporate some features that were suitable for AI programming and dynamic interrupts. Most of these features and concepts had been around in one form or another since the 1950s when the first specialized lists were conceived. The problem is that no one had yet to come up with a well-defined methodology for putting these concepts into practice, which meant teaching someone how to write it was difficult. This is why a lot of AI code resembled spaghetti.
AI Code that was being written with software objects was written with a procedure-driven mindset. The results were convoluted code that was hard to write, harder to understand, and near impossible to modify. As far as seeing someone else’s code in a scientific journal---written for different hardware from yours, naturally---and trying to test it out and play with it anyway was futile. Artificial Intelligence was more than just a novelty, it was still a pipe dream.
Consumers were no longer purchasing computers because of what they were made from---genuine IBM/Intel parts. Consumers purchased computers because of what they are used for and what they could do. The consumers and software vendors defined those rules. The software manufacturers were defining the personal computer industry. The hackers were defining the software industry.
The software manufacturers made a lot of money. Many of the hackers did not make a lot of money. Many companies rewarded the programmers behind their profitable products quite well. Other companies did the best they could to spread the wealth, while some did not. Some companies simply had too many people working on a single product to make all of them multimillionaires. One such company was Microsoft.
During the PC Clone wars, manufacturers lost some of their independence to build the products that they wished. Clever marketing campaigns had consumers purchasing the most generously bundled clones, which were naturally packed with Microsoft software. Microsoft was rumored to have been pushing PC manufacturers into shotgun weddings with the bootstrap loaders. But, Microsoft did not completely take over. Suits were filed, laws were changed, new suits were filed, and other software vendors were no longer being locked out of the OS market. But several enemies had been made or vanquished.
But in the end, the hackers won. The hacker had made a comeback. In some cases it was not a pretty one. A lot of excellent programmers lost their jobs through no fault of their own or their company. Big Blue had been surpassed by Big Bill as the king of computer software. Big Bill had made some enemies through the use of business tactics long rumored to be ruthless. Some hackers found a way to get even through ruthless software.
Rudy =8^D
PART 9: Silicon Wars: The Return of the Hacker
Now these AI enthusiasts were also the type of hacker that saw the symbiotic relationship between System Specialists and Application Specialists. Most of the time they were one and the same. All software engineers of that day held some interest in AI to some degree. They tinkered and dabbled with the mundane software that could allegedly demonstrate “artificial intelligence” of one sort or another. But, AI software was written differently from most code that was being commercially produced. It was weird and hard to understand on first look. The best of it was designed to operate in an interrupt driven environment, reacting to outside inputs and stimuli. That was what microcontrollers did best, not CPUs. Most microcontrollers had a pin for hardware interrupts. The Intel designs used in the original IBM PC primarily used software interrupts.
By the mid-to-late-80s, Graphical User Interfaces, GUIs were the wild fire in the computer market. Software written for a GUI---whether it was the OS or an application---had to be written a little differently. Instead of running through a set of instructions start to finish, software engineers noticed that the code had to be written so that it waited for the user to do something and react to it. This bore a remarkable similarity AI software, which was also written a little differently.
Some GUI developers began to take a closer look at software architecture of how some of the AI software was written. The interrupt driven environment was a perfect match for the newer GUIs. An interrupt driven environment was designed to be one where the CPU sits idle until it receives an external signal on one of the pins of its’ IC chip, such as on a hardware interrupt CPU. A software interrupt CPU could react to specific instruction being executed at a fixed memory location, so it was thought to be impossible to for it to just sit and wait. Hackers cheated and found a solution. They faked out the CPU by writing OS code to send periodic messages to the OS. The message content was used to initiate the appropriate software interrupt.
A CPU could have numerous interrupt sources. These sources could be a disk drive, the keyboard, the mouse, a serial port, etc. Depending upon what the signal/message is, the CPU will execute one subroutine or another. These subroutines were initially known as interrupt handlers. Interrupts were ideally suited for the multi-taking environment that consumers desired and dreamed of. Today, these message driven interrupts are known as events in .NET.
Interrupt driven microprocessor designs had been around for a decade. They all had interrupts in one form or another. The typical commercial code that was written for them followed the typical procedure-driven patterns of the day. The best AI software did not fit those classic patterns, but it was very good in an environment where it could not be accurately predicted what the program might need to do next. A complete pre-written list of procedures and instructions was out of the question. A program had to be ready for anything the user might do next. It had to react to a variety of inputs that could each vary in a wide variety of ways. Just because it worked well did not mean that it was well written. Procedural code was lacking a bit in its’ capacity to react dynamically to interrupts.
Some computer languages were already starting to incorporate some features that were suitable for AI programming and dynamic interrupts. Most of these features and concepts had been around in one form or another since the 1950s when the first specialized lists were conceived. The problem is that no one had yet to come up with a well-defined methodology for putting these concepts into practice, which meant teaching someone how to write it was difficult. This is why a lot of AI code resembled spaghetti.
AI Code that was being written with software objects was written with a procedure-driven mindset. The results were convoluted code that was hard to write, harder to understand, and near impossible to modify. As far as seeing someone else’s code in a scientific journal---written for different hardware from yours, naturally---and trying to test it out and play with it anyway was futile. Artificial Intelligence was more than just a novelty, it was still a pipe dream.
Consumers were no longer purchasing computers because of what they were made from---genuine IBM/Intel parts. Consumers purchased computers because of what they are used for and what they could do. The consumers and software vendors defined those rules. The software manufacturers were defining the personal computer industry. The hackers were defining the software industry.
The software manufacturers made a lot of money. Many of the hackers did not make a lot of money. Many companies rewarded the programmers behind their profitable products quite well. Other companies did the best they could to spread the wealth, while some did not. Some companies simply had too many people working on a single product to make all of them multimillionaires. One such company was Microsoft.
During the PC Clone wars, manufacturers lost some of their independence to build the products that they wished. Clever marketing campaigns had consumers purchasing the most generously bundled clones, which were naturally packed with Microsoft software. Microsoft was rumored to have been pushing PC manufacturers into shotgun weddings with the bootstrap loaders. But, Microsoft did not completely take over. Suits were filed, laws were changed, new suits were filed, and other software vendors were no longer being locked out of the OS market. But several enemies had been made or vanquished.
But in the end, the hackers won. The hacker had made a comeback. In some cases it was not a pretty one. A lot of excellent programmers lost their jobs through no fault of their own or their company. Big Blue had been surpassed by Big Bill as the king of computer software. Big Bill had made some enemies through the use of business tactics long rumored to be ruthless. Some hackers found a way to get even through ruthless software.
Rudy =8^D
No comments:
Post a Comment