"So...funny story..."

     First off, it has been a while, and I should apologize for that. Writing in a format that doesn't offend is tricky, and conveying anything with importance is even moreso. On top of that, my personal life has gotten in the way, which actually leads to this post: a hopefully enjoyable deviation from attempting to teach things about programming.

     Today's story comes to you courtesy of my first-ever programming job, from now four years ago. I was a sophomore in college, and had experience at a basic level with pointers and creating linked-lists in C++. I was given a unique opportunity to program a software-defined radio (from here on known as a "SDR", basically,  a very expensive WiFi card). Doing so required implementing a Windows NDIS driver, which as you can probably guess meant I was a little over my head, and there was a bit of a learning curve associated with it.

     SDR's serve to help reduce the cost of R&D for a new protocol. Developers have a choice: build unique hardware from the ground-up, plug in some code, and hope that everything works easy-peasy, or use one of these things, which have high initial cost, but are purpose-built for allowing any stack of code to run. They handle their own ADC/DAC, and just need a "front-end" (and antenna) to transmit on a given spectrum. For our purposes, I was transmitting a modified 802.11b protocol, so I had to use the 2.4GHz spectrum.

     Again: I was a noobie. Readers might be quick to point out "wait, you're still pretty young". Yes, but I have experience now, and have learned from my mistakes. Such as this one.

     Seeing as the aforementioned 802.11b protocol was one of our team's own creation (focusing on cooperative networking, in case anyone is curious), this meant a lot of on-the-fly decisions about implementation. Design wasn't really a factor -- I could make linked lists, I tried to separate my code blocks as best I could, but my functions were embarrassingly long. That's neither here nor there, but probably would have helped with debugging (see: previous post).

     Onto the subject of mistakes and bugs: when you are running an executable within a command prompt, and it segfaults, it exits "gracefully" -- alerting the user with a printed message to the screen, and killing the process, restoring control of that prompt to the user.

     Seeing as this driver was being developed, learned about, and decided upon simultaneously, there were numerous times where I would have a null dereference. For those unaware, that's where you dereference a pointer, attempting to access a member of whatever object that pointer was pointing to, but the pointer was NULL to begin with, therefore accessing memory you shouldn't, and the computer yells at you -- AKA a "segfault".

     What do you think a computer does when a null dereference/segfault occurs in kernel-mode code, stuff that is supposed to be super-efficient and super-careful and super-accurate?

Bad Things happen.

     In the TRANSMIT stage of our protocol, this was an inconvenience. That means one computer is down, while I reboot, recover as much of the logs as possible (only towards the end of the job did I get adept at using WinDBG + kernel-mode debugging in XP), and try to figure out which printf() call was showing something that it shouldn't.

     In the RECEIVE stage, it's an entirely different beast. My (malformed) packet has just taken down every SDR-equipped computer in the lab (aside from the source node). One null dereference, one segfault, and my lab is painted blue.

Honestly, it looked cool as hell.

Segfaults are bad, mkay?


1) Oh, and if you have a really, really bad day, the blue-screen might be a hint that you've just corrupted your Windows install. I had to teach myself how to use Clonezilla to have a backup partition to easily restore from, very shortly after such experiences.


2) When we got these SDRs, we had to have three parts: the SDR, a chip to support the front-end, and the front-end itself. These cost about $4000, total, per SDR setup. As another horror story, the instant we took two of them out of the box they came in, we heard pops and could smell a bit of smoke. A fuse blew, instantaneously. Fortunately, between a $0.10 fuse from Digikey, and someone who was way more adept at PCB reading, voltage-drop measurements, and soldering than I, we salvaged those things.

Beginnings

    I am an interesting enigma in the world of CS. That's Computer Science, not Counter-Strike, though I'm game for a round if you are (Source, not 1.6. Sorry, old-school gamers...and new-school, I guess, with GO being out now. Way to alienate right away, self.)

    I have been programming "professionally" for four years now, without actually having a true, contracted, full-time position. Only in the summers (that's not entirely true, my first programming job I elected to do concurrently with school). Many of my peers only have one internship under their belt, then they go into a full-time job. Maybe even two. I've done C-based NDIS driver-development, web development on the ASP.NET MVC platform, and most recently going on two summers worth of C# MVP development. That's a lot of internship, hence the title of this blog. It's also a lot of school, as I am going for two degrees -- both Computer Science, AND Computer Engineering. Hence the driver-dev, and being an enigma.

    There are no shortages of blogs out there that will tell you why your thought patterns are wrong. I'm actually quite a fan of them, which I'll get into why in just a moment (seems odd, right?). Even though I'm an old-as-dirt intern, I feel I can learn a lot (which is appropriate. I may be as old as dirt, but I am still just an intern). A lot of blogs I've been reading are from senior developers (and when I say senior, I mean senior, as in worked for Microsoft for so long that they left to start their own company) and they tend to know what they're doing. They're really good to learn from. I feel I can be good to learn from too -- I am not so presumptuous to say "your methodology is flawed" (or at least, I hope I'm not), but I do feel I can bring something to the table: a unique look from someone who has experienced both quite a bit of college, and quite a bit of industry, and can help bridge the gap between them.

    I will make an effort to update this fairly often -- it will serve as a good exercise of commitment for me, and hopefully a pleasant distraction from elements of my life, as hobbies are intended to do. Perhaps two or three times a week, that seems like a reasonable goal.

    As for now: hello, Internet. Let's see how this goes.

Next: Git101