[Bah]

Всем доброго времени суток.
Задача - завершить выполнение программы под Win95. Знаю имя ехе-файла. Он постоянно читает данные из COM-порта и пишет их в файл на диске. Необходимо получить доступ к этому файлу (переместить его в другое место). Как в Win95 можно завершить выполнение этой программы?
Помогите пожалуйста, только с комментами плз, я начинающий...

Можно воспользоваться чем либо кроме API? По этому вопросу нашел материал в Win32 SDK, но там всё так сложно для понимания, что не вижу иного выхода как только обратиться за помощью к Вам...

Есть возможность убить процесс в Win3.11?

Отредактировано: Bah в сегодня, 13:06

[Bah]

C горя начал читать "Рихтер Дж. - Windows для профессионалов. Создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows". Блин, очень интересная книга, но сколько я время затрачу на свою задачу.... Помогите, плиз!!!
Кстати, эту книгу порекомендую и профи и начинающим. После её прочтения устройство Винды становиться горазда понятнее

[Алладин]

Честно не понимаю задачи((( Как снять процесс? А что диспечер задач не помогает? Он по ctrl+alt+del вызывается. Если не помогает есть другие утилиты для этого. Надо в инете смотреть.

[Bah]

Спасибо за оказанное внимание...
ctrl+alt+del конечно мощная штука, но по ряду причин мне не подходит. Задачу надо реализовать программно. Объясню суть.
Существует ехе-файл (назовем его nnn.exe), который считывает данные из СОМ-порта и записывает их в файл на диске. Раз в сутки (скорее всего в 00.00 часов) необходимо забирать этот файл. Если вышеупомянутый nnn.exe не обнаруживает файл он создает его заново. Программно переместить этот файл не получиться, т.к. он занят занят nnn.exe. Каждую ночь приходить на работу и выполнять операцию ctrl+alt+del что-то в лом
Как реализовать программное закрытие nnn.exe?
Реализовать надо на WIN3.11 или WIN95 ... Помогите!!!

[Boroda]

В общем случае, "чисто" это сделать невозможно.
Невозможно, потому что принудительно завершать приложения нельзя, так как для чистого завершения работы ему может понадобиться выполнитиь кучу специфических действий (закрыть сокеты, деинициализировать D3D, отчитаться в логах, удалить временные файлы итп), и только ему известно, какие именно. Поэтому ему можно только предложить завершить работу, а не заставить. И при этом приложение имеет полное право отказаться без объяснения причин.
А "чисто" - потому что "нечисто" можно всё. Просто скажи ему TerminateProcess(), и у него нет шансов. Однако, это крайний случай. К применению всячески не рекомендуется.
Это была философия. Чтобы прояснить природу сложностей, с которыми ты столкнулся. Для конкретного ответа мало информации. Вот несколько вопросов:
1. имеет ли это приложение окно, лучше всего "главное окно"?
2. имеет ли оно пользовательский интерфейс вообще, консольный или гуйный?
3. нельзя ли просто открыть файл в режиме "только чтение" и потихонечку его покопировать с запоминанием текущего размера, чтоб в следующий раз инкрементильно вычитать только новые данные или же оно держит файл монопольно? (в этом случае не надо перемещать файл и тем более выгружать приложение)?
4. нельзя ли другими способами форсировать его выгрузку, например, вдудолив в COM магическую комбинацию байтов, из-за чего оно скажет stack overflow и само снимется?
Пока хватит. Думаю, ещё поговорим.

[Bah]

1. Окно имеется
2. Интерфейс: "свернуть", "развернуть", "закрыть"
3. В режиме "только чтение" открывать файл не подходит: надо чтобы он создавался заново т.к. при создании екзешник записывает в него нужную заголовочную информацию.
4. !!!do not understand!!!

Про СОМ можно поподробнее? И про магическую комбинацию байтов тоже...

[Boroda]

4. Ну, про COM это я утрировано... Я имел ввиду, нельзя ли извне повлиять на окружение приложения, чтобы оно само "чисто ушло".
1. Раз есть окно, то проще всего послать ему WM_CLOSE. Если при этом начнуться дополнительные вопросы по типу "Вы уверены? OK/Cancel", то и на них поотвечать как-нибудь SendMessage(hDlg, WM_COMMAND, IDOK, 0). Таким образом, програмно имитируются действия пользователя.
2. Если не прокатит, можно попробовать спуститься на более низкий уровень - SendInput(), keybd_event() и mouse_event().
3. тады отпадает.

[Bah]

Спасибо за оказанное внимание!


[/CODE]
#include <vcl.h>
#pragma hdrstop
#include <windows.h>
#include <tlhelp32.h>
#include <dstring.h>
#include "Unit1.h"
//-------------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//-------------------------------------------------------------------------------
//по имени ехе узнаем пид процесса
DWORD GetProcessByExeName(AnsiString ExeN)
{
DWORD id;
HANDLE hProcessSnap = NULL;
PROCESSENTRY32 pe32 = {0};
AnsiString temp="";
hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPALL, NULL);
pe32.dwSize=sizeof(PROCESSENTRY32);
if(Process32First(hProcessSnap,&pe32)) temp = pe32.szExeFile;
pe32.dwSize=sizeof(PROCESSENTRY32);
while(Process32Next(hProcessSnap,&pe32))
{
temp = pe32.szExeFile;
pe32.dwSize = sizeof(PROCESSENTRY32);
if (temp == ExeN)
{
id = pe32.th32ProcessID;
CloseHandle(hProcessSnap);
return id;
}
}
CloseHandle(hProcessSnap);
MessageBox(NULL, "Процесс не найден!", "!", MB_OK|MB_ICONWARNING|MB_SYSTEMMODAL);
return false;
}
//-------------------------------------------------------------------------------
//зная пид убиваем процесс
bool KillProcByPid(DWORD id)
{
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, TRUE, id);
if(INVALID_HANDLE_VALUE != hProcess)
{
TerminateProcess(hProcess, 0);
CloseHandle(hProcess);
}
}
//-------------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
AnsiString ExeName; //имя ехе
DWORD Pid = 0; // PID процесса
ExeName = Edit1->Text;
Pid = GetProcessByExeName(ExeName);
Edit2->Text = (Pid);
KillProcByPid(Pid);
}

Как оптимизировать сие безобразие??? Писано под Builder 6....

[Bah]

Блин, всё хорошо на свете не бывает. Откомпилил всё, попытался запустить на машине с 95 виндой. В итоге ругается и говорит что не может найти vcl60.bpl. В настройках компилера произвел следующие действия:
1. Compiler -> Release
2. Packages -> снял галочку Build with runtime packages
3. Linker -> снял галочку Use dinamic RTL

В итоге размер ехе увеличился с 30кб до 475кб. Под 98 винду вроде нормально запускается, а под 95 пишет "Отсутствует компонент OLEAUT32.DLL:173"
Чё делать надо???

[Boroda]

hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPALL, NULL);

Незачем снапать всё, достаточно только процессы. Замени TH32CS_SNAPALL на TH32CS_SNAPPROCESS. В принципе, это не ошибка, но зачем зря ресурсы расходовать.

hProcessSnap = CreateToolhelp32Snapshot(TH32CS_SNAPALL, NULL);
pe32.dwSize=sizeof(PROCESSENTRY32);
if(Process32First(hProcessSnap,&pe32)) temp = pe32.szExeFile;
pe32.dwSize=sizeof(PROCESSENTRY32);
while(Process32Next(hProcessSnap,&pe32))
{

А где анализ первого процесса? После первого сразу переход ко второму... Я бы так написал:

CODE

pe32.dwSize=sizeof(PROCESSENTRY32);
if(Process32First(hProcessSnap,&pe32))
do
{
 temp = pe32.szExeFile;
 if (temp == ExeN)
 return CloseHandle(hProcessSnap),
          pe32.th32ProcessID;
} while(Process32Next(hProcessSnap,&pe32));
if(GetLastError()!=ERROR_NO_MORE_FILES)
/* тут обрабатываем ошибки */

TerminateProcess(hProcess, 0);

Я же говорил - это нежелательное завершение. Тем более под 9x-ами. Там общее адресное пространство для системных библиотек и ядра, поэтому если приложение не завершить чисто, то неизвестно, где и как это может аукнуться. При TerminateProcess() у приложения вообще нет никаких шансов корректно завершиться, даже __try/__finally не помогут

"Отсутствует компонент OLEAUT32.DLL:173"

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

[Bah]

Фэнк ю коллега

[litelite]

Вижу что ветка уже ДАВНО замолкла, но я молчать не могу. Везде где не встречал этот вопрос, везде встречал что-то похожее на вышеуказанный листинг.

Bah дружище, лучше поздно чем никогда!

Выкладываю своё, рабочее решение обсуждаемого вопроса:

bool kill_p(char *str) {
HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
PROCESSENTRY32 ps;
ps.dwSize = sizeof(ps);
Process32First(hSnap, &ps);

for (int i=0; i<100; i++) { // - число сканируемых процессов
Process32Next(hSnap, &ps);

if ((AnsiString(ps.szExeFile))==str) {
int id=ps.th32ProcessID;
HANDLE ps = OpenProcess(1, false, id);
TerminateProcess(ps, 0);
CloseHandle(hSnap);

return true;
}

}

Просто и удобно, хотя в API функции конечно отстой, как и сам Microsoft.

[Boroda]

И чем это лучше? Я вижу только отрицательные отличия.

1. Обработка ошибок отсутствует в принципе - добро пожаловать в окошко приглашения отправить отчёт об ошибке в MicroSoft. Этого уже достаточно... Однако, продолжим.
2. Количество процессов ограниченно. Зачем?
3. Вместо определённых в SDK констант и типов используются их числовые и C++ эквиваленты. Тебе нравится переписывать свои приложения для новых версий операционных систем?
4. Код неоптимален. По крайнем мере в двух местах. Ищи сам.
5. Функция написана не только небезопасно - об этом говорится в 1. - но она к тому же никак не отчитывается об успехе/неуспехе. По большому счёту возвращаемое значение вообще не определено.
6. Используется метод завершения (TerminateProcess()), крайне не рекомендованный к применению.
7. Имеет место утечка ресурсов. В двух местах.
8. Параметр у функции без причины неконстантен.
9. Функция неоптимальна под WinNT-based ОСами, потому что ориентирована только на ANSI-приложения. Более того, в UNICODE-приложениях она будет работать неправильно. Вернее, вообще не будет работать.
10. В реализации функции есть ошибка. Я на неё и оригинальному автору указывал.

Не многовато-ли для столь малого по объёму кода? И ты ещё позволяешь себе в чём-то обвинять API и MicroSoft? Так, для справки: Win32 API один из самых лучших в мире по диапазону предоставляемых программисту возможностей без привлечения API других уровней. Даже с точки зрения системного программирования, не говоря уже о прикладном.

[Seryega]

+1 в поддержку АПИ

to litelite
если микрософт отстой, то что тогда не отстой??? на сегодняшний день нет крупнее конторы, которая занималась бы развитием такого же широкого круга инф технологий. но всегда находятся начитавшиеся умники, которые даже проанализировать свои же знания не могут.

[BIL]

Люди Есть много много литературы по програмированию.примерам и програмированию для начинающих С++воснавном
пешите отвечю:) BILBIL@YANDEX.RU