Moving to a new Blog Site!!

Hi - I am moving to a new Blog site, so i'll be blogging there now! View my new Blog

Cryptanalysis of SHA-1

Read Cryptanalysis of SHA-1 by Bruce Schneier.

WaitForSingleObject(Handle, Timeout)

Recently I was working on a problem where I had to create new process on a click of a button. With this, I needed some callback or signal when this new process terminates. This new process was launched on a new thread. I looked into the Thread Class but there was no out of box functionality to achieve this. So I end up writing this code.

Here is the PInvoke Declaration

[DllImport("Kernel32.dll", CharSet=CharSet.Unicode,SetLastError=true)]
static extern uint WaitForSingleObject(
IntPtr HANDLE,
uint Timeout);

Creating a new Thread to start our process…

newThread = new Thread(new ThreadStart(StartNewApplication));
newThread.Name = "ClientApplication";
newThread.Start();

private void StartNewApplication()
{
//Declarations...
const uint INFINITE = 0xFFFFFFFF;
uint returnValue;
int error;

//Creating a new process
Process pr = new Process();
pr.StartInfo.FileName="RemotingServer.exe";
pr.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
pr.Start();


//Using WaitForSingleObject to wait till the threads give a
//signal. As we want to get signaled when the thread gets
//terminated, we set timeout time as "Infinite".
IntPtr HANDLE = pr.Handle;
returnValue = WaitForSingleObject(HANDLE,INFINITE);
if (returnValue == 0xFFFFFFFF)
{
//Getting error code...
error = Marshal.GetLastWin32Error();
}
else
{
//Code which we want to execute after the thread has been terminated
}
}

.NET Framework Resource Management

This white paper discusses details of resource management in components written for the Common Language Runtime (CLR). Click here to view.

CLR and its relationship to MemToLeave

Larry Chesnut talks about "CLR and its relationship to MemToLeave" in Yukon.

GAC Structure

Everyone knows now that GAC physically have directories for each version of assembly. Now what happens when Whidbey Beta 1 is released as it supports both 32 bit platform and 64 bit platform. So if we have directory for each assemblies, there can be problem because both assemblies for 32 bit and 64 bit will have same assemblies unless Microsoft make them with different versions. This obviously is not the right way. We make an application on 32 bit platform using some assembly and then when we want to port it to 64 bit platform; we need to use assemblies with different version. Its not an easy and friendly way.

Before Whidbey, we had only one directory “GAC” which further had directories named after assemblies and they further had directories with respect to version. It was something like this “WinDir”\assembly\GAC\“AssemblyName”\ “VersionNumber”__“PublicKeyToken”. So what Microsoft has done is they have reorganised the directory structure a bit. They have new directories named “GAC_32” for 32 bit and something similar for 64 bit in future like “GAC_64”. This structure can be viewed by disabling the Cache Viewer. To do this, go to registry editor, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion and change value for "DisableCacheViewer" to 1. If its not present, then create a DWORD value for it and set its value to 1. Now open explorer and see "WinDir"\assembly folder. You'll be able to see the physical structure of GAC.

Now after we install framework 2.0 Beta 1, we have 3 GACs in all. One is for “specific to 32 bit system” which is “GAC_32”, one for portal assemblies “GAC_MSIL” and the last one is for v1.0 and v1.1 called “GAC”.

Also, when we see the assembly folder in explorer, we see another column which tells us about the process architecture. It shows “MSIL” or “x86” or nothing. MSIL is for Portable Assemblies, x86 ones are 32 bit platform specific and the ones which don’t have anything are v1.0 or v.1.1 assemblies.

Note: The above implementation is for Framework 2.0 Beta 1. It might change in future releases.

.NET Memory Management and GC Myths

Just came across this series of post by Paul Wilson on .NET Memory Management and GC Myths. He talks about how to handle large objects and how .NET Framework internally manages memory when Object.Dispose() is called. Beside the post, the comments section is also good where they had good discussion on some points.

• .NET Memory Management and Garbage Collection
• .NET GC Myth #1 - Set Object to Null
• .NET GC Myth #2 - The GC Frees Memory
• .NET GC Best Practice - ALWAYS Call Dispose
• .NET GC is Excellent - Better Than Java