Получив три только что описанные API-функции, легко создать серверный процесс, экспортирующий один или более классов. Ниже приводится простая программа, которая экспортирует три класса из МТА сервера:
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) {
// define a singleton class object for each class
// определяем синглетон для каждого класса
static GorillaClass s_gorillaClass; static OrangutanClass s_orangutanClass;
static ChimpClass s_chimpClass; DWORD rgdwReg[3];
const DWORD dwRegCls = REGCLS_MULTIPLEUSE | REGCLS_SUSPENDED;
const DWORD dwClsCtx = CLSCTX_LOCAL_SERVER;
// enter the MTA
// входим в МТА
HRESULT hr = GoInitializeEx(0, COINIT_MULTITHREADED);
assert(SUCCEEDED(hr));
// register class objects with СОM library's class table
// регистрируем объекты класса с помощью
// таблицы класса библиотеки COM
hr = CoRegisterClassObject(CLSID_Gorilla, &s_gorillaClass, dwClsCtx, dwRegCls, rgdwReg);
assert(SUCCEEDED(hr));
hr = CoRegisterClassObject(CLSID_Orangutan, &s_orangutanClass, dwClsCtx, dwRegCls, rgdwReg + 1);
assert(SUCCEEDED(hr)) ;
hr = CoRegisterClassObject(CLSID_Chimp, &s_chimpClass, dwClsCtx, dwRegCls, rgdwReg + 2);
assert(SUCCEEDED(hr));
// notify the SCM
// извещаем SCM
hr = CoResumeClassObjects();
assert(SUCCEEDED(hr));
// keep process alive until event is signaled
// сохраняем процессу жизнь, пока событие не наступило
extern HANDLE g_heventShutdown; WaitForSingleObject(g_heventShutdown, INFINITE);
// remove entries from COM library's class table
// удаляем элементы из таблицы класса библиотеки COM
for (int n = 0; n < 3; n++)
CoRevokeClassObject(rgdwReg[n]);
// leave the MTA
// покидаем MTA CoUninitialize();
return 0;
}
В данном фрагменте кода предполагается, что событие (Win32 Event object) будет инициализировано где-нибудь еще внутри процесса таким образом:
HANDLE g_heventShutdown = CreateEvent(0, TRUE, FALSE, 0);
Имея данное событие, сервер может быть мирно остановлен с помощью вызова API-функции
SetEvent(g_heventShutdown);
которая запустит последовательность выключения в главном потоке. Если бы сервер был реализован как сервер на основе STA, то главный поток должен был бы вместо ожидания события Win32 Event запустить конвейер обработки оконных сообщений (
Снова о времени жизни сервера
В примере, показанном в предыдущем разделе, не было точно показано, как и когда должен прекратить работу серверный процесс. В общем случае серверный процесс сам контролирует свое время жизни и может прекратить работу в любой выбранный им момент. Хотя для серверного процесса и допустимо неограниченное время работы, большинство из них предпочитают выключаться, когда не осталось неосвобожденных ссылок на их объекты или объекты класса. Это аналогично стратегии, используемой большинством внутрипроцессных серверов в их реализации
// reasons to remain loaded
// причины оставаться загруженными
LONG g_cLocks = 0;
// called from AddRef + IClassFactory::LockServer(TRUE)
// вызвано из AddRef + IClassFactory::LockServer(TRUE)
void LockModule(void) {
InterlockedIncrement(&g_cLocks);
}
// called from Release + IClassFactory::LockServer(FALSE)
// вызвано из Release + IClassFactory::LockServer(FALSE)
void UnlockModule(void) {
InterlockedDecrement(&g_cLocks);
}
Это сделало реализацию
STDAPI DllCanUnloadNow() { return g_cLocks ? S_FALSE : S_OK; }
Подпрограмму
Имеются некоторые различия в том, как ЕХЕ-серверы прекращают работу серверов. Во-первых, обязанностью серверного процесса является упреждающее инициирование процесса своего выключения. В отличие от внутрипроцессных серверов, здесь не существует «сборщика мусора», который запросил бы внепроцессный сервер, желает ли он прекратить работу. Вместо этого серверный процесс должен в подходящий момент явно запустить процесс своего выключения. Если для выключения сервера используется событие Win32 Event, то процесс должен вызвать API-функцию
void UnlockModule(void) {