Personal/Technical History #1
Introduction
I have worked for Microsoft for over 10 years. I started in Windows supporting Windows NT 3.51 and then did a brief stint in SNA Server until shortly after the SNA Server 3.0 launch.
My introduction to the WWW.. and IIS
While on the SNA team I was exposed to IIS 1.0 beta. This was my first beta as a Microsoft employee. You see, while I was in college I worked with Windows NT 3.5 Server and I the Windows NT Resource Kit came with a web server called EMWACS Web Server. This was a simple web server that had a Control Panel interface and an option to determine where you wanted your content placed. I started writing very simple web pages and was hooked on HTTP and the World Wide Web.
When I found out that Microsoft was writing an web server, I jumped at the chance to learn more about it. At the time CGI was the only way to make web servers do anything interesting, and CGIs were usually written in PERL or C++. IIS brought ISAPIs to the table, and I was anxious to learn the power of ISAPI DLLs. The first one I started working with was called HTTPODBC.dll.
On to Dynamic web pages...
While on the SNA Server support team, I worked with HTTPODBC and soon started taking IIS cases and solving HTTPODBC issues for customers. My natural progression was toward the IIS support team so I applied and joined the small team of IIS Support engineers.
Playing in the same sandbox..
While on the IIS support team, I noticed a common pattern with issues. Customers would call in with a server that created a dr watson or was hung and then would want to know what the problem was. Time after time, the issue was determined to be within ISAPI code that was "plugged in" to the IIS framework. The disadvantage was that if there was a problem with ISAPI dlls then they took down the entire INETINFO.EXE process... and then the phone rang.
My introduction to debugging..
When our customers had a "server down" I learned very quickly that you do all that is in your power to solve the issue at hand. The more seasoned engineers and the development teams for Microsoft's products used a tool called CDB to perform their debugging. This tool had an arcane syntax that has become more and more accepted with the hard-core technical community over the years.
The idea was that you connect to a process, examine callstacks for running threads and if your symbols line up, you may find something interesting. The trick was getting your symbols to line up. If they didn't, then the debug session would be of little use and you might as well be trying to solve the issue by throwing darts at a dart board.
On to remote debugging...
Sometimes you needed development to "remote" into your CDB session. Back then this was accomplished with a Resource Kit utility called REMOTE.EXE. You would run REMOTE.EXE /s cmd "sessionname" on the debuggee and then run REMOTE.EXE /c SERVER-NAME "sessionname" on the remote client to connect in and perform your debugging. Things haven't changed that much since then.
[more of this later...]
