Re[6]: Поздравляю всех с кончиной Win32 API :))
От: Mamut Швеция http://dmitriid.com
Дата: 31.10.05 12:31
Оценка:
VD>Надо сказать, что как раз ДОС виндовс поддерживает великолепно.

Не совсем. Transport Tycoon вылетает при попытке обратиться к COM3



dmitriid.comGitHubLinkedIn
Re: Поздравляю всех с кончиной Win32 API :))
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 31.10.05 13:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот его ответ:


Для полноты, здесь ссылка на исходное сообщение Leonardo Blanco.
Re[5]: Поздравляю всех с кончиной Win32 API :))
От: Pavel Dvorkin Россия  
Дата: 31.10.05 13:28
Оценка:
Здравствуйте, TK, Вы писали:

TK>То, что нынешнего Win32 API не будет совсем — на это, наверное, не стоит рассчитывать (например с момента выхода Windows 3.x прошло уже больше 10-ти лет, а до сих пор в WinXP есть поддержка Win16...)


Там даже поддержка DOS FCB file IO есть, хотя этим уже давно никто не пользуется, со времен DOS 2.0

TK>Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.



Думаю, что да. Примерно так же, как в свое время продвинули Win32. Common controls в Win16 не реализовали.
With best regards
Pavel Dvorkin
Re[17]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:06
Оценка:
Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>И через пять лет чтения, я таки понял эти "25 интерфейсов" Правда не понял этот вопрос на вопрос.


Тогда должен представлять сколько там лишних действий.
OLEDB обладает дичайшей избыточностью. Да и с точки зрения производительности структуры данных OLEDB довольно плохи.

КД>OLEDB (с точки зрения реализации) проигрывает ADO.NET провайдеру только в тех позициях, где .NET выигрывает у COM. И наоборот. Все остальные измышления — бесполезный бред и трата времени, которые обусловлены толщиной и длиной шворцев.


Да нет, OLEDB в первую очередь проигрывает алгоритмически. Куча виртуальных КОМ-мовских вызовов конечно тоже замедляют работу, но не думаю, что больше чем просто ваозня с ACCESSOR-ами и т.п.

КД>Формально, в крупном приложении по-барабану через что работать — что через OLEDB напрямую (но только не для начинающих и только не через ATL.OLEDB и только не явно через интерфейсы), что через ADO (здесь проще, но есть нюансы), что через .NET-провайдер.


Реально чтобы работать с OLEDB напрямую нужно быть не всвоем уме. И начинающий или нет тут в общем-то без разницы. Хотя специалист конечно просто не имеет права на такие ошибки. OLEDB — это убогий низкоуровневый стандарт созданный явно не для прямого использования.

Вообще зачем было нужно лепить такого монстра как OLEDB я вообще не понимаю. Но это уже отдельная филосовская тема.

КД>Но пять лет назад, с точки зрения масштабируемости архитектуры конечного приложения, OLEDB был самым оптимальным выбором (правда начальная стоимость очень высокая).


С точки зреня масштабируемости, OLEDB и сейчас неплохо выглядит. Впрочем, как и доисторический ODBC.

КД> И на текущий момент, лично для меня, ничего не поменялось. Правда основная херня в том что MS не предоставила шлюз OLEDB провайдер<->OLEDB.NET провайдер, как это было сделано для ADODB в виде незадокументированных интерфейсов конструирования. Но, слава Богу, не первый год замужем


Я не знаю как эти слова относятся к тому о чем коворил я:

IP>вот это _очень_ сильно. только сильно сомневаюсь что сам этот юкон будет managed.

А тут и сомневаться нечено. Конечно... не будет. Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...


КД>В любом случае, глядя на свой провайдер, скажу, что нормальный драйвер (OLEDB/NET) "на ура" написать не реально.


Я не знаю что такое OLEDB/NET. Но знаю что оба типа провайдера пишутся. Только OLEDB с большим гемороидальным трахом, а дотнетный довольно просто. Собственно оных уже море и ни про какие проблемы не слышно.

КД> И постепенно уровень сложности реализации станет такого уровня, что один два лишних вызова (слоя) — это даже не копейки. Спрашиваете "почему"? Да потому, что драйвер (перешедший на промышленный уровень) однозначно будет состоять из двух уровней — того, с которым вы общаетесь наверху, и того, который общается с БД. А между этими двумя уровнями будут лежать абстрактные интерфейсы


Факты... батенька, факты... Банальные испытания показывают, что управляемый провадер для MSSQL работает отровенно быстрее нэйтивного OLEDB-провайдера. И тому есть простое обяснение. OLEDB — явно переусложненный стандарт рожденный от чего угодно, но только не от большого ума.

КД>Только для зрителей нашего телеканала, часть списка файлов OLEDB-провайдера для FireBird:

...

Спасибо, я не люблю читать ужастики перед сном. Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:06
Оценка: 15 (1) +1
Здравствуйте, Блудов Павел, Вы писали:

БП>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.


Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.

Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Поздравляю всех с кончиной Win32 API :))
От: aik Австралия  
Дата: 31.10.05 15:25
Оценка:
Здравствуйте, VladD2, Вы писали:

БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.


VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.


Во тут интересно — что с ним не так то? Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению
Re[13]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:32
Оценка:
Здравствуйте, mefrill, Вы писали:

M>Ну так, насколько я помню, есть же такая найтивная для SQl Server вещь как DB Library? Как утверждается в документации, все остальные интерфейсы поверх нее реализованы.


Можно привести цитатату?

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

M>Но, я так понял, что ты имел ввиду хорошую и быструю логику обработки абстракций (типов, данных и т.д.) через управляемый интерфейс? Хлтя и здесь мы ведь имеем дело с плоскими массивами данных.


OLEDB это еще тот монстр. Так чт и да, и нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Поздравляю всех с кончиной Win32 API :))
От: IPv6 Россия http://www.lumarnia.com/
Дата: 31.10.05 15:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Блудов Павел, Вы писали:


БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.


VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.


VD>Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.

вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?
Re[4]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:57
Оценка:
Здравствуйте, aik, Вы писали:

aik>Во тут интересно — что с ним не так то?


Кривизна, сложность и неудобсность в использовании.

aik> Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению


Иногда случается и так. Но то что обертывание в менеджед обертки зачастую координально упрощает использование ВыньАПИ указывает именно на кривость реализации.

Простой пример который мне пришлось опробывать на своей шкуре совсем недавно. Функция SystemParametersInfo. Попробуй, например, с ее помощью сменить режим сглаживания шрифта на ClearType.

А как тебе интерфейсы OLEDB? А Защиты в СOM? Да куда не копни убогие и дико переусложненные интерфейсы.

А reserved-апраметры напиханные там и тут? А названия методов выбираемые рандомом (например, перечисли все методы вывода текста на экран в Windows).

Просто те кто этим ужасом пользуются сильно привыкли и не замечают маразма ситуации.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:57
Оценка:
Здравствуйте, aik, Вы писали:

aik>Раньше любая новая фича сопровождалась 2 уровнями API — winapi + надстройка в виде .net. Теперь от нас будут умышленно прятать winapi, хотя реально то он вряд ли куда то денется. Довольно неумный шаг в продвижении дотнета.


Вот Indigo и Avalon ничего не прячют. Они и есть исходное АПИ. Где-то в глубине недр они конечно обращаются к низкоуровневым АПИ ОС, но используя эти АПИ получить тот же результат просто не удастся. И сделано это не в целях продвижения дотнета (что это самоцель, что ли?), а в целях упрощения разработки и поддержки. Ну, и с целью уменьшения оверхэда создаваемого интеропом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 16:19
Оценка: -1
Здравствуйте, IPv6, Вы писали:

IP>вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?


Пример я уже привел Re[4]: Поздравляю всех с кончиной Win32 API :))
Автор: VladD2
Дата: 31.10.05
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Поздравляю всех с кончиной Win32 API :))
От: c-smile Канада http://terrainformatica.com
Дата: 31.10.05 16:26
Оценка: +1
Здравствуйте, VladD2, Вы писали:

Кончина подзатянулась,

Ровно как два года сообщению.
Re[18]: Поздравляю всех с кончиной Win32 API :))
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 31.10.05 16:43
Оценка:
Здравствуйте, VladD2, Вы писали:

КД>>И через пять лет чтения, я таки понял эти "25 интерфейсов" Правда не понял этот вопрос на вопрос.


VD>Тогда должен представлять сколько там лишних действий.

VD>OLEDB обладает дичайшей избыточностью. Да и с точки зрения производительности структуры данных OLEDB довольно плохи.

Вот избыточности, кстати, я там не видел. Просто много интерфейсов, которые позволяют подстраиваться под клиентов с разным уровнем "интеллекта".

Хотя нет... IRow и IRowChange были созданы, когда кого-то в MS запарило работать с аксессорами

VD>Да нет, OLEDB в первую очередь проигрывает алгоритмически. Куча виртуальных КОМ-мовских вызовов ...


Вызовов не очень много, а вот предварительной работы — достаточно

VD>Реально чтобы работать с OLEDB напрямую нужно быть не всвоем уме.


Я и написал — напрямую не выйдет. Только через ADO. Я работаю без напрягов через свою плюсовую библиотеку

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

В реальности, визуальные ActiveX компоненты гораздо сложнее. Я помню как тебя терроризировал относительно UserForm

VD>Вообще зачем было нужно лепить такого монстра как OLEDB я вообще не понимаю. Но это уже отдельная филосовская тема.


По-моему это внутренности MSSQL. Причем родил эту спецификацию явно человек с оторванным сознанием Многие вещи я понял только недавно, а он это родил еще в 98

VD>С точки зреня масштабируемости, OLEDB и сейчас неплохо выглядит. Впрочем, как и доисторический ODBC.


Ну, это, ставить ODBC рядом с OLEDB, это все равно что котенка сравнивать с тигром

КД>> И на текущий момент, лично для меня, ничего не поменялось.


VD>Я не знаю как эти слова относятся к тому о чем коворил я:

VD>

IP>>Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...


Это нужно интерпретировать так — я понимаю откуда растут ноги

КД>> И постепенно уровень сложности реализации станет такого уровня, что один два лишних вызова (слоя) — это даже не копейки.


VD>Факты... батенька, факты... Банальные испытания показывают.


Факты? Только на основе своего провайдера. Когда я в него встроил парсер SQL запросов, я понял что про милое детство можно забыть

Кстати, страшно боялся что это отразиться на скорости работы системы в целом. К счатью, тормоза остались те же И даже когда я переписал этот парсер, заменил мьютексы на критические секции, оптимизировал конвертирование текстовых данных (из кодировки БД в кодировку клиента), вылизал все алгоритмы — скорости в целом это не прибавило. Хотя тесты — это да — IBP v3 проходит их в два раза быстрее чем IBP v2. Ну и ху$и ??? Меня это не радует абсолютно.

Так вот у меня тормозит в основном сервер, куда отправляются запросы, клиент, который эти запросы посылает и управляющие VB-скрипты, которые помогают клиенту генерировать эти запросы. Утрировано, конечно, но смысл такой — подозреваю что доля провайдера в общем объеме затрат CPU — ГОРАЗДО меньше 10%

И если раньше я жался насчет каждого вызова к провайдеру/сервер, типа "не дай бог использовать автоматическое формирование определений параметров!", то сейчас мне на это положить. Гораздо ценнее глобальная оптимизация системы Хотя, по старинке, продолжаю в работать только через SQL запросы.

VD>Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!


Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[2]: Поздравляю всех с кончиной Win32 API :))
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 31.10.05 16:47
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Кончина подзатянулась,


CS>Ровно как два года сообщению.


Оно сопротивляется
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[19]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 18:47
Оценка:
Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Хотя нет... IRow и IRowChange были созданы, когда кого-то в MS запарило работать с аксессорами


Эксессоры сами по себе ужасны и избыточны.

КД>Я и написал — напрямую не выйдет. Только через ADO. Я работаю без напрягов через свою плюсовую библиотеку


С тем же успхом она могла бы работать напрямую с датастримом (как АДО.НЭТ). Так что приемущество от ОЛЕДБ тут только в его стандартности. Но ведь ОДБЦ был сто лет назад, и я уверен, что для твоей обертки работать с ним было бы куда проще.

КД>Насчет убогости — это ты зря. Просто сложная для понимания вещь. Но только дураки постоянно с ней живут.


Под убогостью я и понимаю сложность и неуклюжесть. С воможностями то там все ОК. Но все тоже самое делается куда проще. Просто не нужно было добиваться супер универсальности.

КД>В реальности, визуальные ActiveX компоненты гораздо сложнее. Я помню как тебя терроризировал относительно UserForm


А это тоже пример дебилизма АПИ. Только я все же ActiveX отношу к АПИ КОМ-а. Но по сути это тоже ВыньАПИ.

Честно говоря ActiveX и ОЛЕ2 проектировали тоже не вполне разумные люди. Я в этой каше года два разбирался, но вопросы остались. По сравнеию с этими технологиями ВыньФормс и их контролы — это супер гладкая архитектура и приятнейший АПИ. Жаль что только по сранвению.

КД>По-моему это внутренности MSSQL.


Я тоже так думал. Но когда копнул глубже, то оказалось, что и ОЛЕДБ, и ДБЛИБ, и ОДБЦ работают через практически одно и то же низкоуровневое АПИ и друг-друга не используют. А узнал я это как раз когда разбирался с тем как написан управляемый провайдер.

КД> Причем родил эту спецификацию явно человек с оторванным сознанием Многие вещи я понял только недавно, а он это родил еще в 98


По-моему, раньше, но может я тут ошибаюсь. Не, не ошибаюсь. Рядом, в коридоре, валяется справочник по ОЛЕДБ 1.1 дебильно переведенный "Русской редакцией" в 1997 году. Стало быть 1.0 было где-то в 1996-ом.

А сделан ОЛЕДБ был вроде бы как когда делали внешние запросы в сиквеле. Но думаю, планы были наполеоновскими. А ОЛЕ там появилось, так как в это время в МС все пытались переписать на КОМ.

КД>Ну, это, ставить ODBC рядом с OLEDB, это все равно что котенка сравнивать с тигром


Хм. ОЛЕДБ это тигр, или котенок? Для котенка очень уже жирный и огромный, а для тигра не поворотливый и опять же жирный.

Кстати, что тебе не хватает в ОДБЦ по сравнению с ОЛЕДБ?

КД>Ну и ху$и ??? Меня это не радует абсолютно.


Это, за мат здесь банят. Даже за такой. Так что в этот раз я не заметил. Но в следующий, не обессудь.

КД>Так вот у меня тормозит в основном сервер, куда отправляются запросы, клиент, который эти запросы посылает и управляющие VB-скрипты, которые помогают клиенту генерировать эти запросы. Утрировано, конечно, но смысл такой — подозреваю что доля провайдера в общем объеме затрат CPU — ГОРАЗДО меньше 10%


Я и не утверждаю, что скорость интерфейса может существенно замедлить прилоежение. Я всего лишь, сказал, что то что Юкон не менеджед не мешает с ним эффекивно работать, и привел обоснование. А тут дескуссия вокруг ОЛЕДБ организовалась.

КД>И если раньше я жался насчет каждого вызова к провайдеру/сервер, типа "не дай бог использовать автоматическое формирование определений параметров!", то сейчас мне на это положить. Гораздо ценнее глобальная оптимизация системы Хотя, по старинке, продолжаю в работать только через SQL запросы.


Это ты вот тут расскажи:
История одной оптимизации
Автор: VladD2
Дата: 27.10.05

Об эффективности программ
Автор: Pavel Dvorkin
Дата: 05.10.05


VD>>Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!


КД>Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану


Ох уж эти аналогии. И почему ты ОЛЕДБ к внедорожникам отнес? Работает ОЛДБ при доступе к сиквелу медленее. Используется наверно уже тоже реже чем нэйтивный провайдер. Так о чем разговор то?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 18:47
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Кончина подзатянулась,


CS>Ровно как два года сообщению.


Думаю, оно еще лет 5-10 помучается.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Поздравляю всех с кончиной Win32 API :))
От: CreatorCray  
Дата: 31.10.05 20:49
Оценка: 25 (1)
Здравствуйте, VladD2, Вы писали:

VD>Функция SystemParametersInfo. Попробуй, например, с ее помощью сменить режим сглаживания шрифта на ClearType.


Лехко! А я то думал там будет что либо сложное... Обычный косяк в MSDN... Ну не указали они что надо значение вместо указателя пхать. У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam.
Так что тут надо дать по голове пьяным индусам из микрософт

#include <windows.h>

// Эти константы надо потому, что у меня дома 6-я старая вижуалка в .h которой этих определений нету
#define FE_FONTSMOOTHINGCLEARTYPE    0x0002
#define SPI_SETFONTSMOOTHINGTYPE    0x200B

void main ()
{
    DWORD smoothType = FE_FONTSMOOTHINGCLEARTYPE;
    SystemParametersInfo (SPI_SETFONTSMOOTHING, TRUE, NULL, 0);
    SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, (void*)FE_FONTSMOOTHINGCLEARTYPE, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
    
    MessageBox (NULL,"Cleartype включен.","Мессага",MB_OK);

    SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
    SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);

    MessageBox (NULL,"Фу! Cleartype + CRT моник = уродская картинка. Нафиг этот Cleartype","Мессага",MB_OK);
}
Re[5]: Поздравляю всех с кончиной Win32 API :))
От: CreatorCray  
Дата: 31.10.05 20:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, IPv6, Вы писали:


VD>Пример я уже привел Re[4]: Поздравляю всех с кончиной Win32 API :))
Автор: VladD2
Дата: 31.10.05
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.


Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++. Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.
Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?
Re[6]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 21:34
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>Лехко! А я то думал там будет что либо сложное...


Что же я изверг что ли?
Время то засек?

CC> Обычный косяк в MSDN...


Ой, МСДН-а ли? У меня в МСДН-е все ОК. Но вот назвать это нормальным я не могу.

CC> Ну не указали они что надо значение вместо указателя пхать. У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam.

CC>Так что тут надо дать по голове пьяным индусам из микрософт

Это ты заметил. А ты не обратил внимание на маразматичность ситуации когда нужно значение приводить к указаетелю? Ты считашь это нормальным?


CC>
CC>#include <windows.h>

CC>// Эти константы надо потому, что у меня дома 6-я старая вижуалка в .h которой этих определений нету
CC>#define FE_FONTSMOOTHINGCLEARTYPE    0x0002
CC>#define SPI_SETFONTSMOOTHINGTYPE    0x200B

CC>void main ()
CC>{
CC>    DWORD smoothType = FE_FONTSMOOTHINGCLEARTYPE;
CC>    SystemParametersInfo (SPI_SETFONTSMOOTHING, TRUE, NULL, 0);
CC>    SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, (void*)FE_FONTSMOOTHINGCLEARTYPE, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
    
CC>    MessageBox (NULL,"Cleartype включен.","Мессага",MB_OK);

CC>    SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
CC>    SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);

CC>    MessageBox (NULL,"Фу! Cleartype + CRT моник = уродская картинка. Нафиг этот Cleartype","Мессага",MB_OK);
CC>}
CC>


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

А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно:
// Запоминаем исходное значение настроек сглаживания.
FontSmoothingType initialFontSmoothingType = SysInfo.FontSmoothingType;

foreach (FontSmoothingType value in Enum.GetValues(typeof(FontSmoothingType)))
{
  SysInfo.FontSmoothingType = value;
  MessageBox.Show("Режим сглаживания - " + value + ".", "Мессага");
}

SysInfo.FontSmoothingType = initialFontSmoothingType;


Его конечно не сложно повторить и на С++, но почему-то это не делается. Вместо этого вот такие приколы с приведением констант к указателям на void. Причем зачем это было делать когда у метода есть целочисленный параметр? Да и вообще зачем деалать универсальную функцию в которую можно подсунуть все что угодно? Почему не сделать две специализированные? Это ведь позволило бы вообще не иметь проблем у программистов. Ну, и последнее... Зачем было вводить включение режима сглаживания и переключения типов сглаживания? Ведь проще было ввести тип сглаживания — None.

К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки:
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;
using System.Windows.Forms;
using System.Drawing;
using System.Diagnostics;
using Microsoft.Win32;

namespace Rsdn.Windows.Forms
{
    /// <summary>
    /// <b>FontSmoothingTypes</b> Specifies fontsmoothing/antialiasing.
    /// </summary>
    public enum FontSmoothingType : uint
    {
        None = 0,
        /// <summary>FE_FONTSMOOTHINGSTANDARD</summary>
        Standard = 1,
        /// <summary>FE_FONTSMOOTHINGCLEARTYPE</summary>
        ClearType = 2
    }

    public class VideoAdapterInfo
    {
        public VideoAdapterInfo(string name, Rectangle bounds)
        {
            _name = name;
            _bounds = bounds;
        }

        [DebuggerBrowsable(DebuggerBrowsableState.Never)]
        string _name;

        public string Name
        {
            get { return _name; }
        }

        [DebuggerBrowsable(DebuggerBrowsableState.Never)]
        Rectangle _bounds;

        public Rectangle Bounds
        {
            get { return _bounds; }
        }
    }

    /// <summary>
    /// <b>ClearTypeController</b> Wrapper class for Win32 IsFontSmoothingEnabled API. 
    /// Use Redraw() to perform instant changes.
    /// </summary>
    public class SysInfo
    {
        #region Импорт API-шных функций

        #region Константы

        enum RDW : uint
        {
            Invalidate = 1,    // 0x1;
            InternalPaint = 2,    // 0x2;
            Erase = 4,    // 0x4;
            AllChildren = 128,    // 0x80;
            UpdateNow = 256,    // 0x100;
            EraseNow = 512,    // 0x200;
            Frame = 1024,    // 0x400;
        }

        enum SPI : uint
        {
            GetFontSmoothing = 74,    // 0x004A;
            SetFontSmoothing = 75,    // 0x004B;
            GetFontSmoothingType = 8202,    // 0x200A;
            SetFontSmoothingType = 8203,    // 0x200B;
            GetFontSmoothingContrast = 8204,    // 0x200C;
            SetFontSmoothingContrast = 8205,    // 0x200D;
        }

        enum SPIF : uint
        {
            UpdateInifile = 1, // 0x1;
            SendChange = 2, // 0x2;
            SendWininiChange = 2, // 0x2;
            TELLALL = UpdateInifile | SendWininiChange, // 0x1 | 0x2;
        }

        #endregion


        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool RedrawWindow(IntPtr hWnd, int lprcUpdate,
            int hrgnUpdate, [MarshalAs(UnmanagedType.U4)] RDW flags);

        // SPI_SETFONTSMOOTHING
        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SystemParametersInfo(SPI uiAction, bool uiParam,
            IntPtr pvParam, SPIF fWinIni);

        // SPI_GETFONTSMOOTHING
        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
            out bool pvParam, SPIF fWinIni);

        // SPI_SETFONTSMOOTHINGTYPE &&  SPI_SETFONTSMOOTHINGCONTRAST
        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
            IntPtr pvParam, SPIF fWinIni);

        // SPI_GETFONTSMOOTHINGTYPE &&  SPI_GETFONTSMOOTHINGCONTRAST
        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
            out int pvParam, SPIF fWinIni);

        // SPI_GETFONTSMOOTHINGTYPE
        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        private static extern bool SystemParametersInfo(SPI uiAction, int uiParam,
            out FontSmoothingType pvParam, SPIF fWinIni);

        enum Monitor : uint
        {
            DefaultToNull = 0,
            DefaultToPrimary = 1,
            DefaultToNearest = 2,
        }

        /// <summary>
        /// 
        /// </summary>
        /// <param name="hwnd">handle to a window</param>
        /// <param name="dwFlags">determine return value</param>
        /// <returns></returns>
        [DllImport("user32.dll")]
        private static extern IntPtr MonitorFromWindow(IntPtr hwnd, Monitor flags);

        [StructLayout(LayoutKind.Sequential)]
        public struct RECT
        {
            public int left;
            public int top;
            public int right;
            public int bottom;

            public RECT(Rectangle r)
            {
                this.left = r.Left;
                this.top = r.Top;
                this.right = r.Right;
                this.bottom = r.Bottom;
            }

            public RECT(int left, int top, int right, int bottom)
            {
                this.left = left;
                this.top = top;
                this.right = right;
                this.bottom = bottom;
            }

            public static RECT FromXYWH(int x, int y, int width, int height)
            {
                return new RECT(x, y, x + width, y + height);
            }

            public int Width { get { return right - left; } }
            public int Height { get { return bottom - top; } }

            public Rectangle ToRectangle()
            {
                return new Rectangle(left, top, Width, Height);
            }

            public Size Size { get { return new Size(right - left, bottom - top); } }
        }


        [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto, Pack = 4)]
        class MONITORINFOEX
        {
            public MONITORINFOEX()
            {
                cbSize = Marshal.SizeOf(typeof(MONITORINFOEX));
            }

            private const int szDeviceSize = 0x20;

            public int cbSize;
            public RECT rcMonitor;
            public RECT rcWork;
            public int dwFlags;
            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = szDeviceSize)]
            public string Device;
        }

        //[DllImport("user32.dll")]
        //static extern bool GetMonitorInfo(IntPtr hMonitor, MONITORINFOEX lpmi);

        [DllImport("user32.dll", CharSet = CharSet.Auto)]
        static extern bool GetMonitorInfo(IntPtr hmonitor,
            [In, Out] MONITORINFOEX info);



        [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto, Pack = 4)]
        class DISPLAY_DEVICE
        {
            internal DISPLAY_DEVICE()
            {
                cb = Marshal.SizeOf(typeof(DISPLAY_DEVICE));
            }

            private const int DeviceNameSize = 32;
            private const int OtherSize = 128;

            int cb;

            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = DeviceNameSize)]
            internal string DeviceName;

            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
            internal string DeviceString;

            internal uint StateFlags;

            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
            string DeviceID;

            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = OtherSize)]
            internal string DeviceKey;
        };

        [DllImport("user32.dll", CharSet = CharSet.Auto)]
        static extern bool EnumDisplayDevices(string lpDevice, int iDevNum,
             [In, Out] DISPLAY_DEVICE lpDisplayDevice, uint dwFlags);

        #endregion

        #region Font smoothing information

        /// <summary>
        /// Gets or sets a value indicating whether font smoothing is enabled.
        /// </summary>
        public static bool IsFontSmoothingEnabled
        {
            get
            {
                bool fontSmoothing;
                Verify(SystemParametersInfo(SPI.GetFontSmoothing, 0,
                    out fontSmoothing, 0));
                return fontSmoothing;
            }

            set
            {
                Verify(SystemParametersInfo(SPI.SetFontSmoothing, value, IntPtr.Zero,
                    SPIF.SendWininiChange | SPIF.UpdateInifile));
            }
        }

        /// <summary>
        /// Gets or sets the current type of font smoothing.
        /// </summary>
        public static FontSmoothingType FontSmoothingType
        {
            get
            {
                FontSmoothingType fontSmoothingType;

                if (!IsFontSmoothingEnabled)
                    return FontSmoothingType.None;

                Verify(SystemParametersInfo(SPI.GetFontSmoothingType, 0,
                    out fontSmoothingType, 0));

                return fontSmoothingType;
            }

            set
            {
                bool isFontSmoothing = value != FontSmoothingType.None;

                IsFontSmoothingEnabled = isFontSmoothing;

                if (isFontSmoothing)
                    Verify(SystemParametersInfo(SPI.SetFontSmoothingType, 0,
                        (IntPtr)value, SPIF.SendWininiChange | SPIF.UpdateInifile));
            }
        }

        /// <summary>
        /// Gets or sets the font smoothing contrast value used in ClearType 
        /// smoothing.
        /// The value must be betwin 1000 and 2200. Default value 1400.
        /// </summary>
        public static int FontSmoothingContrast
        {
            get
            {
                int fontSmoothingContrast;

                Verify(SystemParametersInfo(SPI.GetFontSmoothingContrast, 0,
                    out fontSmoothingContrast, 0));

                return fontSmoothingContrast;
            }

            set
            {
                if (value > 2200 || value < 1000)
                    throw new ArgumentException(
                        "The value must be between 1000 and 2200.");

                Verify(SystemParametersInfo(SPI.SetFontSmoothingContrast, 0,
                    (IntPtr)value, SPIF.SendWininiChange | SPIF.UpdateInifile));
            }
        }

        #endregion

        #region Video Adapter information

        public static VideoAdapterInfo GetVideoAdapterInfo(IWin32Window wnd)
        {
            IntPtr hMonitor = MonitorFromWindow(wnd.Handle, Monitor.DefaultToNearest);
            Verify(hMonitor != IntPtr.Zero);

            // Получаем описание монитора
            MONITORINFOEX monitorInfoEx = new MONITORINFOEX();
            Verify(GetMonitorInfo(hMonitor, monitorInfoEx));

            // Ищем описание адаптера...

            string adapterDevName = monitorInfoEx.Device;
            string adapterName = "";

            // Перебираем все адаптеры и ищем среди них адаптер имя которого
            // совпадает с adapterDevName (полученным ранее из монитора).
            for (int i = 0; ; i++)
            {
                DISPLAY_DEVICE displayDevice = new DISPLAY_DEVICE();


                if (!EnumDisplayDevices(null, i, displayDevice, 0))
                    break;

                if (adapterDevName == displayDevice.DeviceName)
                {
                    adapterName = displayDevice.DeviceString;
                    break;
                }
            }

            return new VideoAdapterInfo(adapterName,
                monitorInfoEx.rcMonitor.ToRectangle());
        }

        #endregion

        #region Processor information

        public static string GetProcessorName()
        {
            using (RegistryKey hKey = Registry.LocalMachine.OpenSubKey(
                    @"Hardware\Description\System\CentralProcessor\0"))
            {

                string processor = (string)hKey.GetValue(
                    "ProcessorNameString", "unknown");

                int mhz = Convert.ToInt32(hKey.GetValue("~MHz", 0));

                if (mhz > 0)
                    processor += string.Format(" ({0} MHz)", mhz);

                return processor;
            }
        }

        #endregion

        #region Вспомогательные методы

        /// <summary>
        /// Проверяет значение параметра <paramref name="test"/> и возбуждает
        /// исключение Win32Exception если оно равно false.
        /// </summary>
        [DebuggerHidden]
        private static void Verify(bool test)
        {
            if (!test)
                throw new Win32Exception();
        }

        /// <summary>
        /// Redraw the Windows desktop area and active windows. Returns true on 
        /// success and false if it fails.
        /// </summary>
        public static bool Redraw()
        {
            bool status = RedrawWindow(IntPtr.Zero, 0, 0,
                RDW.Erase | RDW.Frame | RDW.AllChildren | RDW.InternalPaint
                | RDW.Invalidate | RDW.EraseNow | RDW.UpdateNow);

            return status;
        }

        #endregion
    }
}
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Поздравляю всех с кончиной Win32 API :))
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 21:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++.


К дотнету.

CC> Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.


А тебя не напрягает, что в дотнете доступны горы кода нре доступные в С++? WinFX — это управляемая библиотека. Этим все сказано.

CC>Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?


Когда как. Вот WinFX в основном реализован на C# (частично на МС++). Только на низком уровне используются неуправляемый код (для отрисовки примитивов).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.