About David
Motivation
I recently decided to take a step back and looked around at some other blogs, and I realized that I had forgotten a very basic entry - a bio about myself. After all, who is this person that keeps writing Q&A about IIS and ISAPI in such a blunt (bordering on pedantic) tone, and can we get the guy to be nice and talk about something else? ;-)
Well, I decided to author this blog for a very simple reason. I wanted to establish a singular identity and location to help people with their issues related to IIS and ISAPI. Believe it or not, I wager that there are only about two dozen distinct issue patterns (and obviously lots of sub-variations) related to IIS and ISAPI. So, I plan on posting categorical and clarifying answers for all of them. At least, this is my personal conclusion from answering questions on various newsgroups since late 2001, including IIS and ISAPI.
But believe me, I will definitely continue writing even after I tackle the distinct issue patterns. People are amazingly good at coming up with problems, and I am opinionated and enjoy giving feedback with my own insight. :-)
Contrary to style issues, blogging and writing in first person is not a problem for me because I already keep a personal daily journal. So, you can say that this blog gets to have all the "technical" stuff while the "personal" stuff goes elsewhere. Oh, there may be some leakages here and there, but the brain works in subtle ways...
And before we get to far... let me first apologize and explain for my tone. When writing, I have a natural tendency to communicate with a tone that is logical, bordering on pedantic, and when you combine that with Q&A... I believe that the resulting message can be construed negatively. At least, that is what history has told me. But rest assured, I am NOT trying to be mean-spirited; I am just trying to help by providing information that I know.
Now, onward with the bio!
Before Microsoft
My first foray into working for hire was my junior year in high school, where for the next two summers, I worked at a local dentist's office. I learned to do everything in the dental office other than operate on the patient, from receptionist to developing bite-wing X-rays, from patient data entry to handling insurance verification. Yes, it was a lot of random tasks, but back then, I really did not think of it that way. Besides, I got to do some data entry on an old 80286 machine, and scouring around DOS on that machine more than filled any of my idle time during the day.
I even remember the one time that I turned SmartCache on, thinking it would speed up the dental LOB database application... until a week later when the cache's delay-write functionality and an unfortunate power outage caused some data loss and corrupted the database. Fortunately, the database had a backup and was recovered, but what I learned from this was the famous "if it ain't broke, don't fix it" rule - especially for finicky old computers.
After bumming around the entire summer following my college freshman year in Taiwan for "cultural studies exchange" (the Asians in the crowd should know what program I am referring to), I decided to get real and actually do summer internships. After all, the year was 1997, the Computer Industry and the Internet was all the craze, and I had declared Computer Science as my major.
I grew up in Houston, Texas, so my first internship following my college sophomore year was at a little computer hardware company called "CompaQ". Not a lot of exciting stuff at that time other than NT4 and $7700 for a 512MB stick of RAM. My main takeaways from the internship were:
- I hate Commuting. I lived about 20 miles drive from CompaQ, but the daily commute took 45 minutes to cover that distance. It drove me crazy that I had to switch to really odd work-hours, leaving for work at 6am or leaving for home at 6pm. I can totally understand roadrage after a summer of this.
- Hardware is not the place for me. While I am glad at the opportunity to man-handle a lot of circuit boards, RAM sticks, and cables (I only had my own PC prior to this, so I was ultra careful at first, but after seeing the veterans go at hardware, my perceptions quickly changed), the routine quickly wore out. And most of the interesting stuff I had to do was related to performance benchmarks of various hardware, where once the hardware combo was assembled, it was all about software automation for testing, data gathering, and analysis/charting. I enjoyed that far more.
Then, for the next two summers, I interned at another little computer software company called "Microsoft" in Redmond, Washington. For those that have not interned at Microsoft... you are missing out. It is the epitomy of work hard, play harder. You stress out during the week, you unwind on Friday, and then you party all weekend.
During my second internship, I was a part of a little project called "duct tape" which consisted of a kernel mode driver called Universal Listener that parsed and routed HTTP requests to user mode processes, the XSP request pipeline was used to process requests, and a bunch of managed code modules loaded into this pipeline to implement IIS5-like functionality. Yup, you guessed it - the precursor to HTTP.SYS, IIS 6.0, and ASP.Net, but with much more managed code.
Yeah, for a time period, IIS 6.0 was actually a managed code web server running on top of ASP.Net - wrap your mind around that for a while. We all knew it was twisted - it took 10 seconds startup time to serve an initial static file (sound familiar, anyone?) - but something Drastic had to happen for the Right Things to happen and result in the current-day IIS process model in pure native code.
And for the astute reader that has been following IIS 7.0, it is a complete flashback to the 1999 days, where IIS functionality is implemented by modules running on top of a request pipeline that has full fidelity for managed code... except this time, I will wager to say, it is done right. IIS 7.0 goes out of its way to exclude managed code from being invoked unless it is absolutely necessary through configuration, so you get the best of both worlds.
At Microsoft
I joined Microsoft full-time in the summer of 2000, right after I graduated with my degree in Computer Science.
I joined the IIS team, and I started out testing ISAPI Filter API, eventually adding ISAPI Extension API to the mix, and with IIS 7.0, the new IIS Modules API. Hmm... a pattern emerges... this guy likes to test native code API that underlie core IIS extensibility. Well, I enjoy learning and figuring out how things work, plumbing and all, so this is my sort of challenge. :-)
I also enjoy writing tools to simply make things "go" in the IIS team, including:
- Automation framework and driver to install Windows OS and run any IIS test
- Automation to actually locate and install all IIS tests, which are compiled and packaged as a real-world MSI nightly
- MSI generation tool that automatically crawls over the daily build and creates a new MSI install package for that day's test binaries/scripts/content
- Virtual Machine integration so that installing Windows and IIS to run tests is the same on both virtual machines and physical machines
Yeah, I enjoy learning about various technologies, building automation tools exposing the best of their abilities, integrating them all together into a cohesive whole, and fulfilling team-wide processes. I am always looking for the "big picture" and plan appropriately.
Finally...
So... this concludes a rather long-winded mini-essay... I promise to write shorter entries and lose less people's interest. Really. :-D Ok, so I can be a very long-winded person at times.
I hope you find the information that I am trying to share via the blog useful, and that you will take the effort to remark and debate. I do enjoy the challenge and want to help, but unfortunately, I am not psychic and cannot read your mind... so unless you disclose what issues you are trying to do with IIS/ISAPI, I cannot help...
//David
PS: Yes, I will get back to the managed code extensibility of IIS 6 series now.