deeptanshuv's WebLog

Five card stud, nothing wild, and the sky's the limit

deeptanshuv — Tue, 08 Aug 2006 07:04:00 GMT

Aug 7 was my last working day at Microsoft. I am on vacation now and will officially end my employment at MS on Aug 23. This means that there won't be any more Visual Studio blogs from me, unless I write one influenced by separation pangs.

It has been an interesting seven years. Not all of it was good but there have been more positive experiences than otherwise and I consider myself lucky to have gotten the opportunity to have been here. Meeting my wife here was the clear highlight of my stay. Meeting Bill Gates was next. Watching Steve Ballmer dance on Microsoft's 25th anniversary should probably count as the third.

All the best to you all for debugging all your apps, and I hope Visual Studio continues to enable you to do so in a user-friendly and robust manner. Let us face it, if your coding skills are anything like mine you spend 25% of your time in the editor and 75% in the debugger. The AppWizard? Nobody even cares about it unless it generates bad code :)

The title of this blog? A simple search should explain it. (Hint: Picard)

The next chapter of my life will be written at the Yale School of Management.

End of an era for Tech humor columnists

deeptanshuv — Sat, 17 Jun 2006 01:42:00 GMT

I have been reading several websites' coverage of Bill Gates' announcement to step down from the Chief Software Architect role in 2008. Most have focused on its impact on Microsoft, the technology industry, Wall Street and global health care (which stands to gain from the Gates Foundation).

But there is another segment for whom the world has changed significantly. For years I have been reading tech humour websites making fun of Bill Gates and the realization must now be dawning that soon there will be little new material for them. Yesterday someone at Slashdot forums pointed out that Slashdot's 'Borg Bill' gif might now need to be replaced. Without Bill, even the generic 'Microsoft jokes' would start lacking bite after a while, though Steve Ballmer still is well-known and colorful enough to sustain several Microsoft jokes on his own. Still, the curtain has probably come down on articles such as 'Evil Genius Gates Drops Windows 98 Into NYC Water Supply'

Who will provide the fodder for new material? Would Microsoft be able to retain its dominant position as the butt of technology jokes over the next decade? Time will tell. Here are some potential challengers:

Sergey Brin and Larry Page - still too young, raw and well liked in the internet community. May I say also lacking the 'presence' that attracts humorists, though this could change.

Larry Ellison - An excellent target for humorists thanks to his over the top persona. Still, makes it difficult to tell whether some stories are humor or plain facts. Probably peaked as a humor target with 'Diplomas are for losers'.

Scott McNealy - Plethora of 'dot-not' and 'look-out' jokes have been insufficient to attain a leadership position in the tech humor segment. In the tech segment either, for that matter.

The situation looks grim for tech humor columnists. But the great thing about this industry is its ability to throw up a winner from apparently nowhere. There is no reason why some kid in some garage somewhere cannot rise to become the inspiration for all jokes in the days to come. Heck, with a bit of effort and enterprise, it could even be you. And needless to say, Microsoft will be around. And we are still the only company with the resources to build a Death Star.

Code Center Premium integration into Visual Studio

deeptanshuv — Wed, 14 Jun 2006 03:16:00 GMT

Microsoft provides source access to some customers via its Code Center Premium (CCP) program. Not many people are aware that Visual Studio 2005 has integrated CCP support.

It is true! While debugging applications in VS you can download sources for system files from the code premium website provided you have CCP access. The prompting for the CCP card pin is handled in-session. The same license agreements apply.

This link gives you complete instructions on how to go about enabling and using this with VS 2005 - http://msdn2.microsoft.com/en-us/library/ms164729.aspx

Note that the CCP program is independent of Visual Studio and we are not involved in providing CCP source access. If you are interested in the program or have any complaints accessing the files you would need to contact the CCP team - http://www.microsoft.com/resources/sharedsource/ccp/premium.mspx

Regards,
Deep

64-bit and Visual Studio 2005

deeptanshuv — Wed, 12 Apr 2006 03:18:00 GMT

We keep receiving questions about Visual Studio 2005's support for 64-bit. Here is a set of factoids that should help answer the most commonly enquired issues:

(a) There are two flavours of 64-bit - AMD64 or X64, and IA64. Windows 64-bit installs on both architectures.

(b) There is no 64-bit version of VS. Visual Studio 2005 is available only as a 32-bit app. However, you CAN install VS on a 64-bit OS and use it to create, launch and debug 64-bit apps.

(c) VS will install only on X64. The .Net Framework and the Debugger components install on IA64, allowing you to remotely launch and debug applications on IA64 from a VS IDE installed on another machine.

(d) VS installed on either 32-bit or 64-bit OS can create 32-bit or 64-bit applications, but of course the applications need the corresponding platform to execute.

(e) You need the Professional or Team System versions to build X64 (AMD64) apps.

(f) You need Team System to build IA64 apps. Pro does not support this. See http://msdn2.microsoft.com/en-us/library/hs24szh9(VS.80).aspx

(g) On a 32-bit OS, the 64-bit compilers will not be installed by default, you will need to go to custom setup and check the option.

How to create 64-bit apps

A managed project is automatically built according to the architecture selected => default C# project created on AMD64 will be AMD64, X86 on X86. The native one is always 32-bit by default.

To explicitly set a platform:

(1) open the solution explorer, select solution, right click->Configuration Manager.
(2) go to 'Active Solution Platform', click New.
(3) in the 'New Solution Platform' dialog that comes up select the new platform say Itanium. Set 'Copy Settings From' to 'Any CPU' which was the default setting in the 'Active Solution Platform'.
(4) click OK.

You will see that the platform has changed to Itanium in the config manager. Now when you build the solution, you will get an Itanium exe.

Follow the same process for X64, and to rebuild 32-bit apps from that solution.

Quality Milestone, Marriage, Star Trek and Pilchuck

deeptanshuv — Fri, 24 Feb 2006 03:54:00 GMT

It has been a while since I blogged. One reason is that not much is going on. Of course, at Microsoft that is a deceptive statement. By "not much" I mean that not much immediately impacting the customer is going on. We released VS 2005 and are starting work on the next version; however, before doing so we decided to take a break and improve our processes and infrastructure to make for a smoother release cycle than we had for VS 2005. A lot of dust that had gotten under the carpet is being cleaned, some processes and practices are getting discarded and new ones being brought in. It is amazing how "inefficiency" creeps in slowly over time; only when you step back and start asking "why the hell do we do this?" do you realize the baggage you have accumulated.

Additionally, I am getting married in March. Now you know where I spent the time I would use earlier for blogs and newsgroups. Given the time I used to hang out at the MS campus it is not overly surprising that my fiancee is also a Microsoftie. I have gotten her interested in Star Trek: The Next Generation and hope to also develop her interest in Warcraft. In turn, she has cured me of my habit of spending weekends in the office.

I went climbing Mt Pilchuck with some friends this weekend. Just so you know, it is not an easy hike this time of year with all the snow. Heck, it is not even an easy drive to get to the mountain. A couple of cars got stuck in the snow and my friends and I helped push one poor guy's SUV out. The fun part was that when the tires started rolling they sprayed snow all over Richard's trousers.

Finally, I discovered "The Picard Song" in January. Apparently it has been out since 2003 only nobody told me. It is quite addictive and I would recommend that you give it a hearing: http://thepicardsong.ytmnd.com/

Regards,
Deep

Interop followup : handling C2065 errors building C++ Exe

deeptanshuv — Thu, 29 Dec 2005 01:07:00 GMT

Hi!

A customer emailed me with the feedback that my sample code with C++ Exe calling C# Dll does not build with VS 2003.

I investigated; the reason is that in VS 2003 the tlb exposes the namespace in lowercase as csdll instead of CSDll. The fix for this is to update the C++ code to use 'csdll'.

Alternately, you can add a 'no_namespace' to the #import tlb line in the .cpp file and then call all CSDll objects without using the namespace.

Regards,
D.V.

Debugger Chat Thursday Dec 15

deeptanshuv — Wed, 14 Dec 2005 01:58:00 GMT

Hi!

The Debugger team is having a Chat this Thursday (Dec 15) from 1:00 to 2:00 Pacific Time. If you have any problems with the debugger, this would be a great opportunity to ask questions and get live responses.

The Chat homepage is http://msdn.microsoft.com/chats/

Regards,

D.V.

Visual Studio 2003 stops downloading symbols from the Microsoft public symbol server

deeptanshuv — Tue, 11 Oct 2005 00:51:00 GMT

Hi!

Recently, downloading symbols for microsoft shipped binaries using the Microsoft symbol server (http://msdl.microsoft.com/download/symbols) broke for Visual Studio 2003 users. Microsoft has disabled downloading symbols using older versions of symsrv.dll for compatibility reasons.

To resolve this, you need to update the symsrv.dll on your machine with a newer version. Symsrv.dll is a component that is updated periodically, and the latest version can be obtained from the debugging tools for windows package at http://www.microsoft.com/whdc/devtools/debugging/default.mspx.

Simply replace your Visual Studio symsrv.dll (located next to devenv.exe) with the one from the debugging tools package, and everything should start working fine.

Regards,
D.V.

Source checksums and breakpoints

deeptanshuv — Sun, 24 Jul 2005 22:14:00 GMT

In VS 2003 & earlier breakpoints were bound based only on file name, so if the project system found another file with the same name we would bind the bp there. This was a source of a lot of annoyances since files like Class1.cs are everywhere, so in VS 2005 we have added support for source checksums in the compilers, and the debugger looks at these to verify a file.

If we find the correct file, your debugging experience goes exactly as earlier, but some customers have had problems working with sources out of sync with the binaries they are debugging (people may want to try this if the exactly matching sources are inaccessible for some reason).

If you start debugging with mismatching sources, you get a nice dialog informing you that the source is not matching, you can choose to continue to use it anyway. In this case, for the rest of the debugging session, you will not get prompted again, and if you set breakpoints in the file, they will bind.

If you already had set breakpoints before starting to debug, those bp's may not bind. In that case, you can right click on the breakpoint, click the "Location" menu item, and in the "File Breakpoint" dialog check the "Allow source code to be different from the original version" checkbox. Note that only file breakpoints are affected by checksums.

Alternately, you can turn off verifying checksums altogether from Tools->Options->Debugging->General->Require source files to exactly match the original version.

How to call C++ code from Managed, and vice versa (Interop)

deeptanshuv — Mon, 27 Jun 2005 00:39:00 GMT

Interop - calling native (C++) code from managed (C#, VB, J#, MC++) and vice versa - can be very useful if you are trying to extend your libraries without porting existing code. However, it can often be confusing for a newbie to figure out how to set this up.

There are several ways in which you could accomplish this.

(a) Using COM-Interop
(b) Using imports/pinvoke (explicit method calls)
(c) IJW and MC++ apps : MC++ & IJW apps can freely call back and forth to each other.
(d) Hosting. This is rare, but the CLR can be hosted by an unmanaged app which means that the runtime invokes a bunch of hosting callbacks.

Here is how (a) works:

For Native Exe->Managed Dll

(a)     define C# (VB, J#) class with a public interface, and build the file as dll
(b)     run regasm on the dll to create the tlb file
(c)     define C++ code which #imports the type library and creates the C# dll’s interface object using CoCreateInstance() and then calls methods through that.

For managed client->Native Dll

(a)     create C++ Dll
(b)     Create managed exe, add a reference to the Native COM Dll
(c)     Create the Com object and call the methods.

Here are code samples for the cases

Native Exe calling Managed Dll

Dll code is (filename CSDll.cs)

using System;
using System.Collections.Generic;
using System.Text;
namespace CSDll
{
using System;

    [System.Runtime.InteropServices.Guid("D4660088-308E-49fb-AB1A-77224F3FF851")]
    public interface IMyManagedInterface
    {
        int factorial(int arg);
    }

    /// <summary>
    ///    Summary description for Class1.
    /// </summary>
    [System.Runtime.InteropServices.Guid("46A951AC-C2D9-48e0-97BE-91F3C9E7B065")]
    public class Class1 : IMyManagedInterface
    {
        public Class1()
        {
        }

        public int factorial(int arg)
        {
            int result;

            if (arg == 1)
            {
                result = arg;
            }
            else
            {
                result = arg * factorial(arg - 1);
            }

return result;
}

}
}

Compile this with "csc /debug /t:library csdll.cs" to build a dll with symbol info.
Now run "regasm csdll.dll /tlb:csdll.tlb" to create the type library

C++ code is as (filename cppexe.cpp)

#include "windows.h"
#include <stdio.h>
#import "CSDll.tlb" named_guids

int main(int argc, char* argv[])
{
    HRESULT hRes = S_OK;
    CoInitialize(NULL);
    CSDll::IMyManagedInterface *pManagedInterface = NULL;

hRes = CoCreateInstance(CSDll::CLSID_Class1, NULL, CLSCTX_INPROC_SERVER,
CSDll::IID_IMyManagedInterface, reinterpret_cast<void**> (&pManagedInterface));

    if (S_OK == hRes)
    {
        long retVal =0;
        hRes = pManagedInterface->raw_factorial(4, &retVal);
        printf("The value returned by the dll is %ld\n",retVal);
        pManagedInterface->Release();
    }

CoUninitialize();
return 0;
}

Build this with "cl /Zi cppexe.cpp" -> when you run the exe it should print the value 24.

To debug this app, open the exe as a project in Visual Studio. Then go to project->properties->configuration prop->debugging and set debugger type to Mixed. Now when you debug, you should be able to step into the managed dll code from the calling C++ exe.

Managed Exe calling Native Dll

(a) Create an Atl COM Dll from wizard say Atl Dll
(b) Add an ATL Simple Object AtlObj
(c) Add a method to AtlObj say factorial(), you will need to add it to the .idl file to expose it from the COM object
(d) Create a C# console app
(e) project->right click->Add Reference
(f) In the add reference dialog, select the COM tab, find your COM component and add the reference to it
(g) You can now create the AtlObj object as of any other class and call its methods.

You can also accomplish this without using COM by simply using exports/imports.

Managed Exe calling Native Dll using import

(a) Create a Win32 Dll that exports symbols, you can do this from the wizard, just make sure the "export symbols" checkbox is checked.
(b) You need to put extern "C" {} around the definition & declaration of the exported function say fnWin32Dll()
(b) Now create your C# Exe, add using System.Runtime.InteropServices;
(c) add code

[[DllImport("Win32 Dll.dll")]
public static extern int fnWin32Dll(); ' this is the C++ function exposed by the dll

(d) Now you can just call the function in your code
int var = fnWin32Dll();

Note that your C# Exe needs to be able to find the Dll. You can copy the Dll next to the C# Exe and it will run just fine.

These are the most common ways of making cross-language calls, I will follow up later with explanations and examples of the other ways you can make these calls.