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:
• RFC 5321 – Simple Mail Transfer Protocol
• RFC 2045 – Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response
• RFC 4616 – The PLAIN Simple Authentication and Security Layer (SASL) Mechanism

Relaying through Google Mail needs secure connection (SSL or TLS) plus plain text authentication of sender:

message = new ActiveXObject("AlaxInfo.EmailTools.Message");
message.ServerHost = "smtp.gmail.com";
//message.ServerPort = 587;
message.Sender = "Sender <foo+sender@gmail.com>";
message.ToRecipients = "Recipient <bar+receiver@gmail.com>";
//message.CcRecipients = "";
//message.BccRecipients = "";
message.Subject = "Message Test (TLS, Plain)";
message.Body = "This is an e-mail message test:" + "\r\n" +
  "" + "\r\n" +
  "- Security: TLS" + "\r\n" +
  "- Authentication: Plain Text (PLAIN)" + "\r\n" +
  "";
message.TransportLayerSecurity = true;
message.AuthMethods = "plain";
message.AuthName = "foo@gmail.com";
message.AuthPassword = "password";
message.Send();

Download Information

• Download (32-bit): EmailTools.dll
• Download (64-bit): EmailTools.dll
• License: This software is free to use

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?

On my system there was no such environment string, so expansion failed. There however was CommonProgramFiles, and it pointed to correct location. So, this hot fix makes it work right:

BOOL UpdateEnvironmentVariables()
{
    CString sCommonProgramFilesX86;
    sCommonProgramFilesX86.GetEnvironmentVariable(_T("CommonProgramFiles(x86)"));
    if(sCommonProgramFilesX86.IsEmpty())
    {
        CString sCommonProgramFiles;
        sCommonProgramFiles.GetEnvironmentVariable(_T("CommonProgramFiles"));
        if(!sCommonProgramFiles.IsEmpty())
        {
            ATLVERIFY(SetEnvironmentVariable(_T("CommonProgramFiles(x86)"), sCommonProgramFiles));
            return TRUE;
        }
    }
    return FALSE;
}

int _tmain(int argc, _TCHAR* argv[])
{
    ATLVERIFY(SUCCEEDED(CoInitialize(NULL)));
    {
        UpdateEnvironmentVariables();
        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;
} 

I am under impression that the problem is not specific to Windows 7. I remember similar symptoms on Windows XP system, but they were not critical and not investigated to solution. It rather seems that OLE DB component is registering itself using a reference to environment variable which is not present on a number of systems.

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.

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

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.

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.

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%'
		}
	}
}

See beginning in microsoft.public.win32.programmer.directx.video newsgroup.

This sample is demonstrating COM aggregation to embed an existing filter an re-expose it as a new filter having inner filter pre-initialized.

The Visual Studio C++.NET 2008 projects contains a DirectShow filter class that registers itself under Video Capture Sources category and embeds File Source (Async) Filter inside initialized to stream clock.avi file from Windows directory.

The code of interest is in Filter.h. CFilter class is the implementation of the DirectShow filter.

CFilter registers itself as a filter through static UpdateRegistry method, which overrides stock DECLARE_REGISTRY_RESOURCEID macro and adds IFilterMapper2 interface calls to register/unregister the filter.

To take an advantage of aggregating another object we need DECLARE_PROTECT_FINAL_CONSTRUCT macro to be able to instantiate inner (that is aggregated) object on the very start (we cannot do this right in constructor), DECLARE_GET_CONTROLLING_UNKNOWN macro to declare member menthod that exposes controlling unknown.

In a FinalConstruct method we instantiate aggregated object (note GetControllingUnknown() argument which indicates instantiating as aggregated):

ATLENSURE_SUCCEEDED(m_pInnerUnknown.CoCreateInstance(CLSID_AsyncReader, GetControllingUnknown()));

and initialize the object through IFileSourceFilter::Load. The inner object is ready and we are to expose its functionality as if implemented natively. We need to update object’s COM MAP for this:

BEGIN_COM_MAP(CFilter)
	COM_INTERFACE_ENTRY(IFilter)
	// NOTE: We still implement IDispatch through IFilter but we hide it to hopefully expose inner filter's IDispatch
	//COM_INTERFACE_ENTRY(IDispatch)
	// NOTE: We are hiding inner filter IFileSourceFilter to avoid GraphEdit prompts for file path on filter insertion
	COM_INTERFACE_ENTRY_NOINTERFACE(IFileSourceFilter)
	COM_INTERFACE_ENTRY_AGGREGATE_BLIND(m_pInnerUnknown)
END_COM_MAP()

COM_INTERFACE_ENTRY_AGGREGATE_BLIND will expose all inner object interfaces (except mentioned higher on the map) to the outside world. And we explicitly suppress IFileSourceFilter through COM_INTERFACE_ENTRY_NOINTERFACE to prevent GraphEdit from discovering it and popping up a file dialog to select a source file.

Source code: DirectShowWrapperSourceFilterSample.01.zip (note that Release build binary is included)