Как определить, из какого режима запущена программа?

@#pragma · Регистрация: 12.04.2009

Студворк — интернет-сервис помощи студентам

Например есть консольное приложение.Как можно узнать,из какого графического режима оно было запущено?
Подразумевается,что это не одно и то же(может спутаны понятия,но постараюсь объяснить как умею):
1) "DOS"-режим(или терминал?),то есть голая консоль,например через Нортон Коммандер,или в Линукс из терминала без видеорежима.
2)Смешанный режим-то есть из графической среды,просто в отдельном окошке с командной строкой.(cmd,xterm,konsole и т.д.).

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

@Gravity · 16.10.2009, 13:28

В линуксе приходит на ум отследить список родительских процессов для данной программы. Если среди них присутствует X, то приложение запущено из графики, иначе нет. Так же можно пробить на xterm, konsole и т.д.

@kravam · 16.10.2009, 13:51

Хм. Интересно. А не так ли обстоят дела, что:
Если ты запускаешь программу (процесс X), то не абы откуда, а из определённого процесса Y.

То есть Y есть процесс- отец, а X процесс- сын.
То есть тебе нужно найти, какой процесс является отцом для твоего процесса X.

Самые распространённые отцы для программ такие:
1) explorer.exe (Проводник обыкновенный. 99 процентов всех приложений на моём компе запущены из этого процесса)
2) cmd.exe
3) Есть варианты всякие.

Все деревья процессов можно посмотреть с помощью вот этой программки

Это скачаешь Process Explorer

...Если я всё правильно понял и тебе необходимо найти родительские процессы программно, сообщи, обдумаю, как.

@Gravity · 16.10.2009, 16:00

Набросал код для вывода родительских процессов для заданного pid (linux)

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <unistd.h>
 
int m_getppid(char *stpath)
{
    FILE *fp;
    char *p, buf[256];
 
    if( (fp = fopen(stpath, "r")) == NULL) {
        perror("m_getppid: fopen:");
        exit(1);
    }
    do {
        fgets(buf, sizeof(buf), fp);
    } while(!feof(fp) && (p = strstr(buf, "PPid")) == NULL);
    fclose(fp);
 
    if(p == NULL)
        return -1;
    while(!isdigit(*p))
        p++;
    return atoi(p);
}
 
void getpidname(char *s, int pid)
{
    FILE *fp;
    char cmdpath[256];  /* cmdline file */
    int c;
 
    snprintf(cmdpath, sizeof(cmdpath), "/proc/%d/cmdline", pid);
    if( (fp = fopen(cmdpath, "r")) == NULL) {
        perror("getpidname: fopen");
        exit(2);
    }
    while( (c = getc(fp)) != EOF)
        *s++ = c;
    *s = '\0';
    fclose(fp);
}
 
void proclist(int pid)
{
    int ppid;
    char ppidname[256];  
    char stpath[256];   /* status file */
 
    if(pid == 1)    /* init process */
        return;
    snprintf(stpath, sizeof(stpath), "/proc/%d/status", pid);
    ppid = m_getppid(stpath);
    getpidname(ppidname, ppid);
    printf("%d\t%s\n", ppid, ppidname);
 
    proclist(ppid);
}
 
int main(void)
{
    printf("PID\tCMD\n");
    proclist(getpid());
    return 0;
}

Получаем:

Code
1
2
3
4
5
6
7
PID CMD
4482    zsh
4481    urxvt
4388    fluxbox
4382    -:0         
4309    /usr/bin/xdm
1   init [3]

-:0 - на нулевом дисплее запущены Иксы, urxvt - графический эмулятор консоли.
Остается только ввести функцию проверки искомого процесса и передать ее в proclist.

@kravam · 16.10.2009, 21:32

Значит, вот что я нашёл по твоему вопросу.
Читаем у Джефри Рихтера,
http://wm-help.net/books-onlin... .html#h1t1

"Иногда программе приходится определять свой родительский процесс. Однако родственные связи между процессами существуют лишь на стадии создания дочер него процесса. Непосредственно перед началом исполнения кода вдочернем процес се Windows перестает учитывать его родственные связи. В предыдущих версиях Win dows не было функций, которые позволяли бы программе обращаться с запросом к ее родительскому процессу. Но ToolHelp-функции, появившиеся в современных вер сиях Windows, сделали это возможным. С этой целью Вы должны использовать струк туру PROCESSENTRY32: ее элемент th32ParentProcessID возвращает идентификатор "родителя" данного процесса. Тем не менее, если Вашей программе нужно взаимодействовать с родительским процессом, от идентификаторов лучше отказаться. Почему — я уже говорил. Для определения родительского процесса существуют более надежные механизмы: объекты ядра, описатели окон и т. д.
Единственный способ добиться того, чтобы идентификатор процесса или потока не использовался повторно, — не допускать разрушения объекта ядра "процесс" или "поток". Если Вы только что создали новый процесс или поток, то можете просто не закрывать описатели на зти объекты — вот и все. А по окончании операций с иден тификатором, вызовите функцию CloseHandle и освободите соответствующие объек ты ядра. Однако для дочернего процесса этот способ не годится, если только он не унаследовал описатели объектов ядра от родительского процесса."

Теперь по структуре PROCESSENTRY32
Вот в этой теме я с ней удачно работал, ознакомься.
ofstream

Ну, то есть тебе надо создать переменную типа PROCESSENTRY32
заполнить её и поле PROCESSENTRY32.th32ParentProcessID и есть идентификатор родителя.
Не забывай, что если ты его где-то сохранишь, а потом родитель закроется, а его PID будет использоваться... Но старина Рихтер об этом писал уже.

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

...А знаешь что в цитате самое ценное и многообещающее?
Вот эта строка
"Для определения родительского процесса существуют более надежные механизмы: объекты ядра, описатели окон и т. д. "
То есть Рихтер намекает, что возможен доступ к объектам ядра!
А если его ещё и модифицировать можно- это полный контроль над системой!

@odip · 16.10.2009, 22:01

Рассмотрим вариант с Windows.

1) "DOS"-режим. Вообще-то чистый DOS-режим есть только в MS-DOS.
Можешь смело считать что Windows вообще не работает без GUI.

2) Значит твоя программа всегда работает в графическом режиме.
Исключением является Windows Server 2008 в Сore mode - там нет графики.

Осталось понять как узнать развернуто окно консоли на полный экран или нет. Есть функции WinAPI, работающие с консолью. Думаю там можно это найти.

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

Добавлено через 2 минуты
Расмотрим вариант с Linux.

А если я через putty в Windows запускаю консоль на Linux ? Это что будет - графический режим или нет ?
А если я запускаю xterm в Windows, и с его помощью запускаю консоль на Linux ?

Я думаю все-таки нужно определить - если ли возможно вывести на X-ы или нет.
А это можно определить по наличию переменной DISPLAY.

@#pragma · 16.10.2009, 22:16 **[ТС]**

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

Новые блоги и статьи Все статьи Все блоги /
Программный контроль заполнения реквизита табличной части документа Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: реализовать контроль заполнения реквизита табличной части. . .	wmic не является внутренней или внешней командой Maks 02.04.2026 Решение: DISM / Online / Add-Capability / CapabilityName:WMIC~~~~ Отсюда: https:/ / winitpro. ru/ index. php/ 2025/ 02/ 14/ komanda-wmic-ne-naydena/	Программная установка даты и запрет ее изменения Maks 02.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "СписаниеМатериалов", разработанного в конфигурации КА2. Задача: при создании документов установить период списания автоматически. . .	Вывод данных в справочнике через динамический список Maks 01.04.2026 Реализация из решения ниже выполнена на примере нетипового справочника "Спецтехника" разработанного в конфигурации КА2. Задача: вывести данные из ТЧ нетипового документа. . .
Функция заполнения текстового поля в реквизите формы документа Maks 01.04.2026 Алгоритм из решения ниже реализован на нетиповом документе "ВыдачаОборудованияНаСпецтехнику" разработанного в конфигурации КА2, в дополнении к предыдущему решению. На форме документа создается. . .	К слову об оптимизации kumehtar 01.04.2026 Вспоминаю начало 2000-х, университет, когда я писал на Delphi. Тогда среди программистов на форумах активно обсуждали аккуратную работу с памятью: нужно было следить за переменными, вовремя. . .	Идея фильтра интернета (сервер = слой+фильтр). Hrethgir 31.03.2026 Суть идеи заключается в том, чтобы запустить свой сервер, о чём я если честно мечтал давно и давно приобрёл книгу как это сделать. Но не было причин его запускать. Очумелые учёные напечатали на. . .	Модель здравосоХранения 6. ESG-повестка и устойчивое развитие; углублённый анализ кадрового бренда anaschu 31.03.2026 В прикрепленном документе раздумья о том, как можно поменять модель в будущем

@#pragma Временно недоступен 957 / 228 / 14 Регистрация: 12.04.2009 Сообщений: 926

	Как определить, из какого режима запущена программа? 16.10.2009, 04:53. Показов 6436. Ответов 6 Метки нет (Все метки) Например есть консольное приложение.Как можно узнать,из какого графического режима оно было запущено? Подразумевается,что это не одно и то же(может спутаны понятия,но постараюсь объяснить как умею): 1) "DOS"-режим(или терминал?),то есть голая консоль,например через Нортон Коммандер,или в Линукс из терминала без видеорежима. 2)Смешанный режим-то есть из графической среды,просто в отдельном окошке с командной строкой.(cmd,xterm,konsole и т.д.). Зачем это надо: Например,программа может выдавать дополнительные данные,которые желательно не смешивать с основным выводом на экран.Из графического режима тогда можно просто запустить дополнительное окно консоли,в котором будут печататься нужные дополнительные данные.Но если консоль запущена на полный экран/нет возможности переключиться,то удобно печатать эти данные в файл. Как можно определить(в разных системах),в каком режиме запущена программа? 0

@Gravity 577 / 571 / 65 Регистрация: 29.01.2009 Сообщений: 1,274
	16.10.2009, 13:28
	В линуксе приходит на ум отследить список родительских процессов для данной программы. Если среди них присутствует X, то приложение запущено из графики, иначе нет. Так же можно пробить на xterm, konsole и т.д. 1

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,705
	16.10.2009, 13:51
	Хм. Интересно. А не так ли обстоят дела, что: Если ты запускаешь программу (процесс X), то не абы откуда, а из определённого процесса Y. То есть Y есть процесс- отец, а X процесс- сын. То есть тебе нужно найти, какой процесс является отцом для твоего процесса X. Самые распространённые отцы для программ такие: 1) explorer.exe (Проводник обыкновенный. 99 процентов всех приложений на моём компе запущены из этого процесса) 2) cmd.exe 3) Есть варианты всякие. Все деревья процессов можно посмотреть с помощью вот этой программки Это скачаешь Process Explorer ...Если я всё правильно понял и тебе необходимо найти родительские процессы программно, сообщи, обдумаю, как. 1

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,705
	16.10.2009, 21:32
	Значит, вот что я нашёл по твоему вопросу. Читаем у Джефри Рихтера, http://wm-help.net/books-onlin... .html#h1t1 "Иногда программе приходится определять свой родительский процесс. Однако родственные связи между процессами существуют лишь на стадии создания дочер него процесса. Непосредственно перед началом исполнения кода вдочернем процес се Windows перестает учитывать его родственные связи. В предыдущих версиях Win dows не было функций, которые позволяли бы программе обращаться с запросом к ее родительскому процессу. Но ToolHelp-функции, появившиеся в современных вер сиях Windows, сделали это возможным. С этой целью Вы должны использовать струк туру PROCESSENTRY32: ее элемент th32ParentProcessID возвращает идентификатор "родителя" данного процесса. Тем не менее, если Вашей программе нужно взаимодействовать с родительским процессом, от идентификаторов лучше отказаться. Почему — я уже говорил. Для определения родительского процесса существуют более надежные механизмы: объекты ядра, описатели окон и т. д. Единственный способ добиться того, чтобы идентификатор процесса или потока не использовался повторно, — не допускать разрушения объекта ядра "процесс" или "поток". Если Вы только что создали новый процесс или поток, то можете просто не закрывать описатели на зти объекты — вот и все. А по окончании операций с иден тификатором, вызовите функцию CloseHandle и освободите соответствующие объек ты ядра. Однако для дочернего процесса этот способ не годится, если только он не унаследовал описатели объектов ядра от родительского процесса." Теперь по структуре PROCESSENTRY32 Вот в этой теме я с ней удачно работал, ознакомься. ofstream Ну, то есть тебе надо создать переменную типа PROCESSENTRY32 заполнить её и поле PROCESSENTRY32.th32ParentProcessID и есть идентификатор родителя. Не забывай, что если ты его где-то сохранишь, а потом родитель закроется, а его PID будет использоваться... Но старина Рихтер об этом писал уже. Если поподробнее про заполнение структуры надо- пиши в личку. Тут ссылку не даю, там хакерский какой-то ресурс, здесь это не приветствуется. ...А знаешь что в цитате самое ценное и многообещающее? Вот эта строка "Для определения родительского процесса существуют более надежные механизмы: объекты ядра, описатели окон и т. д. " То есть Рихтер намекает, что возможен доступ к объектам ядра! А если его ещё и модифицировать можно- это полный контроль над системой! 1

@odip 7176 / 3234 / 82 Регистрация: 17.06.2009 Сообщений: 14,164
	16.10.2009, 22:01
	Рассмотрим вариант с Windows. 1) "DOS"-режим. Вообще-то чистый DOS-режим есть только в MS-DOS. Можешь смело считать что Windows вообще не работает без GUI. 2) Значит твоя программа всегда работает в графическом режиме. Исключением является Windows Server 2008 в Сore mode - там нет графики. Осталось понять как узнать развернуто окно консоли на полный экран или нет. Есть функции WinAPI, работающие с консолью. Думаю там можно это найти. Но только ты забыл что режим можно изменить в процессе работы. Например программу запущенную в консоли можно развернуть на полный экран, можно свернуть обратно. Что при этом будет делать твоя программа ? Добавлено через 2 минуты Расмотрим вариант с Linux. А если я через putty в Windows запускаю консоль на Linux ? Это что будет - графический режим или нет ? А если я запускаю xterm в Windows, и с его помощью запускаю консоль на Linux ? Я думаю все-таки нужно определить - если ли возможно вывести на X-ы или нет. А это можно определить по наличию переменной DISPLAY. 1

@#pragma Временно недоступен 957 / 228 / 14 Регистрация: 12.04.2009 Сообщений: 926
	16.10.2009, 22:16 [ТС]
	Да,првда не подумал,что в процессе может меняться режим.Тогда лучше не заморачиваться с этим.Спасибо за помощь.Выход простой-просто опция командной строки,по умолчанию пишется в файл. kravam, интересное исследование,но мне вряд ли такое сгодится,по крайней мере не сейчас 0