Tag Archives: COM

COM Class to Send SMTP Email: x64, Attachments, HTML Content-Type

Posted by on April 28, 2012 No comments

Here go the updates on the COM library which offers easy to use COM interface to send emails, including over secure TLS and SSL channels:

  • x64 build
  • Attachments property to enable attchments to the message being sent
  • ContentType property to enable text/html bodies
  • subject non-English characters are correctly UTF-8 encoded
  • empty To, CC, BCC fields are discarded
  • recent properties are put onto persistence map: SecureSocketsLayer, TransportLayerSecurity, ContentType
message = new ActiveXObject("AlaxInfo.EmailTools.Message");
message.ServerHost = "smtp.gmail.com";

// ...
message.Body = "See attached."

attachment = message.Attachments.Add();
attachment.Type = "text/html";
attachment.Disposition = "attachment";
attachment.Name = "AutoBuildResults.html";
attachment.LoadFromFile("C:\\AutoBuildResults.html");

attachment = message.Attachments.Add();
attachment.Type = "image/jpeg";
//attachment.Disposition = "inline";
attachment.Name = "picture.jpg";
attachment.LoadFromFile("C:\\me.jpg");

// ...
message.Send();

Download Information

Utility Clearance: Simple SMTP Email Sender

Posted by on January 29, 2012 No comments

The library implements SMTP client and exposes a simple COM interface to send emails. The interface is simple and straightforward, and the emails can be send from various environments, including such as JavaScript code. The class supports SSL/TLS security and is GMail compliant.

A JScript code snippet below provides a sample use case:

message = new ActiveXObject("AlaxInfo.EmailTools.Message");
message.ServerHost = "mail.alax.info";
//message.ServerPort = 25;
message.Sender = "Sender <test@alax.info>";
message.ToRecipients = "Recipient <address@gmail.com>";
//message.CcRecipients = "";
//message.BccRecipients = "";
message.Subject = "Message Test (Plain)";
message.Body = "This is an e-mail message test:" + "\r\n" +
  "" + "\r\n" +
  "- Security: None" + "\r\n" +
  "- Authentication: Plain Text (PLAIN)" + "\r\n" +
  "";
message.AuthMethods = "plain";
message.AuthName = "test@alax.info";
message.AuthPassword = "12345678";
message.Send();

The capabilities include:

  • No additional dependencies – regsvr32 the DLL and it’s ready to use; SSL/TLS implementation through SChannel API
  • UTF-8 encoding and support for Unicode and international characters
  • Secure SSL connections (SecureSocketsLayer property)
  • Secure Transport Layer Security (TLS) connections with STARTTLS command (TransportLayerSecurity property)
  • Authentication options: plain text (LOGIN, PLAIN), digest (CRAM-MD5)
  • Protocol References:

Read more »

Microsoft.Jet.OLEDB.4.0 ProgID is not available (Windows 7 but probably not only)

Posted by on October 30, 2009 1 comment

It was a sort of ridiculous problem: an attempt to instantiate a Microsoft.Jet.OLEDB.4.0 object failed with error. Still some applications are still running without problems connecting to Jet databases, how comes?

There has been a number of posts on Internet, but none of the top ones appeared to be relevant.

The problem is reproduced extremely simple:

int _tmain(int argc, _TCHAR* argv[])
{
    ATLVERIFY(SUCCEEDED(CoInitialize(NULL)));
    {
        //CoLoadLibrary(L"C:\\Program Files (x86)\\Common Files\\System\\Ole DB\\oledb32.dll", TRUE);
        CComPtr<IDBInitialize> pDbInitialize;
        const HRESULT nResult = pDbInitialize.CoCreateInstance(L"Microsoft.Jet.OLEDB.4.0", NULL, CLSCTX_INPROC_SERVER);
        _tprintf(_T("nResult 0x%08x\n"), nResult);
    }
    CoUninitialize();
    return 0;
}

Oops, the code gives error REGDB_E_CLASSNOTREG 0×80040154 “Class not registered”. It looked like system was unable to locate one of the internally used DLLs – oledb32.dll, and if we help by uncommenting the line commented in the code snippet above, the error changes to ERROR_MOD_NOT_FOUND 0x8007007e “The specified module could not be found”.

The problem appears to be that one of the system components, which is involved, “Microsoft OLE DB Data Conversion Library” is registered with the system using a REG_EXPAND_SZ value, to be located using path “%CommonProgramFiles(x86)%\System\Ole DB\oledb32.dll”. It is obvious that CommonProgramFiles(x86) is placeholder to be expanded, but does the expansion succeed?

Read more »

DirectShow Filter Graph Spy on Vista

Posted by on June 22, 2009 No comments

I have been receiving comments that Filter Graph Spy tool does not work with Microsoft Vista operating system. I never had a moment to check until recently, and this time I realized that it really does not work. I am definitely aware of dramatic changes introduced with this operating system, and in particular UAC feature, virtualization and changes in security. No wonder this was the first guess that security was the cause, however the investigation showed there was a trail of issues underneath…

Investigation details deserve a separate post, while this one briefly outlines the issues and also accompany the repository update with a version compatible with Vista OS.

First of all, COM registration of the DLL (which definitely requires privilege elevation) succeeded on Vista. This means the registration procedure did not encounter any errors on the way, or poorly written code ignored the problem. It appeared that the source of the problem was CoTreatAsClass API, which failed to do the requested action, however returned status code indicating successful operation. This definitely looks like a bug and further comments on this particular behavior are expected to appear on Windows Applications Security MSDN forum, where I opened a topic on the matter.

With a COM TreatAs feature activated, the class’s behavior to instantiate instead of DirectShow’s CLSID_FilterGraph is restored, and in particular the DLL generates FilterGraphSpy.log log file on filter graph activity. Note that log file location is OS dependent (due to Vista’s permissions and file system virtualization):

  • pre-Vista OS: root of syste drive, typically C:\
  • starting Vista, administrator with elevated privileges: CSIDL_COMMON_APPDATA, typically C:\ProgramData (note this directory is hidden by deafult)
  • starting Vista, without elevated administrator privileges: CSIDL_LOCAL_APPDATA, typically C:\Users\$(UserName)\AppData\Local (note that AppData directory is hidden by deafult)

Still even with the log file generated and indicating activation of the spy, it was unable to connect to remote graph through the running object table (ROT). It appeared that the ROT entires are there where expected, it was OK to get an object from ROT and the problem came from QueryInterface code:

CComPtr<IUnknown> pFilterGraphUnknown;
ATLENSURE_SUCCEEDED(pRunningObjectTable->GetObject(pMoniker, &pFilterGraphUnknown));
CComQIPtr<IMyFilterGraph> pFilterGraph = pFilterGraphUnknown; // E_NOINTERFACE

The call reached the original object but COM subsystem was unable to marshal the interface through apartments to enable interprocess communication on it. The reason for this is absence of PSFactoryBuffer class (CLSID {92A3A302-DA7C-4A1F-BA7E-1802BB5D2D02}), which provides proxy/stub pairs for marshaling well known DirectShow interfaces in the Vista’s version of quartz.dll. As mentioned by Microsoft’s Mike Wasson, this class was moved from quartz.dll into Vista SDK’s proppage.dll, so in order to obtain connectivity to remote DirectShow graphs starting Vista, one needs to install this DLL with Windows SDK, or otherwise have it registered with the operating system.

Also note that DirectShow-enabled applications that have their filter graphs published on ROT will need an utility application such as GraphEdit started with the same permissions (elevated or not) in order to be able to access ROT entires.

To sum everything up, to install Alax.Info DirectShow Filter Graph Spy on Vista:

  • get the latest FilterGraphSpy.dll
  • regsvr32 FilterGraphSpy.dll on target system from administrative command prompt, with elevated privileges (note you should have a log file FilterGraphSpy.log generated in CSIDL_COMMON_APPDATA directory, with a few lines indicating registration success)
  • get Windows SDK and make $(WindowsSDK)\Bin\proppage.dll file registered on target system (also administrative regsvr32), note that it is necessary to restart DirectShow-enabled applications and GraphEdit after DLL registration to get graphs visible through ROT
  • mind the log file directories with FilterGraphSpy.log file

A partial Visual C++ .NET 2008 source code is available from SVN, release binary included.

RegisterTypeLibrary to register type libraries the way regsvr32 registers COM servers

Posted by on January 5, 2009 No comments

While regsvr32 tool is used to register COM servers, such as .DLL, .OCX, .AX files, sometimes you need an equivalent for type library files, such as .TLB, for example to automate software registration on a host. There has been no stock utility for this that I am aware of, so I have been using my own one (RegisterTypeLibrary):

C:\Program Files\Alax.Info\Media Tools>RegisterTypeLibrary.exe Acquisition.dll
Type Library Information:
  File Path: Acquisition.dll
  File Full Path: C:\Program Files\Alax.Info\Media Tools\Acquisition.dll
  Name: AlaxInfoMediaToolsAcquisition
  Documentation String: Alax.Info Media Tools Acquisition 1.0 Type Library
  GUID: {4C03D3C8-13AD-451F-9363-FAD08EF94A91}
  LCID: 0
  Platform: 1
  Version: 1.0
  Flags: 0x8

Registering...
Registered.

/U unregisters, /Q displays information about type library (may be useful as it also works for .DLL files where type library is embedded into binary).

A Visual C++ .NET 2008 source code is available from SVN, release binary included.

Private DMO

Posted by on October 25, 2008 No comments

Started as Is it possible to use local component in DLL? on microsoft.public.vc.atl newsgroup. The question is to embed a custom DirectX Media Object (DMO) into executable so that it is only available to proprietary application and not to entire system and could be reused in other applications. If in particular this DMO should be available to intelligent connect, e.g. used by embedded Windows Media Player control, the solution requires that private DMO appears fully registered as full featured regular DMO.

A while ago I proposed a solution on getting COM Class/DMO embedded into executable and temporarily exposed as availble without registry registration through CoRegisterClassObject/RegisterClassObject, however in addition to COM class registration, a DMO needs to also be specifically listed as a DMO, through DMORegister API.

In order to expose private DMO to DirectShow subsystem the following steps has to be performed:

  • register COM class object as a COM class (CoRegisterClassObject) to enable its instantiation by its CLSID
  • use DMORegister API to list DMO in global list (warning, seems to be requiring write permission on HKEY_CLASSES_ROOT key)
  • have the filter graph of interest created
  • use DMOUnregister API as early as possible to unlist private DMO from global list
ATLENSURE_SUCCEEDED(__objMap_CPrivateMediaObject.RegisterClassObject(CLSCTX_INPROC_SERVER, REGCLS_MULTI_SEPARATE));
DMO_PARTIAL_MEDIATYPE pInputMediaTypes[] = { { MEDIATYPE_Video, CPrivateMediaObject::GetXxxxSubtype() } };
ATLENSURE_SUCCEEDED(DMORegister(L"Private DMO", CLSID_PrivateMediaObject, DMOCATEGORY_VIDEO_DECODER, 0, _countof(pInputMediaTypes), pInputMediaTypes, 0, NULL));
...
ATLVERIFY(SUCCEEDED(DMOUnregister(CLSID_PrivateMediaObject, DMOCATEGORY_VIDEO_DECODER)));

The sample code/project takes an .AVI file which is a XVID video file with a FOURCC compression code changed from XVID to XXXX. The file is unplayable but there is a private DMO which accepts XXXX video and copies data as is into XVID format on its output.

A Visual C++ .NET 2008 source code is available from SVN.

ATL Registration Script

Posted by on September 6, 2008 No comments

Since ATL version 3, and actually it probably existed even since even earlier time, I have seen Microsoft Visual Studio (and its predecessor Visual C++) generating .RGS registration script with hardcoded CLSID value, ProgID values and other strings entered through IDE wizard. While it seems to work nice at the moment of generation, it still gives the problem to lose sync between identifiers if code is copied between projects or a different way. It might be an oversight originally, but was not it the obvious thing to do later to avoid possible typos of inaccurate user? Microsoft Visua Studio 2008 still generates the same code.

Previous versions of development environment offered attributed code option which in fact took care of this problem very well. Although there has been a lot of negative feedback written about C++ attributes, this was a kind of problem attributes left no chances to break: CLSID was specified once only in C++ COM class attribute and the rest of the deal was generated automatically, including IDL and registration sequence.

It is especially unclear why it was left this way because internal ATL classes already have all necessary capabilities to process wildcards. For example, default .RGS script contains an entry for COM class type library, HKCR\CLSID\{…} key, “TypeLib” value. Why would hardcode it if it can be specified through a replacement:

HKCR
{
	NoRemove CLSID
	{
		ForceRemove %CLSID% = s '...'
		{
			'TypeLib' = s '%LIBID%'

And the replacement is so easily added overriding CAtlModule’s virtual AddCommonRGSReplacements:

class CFooModule :
	public CAtlDllModuleT<CFooModule>
{
...
// CAtlModule
	HRESULT AddCommonRGSReplacements(IRegistrarBase* pRegistrar) throw()
	{
		_ATLTRY
		{
			ATLENSURE_SUCCEEDED(__super::AddCommonRGSReplacements(pRegistrar));
			ATLASSERT(!IsEqualGUID(m_libid, GUID_NULL));
			ATLENSURE_SUCCEEDED(pRegistrar->AddReplacement(L"LIBID", StringFromIdentifier(m_libid)));
		}
		_ATLCATCH(Exception)
		{
			return Exception;
		}
		return S_OK;
	}

I thought it would be implemented natively in ATL long ago, along with per-coclass replacements like %CLSID%.

This is how I like my registration script:

HKCR
{
	%PROGID% = s '%DESCRIPTION%'
	{
		CLSID = s '%CLSID%'
	}
	%VIPROGID% = s '%DESCRIPTION%'
	{
		CLSID = s '%CLSID%'
		CurVer = s '%PROGID%'
	}
	NoRemove CLSID
	{
		ForceRemove %CLSID% = s '%DESCRIPTION%'
		{
			ProgID = s '%PROGID%'
			VersionIndependentProgID = s '%VIPROGID%'
			ForceRemove 'Programmable'
			InprocServer32 = s '%MODULE%'
			{
				val ThreadingModel = s 'Both'
			}
			TypeLib = s '%LIBID%'
		}
	}
}