If you are looking for the leaked MS source code, don’t do it. As John Lettice points out:

…if you are offered unlicensed access you're smart not to even look at it, because simply knowing how the stuff works compromises your ability to produce products independently, and renders you difficult/dangerous to employ in the relevant field.

And later …

Finally, this is very important: if you propose to continue working in the IT industry, and somebody offers you a look at the source, just say no. Remember - if you learn too much about the internals of Microsoft products, you may find yourself unable to work for anybody except Microsoft. Yikes.

This statement is obviously fact. Don Box told us all about COM internals, and guess where he works now? Microsoft. Chris Sells has openly admitted to pumping MS employees for insider information at trade shows. Guess where Chris works now? Microsoft.

Summary: Delete your Rotor source code, uninstall your decompiler. If not, you are a coding time bomb of intellectual property and a target for assimilation.

For the last 18 months I’ve done no real development outside of C#. After 10 years of C++ I was starting to think at times I missed it. Then I downloaded the source code to Allegiance, because I just can’t resist looking at source code. I ran across this:

while (true) {
    UpdateText((char*)LPCTSTR(CString("Copying ") + CString(data.cFileName)));
 
    if (data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) {
        if (
               (strcmp(data.cFileName, "." ) != 0)
            && (strcmp(data.cFileName, "..") != 0)
        ) {
            CopyDirectory(
                (char*)LPCTSTR(CString(pchFrom) + CString("\\") + CString(data.cFileName)),
                (char*)LPCTSTR(CString(pchTo  ) + CString("\\") + CString(data.cFileName))
            );
        }
    } else {
        if (!
            CopyFile(
                (char*)LPCTSTR(CString(pchFrom) + CString("\\") + CString(data.cFileName)),
                (char*)LPCTSTR(CString(pchTo  ) + CString("\\") + CString(data.cFileName)),
                true
            )
        ) {
            Error("Error copying file.");
        }
    }
    if (!FindNextFile(hff, &data)) {
        if (GetLastError() == ERROR_NO_MORE_FILES) {
            FindClose(hff);
            return;
        }
 
        Error("Error reading directory contents");
    }
}
 

Two thoughts came to mind. First, I cherish the string class in .NET. Second, I realize now I never did like Hungarian notation.

I also had flashbacks to a code review I did about 4 years ago. Another guy and I sat down to prepare and quickly realized our coding standards were missing something important, specifically, how to deal with strings. Inside of the source file for a single COM component (not much code really) we found all of the following were present: CString, CComBSTR, _bstr_t, _T, LPCTSTR, BSTR, wchar_t, and char *. I’m not sure if I remembered them all, perhaps there was an OLECHAR mixed in there too. In any case, it's nice working with just one simple string class, with the occasional StringBuilder thrown in.

Also, I closed a support case with Microsoft recently. There is a bug in the Office 2000 version of OWC and it wouldn’t display all my cube dimensions. More details in this article.

There are some good responses to Rory's post with the above title.

I like the ThreadPool class because it simplifies spinning off worker tasks, but I did run into one area where I could not use it.

All the threads in the ThreadPool CoInitialize into an MTA. If you are doing COM interop with STA components (like any VB6 component), and want to avoid the marshalling overhead, there is no choice but to spin up your own thread with ApartmentState = ApartmentState.STA set before start.

Mono 0.30 is now available. It is also encouraging to see some serious effort in porting useful .NET apps to mono, for example, dasBlog. I agree with a recent posts on [mono-list], rebuild the go-mono.net site in ASP.NET to really show it off.

Note to self:

When the temperatures are consistently below 20 degrees Fahrenheit, don't forget to bring the soda in out of the car.

The ACM Queue has an interesting article on Building Collaboration into an IDE. The authors have been prototyping a version of Eclipse where IM, source control, screen sharing, and email augment the IDE. The goal is to give you more time to code while you spend less outside the IDE or away from the desk. Another goal is to provide additional context and traceability between code artifacts (source code files) and collaborative artifacts (IMs and emails).

I couldn’t stop thinking of questions and ideas while reading, particularly along the lines of how easy it might be to build this with Longhorn technologies.

This made me think of WinFS:

“For example, metadata that links source code with e-mail needs to be stored somewhere—perhaps with a special header field or with an URL. Where to store collaborative artifacts is another issue: You could try to juggle multiple stores (e.g., one for e-mail, one for source code, one for discussion forums, one for chat transcripts, one for bug tracking, etc.), or you could attempt to consolidate everything into a single store (e.g., the source-control repository).‘

This made me think of Indigo:

“An IDE augmented with collaboration requires some kind of supporting network infrastructure. Designing such an infrastructure raises the interoperability issues mentioned earlier (e.g., support for directory services, standards for messaging, etc.).”

Some things I read I just wish were already in VS.NET, like hovering over a checked-out file will tell you who has the file checked out, instead of just “another user”. It would be nice to put a watch on a file and have the IDE notify me when the other user checks the file in.

Being a Visual Source Safe user, it would also be great if the source control product didn’t feel 8 years old. I know MS is working on updating VSS, but I think there is a lot of catching up to do just to make it a solid and trustworthy product. Then I want all the all the bells and whistles and extensible plug-in support.

Reporting Services has an online launch web cast tommorow (the 27th).

I’ve never, ever, ever, been excited about report writing software, nor about integrating report writing software into a product. It is one of those mundane tasks you have to get tough and do now and then, like going to your bi-annual dental checkup. However, there is something about a web service API and an XML based report definition language that makes me want to give it a go soon and replace the “other” reporting software in a current application I work on.

I’m not alone in thinking the “other” reporting software drives programmers to shout vulgarities. An informal poll shows if the “other” reporting software was a person, a majority of developers would want to “give it a sharp kick in the knee”.

I think some of backlash comes from the “it is so easy anyone can do it” hype. I once had to monitor a 2 day training class (subject for another story) where unsuspecting victims were trained to use the “other” reporting software. None of these four had ever seen a SQL statement before in their lives. The expectation was for the trainees to be able to start cranking out ad-hoc reports on a 100+ GB data warehouse immediately afterwards. Can you say stress test?

The beta looked pretty solid. I’m sure reporting services is going to make some big inroads by the end of the year.