Thursday 18 March 2010
Exploiting ObjectFromLresult() to get the IHTMLDocument2 from a window handle
This is interesting as with just a window handle, it was relatively unknown on how that can be mapped to an object.
What you need to do is this:
1.) Register the windows message WM_HTML_GETOBJECT
2.) Send this message to the window handle we have in hand using a SendMessageTimeOut(). The out parameter in the lpdwResult returns you an UIntPtr to the object after the call.
3.) Next, use this out parameter as part of the ObjectFromLresult() call:
ObjectFromLresult(result from sendmessagetimeout, IHtmlDocument, 0)
4.) Cast the result from ObjectFromLresult() to IHTMLDocument2.
5.) Use the all property to get the HTML elements.
The powerfull function here definitely is the ObjectFromLResult() which effectively returns you an object that is 'accessible'. Accessible in terms of the user accessibility factor.
A framework worth checking out in this regard is the UIA framework that allows manipulating individual entities on the screen be it winforms, browser controls...
Wednesday 24 February 2010
Azure Computing Usage, Metering etc and how MS gets richer
Quickly calculate Azure ROI/TCO
Interested in quickly calculating the ROI/TCO for your application once it is deployed in Azure? Check out these two:
1.) http://www.microsoft.com/windowsazure/tco/
2.) http://neudesic.cloudapp.net/azureroi.aspx
View/Query tables/data in Azure Dev Storage
When deploying application on the development fabric, you would usually need to actually view the dev storage - say check out the tables, write a couple of SQLs against it etc. OOB, there isn’t any support in VS2010/tools from MS. Note that development fabric is different from the Azure Storage in the cloud. Development fabric, dev storage resides on your local machine.
A very good tool you could use to access the dev storage for free (in addition to the azure store if you are a registered user) is Cloud Storage Studio from Cerebrata. Check more here:
http://www.cerebrata.com/Products/CloudStorageStudio/Default.aspx
Do let know if you come across any more free/thin/sleek/nifty tool that works.
Friday 5 February 2010
Concurrency & .NET
With earlier versions of .NET, you had the Thread class, the BackgroundWorker class and highly recommended ThreadQueue class. (lets not worry about all the sync objects that came along). With multi-core machines all around, the possibilities in .NET 4.0 are endless :
a.) Parallel Extensions (PLINQ + TPL)
Integrating parallelism right into the framework design while expoiting the extension methods has made expressing concurrency easier. Had a loop that you wanted to execute in parallel? Just use the Parallel.For().
1 core? 2 core? n core? Not sure how to exploit them? Just use the framework provided by TPL (Task Parallel Library) - your applications would scale (not worrying about the internal design/syncs for the moment) based on the number of the cores. Nice. The best part is, C# language and the supporting framework structure appears to move towards the functional programming paradigm - wherein you are not worried about how to do the job but more about what to do. LINQ, TPL, Parallel-extensions etc seems to be inspired by this functional paradigm as in Haskell [my current interest area)] / F#.
Want to dig real deep with some great samples ? Check this out : http://code.msdn.microsoft.com/ParExtSamples
b.) Axum
A very interesting .NET programming language from the MS research yard to check out. A language built with concurrency as the primary design objective. You have 'agent's (think about a block of code being executed independently like threads) talking with each other through the 'channel's using the 'message's (think about the all sync-objects you used to get two threads to talk with each other, but easier). Very promising - you could write your core domain objects in C#, use them within Axum wherein you would ave laid out your concurrency logic.
Check out http://msdn.microsoft.com/en-us/devlabs/dd795202.aspx , http://en.wikipedia.org/wiki/Axum_(programming_language)
c.) DirectCompute
Would like the exploit the massive processing power of your GPU? Check out the DirectCompute library. A DirectX 11/10 based framework that lets you offload tasks onto the GPU - awesome. In similar lines, also check out Brahma framework written by my ex-collegue Ananth at http://brahma.ananthonline.net
Dont miss the DirectCompute session video (http://microsoftpdc.com/Sessions/P09-16) which also showed some cool applications. Was amazing to see the computationally intensive job being done by the GPU while the CPU stayed at ~0% utilization !
d.) Dryad
Yet another product from the MS research aresenal, Dryad appears to be more targetted at making writing distributed applications easier. Need to check this out in detail - once I find an HPC server to do the installation, then perhaps port DES to it?
Check it out further at http://research.microsoft.com/en-us/projects/dryad/
Saturday 31 October 2009
DES R2
Core enhancement - support for child tasks, concept of collection gate, design changes/refactoring etc
Thursday 18 June 2009
Making sense of Contravariance and Covariance in C# 2.0/4.0
Introduction
In simple words, covariance refers to the fact that you can use a type or one of its descendants when the specific type is expected. Say for the following class hierarchy: Doberman -> Dog -> Animal, where Animal is the root/super parent class. If you had a function
public static Dog ProcessDog(Dog myDog)
{
return new Dog();
}
In all versions of C#,
Dog returnDog = ProcessDog(new Dog()); // is valid
Dog returnDog = ProcessDog(new Doberman()); //is valid
Dog returnDog = ProcessDog(new Animal()); //is INVALID.
The above invalidity confirms the fact that all arguments in C# are covariant.
Similarly,
Dog returnDog = ProcessDog(new Dog()); // is valid
Object returnDog = ProcessDog(new Dog()); // is valid
Doberman returnDog = ProcessDog(new Dog()); // is INVALID.
confirms the fact that all return values are contravariant. As in , you cannot use a child type when the parent type is expected in case of return values. Effectively, every type that goes IN is covariant and everything that comes OUT is contravariant.
Covariance and Contravariance in Generics / C# 2.0 / C# 4.0
In C# 2.0, generic interfaces by themselves did not allow for covariance/contravariance. Say if I had
IEnumerable
IEnumerable
animals = dogs;//is INVALID
I cannot do a animals = dogs; though it make sense literally - arent dogs animals?!. Though note that you could still assign an instance of dog to a animal variable. Coming to C# 4.0, the above statement animals = dogs; works perfectly fine! Why? How?
To understand this, assume a case where IEnumerable allowed setting the value of an item. ASSUME, if you could do
IEnumerable
IEnumerable
animals = dogs;
animals[0] = cats[0]; //assume cat type to be descendant of animal type
Accessing dogs[0] would now result in an invalid typecast because you are now trying to cast a cat object as a dog!. Thankfully, IEnumerable does not let you set a value to an item, which makes IEnumerable a perfect candidate for covariance. To make sure animals=dogs statement work in C# 4.0, we need to make sure that IEnumerable does not allow for setting/accepting the generic type as a function argument or directly (which is what we did when we did animals[0] = cats[0]).
In our case, what we need to enforce on IEnumerable is to make sure IEnumerable does not have any function which can accept a instance of T (or its descendant). If we did allow, we are introducing the problem of allowing animals[0] = cats[0] OR allowing for animals.AddItem(cat) (declared perhaps as void AddItem(T item)). If we did not allow this, we can ensure that animals=dogs is valid. (which is what C# 4.0 did)
The idea is this : some generic interfaces do not allow inserting items into their list (like IEnumerable) by default. This makes sure that you cannot actually set a specific item of the list with a casted value. For this kind of generics interfaces, C# 4.0 introduces the concept of in, out keyword.
If you had an interface definition of the below kind:
interface Itest
{
T GetVal();
}
the new 'out' keyword makes sure that the type T is covariant. This effectively means that the type T is forced to be a covariant and cannot be used as an IN variable. Say if you tried to add a new method 'GetNewVal' to the above interface as :
void GetNewVal(T someParam);
The compiler would return an error saying T is covariant as T can be used to return a value ONLY.
Similarly, if you had an interface Itest2 as:
interface Itest2
{
void getval(T another);
}
the 'in' keyword makes sure that T is contravariant such that T can be used as an inbound entity (usually as an argument) only. Effectively, if you try to add a new method 'GetYetAnotherVal' as :
T GetYetAnotherVal(void);
the compiler would return an error.
Within C# 4.0, IEnumerable is declared as :
public interface IEnumerable
{
IEnumerator
}
Note the 'out' keyword indicating that no function within IEnumerable
References
1.) http://research.microsoft.com/en-us/um/people/akenn/generics/ECOOP06.pdf
Above paper also at http://research.microsoft.com/pubs/64042/ecoop06.pdf
2.) http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
Sunday 19 April 2009
Two events and a PG course
1.) Great Indian Developer Summit : Happening on days April 22, 23, 24 appears to be the place to be for any software engineer in the .NET/Web/Java streams. Look forward for talks on upcoming cutting edge technologies.
2.) Like to meet geeky innovators who have taken the turn with their startups ? This is the place to be on June 6th
3.) Would like to pick up an MS in Computer Science by attending a weekend programme ? Check out the 2 year MS Computer Science course for professionals conducted by Christ University.
Friday 17 April 2009
DES Uploaded to CodePlex
Check the homepage at http://des.codeplex.com/ for a brief summary of the project.
Tuesday 24 March 2009
Boxed & Secured Execution Of a .NET Type
One of the usual needs in an application developers world is to instantiate a .NET type in a boxed/contained/isolated environment with zero impact to the current application process space. How do we do that? This article solves this in an easy manner, adoptable easily.
Usual Solution
The immediate answer is to use an Application Domain - create new application domain and instantiate the type within the new domain. Sounds straight forward. Sadly nope. If you thought the following lines of code would just work, you are mistaken. To reconfirm that it does not work, try unloading the app domain and then deleting the loaded assembly from the windows explorer. It does not let you delete the assembly file. What happened here?
//create the application domain and create an instance of the object
AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
Object executionObject = clientDomain.CreateInstanceAndUnwrap("ABC.Test", "MyTest");
//find the Execute method and call it.
MethodInfo executionMethod = executionObject.GetType().GetMethod("Execute");
returnData = executionMethod.Invoke(executionObject, null);
As the type ABC.Test.MyTest was not a MarshalByRefObject descendant, the type instance gets loaded into the main application domain. Instead if the type ABC.Test.MyTest did descend from MarshalByRefObject, the type would have been instantiated in the 'remote' application domain. Thats the way it is designed.
Easy Way Out
Have a proxy type created in your application which descendants from MarshalByRefObject. Instantiate this object and call a proxy routine on this proxy object which then instantiates the real type. In this way, as the proxy type is already created in the new application domain, the real type too would be created in the new application domain.
AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
try
{
AssemblyLoader _aLoader = (AssemblyLoader)clientDomain.CreateInstanceAndUnwrap("XYZ.Test", "XYZ.Test.AssemblyLoader");
returnData = _aLoader.LoadAndRun("ABC.Test", "MyTest");
}
finally
{
AppDomain.Unload(clientDomain);
}
where AssemblyLoader is defined as an MBR descendant as :
[Serializable]
public class AssemblyLoader : MarshalByRefObject
{
public Object Execute(string assemblyName, string typeName)
{
Assembly _assembly = Assembly.Load(assemblyName);
Type _type =_assembly.GetType(typeName);
MethodInfo _method =_type.GetMethod("Execute");
return _method.Invoke(Activator.CreateInstance(_type), null);
}
}
Using this method, we have made sure that "MyTest" is always instantiated in the new application domain.
Impersonate for Security
All good until now, but how do you make sure the executed code executes under a user supplied account ? Pretty simple if you know how to authenticate a username/password/domain. Sadly, there is no direct way to perform a windows authentication in .NET. Not sure why there isnt a "bool WindowsPrincipal.Authenticate(userName, passWord,domain)" routine ? No clues. We could go the LogonUser route, but it appears it has certain permission issues in NT/2000 basedmachines. Hence, lets write one using the NegotiateStream
public static class SSPIHelper
{
enum AuthenticationState { Unknown, Success, Failure } ;
public static WindowsPrincipal LogonUser(NetworkCredential credential)
{
string userName, domain, password;
userName = credential.UserName;
domain = credential.Domain;
password = credential.Password;
TcpListener tcpListener = new TcpListener(IPAddress.Loopback, 0);
tcpListener.Start();
WindowsIdentity id = null;
AuthenticationState authState = AuthenticationState.Unknown;
IAsyncResult serverResult = tcpListener.BeginAcceptTcpClient(delegate(IAsyncResult asyncResult)
{
using (NegotiateStream serverSide = new NegotiateStream(
tcpListener.EndAcceptTcpClient(asyncResult).GetStream()))
{
try
{
serverSide.AuthenticateAsServer(CredentialCache.DefaultNetworkCredentials,
ProtectionLevel.None, TokenImpersonationLevel.Impersonation);
id = (WindowsIdentity)serverSide.RemoteIdentity;
authState = AuthenticationState.Success;
}
catch (Exception e)
{
authState = AuthenticationState.Failure;
}
}
}, null);
using (NegotiateStream clientSide = new NegotiateStream(new TcpClient("localhost",
((IPEndPoint)tcpListener.LocalEndpoint).Port).GetStream()))
{
try
{
clientSide.AuthenticateAsClient(new NetworkCredential(userName, password, domain),
"", ProtectionLevel.None, TokenImpersonationLevel.Impersonation);
authState = AuthenticationState.Success;
}
catch (Exception E)
{
authState = AuthenticationState.Failure;
}
}
while (authState == AuthenticationState.Unknown) ;
tcpListener.Stop();
if (authState == AuthenticationState.Success)
return new WindowsPrincipal(id);
else
return null;
}
}
Ok, we have a windows principal. Now what ? Impersonate to execute the code using this principal, which happens to be the easy bit.
WindowsIdentity newId = (WindowsIdentity)windowsPrincipal.Identity; //the one received from SSPIHelper
WindowsImpersonationContext impersonatedUser = newId.Impersonate();
This makes sure that the code following the above Impersonate() call uses the provided identity. Once we want to revert back to the original identity, just do a Undo() (see below)
So effectively what we now have is an isolated and safe execution of a type provided by the client using the credentials supplied by them. To summarize, the code should look similar to this:
//authenticate the client supplied credentials
WindowsPrincipal windowsPrincipal = SSPIHelper.LogonUser(credentials);
WindowsIdentity newId = (WindowsIdentity)windowsPrincipal.Identity;
//impersonate
WindowsImpersonationContext impersonatedUser = newId.Impersonate();
try
{
//create the application domain and create an instance of the object
AppDomain clientDomain = AppDomain.CreateDomain("ClientTaskDomain");
try
{
//use the proxy MBR object
AssemblyLoader _aLoader = (AssemblyLoader)clientDomain.CreateInstanceAndUnwrap("XYZ.Test", "XYZ.Test.AssemblyLoader");
returnData = _aLoader.LoadAndRun("ABC.Test", "MyTest");//call the client's method
}
finally
{
AppDomain.Unload(clientDomain);
}
}
finally
{
impersonatedUser.Undo();//back to the normal a/c
File.Delete(assemblySaveLocation);//just to clean up things, clean the client's assembly too.
}