Curious perversions from the IT world - 5

The first story. Fatal letters

[ Original ]

Once upon a time, George got a job at the Initech office. The company had just rented several floors in an old office building that had recently moved from the city decay category to the elegant ground floor coffee shops and the smell of shoe polish and fresh leather upholstery on everyone else.

It was a vast area, and George was at that stage in his career when he had a separate office with a view to the lane.
')
His first task was to fix the problem in the Mac version of the company's software. On Windows, it looked perfect, but font rendering bugs appeared on OSX. Such a bug is hard to find, but George was probably a detective in his past life, so he was ready for this challenge.

The most important clue was the history of version control. Over the past three years, five developers have worked on the product. It seems that each of them was in the company for about four months, and then left. The long months went without any changes, then a new developer came and the cycle was repeated anew. As George found out, their names pop up constantly when he tried to understand the functions, performance and causes of product bugs.

Since the application was cross-platform, the developers implemented their own loader and font renderer. At least, it seemed to him. The internal structure of the fonts is a dangerous and confusing thing, and this is reflected in the code. It also reflected the fact that various programmers, who did not preserve its integrity, worked on it one by one. It was chaos .

In the code, George saw a bunch of aspects that were no doubt bad — unprotected calls to memcpy , malloc without free , pointer arithmetic, which worked more on trust than logic. But, apparently, none of this was the source of the font problem.

Frustrated, George decided to approach her from the other side. On screens with rendering bugs there were always one or two specialized fonts. George loaded the fonts into the Adobe and Microsoft font testing utilities, and saw reports about a whole bunch of errors.

The font download code was bad, but the fonts themselves were even worse. Having identified the problem, George told the boss that he needed to fix the fonts. The chief handed it over to the company president.

The next day, the boss approached George: "The president wants to meet with you, urgently ."

The office of the president looked more like a conference room, but without a negotiating table. A long room, on the one hand a table, windows in height in all wall and a view of the river. An angry president sat at his desk.

“What is wrong with you two? George, you're less than four months here, and you're already spending my time - are you spending my money on some crazy idea about a problem in fonts ? "

“But it is. I can show .

“In the Windows version, the font works great! The problem should be in the code, damn it. I know how much you get paid. Maybe I should take a calculator and calculate how much this ghost hunt cost the company? ”He hit his fist on the table so that the calculator next to the keyboard jumped a bit.

The charges continued, but George already knew what he would do after the meeting. By the end of the day, he returned his badge and work laptop, along with a rude and honest resignation.

After a short unpaid leave, George took another job. Years passed, and he began to forget about the time spent in Initech. But one day he saw a message about the release of a critical patch for Microsoft Windows vulnerabilities. As it turned out, "third-party font processing code" could have caused arbitrary code execution in some Windows libraries. After a little research, George confirmed his guess: it was the Initech code that caused the problem. Moreover, the last binary file of Initech was released back in 2008 - a month after he left the company.

The second story. Work on the process, as well as under and above it

[ Original ]

When Kevin got a job at Townbank in the late 1980s, he got into the same situation as thousands of other new programmers before and after him: a corporate programmer does not just write code - he needs to follow the process.

The process differs from the strict commandments of world religions only in that its task is to preserve the integrity of the code. Glory to the process, but be blessed, the process is good, you always have to follow the process, and, most importantly, the process is good for you!

For most developers, the process is not so bad. You just need to get used to it. Fill out the form, get the approval, register the test plan, write the build documentation - it's all in the order of things. However, as Kevin soon found out, Townbank had processes to which neither veterans nor newcomers could adapt.

Shiva factor

Kevin’s first assignment was to work in a group that was engaged in the largest project of Townbank’s IT department at that time — large-scale migration from a gradually aging mainframe to several new VAX systems. In theory, the process looked good - the consultants held meetings with the client and found out which systems would be transferred, it was necessary to write specifications, assign tasks to developers, the quality control department had to confirm that the new system was working as old, after which the code would be outputted to production .

When project managers developed the process, it was expected that unintended actions would always take only a small fraction of the total costs or the amount of time needed to implement the function, and at first it was. However, the project continued to evolve, and the more environments were introduced into the work, the more Kevin and his fellow developers had to add extra time to their estimates. Officially, the developers called it differently - testing system integration, configuring servers, testing media compatibility, but between themselves they called such delays by their true name: “Shiva factor”.

Serious business!

Not that Shiva was an incompetent or inexperienced system administrator - by no means. In fact, when Townbank decided to migrate from the mainframe to the VAX, the name of Shiva was at the beginning of a very short list of people able to cope with such an infrastructure migration. Shiva took up the matter with full responsibility, introducing his own policies that can help in eliminating the flaws of the process. For example, every morning, all developers, analysts, or employees of the control department, before entering Wednesday, had to literally sign the blackboard in the Shiva office to confirm their physical presence. In addition, feeling that the developer’s action tracking was not implemented in sufficient detail, he introduced version control protection: for each code change and transfer between environments, a memo was required. And all changes had to be made by its user ID. And from his terminal.

On a quiet day, a small change could be made in just one day, but quiet days often fell on holidays or weekends. Irritated developers complained to senior management, arguing that these politicians are slowing down the project and seem completely useless. In response, the leadership shrugged - Shiva set out his goals at the very beginning of the project - safe environments protected from cross-contamination with other code and from the incompetence of developers. In the end, VAX servers were still a novelty, and even many of the senior developers have not fully mastered them.

The masses grumbled and cursed fate, but instead of rebelling, overthrowing Shiva and ending his cruel rule, they all resigned and continued to work. Despite the interference and efforts of Shiva, the process continued, but there was one situation that Shiva seemed to neglect - what if he himself was unavailable?

Little programmer assistant

Although Kevin’s terminal showed that he was working in a clone of the production environment, the names of Nosmo King and Joe Blow clients made him understand that he had made a blunder - the application mistakenly connected to the development environment database and had to test it after lunch quality control department. In a normal situation, it would be easy to correct the error - to make changes to the configuration file in the development environment and resume work, but fate would have it that Shiva ended up in a long meeting and had to appear only the next day.

Hoping that Shiva would be able to return earlier, Kevin went to his table, but he saw only an empty chair. However, his attention was attracted by Shiva's keyboard. The letters A, S, V, H and I were erased more than others. Kevin knew that Shiva was intoxicated with power, but was he really so narcissistic that he was ready to type his name again and again? ... And maybe this is a hint? For fun, Kevin went to the command prompt and entered “shiva” as a username and password. Expecting that Shiva could enter the office at any time, Kevin clicked on Enter and was shocked that he was able to log in.

It was amazing. It was great. Kevin knew that he needed to share his discovery with someone. He told this to one of the veterans who had previously been his mentor, but his reaction was a surprise to Kevin.

It turned out that the combination of Shiva's username and password was Townbank's favorite “secret”, which had been known since Shiva worked as the mainframe administrator.

“So that Shiva would not know,” another, even more experienced developer, explained to Kevin, “we play this game with every new promotion he has.”

“By the way, for the future,” he continued, “if you don’t want to be caught and ruined the lives of everyone else, then you should enter from your terminal, NOT from his office.”

The third story. Speak with me in greek

[ Original ]


Many decades ago, before the advent of laser printers, graphic operating systems, and device-independent image formats, Gus worked in the IT department at a local college. As a personal project at the time of idle work, he decided to figure out how to print text in Greek. About a week later, he put together a program that could print classic Greek text to a printer.

Head Gus worked as an IT manager, but despite this, he turned out to be an expert in ancient philology. He never had to see a Greek text printed on an ordinary printer, and he was delighted. The boss told his friends about it, they told their friends, and so on. Soon the world of researchers in classical Greece turned into an enthusiastic and noisy symposium.

One day, Gus received an email from an unknown professor from a college in Arizona. He heard from Chief Gus about a wonderful, mythical program. Can he get it too?

Gus would gladly have agreed, but there was a problem. Its program was designed for the previous version of the VAX / VMS operating system and the Pascal compiler, and it outputted text to one specific VERSAMOD-200 printer, which could be transferred to the matrix mode, and to a specific print driver, which was neatly patched with a binary code so that spoil the matrix image. Gus doubted that the professor had enough technical knowledge to evaluate his explanation, so he answered politely and without going into technical details: I'm sorry, but the program will simply not work on any other machine.

A week later, the boss approached his desk, mentioned his friend from Arizona, and asked Gus gently if he could find any way to send him the program anyway. Gus' attempts to explain the impossibility of running the code on any other computer in the world have not been heard.

“You're a genius, Gus! I'm sure you can think of something. Thanks in advance! ”, - the chief, satisfied with his own optimism, left.

Gus began to think how he would be able to fulfill, or at least half fulfill the request of the boss. Finally, he got an idea. He DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 in the command line of his computer: DUMP /HEX "PRINTGREEK.EXE" /LIST=VERSAMOD-200 .

Soon the hex dump of his program took on a tangible paper look. Gus with a smile gathered a printout and went into the office of the chief. “Here she is! This is a program, as you requested. ”

“Oh!”, The boss seemed surprised, but understanding.

“If they have any problems with the installation, let them contact me and I will help,” Gus said.

"Fine! Thank you very much! ”, The chief glanced at the table, looking for a suitable postal envelope.

A little later, another of our respected IT colleagues in Arizona was handed over and ordered to install this dump printed on paper. He must have experienced a rather shocking moment at WTF, but apparently he successfully coped with the task. At least thirty years have passed since then, and Gus never heard any questions from the professor or other college staff. Perhaps someone just made a deal with Hades or asked Kronos to transfer it at a time when printing special characters ceased to be such a Sisyphean task.

The fourth story. Emergency faxes

[ Original ]


At the current stage of technology development, faxes are outdated. They were invented a dozen years earlier than the phone, but, despite the enormous progress in scanning and e-mail technologies, they still remain the standard form of communication.

When transmitting data, random “stuttering” or noise on the line can spoil the fax. Most modern fax machines have rudimentary error handling functions, warning the user that the fax must be sent again.

This way of working with errors acted so well that no one thought of changing it. But one business analyst from the company where Tom worked had a bright idea.

“What if the user is not sitting next to the fax while waiting for a message?” He wondered. “What if the sender’s fax machine does not detect the problem?” We should fax him a bug report! ”

Although the analyst’s concern was justified, Tom and his group objected that sending a failed fax message would not make life easier for everyone.

They said that because of this, the sender’s machine would be busy and he would not be able to resend the original fax.

“This is normal,” the analyst replied, “our software can send and receive faxes in parallel. This idea is the best that came after the iPod ! She is absolutely reliable ! ”

But the disputes were meaningless: in the eyes of the management, business analysts are always right, and this function was implemented urgently. The program was called “FaxBack”, and it performed the function corresponding to the name: it transmitted the failed transmission back to the sender (determined by Caller ID) within a short time after the occurrence of the failure.

For a long time everything worked without the slightest problem, until one day two police cars with sirens turned on near Tom’s office. The police said they answered an emergency call on 911, but there was no emergency and no one admitted that they dialed 911.

Soon the officers left, but early in the morning of the next day two other police cars promptly drove up to the office. There was no emergency situation again and no one called 911, so they quietly left the office.

But the third time, when the car appeared in the second half of the next day, the officers refused to leave until a source of "concern" was found. At the police station, they were confident that the call came from the company's number and demanded that they understand what was happening.

Having spent the rest of the day and part of the evening on tracking phone calls within the company, Tom found out that calls to 911 are from the data center, and more specifically from FaxBack.

Fax machines, like office telephones, had to dial "9" to reach the external line. Therefore, when FaxBack responded to a failed fax from New Delhi, dialing the nine followed by the international code of India - 11, and the “special rule” of the telecommunications system worked.

The one who installed the telecommunications system came up with the bright idea of ​​treating the “911” as a special case, because the caller might not have thought of in case of an emergency first dialing another nine. A special rule applied to the lines in the fax pool, even if the caller was just a computer.