Santhosh Pillai

Extracting Text from PSD Files

MSDNArchive — Thu, 01 May 2008 02:42:00 GMT

Localizers often need to extract text from PSD (Photoshop) files, translate them, and put the text back in the PSD files in the appropriate places (layers). I haven’t personally seen anyone using a tool to do this. Is there any tool that can extract and...(read more)

Kinsoku, anyone?

MSDNArchive — Wed, 07 Nov 2007 06:16:00 GMT

I should admit that I am a little rusty as my last post was a while ago.

I am interested to find out what content providers do to avoid Japanese Kinsoku issues. This page has a lot of details, but apart from specifying line-break="strict", are there any other known solutions that the Japanese web sites employ to minimize the problem? Ideally, I would like to know if anyone is using ZERO WIDTH NO-BREAK SPACE (U+FEFF), ZERO WIDTH SPACE (U+200B), or WORD JOINER (U+2060) to work around this issue.

Media Center SDK Vista Beta 2

MSDNArchive — Wed, 14 Jun 2006 22:10:00 GMT

Media Center SDK for Windows Vista Beta 2 is now available here for download. The good news is that you do NOT have to be a beta participant to get the SDK now.

Install it, try it, and report any problems that you may have. You can leave a comment here, or report it via one of the channels below:

Media Center Sandbox
Sandbox Discussion Forum
Charlie Owen's blog
Aaron Stebner's blog

Indeo Codec & XP SP2

MSDNArchive — Thu, 18 Nov 2004 01:19:00 GMT

Do you have an AVI file encoded with Indeo codec that stopped displaying video when accessed from a share when your client is XP SP2? That's because XP SP2 blocked the content because of a security problem with the codec. If you should access the content from the share, your best bet would be to re-encode with a codec other than Indeo. Desperate times need desperate measures, so, contact Microsoft Developer Support if you can't live with any of the above solutions.

Account Protection, Baby!

MSDNArchive — Tue, 13 Jul 2004 19:21:00 GMT

So, here I am calling up my credit card company to have my address changed (well, I tried online, and failed to login for some reason). After changing the address, she goes: “do you want to add account protection to your card?”
Me: “Yes, most definitely.”
She: “That will be $12.50 per month charged on your card.”
Me: “Hold on, I want the account protection, and I feel that's something you should provide for your customers without charging them”.
She: “So, is it about the money? If you make money, can't you spend around 40 cents per day to protect it?”
Me: “Your bank's networth is in billions. Can't they spend 42 cents for me to protect my account as a nice gesture of me doing business with them?”
She: “I understand you don't want the protection then!”

Calling C++ Unmanaged Class from C#

MSDNArchive — Wed, 07 Jul 2004 23:59:00 GMT

This may be a no-brainer, but I thought I'd post it anyway.

If you have a C++ class in an unmanaged dll what is the best way to call it from C#?

1. You need to wrap the C++ class in a COM object or expose the class through dll exports. Managed code can call methods on COM object through COM Interop. And it can call dll exports through P/Invoke.

2. There is another way to do this using P/Invoke. Here is the sample code from the SDK.
The best way to do this is to write a thin wrapper in MC++ around your MFC classes and expose managed interfaces from it to your C# code. If you can use Whidbey, you could even compile your MC++ wrapper and rest of the C# code in same DLL using new linker.

// ClassMethods.cs
using System;
using System.Text;
using System.Runtime.InteropServices;
public class LibWrap
{
    /*
    class PINVOKELIB_API CTestClass
    {
        public:
            CTestClass( void );
            int DoSomething( int i );
        private:
            int m_member;
    };
    */
    [ DllImport( "..\\LIB\\PinvokeLib.dll",
    EntryPoint="?DoSomething@CTestClass@@QAEHH@Z",
    CallingConvention=CallingConvention.ThisCall )]
    public static extern int TestThisCalling( IntPtr ths, int i );
    // CTestClass* CreateTestClass();
    [DllImport( "..\\LIB\\PinvokeLib.dll" )]
    public static extern IntPtr CreateTestClass();
    // void DeleteTestClass( CTestClass* instance )
    [ DllImport( "..\\LIB\\PinvokeLib.dll" )]
    public static extern void DeleteTestClass( IntPtr instance );
}
public class App
{
    public static void Main()
    {
        IntPtr instancePtr = LibWrap.CreateTestClass();
        int res = LibWrap.TestThisCalling( instancePtr, 9 );
        Console.WriteLine( "\nResult: {0} \n", res );
        LibWrap.DeleteTestClass( instancePtr );
    }
}

P/Invoke: Should it be this hard?

MSDNArchive — Wed, 31 Mar 2004 23:31:00 GMT

Obviously, no!

We are trying everything we can to make it less painful for the developers. Most of the time, the hard question is whether or not the P/Invoke signature is accurate. Now that we have a sample that shows P/Invoke signature for methods declared in Windows.h, it's just a start.

You can also find a list of resources that provides assistance to developers encountering problems P/Invoke functionality at http://www.gotdotnet.com/team/clr/bcl/TechArticles/TechArticles/PInvokeHelp/FAQ.aspx. Please let us know your feedback.

Hard to Find a Technical Resource? Think About Microsoft Developer Support!

MSDNArchive — Sat, 27 Mar 2004 00:09:00 GMT

I often see questions like this in various forums:

We are about start the coding phase of our project. We would like to validate our architecture against someone with expertise in DCOM/Remoting/--Add your technology here--. We probably need a week or two of someone's time to provide a sanity check before we start our work. It is hard to find a resource, can you help?

You can open an advisory incident with Microsoft Developer Support to get help. Get the details at http://support.microsoft.com/default.aspx?pr=cntactms.

However if it is a quick question, please use the newsgroups.

DCOM: Is there a way to get the IP of the DCOM client from the DCOM server?

MSDNArchive — Mon, 01 Mar 2004 23:26:00 GMT

Another FAQ. Short answer: may be. Shorter answer: no. To be honest: no supported way.

CoQueryClientBlanket() will give "some information", such as the user name and domain name, but unfortunately, there is no way of obtaining the client machine name or IP address from a DCOM application. This is because there is no way to get RPC Binding Handle inside a DCOM server. If you have a RPC application then you have a RPC binding Handle and this will have information about the client.

If you look at Inside Distributed COM by Guy Eddon & Henry Eddon and/or Don Box's article in MSJ back in 98, they talk about the "unpublished and unsupported (by MS)" interface IChannelHook which can be used to obtain the Client address. Both client and server needs to Activate IChannelHook to its process. Microsoft does not recommend nor does it support the use of IChannelHook or any other unpublished interfaces/APIs.

Speaking of "unpublished and unsupported" API's, the web site http://members.tripod.com/IUnknwn gives an example of how to marshal an interface pointer to a stream, and then look at the OBJREF structure that is part of the marshaled interface pointer (as described in Chapter 12 of Inside Distributed COM by Guy Eddon and Henry Eddon). The OBJREF structure contains the client's STRINGBINDING when standard marshaling is used, which contains the client's IP address.

Post your Remoting questions in microsoft.public.dotnet.framework.remoting

MSDNArchive — Wed, 25 Feb 2004 00:56:00 GMT

As I look through the feedback for my post, I thought it may be a good idea that I propose this: feel free to post your Remoting related questions in microsoft.public.dotnet.framework.remoting newsgroup. The newsgroup is pretty active with some MS guys and a couple of MVPs regularly answering queries. It is easy to configure Outlook Express to read newsgroups. Details available at http://msdn.microsoft.com/newsgroups/

Error: The type is not supported because it implements IDictionary.

MSDNArchive — Tue, 24 Feb 2004 22:57:00 GMT

Ferris Beuller asked me in response to my previous post:

Why can the serializer not serialize types that implement IDictionary? SortedList in types cannot be serialized, you get an InvalidOperationException with the innerexception of {"The type System.Collections.SortedList is not supported because it implements IDictionary."}

The serializer should be able to serialize any type as long as it is marked serializable. SortedList is marked serializable. So, you should not be getting this error. I was able to run the following test without getting any errors.

using System;
using System.Collections;
using System.Runtime.Serialization.Formatters.Binary;
using System.IO;

namespace SerializeDict
{
    public class Test
    {
        public static void Main()
        {
            MemoryStream stream = new MemoryStream();
            BinaryFormatter bf = new BinaryFormatter();
            SortedList list = new SortedList();
            list.Add(10, 100);
            list.Add(100, 1000);
            bf.Serialize(stream, list);
            stream.Position = 0;
            bf = new BinaryFormatter();
            list = (SortedList)bf.Deserialize(stream);
            Console.WriteLine(list[100]);
        }
    }
}

Can you share a reproducible sample with me where you get the error?

So, What's the Deal with SerializationException in Remoting & TypeFilterLevel?

MSDNArchive — Tue, 24 Feb 2004 02:09:00 GMT

Applications that used to work well in Framework 1.0 give System.Runtime.Serialization.SerializationException when run under Framework 1.1. The exception has this format:

System.Runtime.Serialization.SerializationException: Because of security restrictions, the type (type name) cannot be accessed. ---> System.Security.SecurityException: Request failed.

This issue is documened at http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx#00000153 (Secure Serialization in .NET Remoting - Backwards Breaking Changes from version 1.0 to 1.1)

A level of security has been added to Serialization. Specifically, there are now two levels of serialization security: Low (Default) and Full.

Low Level Security:

• Remoting infrastructure objects. These are the types needed to make remoting work at a basic level.
• Primitive types, and reference and value types that are composed of primitive types.
• Reference and value types that are marked with the SerializableAttribute attribute but do not implement the ISerializable interface.
• System-provided types that implement ISerializable with a reduced permission set.
• Custom types that implement ISerializable.
• Types that implement the ILease interface.
• ObjRef objects used for activation (to support client-activated objects).

Full Level Security:

• ObjRef objects passed as parameters.
• Objects that implement the ISponsor interface.
• Objects that are inserted between the proxy and client pipeline by the IContributeEnvoySink interface.

In version 1.1 of the .Net Framework, a new security feature was added to the .Net Remoting infrastructure called Type Filtering. This feature, which is enabled by default, limits the type of objects that may be marshaled by a Remoting client to a Remoting server. Type Filtering effectively prohibits the server from deserializing instances of CLR types that may serve as vectors of attack. This feature is part of Microsoft’s commitment to be secure by default.

The following outlines several of the threats that are mitigated by use of this feature (we are not going to give out details about how to exploit these threats), specifically when typeFilterLevel is set to Low:

Exposing a Remoting server with a method or member that takes a delegate.
Threat: Delegates may be used to invoke methods on other types that have the same signature

Exposing a Remoting server with a method or member that takes a MarshalByRefObject type.
Threat: The serialized form of a MarshalByRefObject contains a mutable URL

Exposing a Remoting server with a method or member that takes an ISerializable type.
Threat: Deserialization of an ISerializable type causes the Remoting infrastructure to run the type’s code.

Exposing a Remoting server with a method or member that takes an type found in the GAC on the server machine in an assembly without APTCA
Threat: Types in the GAC are well known to anyone with the .Net Framework installed.

Exposing a Remoting server that enables remote clients to register sponsors
Threat: There is no limit on the number of sponsors that can be registered.

You can set this functionality programmatically or using the config file:

Programmatic Solution:

IDictionary props = new Hashtable();
props["typeFilterLevel"] = "Full";
BinaryServerFormatterSinkProvider formatterProvider = new BinaryServerFormatterSinkProvider(props, null);

Here's the VB.NET code (just in case!)

If you are in VS 2003:

Dim h_Table As IDictionary
h_Table = New Hashtable()
h_Table("port") = 52000
Dim obj_FormatProvider As New BinaryServerFormatterSinkProvider()
obj_FormatProvider.TypeFilterLevel = Runtime.Serialization.Formatters.TypeFilterLevel.Full
Dim chnl As New TcpChannel(h_Table, Nothing, obj_FormatProvider)
ChannelServices.RegisterChannel(chnl)

If you are in VS 2002:

Dim h_Table As IDictionary

h_Table = New Hashtable()
h_Table("port") = 52000
Dim h_Table2 As IDictionary
h_Table2 = New Hashtable()
h_Table2("typeFilterLevel") = "Full"
Dim obj_FormatProvider2 As New BinaryServerFormatterSinkProvider(h_Table2, Nothing)
Dim chnl2 As New TcpChannel(h_Table, Nothing, obj_FormatProvider2)
ChannelServices.RegisterChannel(chnl2)

Config File Solution:

To use a configuration file to set the serialization level, you must explicitly specify the typeFilterLevel attribute of the <formatter> element. Although this is typically done on the server side, you must also specify this attribute to control the serialization level for any channel on the client registered to listen for a callback. The following example sets the serialization level to Full for both the SoapFormatter and BinaryFormatter in this application domain.

See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconautomaticdeserializationinnetremoting.asp for more info.

Your feedback is welcome.

About Me: Santhosh Pillai

MSDNArchive — Tue, 24 Feb 2004 02:04:00 GMT

My Name is Santhosh Pillai. I am a Technical Lead in the Microsoft Developer Support Organization. Till recently I used to support OLE, COM, DCOM, .NET Remoting, and COM Interop technologies. I am moving to Multimedia support soon, but most of the posts I am planning to put here will be on the technologies I supported for the last 4 years: COM, DCOM, Remoting, and COM Interop.

You may have seen my postings in newsgroups like microsoft.public.win32.programmer.ole, microsoft.public.dotnet.framework.remoting, and microsoft.public.dotnet.framework.interop. If I failed to answer any of your queries there, it must be because I was really swamped.

Originally from India, now I live in Seattle with my wife Divya and my son Achu.