информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Страшный баг в WindowsСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Пробовать и смотреть - нельзя. 25.05.01 13:09  Число просмотров: 681
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Опираться можно только на документацию. В ней таких гарантий не дается. Если твоя прога упадет через год у клиента - угадай кто будет ее переписывать.
<programming>
[Win32] что посоветуете ? 24.05.01 20:34  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
известно что по ID потока можно получить HANDLE, for example

DWORD dwThreadId;
.................
HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, TRUE, dwThreadId);

теперь надо обратное, т.е. по HANDLE найти ID
можно конечно по процессу пройтись и перебирать все потоки, пока не наткнешся на нужный.
Есть какие нить предложения - более короткий путь.

P.S. HANDLE - не текущего потока, т.е. вариант GetCurrentThreadId() сразу отпадает.

Thanks.
[Win32] [Win32] что посоветуете ? 25.05.01 15:00  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> известно что по ID потока можно получить HANDLE, for
> example
>
> DWORD dwThreadId;
> .................
> HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, TRUE,
> dwThreadId);
>
> теперь надо обратное, т.е. по HANDLE найти ID
> можно конечно по процессу пройтись и перебирать все потоки,
> пока не наткнешся на нужный.
> Есть какие нить предложения - более короткий путь.
>
> P.S. HANDLE - не текущего потока, т.е. вариант
> GetCurrentThreadId() сразу отпадает.
>
> Thanks.


для WinNt/2k можно попробовать вот это

NTSYSAPI
NTSTATUS
NTAPI
ZwQueryInformationThread(
IN HANDLE ThreadHandle,
IN THREADINFOCLASS ThreadInformationClass,
OUT PVOID ThreadInformation,
IN ULONG ThreadInformationLength,
OUT PULONG ReturnLength OPTIONAL
);

typedef enum _THREADINFOCLASS { // Query Set
ThreadBasicInformation, // 0 Y N
ThreadTimes, // 1 Y N
ThreadPriority, // 2 N Y
ThreadBasePriority, // 3 N Y
ThreadAffinityMask, // 4 N Y
ThreadImpersonationToken, // 5 N Y
ThreadDescriptorTableEntry, // 6 Y N
ThreadEnableAlignmentFaultFixup, // 7 N Y
ThreadEventPair, // 8 N Y
ThreadQuerySetWin32StartAddress, // 9 Y Y
ThreadZeroTlsCell, // 10 N Y
ThreadPerformanceCount, // 11 Y N
ThreadAmILastThread, // 12 Y N
ThreadIdealProcessor, // 13 N Y
ThreadPriorityBoost, // 14 Y Y
ThreadSetTlsArrayAddress, // 15 N Y
ThreadIsIoPending, // 16 Y N
ThreadHideFromDebugger // 17 N Y
} THREADINFOCLASS;

typedef struct _THREAD_BASIC_INFORMATION { // Information Class 0
NTSTATUS ExitStatus;
PNT_TIB TebBaseAddress;
CLIENT_ID ClientId;
KAFFINITY AffinityMask;
KPRIORITY Priority;
KPRIORITY BasePriority;
} THREAD_BASIC_INFORMATION, *PTHREAD_BASIC_INFORMATION;

typedef struct _CLIENT_ID {
ULONG UniqueProcessId;
ULONG UniqueThreadId;
} CLIENT_ID;
typedef CLIENT_ID *PCLIENT_ID;
Thanks! 25.05.01 16:10  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>

Спасибо. Кажись это то что надо. Хотя придется с кернелом поиграть.
Для внятности объясню ситуациу, а то тут я прочел ......

Короче у меня есть класс который работает с потоками и с межпоточными мессагами. к нему прицепил сокет, который в дальнейшем будет крутится как сервер. Каждый раз, когда к серверу кто то коннектится, запускается новый поток со своим сокетом и идет обмен информации через мессаги (PostThreadMessage(DWORD nThreadId !!!!!!!, ....);). тут в качестве LPARAM передаю HANDLE потока, дальше поймете почему (см. FromHandle). Сокеты АСИНХРОННЫЕ. мессаги поддерживают уведомление о событии ... и не только.

Если все создается через мои классы, проблем нет ни каких, я держу и HANDLE и ID потока.
Я написал свой ThreadHandleMap класс, через него все четко идет. Одним словом реализовал аналог FromHandle().
Так вот, для большей гибкости класса мне надо было не только промаппировать потоки созданные моим классом, но и любой. Т.е. FromHandleTemporary() или AttachThread();

2 XR:
Теперь предстовляете если бы мне в такой куче мессаг и потоков, пришлось бы ппросканить весь процесс особенно этот вариант:
for (DWORD nId = 0; nId < 0xFFFFFFFF; nId ++)
HANDLE hThread = OpenThread(....)

тут не то что бы тачка сдохла ..........
кроме того для 2К можно воспользоваться THREADENTRY32 - Thread32First и т.д.

поэтому нужна была фигнюшка, которая при AttachThread() нашла бы ID потока.
по началу хотел поставить жесткое ограничение, ели вызвал FromHandleTemporary или AttachThread, то обязательно указать ID в том числе, но теперь кажется все решится.

2 PS: а структура тут не вписывается, я уже думал об этом, но проблема все равно не решается.

И на всякий случай, если есть какие нить идеи и предложения насчет messageing-а, то выслушаю. Класс еще в стадии развития, поэтому могу еще перестроить.
Thanks! 25.05.01 16:42  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
>> 2 XR:
> Теперь предстовляете если бы мне в такой куче мессаг и
> потоков, пришлось бы ппросканить весь процесс особенно этот
> вариант:
> for (DWORD nId = 0; nId < 0xFFFFFFFF; nId ++)
> HANDLE hThread = OpenThread(....)

Ну это я понятно дело утрирую конечно ... :)


> тут не то что бы тачка сдохла ..........
> кроме того для 2К можно воспользоваться THREADENTRY32 -
> Thread32First и т.д.



> поэтому нужна была фигнюшка, которая при AttachThread()
> нашла бы ID потока.
> по началу хотел поставить жесткое ограничение, ели вызвал
> FromHandleTemporary или AttachThread, то обязательно
> указать ID в том числе, но теперь кажется все решится.

Я чего то про то почему нельзя знать ID и HANDLE вместе так и не понял
если интересно, посмотри как это было сделано в He4 - классы
Server,Forward,Control

В конструкторе Server после accept вызывался CreateThread и в нитку передавался this после чего мы имели и весь класс со всеми его потрохами по указателю

Там правда сокеты были синхронные, поэтому для дуплексного обмена запускалось
еще пара ниток (класс Forward)

BTW: адрес помнишь ?


PS: или я чего не понял ....в смысле потребностей.
не совсем так 25.05.01 18:18  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Я чего то про то почему нельзя знать ID и HANDLE вместе так
> и не понял
> если интересно, посмотри как это было сделано в He4 -
> классы
> Server,Forward,Control

По правде сказкть я не смотрел классы, но кажется они у меня лежат на винте. Я их посмотрю обязательно. Если не найду дам знать.

Но тут дело в другом. Конечно же мой класс содержит и ID и HANDLE. Но представь ситуацию, когда программеру приспичило Attach-нуть свой HANDLE (не созданный через мой класс). Механизм следующий:

HANDLE hSomeThread;
......
CMyThread thread;
.......
thread.Attach(hSomeThread);

или
CMyThread* pThread = CMyThread::FromHandle(hSomeThread); - тут, если поток не создан моим классом, а через API, то создаст временной сласс с указанным HADNLE, потом удалит его.
Теперь надо сделать постинг
pThread->PostThreadMessage(....);
причем, в большинстве custom мессаг, в качестве LPARAM идет Thread HANDLE. так очень удобно, т.к. через FromHandle() всегда получу указатель на класс.
Так вот, если узер аттачит свой хендл, то мне нужно знать и его ID. Я хотел устроить так, чтобу ID из инфо снимал мой класс, а не узер его давал. Естественн, если что то не устраивает, есть вариант
pThread->m_nThreadId = nMyThreadId;

ID мне нужен был всего лишь для постинга, бельше нигде вроде не применяю.
Но суть в том, что все очень четко работает. Я на одной версии сделал Демо - просто супер. Клиент запускает несколько потоков с сокетами и обмен идет без каких либо проблем. причем не надо иметь приложение с окном, сойдет любое лишь бы Win32 :)) одно хреново,я кажется плотно его связываю с 2К.
Легким движением можно накатать Клиент/Сервер только свои обработчики событий написать надо.

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

Кстати, мне потом надо будет серввер тестировать с большим колчеством клиентов, не знаю че делать.

P.S. если че тут несвязанное накатал, sorry :))) немного спешил, за мыслями не успевал :)))
[Кстати о документации, если не трудно... 25.05.01 15:16  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Подскажи в каком MSDN описанна эта ф-я. В моем July-2000 упоминание о ней есть только в ОДНОМ месте, вот в каком контексте

Dr. GUI replies:
First, perhaps, we should talk to your driver to see why it feels a special affinity for a particular processor. Or perhaps not. But you must admit this is an odd thing to want in a symmetric multiprocessing system—it's hardly symmetric.

In any case, life is a bit different for device drivers—major portions of the Win32 API are simply not available to device drivers. For instance, you cannot call ZwQueryInformationThread in a device driver—so there's no way to find out what processor you're running on.


Кажется пора менять MSDN :)
Это из DDK 25.05.01 16:44  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
это из DDK
MSDN менять не следует, просто скачай DDK с доками и все.
пойди по ссылке.

DDK Website
[Win32] Это из DDK 28.05.01 10:06  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> это из DDK
> MSDN менять не следует, просто скачай DDK с доками и все.
> пойди по ссылке.

многие вещи которые считаются недокументированными - прекрасно описаны самим M$ в DDK, IFs Kit-е. Посему их можно считать такими же надежными (в плане изменения API) как и Win32 API. Конечно в коммерческом софте лучше избегать подобного. Но как показывает опыт практически никто не гарантирует работу своего софта для еще не написанных версий OS. Так что данные вещи можно пользовать.
[Win32] вдогон... 25.05.01 12:24  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> известно что по ID потока можно получить HANDLE, for
> example
>
> DWORD dwThreadId;
> .................
тупо делаешь:

for(dwThreadId=0;dwThreadId++;dwThreadId<(DWORD)(-1L)) {
hThread = OpenThread(THREAD_ALL_ACCESS, TRUE,dwThreadId);
.....
if(hThread == hTestThread) return dwThreadId;
}

вот только что ты будешь скармливать в качестве hTestThread ? (см. мой предыдущий msg)

... или ты потерял свою собственную нитку ? :)

тогда то что ты написал ниже:

> теперь надо обратное, т.е. по HANDLE найти ID
> можно конечно по процессу пройтись и перебирать все потоки,
> пока не наткнешся на нужный.
> Есть какие нить предложения - более короткий путь.

ImHO нет :)
И еще из той же оперы 25.05.01 13:05  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Где сказанно что threadID выдаются с 0 последовательно ? MicroSoft это гарантирует ?
это гарантирует dword (пока m$ не сменил размер handle) ;) 25.05.01 13:28  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
Вай ! 25.05.01 12:33  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
А откуда у тебя уверенность, что OpenThread на один и тот же ID (т.е. thread) вернет тебе одно и то же значение hаndle ? Может твое "==" и сработает, а может и нет.
И кто знает как MicroSoft поменяет логику выдачи handle... на одной версии будет такое работать, на другой - нет.
Нельзя чёхом handles сравнивать !
:) 25.05.01 13:03  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> А откуда у тебя уверенность, что OpenThread на один и тот
> же ID (т.е. thread) вернет тебе одно и то же значение
> hаndle ?

А ты попробуй :))

hint: HANDLE это не что иное как линейный адрес в контекстеданного
процесса

Может твое "==" и сработает, а может и нет.
> И кто знает как MicroSoft поменяет логику выдачи handle...
> на одной версии будет такое работать, на другой - нет.
> Нельзя чёхом handles сравнивать !

Это от версии не зависит - cм. hint
[Win32] :) 25.05.01 15:07  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> hint: HANDLE это не что иное как линейный адрес в контексте
>данного процесса

ну это ты перегнул... я бы не назвал ЭТО линейным адресом.. ;))
[Win32] Могет быть :) 25.05.01 15:31  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> > hint: HANDLE это не что иное как линейный адрес в
> контексте
> >данногопроцесса
>
> ну это ты перегнул... я бы не назвал ЭТО линейным адресом..
> ;))

Это как в том анекдоте про п. Ржевского "Подробностей не помню но ..." ;)

Это я глядя на GetModuleHandle() ;)
Пробовать и смотреть - нельзя. 25.05.01 13:09  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Опираться можно только на документацию. В ней таких гарантий не дается. Если твоя прога упадет через год у клиента - угадай кто будет ее переписывать.
<без заголовка> 25.05.01 13:30  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Опираться можно только на документацию. В ней таких
> гарантий не дается. Если твоя прога упадет через год у
> клиента - угадай кто будет ее переписывать.

А что там было недокументировано то ?

ты ImHO демагогией занимаешся :)
Давай завязывать... или кидай сюда код
Код ? 25.05.01 13:47  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Я уже предложил решение, как я бы сделал - хранил бы у себя в одном месте id и handle.

А на счет for(id=0; id...; id++ ) - при чем тут DWORD ? Им пожет приспичить выдавать id случайным образом :)

Это не демагогия - это попытка обойти как можно больше скользких мест, что бы потом проблемм не было.

Ладно, закончим ?
Id и handle не могут быть случайными 25.05.01 16:28  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
ID и HANDLE не могут быть случайными в предела процесса, а может даже в пределах ядра.
Если бы они были случайные как ты представляешь
PostThreadMessage(ID, .....)
то же самое что утверждать HWND выдается случайно, например каждый раз вызывая GetDlgItem() получим случайный HWND. нет такого и не должно быть, вся логика связки между HWND а тк же между Parrent и Child рушится.
и HANDLE в том числе тоже не случайность из тех же соображений
Wait- ф-и, Terminate и прочее
каждый процесс имеет свою таблицу, вот из него все и выдается.
Код ? 25.05.01 14:01  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Я уже предложил решение, как я бы сделал - хранил бы у себя
> в одном месте id и handle.

я про это уже говорил:

это или design issue либо хач чужого процесса.


> А на счет for(id=0; id...; id++ ) - при чем тут DWORD ? Им
> пожет приспичить выдавать id случайным образом :)
>

А если подумать ? :) (можно на досуге)


> Это не демагогия - это попытка обойти как можно больше
> скользких мест, что бы потом проблемм не было.
>
> Ладно, закончим ?

Ладушки :)
1  |  2 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach