В общем случае это разные хендлы. Если стандартный вывод перенаправлен, то CreateFile("CONOUT$" возвращает не то, что GetStdHandle

Добавлено через 9 минут и 41 секунду

то есть хендлы конечно же в любом случае разные, я про сам объект говорю.

Не хватает еще одного слова -
вот теперь 'последователен'. Согласитесь, что File и FileObject - это несколько разные сущности   

Ну ты программист или куда? Конечно ж объект, потому что всё суть объекты

bems, вот цитата из документации на CreateFile:Где ты тут видишь упоминание о "объекте ядра"? Нет такого! Я конечно рад за разработчиков API, которые создавали его для себя. Но я, как пользователь, чувствую себя не комфортно от того, что функции делают не то, что следует из их названия.
Согласись, прикладному программисту должно быть глубоко фиолетово от того, что происходит внутри системы. Он захотел открыть файл, файл открылся. А то, что система для этого сделала миллион операций, его волновать вообще не должно.

А вот описалово писали уже для таких как ты, которые за деревьями леса не видят. Пришлось перечислить всякие file, file stream, directory, physical disk и тд.
Также для детей природы есть такой топик http://msdn.microsoft.com/en-us/library/ms...28VS.85%29.aspx

Люди, которым фиолетово работают в бухгалтерии. Им действительно не нужно знать что такое логарифм, чтобы считать сложные проценты.


Это сообщение отредактировал(а) bems - 20.4.2011, 18:46

Ну если подходить ко всему с точки зрения ядра, то Mutex надо было назвать Mutant. Ибо в ядре он именно так называется   

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

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

Еще пример. Мне нужна работа с СОМ портом. В частности, узнать, сколько байт во входном и выходном буферах. Так вот, ни одна функция, отвечающая за получение информации не позволяет это получить. Зато есть магическая функция ClearCommError, которая кроме того, что сбрасывает флаги ошибок порта (ну в принципе следует из ее названия), еще и позволяет получить определенную информацию о состоянии порта. Догадаться не используя поиск по примерам и не перечитывая все описания НЕВОЗМОЖНО!

Во-первых KMUTANT и KMUTEX синонимы, и строго ядерные (не винапи) функции для манипуляции с ним часто ссылаются на него как на мютекс, например KeInitializeMutex, так что тут скорее просто два названия
Во-вторых понятие "объект ядра" вводится именно в винапи, прикладному коду не нужно знать подробностей, но примерное представление имень необходимо.

нет, таксисту не надо. но ты не таксист, ты программист, это инженерная специальность. А веб-программистам нужно знать веб-сервер, даже если по началу сначала кажется что "я нажимаю кнопочку и это работает"

Внутренне устройство - дело другое. Тебя же никто не заставляет работать со структурой FILE_OBJECT напрямую, но что есть объект файл, что он представлен для тебя хендлом, что объект reference-counted, и счетчик ссылок уменьшается вызовом CloseHandle ты знать обязан, если хочешь использовать апи


Когда ты используя CreateFile открываешь ком-порт, то получаешь хендл на реальный FILE_OBJECT, обслуживаемый соответствующим драйвером. Но файловый объект он больше для поточного обмена данными, а драйвероспецифичные вещи всю жизнь делались посылкой драйверу ioctl. И это есть в msdn, да. в этом случае указывается тот же хендл файлового объенкта, но он служит скорее неким ключем у нужному DEVICE_OBJECT. 
Исходя их этого, уж не является ли тем несуществующим способом, о котором ты говоришь вызов DeviceIoControl с кодом IOCTL_SERIAL_GET_COMMSTATUS? 
кстати эта штука тоже заодно сбрасывает флаги. Если поведение драйвера делает из этих вещей одну цельную операцию, то не удивительно что разработчики апи сделали это одним вызовом.

Это сообщение отредактировал(а) bems - 21.4.2011, 00:21