Fooling Around

In continuation of Nero API…

Windows IMAPI is much more convenient to use, it is built on COM, it is “more Windows” etc, however there was an issue even there.

Normally IEnumXXX::Next enumerator method accepts third parameter NULL since if we are getting items one by one, we are fine processing return code S_OK/S_FALSE and we don’t need extra parameter pceltFetched to get us number of fetched items. It is ok to pass NULL in most cases, not with IMAPI enumerators however - they require a valid pointer.

I have recently been working on CD/DVD burning feature and I was using Ahead Nero API as an option. Frankly, I was of a better opinion of this API. It is more or less well documented and C++ definitions looks fine, however…

The first problem was it failed to operate on a worker thread. My lord! I have to have burning task running on the application GUI STA thread using crappy poll-style abort callbacks. Anyway it did not work on a worker thread stumbling on a number of memory access violations. It was ludicrous that I already made everything look almost like in their sample application but API kept throwing exceptions. Until I realized it makes difference if it was running on a worker thread or not.

Anyway it keeps throwing int exceptions, and when under debugger and you stop on the exception, then chances are high that there will be anyway access violations later after burn is complete.

First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: dummy_exception @ 0×0013a688.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.
First-chance exception at 0×7c81eb33 in DVRRunDll.exe: Microsoft C++ exception: int @ 0×00139594.

Did you know that when you handle LVN_GETINFOTIP notification message and you are provided with NMLVGETINFOTIP structure, you cannot just supply your own pszText string for the tooltip text? Instead you have to copy your string into supplied buffer, such as using _tcsncpy function. Otherwise things would not work.

BEGIN_MSG_MAP_EX(CFooPropertyPage)
	CHAIN_MSG_MAP(CPropertyPageT)
	...
	MSG_LVN_GETINFOTIP(IDC_FOOLISTVIEW, OnFooListViewGetInfoTip)
	REFLECT_NOTIFICATIONS()
END_MSG_MAP()
...
LRESULT OnFooListViewGetInfoTip(NMLVGETINFOTIP* pHeader)
{
	ATLASSERT(!pHeader->lParam);
	CFoo* pFoo = m_FooListView.GetItemData(pHeader->iItem);
	CString& sTextBuffer = m_ModelListView.GetTextBufferString(TRUE);
	...
	sTextBuffer.TrimRight(_T("\t\n\r "));
	_tcsncpy(pHeader->pszText, sTextBuffer, pHeader->cchTextMax - 1);
	pHeader->pszText[pHeader->cchTextMax - 1] = 0;
	return 0;
}

SMTP Session:
...
Wed 2008-05-07 17:22:45: [1304:1] –> DATA
Wed 2008-05-07 17:22:45: [1304:1] <– 354 go ahead punk, make my day
Wed 2008-05-07 17:22:45: [1304:1] Sending <xxxxxxxxxxxxxxxxxx\pd35000088936.msg> to [64.202.166.12]
Wed 2008-05-07 17:22:45: [1304:1] Transfer Complete
Wed 2008-05-07 17:22:46: [1304:1] <– 554 The message was rejected because it contains prohibited virus or spam content
Wed 2008-05-07 17:22:46: [1304:1] –> QUIT

While there are documented Limitations of the FAT32 File System in Windows XP, I keep on stumbling on another one: maximal number of files per directory. Video archives are large and by design are kept in single directory. While NTFS is recommended, FAT32 is still used on a number of systems, more often on small scale ones, and the bad news is that FAT32 is often met on network-attached storage (NAS) devices, which are often of large capacity.

So, once we have 21844 (0×5554) files in the directory (it may appear though that the limit is dependent on FAT cluster size), an attempt to create new file will cause a lock inside API call boosting thread’s CPU consumption to 100%. An annoying issue to keep in mind.