COM/OLE question: Is this bad practice?

//////////////////////////////////////////////////////////////////////////// Thread procedure for running OLE drag and drop. We use a separate thread// because OLE's drag and drop feature requires a single-threaded COM// apartment, and we want our application to be able to use a multi-threaded// apartment.uint __stdcall ThreadProc(void *arguments){	// Applications that use drag and drop must call OleInitialize before calling any other function in the COM library. 	OleInitialize(NULL);	CDropTarget *target;	try	{		target = new CDropTarget();	}	catch (bad_alloc)	{		StatusLog_ReportOutOfMemory();		OleUninitialize();		_endthreadex(0);		return 0;	}	// The CoLockObjectExternal function prevents the reference count of an object	// from going to zero, thereby "locking" it into existence until the lock is	// released.	CoLockObjectExternal(target, TRUE, FALSE);	// Tell OLE that the window is a drop target.	HRESULT hResult = RegisterDragDrop(g_hMainWnd, target);	if (hResult != S_OK)		StatusLog_ReportWarning(L"Drag and Drop", L"Unable to register drag and drop (error code %d).", hResult);	// Each single-threaded apartment must have a message loop to handle calls from other	// processes and apartments within the same process. If we didn't have this message loop,	// we would hang other applications that are acting as drag-drop sources for us because	// their message could not get handled.	while (MsgWaitForMultipleObjects(1, &g_hEvtStopThread, FALSE, INFINITE, QS_ALLINPUT))	{		MSG msg;		if (GetMessage(&msg, NULL, NULL, NULL) <= 0)			break;		TranslateMessage(&msg);		DispatchMessage(&msg);	}	// Remove drag and drop from the window.	RevokeDragDrop(g_hMainWnd);	// Remove the strong lock.	CoLockObjectExternal(target, FALSE, TRUE);	// Release our own reference.	target->Release();	OleUninitialize();	// Calling end is not strictly necessary but according to MSDN is a good practice.	_endthreadex(0);	return 0;}