Взаимодействие экземпляров приложения — Архив WASM.RU

  Вспоминается одна смешная история. Во времена Word 6.0, работая как-то в одной солидной организации, трепетно относившейся к своим коммерческим тайнам, был приглашен возмущенным соседом по комнате к его компьютеру. На экране красовалось нечто вроде: "Вы не можете открыть этот очень конфиденциальный документ, так как его уже открыл пользователь имярек". Имяреком был назван начальник отдела эксплуатации, сидевший в другом конце здания. Параноидальное сознание сразу стало выстраивать сложную схему шпионажа через локальную сеть, который развернул этот самый начальник. Другая часть мозга, пользуясь невытесняющей многозадачностью, принялась прикидывать размер вознаграждения за его поимку. Короче, помчались разбираться. Через пять минут половина отдела эксплуатации во главе с недоумевающим начальником толклась около компьютера и выдвигала идеи. В итоге оказалось, что никакого шпионажа нет, а ...

  ... а во всем виноваты Word 6.0, невнимательный пользователь и пиратство. Пиратство виновато потому, что так тогда делали все. Word 6.0 инсталлировался с дискет, которые добрый начальник отдела эксплуатации по очереди раздавал всем желающим, так что под его именем рожала документы вся организация. Невнимательный пользователь виноват потому, что редактировал-редактировал документ в одном экземпляре Word'а, а потом взял, да и попытался открыть его из файл-менеджера еще раз. А Word виноват потому, что уж так он тогда обеспечивал взаимодействие нескольких экземпляров приложения (сейчас гораздо лучше).

Больше всех жалко начальника отдела эксплуатации, которому пришлось прилично понервничать. Пользователь-то, которому его заложил глупый Word, был сотрудником отдела безопасности!

  Многозадачность Windows, являясь безусловным благом, не подлежащим ныне обсуждению и сомнению, является вместе с тем источником многих вызовов, бросаемых программисту. Некоторые из них весьма изощренны и ответ на них требует глубокого понимания принципов организации рабочей среды.

Например, при разработке приложения MyCall пришлось столкнуться с такой проблемой. Как известно, Remote Access Service (RAS), работающий в асинхронном режиме, запускается в отдельном потоке (нити), отличном от основного потока приложения. Также не менее хорошо известно, что для контроля процесса установления соединения в RAS используется callback-функция (например, RasDialFunc), которую работающий RAS вызывает при необходимости сообщить приложению о своем состоянии. Так вот, если у программиста имеется потребность передать из RasDialFunc какое-либо пользовательское сообщение окну приложения, то он может побояться воспользоваться для этой цели функцией SendMessage, полагая, что два потока, одновременно запускающие одну и ту же оконную процедуру в одном контексте - это пролог к катастрофе. Между тем такое действие вполне допустимо и безопасно, так как умная Windows, прежде чем передать управление оконной процедуре, проверяет, в каком потоке создавалось соответствующее окно, и при необходимости переключает потоки. При этом передающий поток замораживается на время обработки сообщения принимающим потоком.

  Другие же проблемы многозадачности более тривиальны, даже рутинны. Одна из них встает всякий раз, когда программист начинает работу над новым проектом: что делать в случае попытки запуска приложения, если оно уже запущено?

  В самом деле. Сама по себе Windows не ограничивает возможности пользователя запускать какое-либо приложение любое разумное количество раз. Выполнив два двойных щелчка по одной и той же иконке, пользователь может получить два экземпляра одного и того же приложения, и каждый из них будет функционировать в собственном процессе и собственном контексте так, как будто другого не существует.

Правда, только до той поры, пока они не попытаются разделить между собой какой-нибудь ресурс (в широком смысле), который разделять невозможно или нельзя. Например, невозможно разделять коммуникационный порт. И нельзя разделять общий файл данных, если оба экземпляра приложения пишут в него противоречащие друг другу данные. Разнообразие возникающих в этом случае эффектов может порадовать самого взыскательного искателя развлечений.

  Принятие решения о том, как поступать со вторым и последующими экземплярами приложения, целиком возлагается на программиста. Можно придумать много разных вариантов стратегии поведения приложения, в зависимости от назначения приложения. Среди них такие:

1. Второй и последующие экземпляры приложения запускаются и функционируют самостоятельно, безотносительно к существованию друг друга
2. Запуск второго экземпляра (и, следовательно, всех последующих) запрещен, пока функционирует первый запущенный экземпляр
3. При попытке запуска второго экземпляра он не запускается, а в работе первого происходят некоторые изменения

Яркий пример третьей стратегии реализован в Word. Если экземпляр приложения уже запущен, и пользователь выполняет двойной щелчок по какому-нибудь файлу .doc в Проводнике, то запускаемый при этом второй экземпляр Word передает реквизиты загружаемого файла первому экземпляру и завершается, а первый экземпляр загружает файл в новое окно документа.

  С первой стратегией все просто. При запуске приложения ничего делать не надо - и тогда вы сможете наблюдать на экране столько экземпляров вашего приложения, сколько нужно, чтобы получить моральное удовлетворение. Главное - позаботиться, чтобы экземпляры приложения никогда не пытались разделять ресурсы, которые невозможно или нельзя разделять.

  Вторая стратегия несколько сложнее. Очевидно, для ее реализации необходимо, чтобы второй экземпляр приложения каким-то образом узнал о том, что существует первый экземпляр, и завершился, не успев принести какого-нибудь вреда. К сожалению, никакого специального средства для этого не существует.

Поговаривают, что не всегда все было так трагично. Во времена наших предков, когда "Докторская" стоила 2.20, а Билл был еще совсем бедным со своими двумя десятками гигабаксов, заработанных на DOSе, это делалось очень просто. В win16 имел смысл параметр hPrevInstance функции WinMain. Достаточно было убедиться, что он ненулевой - и приложение знало, что оно не одиноко на этом свете. Но когда разрабатывалась win32, кто-то из главных системщиков Microsoft лопухнулся, а потом, когда все всплыло, на специальном совещании было принято решение прикрыть провинившегося и объяснить все произошедшее какими-нибудь благообразными словами, вроде: "Мы так и хотели с самого начала, а hPrevInstance сохранили для совместимости снизу вверх." Так или иначе - но hPrevInstance теперь бесполезен. А следует пользоваться средствами межпроцессного взаимодействия (Interprocess Communications), которые, к чести Microsoft, реализованы в Windows великолепно.

  Способов дать знать второму экземпляру о существовании первого можно придумать много. Один из них прямо дается в MSDN в статье WinMain:

hPrevInstance
Identifies the previous instance of the application. For a Win32-based application, this parameter is always NULL. If you need to detect whether another instance already exists, create a named mutex using the CreateMutex function. If the GetLastError function returns ERROR_ALREADY_EXISTS, another instance of your application exists (it created the mutex).

Идентифицирует предыдущий экземпляр приложения. Для Win32-приложений этот параметр всегда равен NULL. Если вам необходимо определить, существует ли уже экземпляр приложения, создайте именованный объект mutex, используя функцию CreateMutex function. Если функция GetLastError вернет ERROR_ALREADY_EXISTS, другой экземпляр вашего приложения существует (так как он уже создал mutex).

  Вот этой самой идеей и воспользуемся, слегка модифицировав ее:

Код (Text):

1.  
2. .386
3. .Model flat,stdcall
4.  
5. ;///////////////////////////////////////////////////////////// windows.inc
6. OpenMutexA        PROTO :DWORD,:DWORD,:DWORD      ;прототипы функций API
7. CreateMutexA      PROTO :DWORD,:DWORD,:DWORD
8. ExitProcess       PROTO :DWORD
9.  
10. SYNCHRONIZE              =00100000h               ;константы типов доступа
11. STANDARD_RIGHTS_REQUIRED =000f0000h
12. MUTANT_QUERY_STATE       =0001h
13. MUTANT_ALL_ACCESS        =STANDARD_RIGHTS_REQUIRED OR SYNCHRONIZE
14.                           OR MUTANT_QUERY_STATE
15. MUTEX_ALL_ACCESS         =MUTANT_ALL_ACCESS
16.  
17. NULL                     =0                       ;разные константы
18. FALSE                    =0
19. TRUE                     =1
20.  
21. ;///////////////////////////////////////////////////////////// WinMain
22. EXIT_OK                    =0                              ;коды выхода
23. EXIT_ALREADY_EXIST         =1
24. .const
25.   check_inst_mutex_name    db "Check Instant Mutex 0001",0 ;имя mutex
26. .data?
27.   check_inst_mutex         dd ?                            ;дескриптор mutex
28. .code
29. ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::
30. WinMain PROC PUBLIC hinst,prev_hinst,command_line,cmd_show
31. ;................................................. проверка повторного запуска
32.  mov check_inst_mutex,0
33.  invoke OpenMutexA,MUTEX_ALL_ACCESS,FALSE,offset check_inst_mutex_name
34.  .if(!eax)    ;если mutex не существует - создать его и запустить приложение
35.   invoke CreateMutexA,NULL,TRUE,offset(check_inst_mutex_name)
36.   mov check_inst_mutex,eax
37.  .else        ;если mutex существует - прервать работу приложения
38.   invoke ExitProcess,EXIT_ALREADY_EXIST
39.  .endif
40. ;......................................................... тело приложения
41. ;...
42. ;...                      ;весь остальной текст приложения
43. ;...
44. ;......................................................... завершение работы
45.  .if(check_inst_mutex!=0)                     ;уничтожить объект mutex
46.   invoke ReleaseMutex,check_inst_mutex
47.  .endif
48.  invoke ExitProcess,EXIT_OK
49. WinMain ENDP
50. ;#############################################################
51. end
52.  

  Как видим, логика работы очень проста. Первым делом пытаемся открыть mutex с заданным именем.

Если вы - автор многих разных приложений, имейте в виду, что одинаковое имя mutex'а позволит запускаться только одному из этих приложений. Если ваше чувство юмора не столь развито, не забывайте модифицировать имя mutex'а в разных приложениях.

  Если mutex открыть не удается, значит запускаемый нами экземпляр приложения уникален, и мы смело можем продолжат его работу. Только перед этим создадим mutex, чтобы не дать запускаться последующим экземплярам.

  Ну и, конечно, при завершении работы приложения следует не забыть вызвать функцию ReleaseMutex.

В принципе, это не обязательно, так как если не освободить mutex с помощью этой функции, по завершении работы приложения он переводится в состояние WAIT_ABANDONED, которое в данном случае не мешает достижению стоящей перед нами задачи. Однако хороший стиль программирования предполагает явное освобождение занимаемых приложением ресурсов.

А вот Сергей AKA The Byte Reaper (http://neptunix.narod.ru) совершенно справедливо обратил наше внимане на то, что приведенный выше пример реализации второй стратегии сильно перегружен формальностями и реверансами в сторону MSDN. Полностью сохраняет ту же функциональность, но гораздо приятнее взору настоящего ассемблерщика предложенный Сергеем вот какой вариант:

Код (Text):

1.  
2. ;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
3. invoke CreateMutexA,NULL,0,offset(check_inst_mutex_name)
4. invoke GetLastError
5. .if(eax==ERROR_ALREADY_EXISTS)
6.   invoke ExitProcess,EXIT_ALREADY_EXIST
7. .endif
8. ;=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
9.  

Идея проста предельно. Если создаваемый mutex уже присутствует в системе, то функция GetLastError вовращает код ERROR_ALREADY_EXISTS. Кстати, функция CreateMutex возвращает при этом вполне валидный дескриптор существующего mutex'а, но нас это совершенно не должно интересовать. Мы просто заканчиваем работу приложения - и все.

  Третья стратегия существенно сложнее в реализации, а гамма возможных решений намного больше. Очевидно, ее основой должно быть не только взаимное оповещение экземплярами приложения о существовании друг друга, но и обмен между ними какой-то информацией. Все зависит от того, какой объем информации потребуется. Если это одно-два двойных слова, то может оказаться достаточным использовать систему сообщений. В других случаях имеет смысл, например, организовать разделяемую память посредством File Mapping.

  Пример реализации третьей стратегии, использующий только систему оконных сообщений, можно найти в приложении MyCall. Там используется регистрируемое глобальное сообщение, которое приложение передает в широковещательном режиме в надежде, что уже запущенный экземпляр ответит ему тем же сообщением. Если такой ответ получен, то делается вывод, что один экземпляр приложения уже запущен, и запускаемый экземпляр завершает работу. Но перед этим он извлекает из ответного сообщения дескриптор главного окна работающего экземпляра и выводит это окно на первый план, чтобы удовлетворить потребность пользователя в доступе к приложению.

  Здесь мы приведем версию, выполняющую ту же задачу, но несколько отличную в реализации. По сути, она является гибридом из описанной выше и примененной в MyCall: для определения факта повторного запуска приложения используется mutex, а для передачи дескриптора окна работающего приложения вновь запускаемому - глобальное сообщение.

  Это полностью работающее приложение. В его основу положен шаблон оконного приложения. Содержимое файла windows.inc не приводится (то, что он должен собой представлять, показано в предыдущем примере. Недостающие элементы следует добавить самостоятельно, по аналогии, пользуясь заголовочными файлами для C/C++).

Код (Text):

1.  
2. .386
3. .Model flat,stdcall
4.  
5. include windows.inc                     ;заголовочный файл API
6.  
7. ;///////////////////////////////////////////////////////////// WinMain
8. EXIT_OK                   =0            ;коды выхода
9. EXIT_ERROR                =1
10. EXIT_ALREADY_EXIST        =2
11.  
12. QUESTION_PRIME_HWND       =1            ;запрос идентификатора окна
13. ANSWER_PRIME_HWND         =2            ;ответ идентификатора окна
14.  
15. .data?
16.   win_class               WNDCLASSEXA{} ;структура класса главного окна
17.   main_window             dd ?          ;дескриптор главного окна
18.   check_inst_mutex        dd ?          ;дескриптор mutex'а
19.   second_instance         dd ?          ;признак второго экземпляра
20.   check_inst_message      dd ?          ;идентификатор регистрируемого сообщения
21.   loop_message            MSG{}         ;сообщение для цикла обработки
22. .const
23.   app_name                db "Single Instance Application",0
24.   class_name              db "Single Instance Application Class",0
25.   check_inst_mutex_name   db "Check Instant Mutex 0001",0
26.   check_inst_message_name db "Check Instant Message 0001",0
27. .code
28. ;:::::::::::::::::::::::::::::::::::::::::::::::::::::::::
29. WinMain PROC PUBLIC hinst,prev_hinst,command_line,cmd_show
30. ;................................ регистрация класса окна
31.   mov win_class.cbSize,sizeof(WNDCLASSEXA)
32.   mov win_class.style,CS_HREDRAW OR CS_VREDRAW
33.   mov win_class.lpfnWndProc,offset win_procedure
34.   mov win_class.cbClsExtra,0
35.   mov win_class.cbWndExtra,0
36.   invoke GetModuleHandleA,NULL
37.   mov win_class.hInstance,eax
38.   invoke LoadIconA,NULL,IDI_APPLICATION
39.   mov win_class.hIcon,eax
40.   mov win_class.hIconSm,eax
41.   invoke LoadCursorA,NULL,IDC_ARROW
42.   mov win_class.hCursor,NULL
43.   mov win_class.hbrBackground,COLOR_WINDOWFRAME
44.   mov win_class.lpszMenuName,NULL
45.   mov win_class.lpszClassName,offset class_name
46.   invoke RegisterClassExA,offset win_class
47.   .if(!eax)
48.     jmp abort
49.   .endif
50. ;....................... .......... создание окна
51.   invoke CreateWindowExA,NULL,\
52.                          offset class_name,\
53.                          offset app_name,\
54.                          WS_OVERLAPPEDWINDOW,\
55.                          100,100,300,200,\
56.                          NULL,\
57.                          NULL,\
58.                          win_class.hInstance,\
59.                          NULL
60.   .if(!eax)
61.     jmp abort
62.   .endif
63.   mov main_window,eax
64. ;................................. зарегистрировать глобальное сообщение
65.  mov check_inst_message,0
66.  invoke RegisterWindowMessageA,offset check_inst_message_name
67.  .if(eax)
68.   mov check_inst_message,eax
69.  .endif
70. ;.................................. проверить повторный запуск
71.  mov check_inst_mutex,0
72.  invoke OpenMutexA,MUTEX_ALL_ACCESS,FALSE,offset check_inst_mutex_name
73.  .if(!eax)
74.   mov second_instance,FALSE
75.   invoke CreateMutexA,NULL,TRUE,offset check_inst_mutex_name
76.   mov check_inst_mutex,eax
77.  .else
78.   mov second_instance,TRUE
79.   .if(check_inst_message)
80.    invoke SendMessageA,HWND_BROADCAST,check_inst_message,
81.                        QUESTION_PRIME_HWND,NULL
82.  
83.  .endif
84.   invoke ExitProcess,EXIT_ALREADY_EXIST
85.  .endif
86. ;.................................. вывод окна на экран
87.   invoke ShowWindow,main_window,SW_SHOW
88. ;................................... инициализация
89. ;здесь можно вставить все необходимые действия для первичной инициализации
90. ;приложения (например, загрузку и разбор файла настроек)
91. ;......................................... цикл опроса очереди сообщений
92. msg_loop:
93.   invoke GetMessageA,offset loop_message,NULL,0,0
94.   .if(!eax)                                         ;завершение работы
95.    .if(check_inst_mutex!=0)                           ;освободить mutex
96.     invoke ReleaseMutex,check_inst_mutex
97.    .endif
98.    invoke ExitProcess,loop_message.wParam
99.   .endif
100.   invoke TranslateMessage,offset loop_message
101.   invoke DispatchMessageA,offset loop_message
102.   jmp msg_loop
103. abort:
104.   invoke ExitProcess,EXIT_ERROR
105. WinMain ENDP
106.  
107. ;/////////////////////////////////////////////////////////// Оконная процедура
108. win_procedure PROC hwnd,message,w_param,l_param
109.   mov eax,message
110. ;................................. обработка регистрируемого сообщения
111.  .if(eax==check_inst_message)   ;если получено зарегистрированное сообщение
112.   .if(check_inst_message)
113.    .if(second_instance)            ;если это второй экземпляр
114.     .if(w_param==ANSWER_PRIME_HWND)    ;если в сообщении получен дескриптор окна
115.      invoke SetForegroundWindow,l_param    ;вывести это окно на первый план
116.      jmp worked
117.     .endif
118.    .else                              ;если это первый экземпляр
119.     .if(w_param==QUESTION_PRIME_HWND)   ;если запрашивается дескриптор окна
120.      mov eax,hwnd                        ;послать ему дескриптор главного окна
121.      .if(eax==main_window)
122.       invoke SendMessageA,HWND_BROADCAST,check_inst_message,
123.                           ANSWER_PRIME_HWND,main_window
124.       jmp worked
125.      .endif
126.     .endif
127.    .endif
128.   .endif
129.   jmp noworked
130. ;............................................ закрытие приложения
131.  .elseif(eax==WM_DESTROY)
132.   invoke PostQuitMessage,EXIT_OK
133.   jmp worked
134. ;............................................ обработка остальных сообщений
135. ; .elseif(message==...)
136. ;   ...
137. ; .elseif(message==...)
138. ;   ...
139. ; .elseif(message==...)
140. ;   ...
141. ;.............................. ............. сообщение не обработано
142.  .else
143. noworked:
144.   invoke DefWindowProcA,hwnd,message,w_param,l_param
145.   ret
146. ;............................................ сообщение обработано
147.  .endif
148. worked:
149.  xor eax,eax
150.  ret
151. win_procedure ENDP
152. ;#############################################################
153. end
154.  

  Общая идея такова:

• регистрируется класс главного окна и создается само окно с тем, чтобы вновь запускаемое приложение могло принимать и обрабатывать сообщения с помощью оконной процедуры win_procedure
• регистрируется глобальное сообщение, которое впоследствии должно использоваться для обмена информацией между экземплярами приложения
• выполняется проверка наличия уже работающего экземпляра приложения с помощью объекта mutex
• если уже работающий экземпляр приложения существует - ему посылается инициирующее сообщение с параметром QUESTION_PRIME_HWND. Поскольку дескриптор окна этого экземпляра неизвестен, сообщение посылается широковещательно (HWND_BROADCAST).
  • ответ от уже работающего экземпляра принимает оконная процедура приложения в виде такого же сообщения, но уже с параметром ANSWER_PRIME_HWND. При этом второй параметр сообщения представляет собой дескриптор окна работающего приложения.
  • запускаемый второй экземпляр приложения, пользуясь полученным дескриптором, выводит окно первого экземпляра на первый план с помощью функции SetForegroundWindow и завершает свою работу
• если запускаемый экземпляр приложения - первый и единственный, то он продолжает свою работу так, как задумал программист. При этом его оконная процедура всегда готова получить и обработать зарегистрированное сообщение с параметром QUESTION_PRIME_HWND, которое могут послать повторно запускаемые экземпляры. В ответ на такое сообщение работающий экземпляр отвечает таким же сообщением, но с параметром ANSWER_PRIME_HWND, передавая в качестве второго параметра дескриптор своего главного окна.

  См. также интересный, эффективный и простой вариант решения рассматриваемой задачи, предложенный Геннадием Майко. © Svet(R)off