Greatest Hackers of All Time: Windows System Programmers

Prologue

Starting with DOS 5.0, being run on a 5150 aka IBM PC, it immediately became clear that too much things are going on there, and there's no time to learn all of that. From BIOS and its APIs, to jumpers and all those DIPs, noises from the glorious-duo of 5.25 inch of the FD Drives — call it FDD if you want, I won't bite.

I had a mission of my own in my hands. However, Oh dear, few month later, it was CRT-clear that you couldn't possibly do much with the IBM machine. The name PC has stuck to workstations manufatered by IBM, but IBM PC's are still workstations, comparing to mini-monsters from DEC, e.g. PDP8 and PDP11.

Skipping some commands, I nearly learnt everything user-ish about DOS 5.0. And it was good. There were some holes and difficulties which wasn't DOS' fault at all. Almost every time you stuck somewhere in DOS, it's on you, and to be specific, it's the lack of knowledge about underlying concepts behind hardware and firmware, esp. BIOS and its APIs, not to mentions all those creepy hardware-controllers. That's correct, I'm thinking of RLL and MFM!

For a moment, ignore the whole horror of implementation of trash specifications of the whole shebang of MBR and BIOS/CHS … Unless you're a hardware-illiterate type of guy, frankly there's nothing complex about MBR and DOS fdisk by itself. That too applies to OpenBSD, FreeBSD, Linux and other UNIX-ish OSes. Boys are constantly whining about horrors of working with disklabel(8) and fdiks(8). My advice to you: just shut your mouth, spend some time, and learn how things like HDD and BIOS actually work. Meh! You have to know one or two things about CHS, otherwise how could you possibly expect to find your way out of the filesystem-utilities. Meh!

However, regarding PC and DOS, both MS and IBM DOS, and for now, pray let's forget about DR-DOS, there were some obvious limitations.

GW-BASIC and Transcendental Functions

I picked up GW-BASIC very early. I've learnt about logarithms and trigonometric functions way before studying them in a proper class in a proper school. It all happened during the time, when I was learning GW-BASIC. Typical students learn trigonometric and logarithmic functions somewhere between the age of 12 and 14. However, back then, I had to learn all of those concepts few years earlier. After all, they all had been part of the BASIC language and also were crawling all over of my GW-BASIC book. Thus, I needed to learn about sine and co-sine, logs and other stuff. It turned out it was a good accident.

Presently, I use both OpenBSD and Windows. UNIX always has its own great men, e.g. Ken Thompson and Theo de Raadt. There are many more, but I reserve the right not to remain silent, when it comes to my preferences and biases. I love my biases. They are great. Everyone should have bias. Biases are one of the greatest virtues, having being ever possessed by any men since dawn of civilization, Egypt and Sumer towards the great Greco-Roman world.

All things great, came first out of IBM and then AT&T Bell Labs and BSD. Then OpenBSD has raised like a Sol from whatever had been left from NetBSD. Actually, I couldn't possibly learn about Kernel internals if it wasn't for the magnificent OpenBSD, and now while I'm on the topic, it was Perl which taught me programming. GNU/FSF too has done some good works though. There's also FreeBSD, but right now, I can't think of any specific innovations from them to point to, except the magnificent initiative of having the kernel's size doubled, by pushing ZFS into it. Some say that's great, I say go HAMMER2 But remember? I am biased. So let's move on!

Difference Between Windows And UNIX Programmers

There's a fundamental difference between Windows and UNIX programmers, and I'm going to name some of those, mind you, as far as I can remember. In UNIX, you have source code. In Windows, that's not an option. There were a lot of different utilities and build-toolchains, both from Microsoft and 3rd-party developers. However, it has always been the case that most of them were either too cryptic to understand and work with, or incomplete enough in functionality.

If you were lucky enough, you would have access to some MODEMs, having connected the thing to some BBS somewhere on this planet. In good old days, using BBS was one the ways to be able to learn about some specific things. While crossing you fingers, someone might have known much more about the problem than you did, and if you were lucky, he would have answered your question.

On the contrary, to these days, all UNIX programmers have access to glorious man-pages. All they have to do is to read man-pages and then, skim through pages of mailing-lists, or even posting some questions. But a Windows Programmer have to scratch his head 24/7… no more test, having hopped for the best.

In the Windows circle, a lot of magic is going on, which is needed! Mind you, that very problem gave birth to thousands of 3rd-party tools and developers around the world, for whom their main job, for the most part, was one thing: to explain things that Microsoft was too dumb to explain. I hate Bill Gates, nevertheless Steve Ballmer was a gentleman. All of that means a DOS/Windows developer was and still is on his own.

UNIX Source Code and Documentations

Not having source code, or the lack of documentations, which is worse? What can I say! It is nearly impossible to know how a Windows construct works, and above that, there's no written text, good and helpful enough, to explain how to fit that very construct in your hand, alongside of other constructs in harmony. That's Windows. Often, it was all about trial-and-error. I'm telling ya'… just wild guesses. Let's see what would happen, if …!

Now, what the hell are you supposed to do with all that? Again, if you were lucky you had access to a BBS, a list or whatever, and hopefully you could have found a knowledgeable guy who would have the answer to your specific question, while willing to hand it to you in the first place. And most of those services weren't free at all, which was fair by the way. He hacked to the bone, not to set the controls for the heart of the sun, and now he wants to sell his art to you. Hammurabi was right: that all make sense now.

Microsoft Support Is A Ghetto

It's a common body of knowledge that there's no Microsoft support anywhere on Earth. There are some Microsoft ghettos though which all are as good as trash. They are recruiting bunch of idiots from all over the no-name places, people who know jack nothing about anything, being busy making some scores here and there, or whatever.

Third-party Windows forums were better. They're still around, showing advertisements. The best thing you can get out of all those Microsoft forums is to learn how to delete a folder; and that's the sad part of the tale. Nearly none of those so-called experts even knows what's the difference between a folder, path, and a directory.

In short and considering the documentations alone, as a Windows programmer, you are all on your own.

UNIX Is The Land of Utilities

UNIX and most importantly, its concept of pipe and filters has always been a great can-opener. The ed(1) is not enough(.?!) … now, there's vi(1), and whilesort(1)-ing… oh no, I need REGEX, and now, after few days, you have grep(1), and eventually sed, awk and all of those. That's UNIX.

It's safe to say if you're on UNIX and think that it would have been great if there was utility alpha to fix your problem, then you are almost certainly is an idiot. The utility is there, but you weren't smart enough to find it. Dig in more, and do not whine.

In Windows, we were and still are screwed in different scales, in a unimaginable gigantic fashion, of all states of affairs. Let's be honest, there wasn't any useful utilities in Windows directories at all. NOTEPAD.EXE is fine, but not as practical as something like wc(1). Then suddenly, Sysinternals happened.

Diabolus: The Black Kernel of NT

Mark Russinovich and men like him went deep down into the darkest corners of black-boxed kernel of NT and DOS. Men who weren't pleased by some junk-lines of interfaces to the APIs. They went down deep, into the deepest holes of holes, the Windows Kernel. As a result, a big class of different system utilities had blessed us.

To be exact, Sysinternals wasn't the first, nor the last one on that line of work. Moreover, not all system-utilities need to have the kernel hacked. And I, too, won't suggest Mark Russinovich and men like him had been breaking into the kernel to write all those utilities. Nearly all components of Sysinternals can be written, merely using pure WinAPI. But the preciseness of the work suggests that Mark knew more than APIs. When you're trying to do something out of ordinary way of doing things with and by the Black Kernel Of Windows, there's a good chance that you would've known a little more than a little, more than just interfaces to routines and APIs.

Knowing your way about the UNIX, by no means will help you to deal with the darkness of Windows kernel either. Both Windows and UNIX are using system-calls to switch the context and modes. However, they're fundamentally different from each other, esp. regarding the model of handling processes and threads in the kernel; e.g. in Windows, processes are expensive, while in UNIX you can go full CGI. That one example underlines the fundamental difference which draws a big fat red-line between Windows and UNIX internals. Let's move on.

Sysinternals was one of the greatest thing ever happened in Windows circle. It wasn't the first, nor the last, but the accident was monumental, which shall lead us to the next point, an important one, the virtue of knowing assembly language when you're dealing with Windows, esp. during the old days of pre-.NET.

MASM and Assembly Language

If you didn't know MASM and assembly language, especially during DOS era till the end of Windows XP/2000, I bet whenever you wanted to do some system utility works, you had been sinking into a vast ocean of shit while your mouth was open. Some backgrounded is needed.

IBM mainframes' fellas with a solid background in FORTRAN, all had a tendency for joining to the BASIC circle of primevals. I don't know why, but that was the way, the way things were working. Later on, most of those men moved to VB6 and finally to Visual Basic .NET. If you ever wonder who were all those men who had chosen VB.NET over the C#, well; now you know who they were: probably, men with a FORTRAN background from the circle of IBM. Developers with a UNIX background were immediately jumping on WinAPI. After all, it was C and later on, C++. The former was the one that all UNIX programmers are very keen on.

There was one problem though. Again, there was no source code or comprehensive documentations. Just bunch of cryptic rolls of text, explaining the interfaces, to APIs and system-calls… procedures and routines — you excuse my Pascal, so forth and so on. Pascal and Delphi, Basic and VB6, C and C++ … but everyone knew if you wanted to do something serious with DOS, Windows, or both — for pre-NT purposes, you first had to know the WinAPI, i.e. 16bit WinAPI -> Win32API and later Win64API aka WinAPI!

Second, when it came to Graphics and some hairy computation and number-crunching tasks in IBM PC — number-crunching: a term which was popular among IBM fellas of 700/7000 series, you needed to know assembly language too. There was no way round. Ask anyone with a DooM2-level skill of developing games for DOS and they will tell you the whole story; e.g. Jazz Jackrabbit developers.

WinAPI aka Windows API

WinAPI by itself wasn't an issue, but lack of source code and a good documentation definitely were. You had to play the game of trial-and-error, lots of guessing, utter waste of time in many instances. Beside, the developer-suite from Microsoft was way expensive. You had to pay a lot, stick to whatever were shoved-in, inside of the luggage. With an extra (too extra) you would've granted access to all those documentations too, which comparing to UNIX documentations was trash.

Then, Borland happened and Philippe Kahn came down on the price in an order of magnitude, comparing to overpriced luxuries from Microsoft. Before Borland, if you wanted to compile hello-world in Windows — and I'm exaggerating, you could have gone broken. Philippe Kahn made Bill Gates really mad, but it was what it was. Eventually, Microsoft forced to cut the price too, and now all are free of charge. But none of those changed the fact that although Windows C was C, but no joking, it wasn't a proper C, the C proper.

Compare that to UNIX. Damn all of ya! UNIX developers even had access to internal-routines of the kernel, aka intro(9). Let it out: I hate yo'all! The last point, the one which I've just made, is the prelude the next one, i.e the fundamental one:

UNIX Developers

If you are a UNIX developer and want to graduate to a killer one, then you need to have (beside having a sharp three-digit IQ) a thing for reading documentations and source codes. Hardware is really doesn't matter, they all are have been abstracted out at Library Function level of intro(3).

A good background on Network concept, Cryptography and the internals of operating-systems are always blessing, but you needn't have a Ph.D. in computer science to write system programs in UNIX. You only need to know enough, and connect the dots between manuals and source codes of yours and the others. There are many examples and working projects to learn from on the Internet. There's always people who know much better than you do, and will always help you to know your way about the town, and do all they can to make your experience a pleasant one. the UNIX circle is a AAA league.

Windows Hackers

In contrast, to be a killer DOS/Windows developer, you're pretty much out of luck — and I'm talking about writing system utilities and dealing with framebuffer and GPU, not some .NET and/or MFC crap. Why am I saying that? Well, to be a DOS/NT killer developer you have to be able to hack into black-box of Windows kernel. I rest my case right there, and that's all you have to know.

Hacking to Windows kernel will give you the power to write ant-iviruses, for example. There's no way around to write those stuff on Windows, unless you find some way to hook your code up to somewhere dark, deep inside of DOS or Windows kernels. You needed to know how the Hardware and interrupts are actually working, how to take advantage of BIOS APIs (old DOS) and different controllers (again, DOS era). You needed to hack to the kernel in such a way, that not being BSOD-ed by your own creatures. Pretty much everything were working at Ring 0 with administrator-level access and permissions.

Suddenly, Windows Security/Defender happened and screwed everything up. Windows Security/Defender was a busybody, so you'd had to find a way not to be flagged as a malware; because after all, your piece of work actually was a rootkit to the black-heart of NT kernel, or DOS, or whatever.

Debugging Windows Without Symbol Tables

DOS and Windows programmers had to dis-assemble the code without any help from debug/symbol table, re-assemble some part of the codes again, and know how to use assembly language to take advantage of new instructions, which had not been implemented yet by the official channels of Microsoft. Moreover, you probably would be screwed with next updates from Microsoft. They were and are in business of changing internal implementations, and now your magnificent work of art is giving the windows users a black-hearted BSOD. Yes, that's correct: Bill Gates is trash.

To make it clear, I was talking about pre-.NET life of NT and DOS programmers. Men who had to deal with NASM 5 and Win16API/Win32API. The whole pocess of developing .Net software is a joke. The .Net is Python of NT; nevertheless, it's good enough for Soydevs.

Epilogue

To wrap it up: I don't use Windows much these days, definitely not any coding, but still, I believe DOS and NT system/utility programmers of pre-.NET era were the greatest programmers and hackers of all time. That doesn't implies at all that the others were dumb. „No“. It just was a side-effect, out of necessity. They needed to hack their way into the black Kernel of DOS and Windows, to turn those to something usable like UNIX. Men who knew how to hack the API, to kill the biased BIOS, point-blank.