Я уже это подозревал, но вот тут наткнулся на прямой ответ одного из сотрудников МС.
Он отвечал на вопрос есть ли в Лонгхоне новый анменеджед АПИ?
Вот его ответ:
WinFX is not a managed wrapper around new Win32 native APIs; it's a new
managed API, implemented primarily in managed code. The only way to access
the new WinFX features is through this managed API.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
There are no
corresponding native APIs.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are starting a new project, we recommend
that you write it in managed code, which will provide maximum benefit,
particularly around the areas of security and reliability. However, if you
have existing native code and you'd like to take advantage of WinFX without
rewriting your app then you can use a language interop mechanism such as
that provided by Managed C++ to call WinFX from native code.
----------
Leonardo Blanco Windows Client Platform Group, Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
... << RSDN@Home 1.1 beta 2 >>
31.10.05 14:48: Перенесено модератором из '.NET' — TK
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я уже это подозревал, но вот тут наткнулся на прямой ответ одного из сотрудников МС.
VD>Он отвечал на вопрос есть ли в Лонгхоне новый анменеджед АПИ?
VD>Вот его ответ: VD>
VD>WinFX is not a managed wrapper around new Win32 native APIs; it's a new
VD>managed API, implemented primarily in managed code. The only way to access
VD>the new WinFX features is through this managed API.
VD>vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
VD>There are no
VD>corresponding native APIs.
VD>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
VD> If you are starting a new project, we recommend
VD>that you write it in managed code, which will provide maximum benefit,
VD>particularly around the areas of security and reliability. However, if you
VD>have existing native code and you'd like to take advantage of WinFX without
VD>rewriting your app then you can use a language interop mechanism such as
VD>that provided by Managed C++ to call WinFX from native code.
VD>----------
VD>Leonardo Blanco
VD>Windows Client Platform Group, Microsoft Corporation
VD>This posting is provided "AS IS" with no warranties, and confers no rights.
Здравствуйте, gbush, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
G>Ядро все равно на COM
С чего бы? На С++ да на асм-е. Хотя КОМ понятие растяжимое. В каком-то смысле сам дотнет на КОМ. По крайней мере он там есть.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Поздравляю всех с кончиной Win32 API :))
От:
Аноним
Дата:
05.11.03 05:42
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gbush, Вы писали:
G>>Здравствуйте, VladD2, Вы писали:
G>>Ядро все равно на COM
VD>С чего бы? На С++ да на асм-е. Хотя КОМ понятие растяжимое. В каком-то смысле сам дотнет на КОМ. По крайней мере он там есть.
Здравствуйте, VladD2, Вы писали:
VD>Я уже это подозревал, но вот тут наткнулся на прямой ответ одного из сотрудников МС. VD>Он отвечал на вопрос есть ли в Лонгхоне новый анменеджед АПИ?
VD>Вот его ответ: VD>
VD>WinFX is not a managed wrapper around new Win32 native APIs; it's a new
VD>managed API, implemented primarily in managed code. The only way to access
VD>the new WinFX features is through this managed API.
VD>vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
VD>There are no
VD>corresponding native APIs.
VD>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Типа, началась жизнь после смерти?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>particularly around the areas of security and reliability. However, if you VD>have existing native code and you'd like to take advantage of WinFX without VD>rewriting your app then you can use a language interop mechanism such as VD>that provided by Managed C++ to call WinFX from native code.
это что, без перекомпиляции у них _ни одно_ старое (к тому времени) приложение не будет работать? да на###г такая операцинка
Здравствуйте, IPv6, Вы писали:
VD>>particularly around the areas of security and reliability. However, if you VD>>have existing native code and you'd like to take advantage of WinFX without VD>>rewriting your app then you can use a language interop mechanism such as VD>>that provided by Managed C++ to call WinFX from native code.
IP>это что, без перекомпиляции у них _ни одно_ старое (к тому времени) приложение не будет работать? да на###г такая операцинка
Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Аноним, Вы писали:
А>Основа все равно та же.
Конечно та же. Ведь CLR — unmanaged application. Но только все перенесено на другой уровень. Теперь не нужно проходить кучу стадий чтобы вызвать API функцию.
Здравствуйте, TK, Вы писали:
TK>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
А старые запретят писать? Вынут клаву из под рук. Или это философский вопрос про то, что старое остаеться старым, пока не перепишиться заново.
Здравствуйте, Mika Soukhov, Вы писали:
MS>А старые запретят писать? Вынут клаву из под рук. Или это философский вопрос про то, что старое остаеться старым, пока не перепишиться заново.
конечно нет, пишите. вот только использовать новые возможности будет нельзя.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, IPv6, Вы писали:
VD>>>particularly around the areas of security and reliability. However, if you VD>>>have existing native code and you'd like to take advantage of WinFX without VD>>>rewriting your app then you can use a language interop mechanism such as VD>>>that provided by Managed C++ to call WinFX from native code.
IP>>это что, без перекомпиляции у них _ни одно_ старое (к тому времени) приложение не будет работать? да на###г такая операцинка
TK>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
Я думаю просто поменяется ситуация... Win32 API станет враппером над maneged API. ТО есть старые приложения работать будут, но медленне чем .NET
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Mika Soukhov, Вы писали:
MS>>А старые запретят писать? Вынут клаву из под рук. Или это философский вопрос про то, что старое остаеться старым, пока не перепишиться заново.
TK>конечно нет, пишите. вот только использовать новые возможности будет нельзя.
Исходя из субъективных мироощущений — преобладающая часть программистов не умеет использовать и "старые" возможности.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
TK>>конечно нет, пишите. вот только использовать новые возможности будет нельзя.
КД>Исходя из субъективных мироощущений — преобладающая часть программистов не умеет использовать и "старые" возможности.
Так эти старые возможности после выхода Лонгхорн будут с ужасом вспоминать. Примерно, как программирование Windows под чистым C.
Здравствуйте, mihailik, Вы писали:
TK>>>конечно нет, пишите. вот только использовать новые возможности будет нельзя.
КД>>Исходя из субъективных мироощущений — преобладающая часть программистов не умеет использовать и "старые" возможности.
M>Так эти старые возможности после выхода Лонгхорн будут с ужасом вспоминать. Примерно, как программирование Windows под чистым C.
Наверное.
Тем не менее, сдается мне, пропорции сохранятся. Поскольку закон Энштейна(?) — "количество ума вещь постоянная, а население растет" пока никто не отменял
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Hello, "Ведмедь"
> > Я думаю просто поменяется ситуация... Win32 API станет враппером над maneged API. ТО есть старые приложения работать будут, но медленне чем .NET
Существующие приложения будет работать только быстрее (будущее: больше памяти, быстрые процессоры и т.п.) вот только возможности получить доступ к новой функциональности думаю, что не будет (и уже не важно кто кому будет враппером).
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
Уважаемый TK, поясните пожалуйста как они будут работать. В других сообщениях и в новостях говорилось о том, что нынешнего API не будет (т.е. как я понимаю совсем), а API будет нынешний .net (вернее та версия, которая будет в тот момент). Так какой же код будет выполняться при API вызове?
Hello, "Spark2K" > > TK>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET > > Уважаемый TK, поясните пожалуйста как они будут работать. В других сообщениях и в новостях говорилось о том, что нынешнего API не будет (т.е. как я понимаю совсем), а API будет нынешний .net (вернее та версия, которая будет в тот момент). Так какой же код будет выполняться при API вызове?
То, что нынешнего Win32 API не будет совсем — на это, наверное, не стоит рассчитывать (например с момента выхода Windows 3.x прошло уже больше 10-ти лет, а до сих пор в WinXP есть поддержка Win16...)
Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.
А какой код будет выполнять при вызове API, то тут могу сказать точно — это будет код API фукции.
PS.
Еще не известно — может в Longhorn и поддержка Win16 будет... Пока про ее удаление ничего особо не говорили
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Про вырезание — в этом я тоже несколько сомневаюсь.
Скорее всего эти слухи вызваны тем что MS обещал в несколько раз сократить количество функций Win32 API. Это не означает что этих функций не будет, просто они будут объявлены deprecated и не рекомендованы к использованию, как тот же GetCurrentTime() к примеру.
TK>PS. TK>Еще не известно — может в Longhorn и поддержка Win16 будет...
Здравствуйте, TK, Вы писали:
TK>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
Я бы сказал так. Если старому приложению захочется использовать новые возможности (WinFS, Avalon, ...) то оно вынужденно будет делать это через дотнет, т.е. его придется перекомпилировать под дотнет (МС++, Дельфи.НЭТ, ...).
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>100% будет?
AVK>Да
Странновато. В общем-то можно было бы уже и не поддерживать совместимость с 16-битными приложениями. А где они об этом говорят? Мне что-то не попадалось..
Здравствуйте, TK, Вы писали:
TK>Существующие приложения будет работать только быстрее (будущее: больше памяти, быстрые процессоры и т.п.) вот только возможности получить доступ к новой функциональности думаю, что не будет (и уже не важно кто кому будет враппером).
Скорость вещь относительная. Думаю, на одном и том же железе старые приложения будут быстрее работать на ХаРэ, так как не будет никаких лишних действий. Я где-то в СДК Лонгхорна читал, что мол старые приложения будут рабоать с ВинФС почти так же быстро как и новые... Т.е. факт, что не так же. Да и то, что новые будут работать быстрее чем на старой ОС не факт.
Доступ же к фичам получить будет можно двумя способами. Первый компиляция в МС++. Второй использование КОМ-враперов работающих через интероп. Правда тут скорее всего будет доступ только к ВинФС. Авалон так скорее всего не прокатит, или будет дико тормозить.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
VD>>С чего бы? На С++ да на асм-е. Хотя КОМ понятие растяжимое. В каком-то смысле сам дотнет на КОМ. По крайней мере он там есть.
А>а какже объекты.NET?
Не понял вопроса. В ядре никакого .NET пока не будет.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Странновато. В общем-то можно было бы уже и не поддерживать совместимость с 16-битными приложениями. А где они об этом говорят? Мне что-то не попадалось..
Э...э... у меня 16-битная бухгалтерия до сих пор работает. Что же мне ее перписвать?
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
TK>>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
VD>Я бы сказал так. Если старому приложению захочется использовать новые возможности (WinFS, Avalon, ...)
С чего-бы это старому приложению захотеть использовать новые возможности?
Мне всегда казалось, что про новые возможности сначала узнают разработчики и только потом, они переписывают старые приложения на новый лад... (считаем, что приложения с элементами AI особо не распространены...)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>То, что нынешнего Win32 API не будет совсем — на это, наверное, не стоит рассчитывать (например с момента выхода Windows 3.x прошло уже больше 10-ти лет, а до сих пор в WinXP есть поддержка Win16...)
TK>Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.
Много говорят о новой файловой системе WinFS, котороя будет несовместима с NTFS и FATXX. Ясно, что многие приложения так или иначе работают с файлами, поэтому возникает вопрос: старые приложения через "старый" API будет работать с новой FS или если используешь новую FS — прощай страрые проги?
Здравствуйте, Spark2K, Вы писали:
TK>>Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.
SK>Много говорят о новой файловой системе WinFS, котороя будет несовместима с NTFS и FATXX. Ясно, что многие приложения так или иначе работают с файлами, поэтому возникает вопрос: старые приложения через "старый" API будет работать с новой FS или если используешь новую FS — прощай страрые проги?
NTFS и FATXX так-же не совместимы друг с другом, так-же не совместимо хранилище Exchange, сетевые папки, HTTP сервер через WebDAV протокол. Между тем существующие приложения через стандартный WinAPI могут работать со всеми ими и не испытывать никаких проблем...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>NTFS и FATXX так-же не совместимы друг с другом, так-же не совместимо хранилище Exchange, сетевые папки, HTTP сервер через WebDAV протокол. Между тем существующие приложения через стандартный WinAPI могут работать со всеми ими и не испытывать никаких проблем...
Я же не утверждаю, что это невозможно. Я только спрашиваю как это будет работать.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, VladD2, Вы писали:
TK>>>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
VD>>Я бы сказал так. Если старому приложению захочется использовать новые возможности (WinFS, Avalon, ...)
TK>С чего-бы это старому приложению захотеть использовать новые возможности? TK>Мне всегда казалось, что про новые возможности сначала узнают разработчики и только потом, они переписывают старые приложения на новый лад... (считаем, что приложения с элементами AI особо не распространены...)
Думается, имелась в виду возможность апгрейда старых приложений с минимальными изменениями.
Здравствуйте, Spark2K, Вы писали:
SK>Здравствуйте, TK, Вы писали:
TK>>NTFS и FATXX так-же не совместимы друг с другом, так-же не совместимо хранилище Exchange, сетевые папки, HTTP сервер через WebDAV протокол. Между тем существующие приложения через стандартный WinAPI могут работать со всеми ими и не испытывать никаких проблем...
SK>Я же не утверждаю, что это невозможно. Я только спрашиваю как это будет работать.
Я полагаю, что для таких вещей, как старый API, NTFS и пр. создадут множество враперов, которые будут обеспечивать выполнение классических операций ОС в старом стиле через новое API. Приблизительно так, как это происходит при смене разрядностей процессоров. Ведь на них же выполняется старый код. На процессорах это обеспечить значительно сложнее, чем в ОС.
Здравствуйте, Spark2K, Вы писали:
SK>Здравствуйте, TK, Вы писали:
TK>>То, что нынешнего Win32 API не будет совсем — на это, наверное, не стоит рассчитывать (например с момента выхода Windows 3.x прошло уже больше 10-ти лет, а до сих пор в WinXP есть поддержка Win16...)
TK>>Про вырезание — в этом я тоже несколько сомневаюсь. Скорее всего развитие Win32 API просто остановится и в дальнейшем все развитие будет сосредоточенно на longhorn api.
SK>Много говорят о новой файловой системе WinFS, котороя будет несовместима с NTFS и FATXX. Ясно, что многие приложения так или иначе работают с файлами, поэтому возникает вопрос: старые приложения через "старый" API будет работать с новой FS или если используешь новую FS — прощай страрые проги?
Чушь, WinFS совместима с NTFS, а следовательно диск с WinFS будет работать под 2000.
Здравствуйте, <Аноним>, Вы писали:
А>Чушь, WinFS совместима с NTFS, а следовательно диск с WinFS будет работать под 2000.
Квоть по меньше...
Совместимо будет API. Т.е. в Лонгхорне будет API обеспечивающее доступ к разделу WinFS как к обычному NTFS -разделу. Так же сам WinFS физически будет лежать на обычном NTFS-разделе. Но получить доступ к содержимому WinFS -тома из-под W2k будет нельзя.
WinFS реализован на базе MS SQL Server (Юкон), т.е. фактически новая файловая система — это надстройка над реляционной БД.
В WinFS к данным можно будет обращаться как к объектам (вернее коллекциям объектов), реляционным данным или как к XML-данным.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>WinFS реализован на базе MS SQL Server (Юкон), т.е. фактически новая файловая система — это надстройка над реляционной БД.
Жаль, что того умника, который четыре года назад крутил пальцем у виска, когда я ему про это говорил, рядом нет. Отряд не заметил потери бойца
VD>В WinFS к данным можно будет обращаться как к объектам (вернее коллекциям объектов), реляционным данным или как к XML-данным.
В свете всей этой хрени, как то настораживает будущее других серверов баз данных под Windows ... Это будет реальная хохма — типа "MSSQL помогает Oracle хранить его данные"
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>WinFS реализован на базе MS SQL Server (Юкон), т.е. фактически новая файловая система — это надстройка над реляционной БД. VD>В WinFS к данным можно будет обращаться как к объектам (вернее коллекциям объектов), реляционным данным или как к XML-данным.
вот это _очень_ сильно. только сильно сомневаюсь что сам этот юкон будет managed. уж файловой системе от закидонов сборщика мусора нельзя никак зависить. ну или распрощаться с понятием "система реального времени" даже в отдаленном представлении (в каком NT/2000/XP сейчас еще является)
Здравствуйте, IPv6, Вы писали:
IP>Здравствуйте, VladD2, Вы писали:
VD>> ну или распрощаться с понятием "система реального времени" даже в отдаленном представлении (в каком NT/2000/XP сейчас еще является)
Что-что чем является? Это где ж вы, мил человек, нашли в nt/2000/xp реальное время?...
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>В свете всей этой хрени, как то настораживает будущее других серверов баз данных под Windows ... Это будет реальная хохма — типа "MSSQL помогает Oracle хранить его данные"
Oracle гордо достанет из кармана свой RAW Partition, оденется во все коричневое и будет эээ... портить всем в углу настроение..
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>В свете всей этой хрени, как то настораживает будущее других серверов баз данных под Windows ... Это будет реальная хохма — типа "MSSQL помогает Oracle хранить его данные"
Не. Хохмой будет то, что БД оракла будет реально храниться в виде файла внутри MSSQL. А еще можно в Оракле ихнюю распределенную файловую систему запуситить. Вот это будет эмуляция эмулятора на эмуляторе.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IPv6, Вы писали:
IP>вот это _очень_ сильно. только сильно сомневаюсь что сам этот юкон будет managed.
А тут и сомневаться нечено. Конечно... не будет. Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...
IP> уж файловой системе от закидонов сборщика мусора нельзя никак зависить.
Это почему? Ничего страшного в сборке мусора нет.
IP> ну или распрощаться с понятием "система реального времени" даже в отдаленном представлении (в каком NT/2000/XP сейчас еще является)
NT никогда не отвечала требованиям предявляемым к системам реального времени.
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
КД>В свете всей этой хрени, как то настораживает будущее других серверов баз данных под Windows ... Это будет реальная хохма — типа "MSSQL помогает Oracle хранить его данные"
Ну, на самом деле в доках на MSDN видул упоминание о том, что WinFS (особенно по-первости) коснется исключительно Document and Settings. А проги будут по прежнему на старом добром NTFS жить.
Здравствуйте, Merle, Вы писали:
M>Oracle гордо достанет из кармана свой RAW Partition, оденется во все коричневое и будет эээ... портить всем в углу настроение..
А что он научился пользоваться RAW Partition-ом под виндами? Или ему Юкон помог?
... << RSDN@Home 1.1 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Ну, на самом деле в доках на MSDN видул упоминание о том, что WinFS (особенно по-первости) коснется исключительно Document and Settings. А проги будут по прежнему на старом добром NTFS жить.
Здравствуйте, Аноним, Вы писали:
А>Основа все равно та же.
Мда-с...
А может, MS наконец-то и от РЕЕСТРА хранимого по файлам избавиться? А то всё оно никак... ... вот иногда "затирает" улии реестра просто и со вкусом и только на консоль восстановления (заблаговременно установленную) уповать и приходиться...
представляю, что будет, если это всё в MS SQL-евом виде "навернётся"
файловые системы "древовидные";
реестр, где самые главные настройками ОС в тысячя-цатых ветках замурованы;
API для совместимостей всего чего было со всем чем ещё можно будет...
и событийная модель, где иногда непонятно "кто за кем стоял".
Вы тут спорите о том, удет ли предыдущий API включен в Longhorn или не будет. Как можно будет запускать приложения, основанные на ныне существующем интерфейсе. Но, не стоит забывать, что Windows Longhorn выйдет, ориентировочно, только в 2006 году. Это через два с половиной — три года. Добавим год — два на, так сказать, разгон. Имеем: около четырёх лет в запасе!
Это очень немалый срок. И, думаю, уже к тому времени все забудут о существующем API и будут использовать .Net. За исключением некоторых сфер разработки ПО (теоретически). За четыре года Microsoft может успеть всех разработчиков переориентировать на .Net. Говорят, в 2004 году, чуть ли не каждый квартал количество разработчиков под .Net будет удваиваться. И к 2006-2007 годам, думаю, данный вопрос уже не будет целесообразен. Размышления.
Re[4]: Поздравляю всех с кончиной Win32 API :))
От:
Аноним
Дата:
21.11.03 10:52
Оценка:
SK>Уважаемый TK, поясните пожалуйста как они будут работать. В других сообщениях и в новостях говорилось о том, что нынешнего API не будет (т.е. как я понимаю совсем), а API будет нынешний .net (вернее та версия, которая будет в тот момент). Так какой же код будет выполняться при API вызове?
Почти цитата из BDD2003, когда представитель Майкрософта выступал и рассказывал про этот лонгхорн он сказал следующее: старые программы работать будут, но развитие win32 полностью останавливается и win32 будет примерно такой-же надстройкой, вроде того как сейчас windows поддерживает DOS.
Re[2]: Поздравляю всех с кончиной Win32 API :))
От:
Аноним
Дата:
21.11.03 11:32
Оценка:
Здравствуйте, Ummagumma, Вы писали:
U>Вы тут спорите о том, удет ли предыдущий API включен в Longhorn или не будет. Как можно будет запускать приложения, основанные на ныне существующем интерфейсе. Но, не стоит забывать, что Windows Longhorn выйдет, ориентировочно, только в 2006 году. Это через два с половиной — три года. Добавим год — два на, так сказать, разгон. Имеем: около четырёх лет в запасе!
U>Это очень немалый срок. И, думаю, уже к тому времени все забудут о существующем API и будут использовать .Net. За исключением некоторых сфер разработки ПО (теоретически). За четыре года Microsoft может успеть всех разработчиков переориентировать на .Net. Говорят, в 2004 году, чуть ли не каждый квартал количество разработчиков под .Net будет удваиваться. И к 2006-2007 годам, думаю, данный вопрос уже не будет целесообразен. Размышления.
А всегда думал, что к тому времени останутся только программисты под Linux.
разработчиков под .Net будет удваиваться. И к 2006-2007 годам, думаю, данный вопрос уже не будет целесообразен. Размышления.
>А всегда думал, что к тому времени останутся только программисты под Linux.
нет — эти вымрут 2-3 годами раньше. Хотя и щас это не назвать жизнью =)
Здравствуйте, <Аноним>, Вы писали:
А>Почти цитата из BDD2003, когда представитель Майкрософта выступал и рассказывал про этот лонгхорн он сказал следующее: старые программы работать будут, но развитие win32 полностью останавливается и win32 будет примерно такой-же надстройкой, вроде того как сейчас windows поддерживает DOS.
Надо сказать, что как раз ДОС виндовс поддерживает великолепно. Да и слова эти в основном пока рекламма. Но правда в том, что новые выпендрежи можно быдет получить только через дотнет. Даже для ком только через КОМ-интероп.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Поздравляю всех с кончиной Win32 API :))
От:
Аноним
Дата:
22.11.03 06:23
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>А чем тебе помешают транзакции при работе с реестром?
А вот тогда вопрос — что блокировки будут так же страничные как в MS SQL если там Юкон будет?
D>Что-что чем является? Это где ж вы, мил человек, нашли в nt/2000/xp реальное время?...
Все условно. В отличие от Win98 на NT работает масса индустриальных приложений, которые успевают пару раз за секунду пообщатся с какой нибудь железкой по RS и прорисовать состояние котла в реальном времени.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>А чем тебе помешают транзакции при работе с реестром?
А>А вот тогда вопрос — что блокировки будут так же страничные как в MS SQL если там Юкон будет?
MS SQL есть не только страничные блокировки, я думаю — они разберуться, какие блокировки лучше юзать для реестра.
Здравствуйте, VladD2, Вы писали:
VD>Я уже это подозревал, но вот тут наткнулся на прямой ответ одного из сотрудников МС.
VD>Он отвечал на вопрос есть ли в Лонгхоне новый анменеджед АПИ?
VD>Вот его ответ: VD>[q] VD>WinFX is not a managed wrapper around new Win32 native APIs; it's a new VD>managed API, implemented primarily in managed code. The only way to access VD>the new WinFX features is through this managed API.
Но он видать забыл сказать, что помимо WinFX в лонгхорне будет еще туча новых unmanaged API.
Не надо быть наивным по поводу смерти Win32, Win32 настолько захардкожен в винду, что он никуда не денется.
Здравствуйте, VladD2, Вы писали:
VD>А тут и сомневаться нечено. Конечно... не будет. Но от этого ничего не меняется. Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих. Так что...
А откуда дровишки?
Личные наблюдения/тесты или это из маркетинговых заявлений MS?
Хотелось бы ещё услышать почему.
Попробуй почитать статьи на этом сайте.
EC>Личные наблюдения/тесты или это из маркетинговых заявлений MS? EC>Хотелось бы ещё услышать почему.
Потому что написан эффективно. Там датастрим (формат пакета МS SQL) разбирается прямо на шарпе. Так что чтение через дата-ридер шустрее чем через OLE DB.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Поздравляю всех с кончиной Win32 API :))
От:
Аноним
Дата:
29.10.05 20:36
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Странновато. В общем-то можно было бы уже и не поддерживать совместимость с 16-битными приложениями. А где они об этом говорят? Мне что-то не попадалось..
VD>Э...э... у меня 16-битная бухгалтерия до сих пор работает. Что же мне ее перписвать?
Надеюсь 4-битная у тебя тоже имеется и работает на каком-нибудь крупном предприятии?
).
VD>Потому что написан эффективно. Там датастрим (формат пакета МS SQL) разбирается прямо на шарпе. Так что чтение через дата-ридер шустрее чем через OLE DB.
А OLE DB Provider написан неэффективно?
За счёт чего шустрее?
Ты имеешь в виду, что если ходить напрямую через OLE DB, то это всё равно менее эффективно или ты про ADO?
Здравствуйте, EvilChild, Вы писали:
EC>А OLE DB Provider написан неэффективно?
OLE DB может быть написан не эффктивно. Это зависит от реализации. Но тут речь не о том. Сама архитектура OLE DB несколько менее эффективна чем подход используемый в управляемом интерфейсе к MSSQL.
EC>За счёт чего шустрее? EC>Ты имеешь в виду, что если ходить напрямую через OLE DB, то это всё равно менее эффективно или ты про ADO?
Цитирую себя:
Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих.
Так вот ADO приципиально работает через OLE DB. И даже при использовании его из ассемблера оно все равно будет проигрывать управляемому провайдору для MSSQL, так как последний написан очень эффективно и не имеет кучи промежуточных (и не нужных в данном случае) промежуточных абстракций.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>OLE DB может быть написан не эффктивно. Это зависит от реализации. Но тут речь не о том. Сама архитектура OLE DB несколько менее эффективна чем подход используемый в управляемом интерфейсе к MSSQL.
Так может быть или написан неэффективно?
В чём архитектура OLE DB проигрывает .NET'ной?
Можно услышать какие-то технические детали?
VD>Цитирую себя: VD>
Менеджед интерфейс к MSSQL и сегодня самый быстрый из существующих.
Твоё самоцитирование ничего не объясняет.
VD>Так вот ADO приципиально работает через OLE DB. И даже при использовании его из ассемблера оно все равно будет проигрывать управляемому провайдору для MSSQL, так как последний написан очень эффективно и не имеет кучи промежуточных (и не нужных в данном случае) промежуточных абстракций.
То что ADO работает поверх OLE DB я и так знаю.
Вопрос в другом: что в OLE DB Provider реализовано криво/неоптимально и что в .NET Provider сделано лучше, что .NET реализация получается быстрее.
Или то, что оно на .NET написано, автоматом делает его быстрее/лучше?
Здравствуйте, EvilChild, Вы писали:
EC>Так может быть или написан неэффективно? EC>В чём архитектура OLE DB проигрывает .NET'ной? EC>Можно услышать какие-то технические детали?
Ты читал спецификацию OLE DB?
EC>Вопрос в другом: что в OLE DB Provider реализовано криво/неоптимально и что в .NET Provider сделано лучше, что .NET реализация получается быстрее. EC>Или то, что оно на .NET написано, автоматом делает его быстрее/лучше?
Ты понимашь чем прямой рабзор протокола передачи данных отличается от возни через 25 КОМ-интерфейсов/объектов?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, EvilChild, Вы писали:
EC>>Так может быть или написан неэффективно? EC>>В чём архитектура OLE DB проигрывает .NET'ной? EC>>Можно услышать какие-то технические детали?
VD>Ты читал спецификацию OLE DB?
Я читал
VD>Ты понимашь чем прямой разбор протокола передачи данных отличается от возни через 25 КОМ-интерфейсов/объектов?
И через пять лет чтения, я таки понял эти "25 интерфейсов" Правда не понял этот вопрос на вопрос.
OLEDB (с точки зрения реализации) проигрывает ADO.NET провайдеру только в тех позициях, где .NET выигрывает у COM. И наоборот. Все остальные измышления — бесполезный бред и трата времени, которые обусловлены толщиной и длиной шворцев.
Формально, в крупном приложении по-барабану через что работать — что через OLEDB напрямую (но только не для начинающих и только не через ATL.OLEDB и только не явно через интерфейсы), что через ADO (здесь проще, но есть нюансы), что через .NET-провайдер.
Но пять лет назад, с точки зрения масштабируемости архитектуры конечного приложения, OLEDB был самым оптимальным выбором (правда начальная стоимость очень высокая). И на текущий момент, лично для меня, ничего не поменялось. Правда основная херня в том что MS не предоставила шлюз OLEDB провайдер<->OLEDB.NET провайдер, как это было сделано для ADODB в виде незадокументированных интерфейсов конструирования. Но, слава Богу, не первый год замужем
В любом случае, глядя на свой провайдер, скажу, что нормальный драйвер (OLEDB/NET) "на ура" написать не реально. И постепенно уровень сложности реализации станет такого уровня, что один два лишних вызова (слоя) — это даже не копейки. Спрашиваете "почему"? Да потому, что драйвер (перешедший на промышленный уровень) однозначно будет состоять из двух уровней — того, с которым вы общаетесь наверху, и того, который общается с БД. А между этими двумя уровнями будут лежать абстрактные интерфейсы
Только для зрителей нашего телеканала, часть списка файлов OLEDB-провайдера для FireBird:
...и на RSDN появятся статьи типа "Как незаметно использовать .Net в DLL" и библиотеки обёрток из .Net в C. Для маньяков.
Кстати, это уже было. С COM. Помните, в NTFS5 появилась возможность задавать квоты для пользователей?
Так вот, в WinApi накаких SetUserQuota() не появилось. Появилась кучка интерфейсов IDiskQuota*.
То же самое BITS, IDiscMaster, про shell я вообще молчу — там ещё с 95-той все по-новому.
Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
Думаю и в висте пара новых функций для Wow64 объявится. Но не более.
Здравствуйте, VladD2, Вы писали:
VD>Ты понимашь чем прямой рабзор протокола передачи данных отличается от возни через 25 КОМ-интерфейсов/объектов?
Очень много раз перечитал, долго думал
Насчет "возни" — судьба такая у OLEDB. И назначение.
Насчет прямой передачи. Ну дык это. OLEDB грузит и представляет данные через свой свой интерфейс. А ADO.NET грузит и представляет через свой.
Если идет связка ADO.NET — OLEDB, то, ясный пень, есть затраты на переконвертацию из одного интерфейса в другой.
Но здесь есть одно но. Звено native->OLEDB может быть написано более качественно, чем native->ADO.NET и затраты последнего будут выше чем native->OLEDB->ADO.NET
Но опять же, в реальности, на эти затраты можно положить.
Главное — предоставляемая функциональность на последнем уровне.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Mika Soukhov, Вы писали:
TK>>Старые приложения работать будут (на то они и старые). разговор о том, что для того, что-бы писать новые нужно будет использовать .NET
MS>А старые запретят писать? Вынут клаву из под рук. Или это философский вопрос про то, что старое остаеться старым, пока не перепишиться заново.
Раньше любая новая фича сопровождалась 2 уровнями API — winapi + надстройка в виде .net. Теперь от нас будут умышленно прятать winapi, хотя реально то он вряд ли куда то денется. Довольно неумный шаг в продвижении дотнета.
Здравствуйте, Аноним, Вы писали:
ВВ>>>Странновато. В общем-то можно было бы уже и не поддерживать совместимость с 16-битными приложениями. А где они об этом говорят? Мне что-то не попадалось.. VD>>Э...э... у меня 16-битная бухгалтерия до сих пор работает. Что же мне ее перписвать? А>Надеюсь 4-битная у тебя тоже имеется и работает на каком-нибудь крупном предприятии?
как количество бит коррелирует с качеством софтины?
Здравствуйте, VladD2, Вы писали:
VD>Потому что написан эффективно. Там датастрим (формат пакета МS SQL) разбирается прямо на шарпе. Так что чтение через дата-ридер шустрее чем через OLE DB.
Ну так, насколько я помню, есть же такая найтивная для SQl Server вещь как DB Library? Как утверждается в документации, все остальные интерфейсы поверх нее реализованы. Но, я так понял, что ты имел ввиду хорошую и быструю логику обработки абстракций (типов, данных и т.д.) через управляемый интерфейс? Хлтя и здесь мы ведь имеем дело с плоскими массивами данных.
Здравствуйте, Блудов Павел, Вы писали:
БП>...и на RSDN появятся статьи типа "Как незаметно использовать .Net в DLL" и библиотеки обёрток из .Net в C. Для маньяков. БП>Кстати, это уже было. С COM. Помните, в NTFS5 появилась возможность задавать квоты для пользователей? БП>Так вот, в WinApi накаких SetUserQuota() не появилось. Появилась кучка интерфейсов IDiskQuota*. БП>То же самое BITS, IDiscMaster, про shell я вообще молчу — там ещё с 95-той все по-новому. БП>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие. БП>Думаю и в висте пара новых функций для Wow64 объявится. Но не более. БП>Вот темы в XP почему-то сделали по-старинке.
Я думаю что народ больше переживает по поводу необходимости перелезания на managed языки и дотнет вместо старого доброго ассемблера в формате PE, а не по поводу собственно winapi
Ведь и шелл — тоже через API сделан, чтоб получить верхушку — надо вызвать обычную сишную функцию
U>Вы тут спорите о том, удет ли предыдущий API включен в Longhorn или не будет. Как можно будет запускать приложения, основанные на ныне существующем интерфейсе. Но, не стоит забывать, что Windows Longhorn выйдет, ориентировочно, только в 2006 году. Это через два с половиной — три года. Добавим год — два на, так сказать, разгон. Имеем: около четырёх лет в запасе!
Эта самая dotnet — она уже года 4 разгоняется (раздается и поддерживается). Я пока не замечаю победного шествования.
U>Это очень немалый срок. И, думаю, уже к тому времени все забудут о существующем API и будут использовать .Net. За исключением некоторых сфер разработки ПО (теоретически). За четыре года Microsoft может успеть всех разработчиков переориентировать на .Net. Говорят, в 2004 году, чуть ли не каждый квартал количество разработчиков под .Net будет удваиваться. И к 2006-2007 годам, думаю, данный вопрос уже не будет целесообразен. Размышления.
Да где уж там "забудут". Куча очень квалифицированного народу в msvc6 до сих пор сидит, не понимая на черта им дотнет. Переход msvc5->msvc6 проходил ГОРАЗДО шустрее, чем на msvc7(2003/2005).
Это заблуждение что весь мир программирует мышкой аддоны к офису и sql клиентов.
VD>>Э...э... у меня 16-битная бухгалтерия до сих пор работает. Что же мне ее перписвать?
А>Надеюсь 4-битная у тебя тоже имеется и работает на каком-нибудь крупном предприятии?
В Турции (и вообще, по-моему, везде) бухгалтерский софт должен пройти сертификацию Министерства Финансов, прежде, чем его можно будет использовать для выписывания счетов, например. То есть, можно на коленке наваять краасивые формочки для бухгалтеров, но вот отчетную документацию из этих формочек налоговая не примет никогда.
Вот сейчас, например процентов 80 фирм в Турции, если не больше сидят в 16-битной бухгалтерии. Потому что альтернатив нет (ну или почти нет).
Здравствуйте, 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 не реализовали.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>И через пять лет чтения, я таки понял эти "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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Блудов Павел, Вы писали:
БП>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
Во тут интересно — что с ним не так то? Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению
Здравствуйте, mefrill, Вы писали:
M>Ну так, насколько я помню, есть же такая найтивная для SQl Server вещь как DB Library? Как утверждается в документации, все остальные интерфейсы поверх нее реализованы.
Можно привести цитатату?
Насколько мне извесно OLEDB реализован напрямую. Да и дотнетный провайдер тоже. Он использует тольок очень низкоуровневую библиотеку для чтения сырого потока данных. Далее закат солнца вручную.
M>Но, я так понял, что ты имел ввиду хорошую и быструю логику обработки абстракций (типов, данных и т.д.) через управляемый интерфейс? Хлтя и здесь мы ведь имеем дело с плоскими массивами данных.
OLEDB это еще тот монстр. Так чт и да, и нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Блудов Павел, Вы писали:
БП>>Так что API давным-давно не развивается. Так, доделывают по мелочи — ReOpenFile, FindFirstStreamW, FlsAlloc всякие.
VD>Откровенно говоря за Win32 API нужно руки по туловище отрубать. Спроектировано оно просто ужасно. Но новые КОМ-повские расширения в большинстве случаев стали еще более ужасными.
VD>Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?
Здравствуйте, aik, Вы писали:
aik>Во тут интересно — что с ним не так то?
Кривизна, сложность и неудобсность в использовании.
aik> Оно ведь просто отражает реализацию. Если API кажется кривым, то ровно от того, что описываемая им область криво спроектирована, либо просто кривая по определению
Иногда случается и так. Но то что обертывание в менеджед обертки зачастую координально упрощает использование ВыньАПИ указывает именно на кривость реализации.
Простой пример который мне пришлось опробывать на своей шкуре совсем недавно. Функция SystemParametersInfo. Попробуй, например, с ее помощью сменить режим сглаживания шрифта на ClearType.
А как тебе интерфейсы OLEDB? А Защиты в СOM? Да куда не копни убогие и дико переусложненные интерфейсы.
А reserved-апраметры напиханные там и тут? А названия методов выбираемые рандомом (например, перечисли все методы вывода текста на экран в Windows).
Просто те кто этим ужасом пользуются сильно привыкли и не замечают маразма ситуации.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, aik, Вы писали:
aik>Раньше любая новая фича сопровождалась 2 уровнями API — winapi + надстройка в виде .net. Теперь от нас будут умышленно прятать winapi, хотя реально то он вряд ли куда то денется. Довольно неумный шаг в продвижении дотнета.
Вот Indigo и Avalon ничего не прячют. Они и есть исходное АПИ. Где-то в глубине недр они конечно обращаются к низкоуровневым АПИ ОС, но используя эти АПИ получить тот же результат просто не удастся. И сделано это не в целях продвижения дотнета (что это самоцель, что ли?), а в целях упрощения разработки и поддержки. Ну, и с целью уменьшения оверхэда создаваемого интеропом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IPv6, Вы писали:
IP>вот мне тоже интересно в чем конкретно кривость? единственное что можно поставить в вину винапям так это то что оно частично само себя дублирует (иногда не по разу), его использование имеет побочные эффекты иногда. мелочи вроде наличия нескольких стандартов обращения/передачи параметров опустим. что еще?
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 занимает совсем чуть-чуть. И это правильно!
Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Хотя нет... IRow и IRowChange были созданы, когда кого-то в MS запарило работать с аксессорами
Эксессоры сами по себе ужасны и избыточны.
КД>Я и написал — напрямую не выйдет. Только через ADO. Я работаю без напрягов через свою плюсовую библиотеку
С тем же успхом она могла бы работать напрямую с датастримом (как АДО.НЭТ). Так что приемущество от ОЛЕДБ тут только в его стандартности. Но ведь ОДБЦ был сто лет назад, и я уверен, что для твоей обертки работать с ним было бы куда проще.
КД>Насчет убогости — это ты зря. Просто сложная для понимания вещь. Но только дураки постоянно с ней живут.
Под убогостью я и понимаю сложность и неуклюжесть. С воможностями то там все ОК. Но все тоже самое делается куда проще. Просто не нужно было добиваться супер универсальности.
КД>В реальности, визуальные ActiveX компоненты гораздо сложнее. Я помню как тебя терроризировал относительно UserForm
А это тоже пример дебилизма АПИ. Только я все же ActiveX отношу к АПИ КОМ-а. Но по сути это тоже ВыньАПИ.
Честно говоря ActiveX и ОЛЕ2 проектировали тоже не вполне разумные люди. Я в этой каше года два разбирался, но вопросы остались. По сравнеию с этими технологиями ВыньФормс и их контролы — это супер гладкая архитектура и приятнейший АПИ. Жаль что только по сранвению.
КД>По-моему это внутренности MSSQL.
Я тоже так думал. Но когда копнул глубже, то оказалось, что и ОЛЕДБ, и ДБЛИБ, и ОДБЦ работают через практически одно и то же низкоуровневое АПИ и друг-друга не используют. А узнал я это как раз когда разбирался с тем как написан управляемый провайдер.
КД> Причем родил эту спецификацию явно человек с оторванным сознанием Многие вещи я понял только недавно, а он это родил еще в 98
По-моему, раньше, но может я тут ошибаюсь. Не, не ошибаюсь. Рядом, в коридоре, валяется справочник по ОЛЕДБ 1.1 дебильно переведенный "Русской редакцией" в 1997 году. Стало быть 1.0 было где-то в 1996-ом.
А сделан ОЛЕДБ был вроде бы как когда делали внешние запросы в сиквеле. Но думаю, планы были наполеоновскими. А ОЛЕ там появилось, так как в это время в МС все пытались переписать на КОМ.
КД>Ну, это, ставить ODBC рядом с OLEDB, это все равно что котенка сравнивать с тигром
Хм. ОЛЕДБ это тигр, или котенок? Для котенка очень уже жирный и огромный, а для тигра не поворотливый и опять же жирный.
Кстати, что тебе не хватает в ОДБЦ по сравнению с ОЛЕДБ?
КД>Ну и ху$и ??? Меня это не радует абсолютно.
Это, за мат здесь банят. Даже за такой. Так что в этот раз я не заметил. Но в следующий, не обессудь.
КД>Так вот у меня тормозит в основном сервер, куда отправляются запросы, клиент, который эти запросы посылает и управляющие VB-скрипты, которые помогают клиенту генерировать эти запросы. Утрировано, конечно, но смысл такой — подозреваю что доля провайдера в общем объеме затрат CPU — ГОРАЗДО меньше 10%
Я и не утверждаю, что скорость интерфейса может существенно замедлить прилоежение. Я всего лишь, сказал, что то что Юкон не менеджед не мешает с ним эффекивно работать, и привел обоснование. А тут дескуссия вокруг ОЛЕДБ организовалась.
КД>И если раньше я жался насчет каждого вызова к провайдеру/сервер, типа "не дай бог использовать автоматическое формирование определений параметров!", то сейчас мне на это положить. Гораздо ценнее глобальная оптимизация системы Хотя, по старинке, продолжаю в работать только через SQL запросы.
VD>>Кстати, управляемый провайдер для MSSQL занимает совсем чуть-чуть. И это правильно!
КД>Я тоже люблю маленькие машины, но внедорожники нравятся гораздо больше — им что в гору ехать, что с горы — по-барабану
Ох уж эти аналогии. И почему ты ОЛЕДБ к внедорожникам отнес? Работает ОЛДБ при доступе к сиквелу медленее. Используется наверно уже тоже реже чем нэйтивный провайдер. Так о чем разговор то?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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);
}
. Сделай что там описано, и или поймшь все сам, или хотя бы будет предмет для разговора. Пока что говорить с тобой бесполезно. Нормального АПИ ты явно не видел, так что для тебя ВыньАПИ — это нормально. Для меня тоже оно было нормально... до тех пор покая не увидел, что бывает куда лучше.
Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++. Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.
Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Дык вся проблема то не в том что API другой, а в том, что новый API гвоздями прибит к Managed C++.
К дотнету.
CC> Вот это как раз и не нравится многим. Я например жутко не люблю когда меня вынуждают что то делать чего мне сильно не хочется. И считаю позицию мелкомягких "мы так решили а вы никуда не денетесь!" неуважением к программерам, которые пишут под вынь.
А тебя не напрягает, что в дотнете доступны горы кода нре доступные в С++? WinFX — это управляемая библиотека. Этим все сказано.
CC>Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет?
Когда как. Вот WinFX в основном реализован на C# (частично на МС++). Только на низком уровне используются неуправляемый код (для отрисовки примитивов).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что же я изверг что ли? VD>Время то засек?
Неа. разве что только примерно...
я там где то дальше ответил с прикидками по времени. нет времени сейчас искать, сорри
CC>> Обычный косяк в MSDN... VD>Ой, МСДН-а ли? У меня в МСДН-е все ОК.
CC>> У меня их кста 2 шт (MSDN-а) так в одном написано что надо передавать указатель на значение а в другом что надо передавать значение в uiParam.
VD>Это ты заметил. А ты не обратил внимание на маразматичность ситуации когда нужно значение приводить к указаетелю? Ты считашь это нормальным?
Дело в том, что это не первый такой косяк... Я уже довольно много на такую хрень наталкивался. Так что можно сказать — это "особенность реализации"
CC>> SystemParametersInfo (SPI_SETFONTSMOOTHINGTYPE, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE); CC>> SystemParametersInfo (SPI_SETFONTSMOOTHING, FALSE, NULL, 0);
VD>А запоминать исходный вариант кто будет? VD> Да и во втором случае ты не включашь стандартное сглаживаение, ты выключаешь его вовсе.
Дык а зачем? задача стояла включить. Да и выключаю я (предварительно кстати задав обычный режим сглаживания, его значение = 0) только потому, что у меня оно отключено и со включенным сглаживанием на ЭЛТ все выглядит ИМХО ужасно.
VD>А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно:
По мне так это не API а обертка...
VD>К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки:
[skipped]
по моему тут явный перебор... "слишком многа обуви!" (с)
Здравствуйте, VladD2, Вы писали:
VD>К дотнету.
Пардон, опшипся
VD>А тебя не напрягает, что в дотнете доступны горы кода нре доступные в С++?
неа, не напрягает совершенно. Они мне эти горы покуда не понадобились. Тех гор, которые накоплены в сях мне пока хватает с избытком. VD>WinFX — это управляемая библиотека. Этим все сказано.
Меня интересует возможность вызова этой библиотеки из неуправляемого кода.
CC>>Кстати на эту тему вопрос: расскажите кто в курсе, а "Managed API" этож все равно вызовы функций из DLL или нет? VD>Когда как. Вот WinFX в основном реализован на C# (частично на МС++). Только на низком уровне используются неуправляемый код (для отрисовки примитивов).
Меня это интересует с точки зрения как ее юзать не из .нет, если все же микрософт похерит нормальный API (а мне для системного программирования он и нужен).
Здравствуйте, aik, Вы писали:
aik>Эта самая dotnet — она уже года 4 разгоняется (раздается и поддерживается). Я пока не замечаю победного шествования.
Я тоже. Просто всё это время на ней пишу, и почему-то проекты всё крупнее и их всё больше. aik>Да где уж там "забудут". Куча очень квалифицированного народу в msvc6 до сих пор сидит, не понимая на черта им дотнет. Переход msvc5->msvc6 проходил ГОРАЗДО шустрее, чем на msvc7(2003/2005).
Это да. Сегодня лично видел код перцев, недавно перелезших с плюсов — "декораторы", "визиторы", круто! Даже неудобно было говорить, что использование хотя бы Data Access Application Block сведёт всё к двум строкам кода. А во втором дотнете хватит и одной.
aik>Это заблуждение что весь мир программирует мышкой аддоны к офису и sql клиентов.
кто ж спорит!
Здравствуйте, CreatorCray, Вы писали:
CC>Дело в том, что это не первый такой косяк... Я уже довольно много на такую хрень наталкивался. Так что можно сказать — это "особенность реализации"
И я. Но называю это "Особенностями национальной халтуры".
VD>>А вот как выглядит тоже самое на базе АПИ которое спроектировано более размуно: CC>По мне так это не API а обертка...
А какая разница что там внутри? АПИ — это интерфейс к чему-то. SystemParametersInfo тоже не сама все делает. Она обращается к другим АПИ.
Я же говорю о качестве проектирования, а не о том что там под копотом.
А качество очень невысокое. Конечно бывает и хуже, но и это не притяно. На работу с таким АПИ тратится куча времени. Особенно много времени тратится при изучении.
Даже поиск нужной функции/интерфейса занимает уйму времени. На программы с таким АПИ приходится убивать в разы больше времени, нежели на анологичные но создающиеся с использованием добротного АПИ. Думаю, одно это уже подталкивает к выбору фрэймворков со стройным и удобным АПИ.
VD>>К сожалению, чтобы из убогого ВыньАПИ-стиля сделать то что я продемонстрировал приходится писать вот такие вот обертки: CC>[skipped]
CC> по моему тут явный перебор... "слишком многа обуви!" (с)
Ну, там до кучи еще много чего просто. Не выдерать же из работающего кода куски?
Хотя конечно траха не мало. Зато в итоге простой, читабельный код и безопасный код.
Собственно о том и говорю, что если бы АПИ Виндовс сразу проектировалось грамотно, то и таких монстров клепать не приходилось бы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, VladD2, Вы писали:
CS>Кончина подзатянулась,
CS>Ровно как два года сообщению.
С тех пор произошли некоторые перемены. А именно из Лонхорна перед тем как он стал Вистой убрали весь managed code, за исключением .NET FX. WPF & WinFX в основную поставку Висты не входит, только как дополнение. WinFS, вообще выходит позже. Explorer из managed переделался в native, как я когда-то и говорил
. Вывод можно сделать такой: Майкрософт попытался сделать как сам советует: "If you are starting a new project, we recommend that you write it in managed code, which will provide maximum benefit...", и у него не сильно-то вышло. Пришлось немного откатить до следующей версии Windows. К тому времени WinFX и все эти framework'и устоятся, выдержат не по одному сервис паку. Тогда и можно будет говорить о переходе с native и написании программ исключительно на managed коде.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, что тебе не хватает в ОДБЦ по сравнению с ОЛЕДБ?
Я c ODBC ни разу не общался, но исхожу из того, что это набор функций, которые управляют ресурсами через дескрипторы.
У меня приложения состоят из модулей. Модули должны как-то согласованно использовать общие ресурсы. В случае БД это подключение и транзакции.
Дескипторы этой согласованности не предоставляют, а компоненты OLEDB — как раз для этого и придумывались.
По-моему в ODBC сильно хромает масштабируемость системы типов.
В OLEDB же:
Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
Многие вещи, которые изначально казались глупыми, наоборот повлияли на реализацию. Например, центральный метод для выполнения всех типов запросов ICommand::Execute. Обычно разделяют методы для выполнения запросов, возвращающих множества и не возвращающих множества. Пока не реализовал свой парсер SQL-запросов, было тяжко подвести всех под одну гребенку
А потом понял, что через IOpenRowset::OpenRowset тоже можно запросы выполнять. Полгода перестраивал хоровод объектов, управляющих выполнением запросов, отделяя интерфейсы от реализации. Но, в конечном итоге, получил такую конфету, что самому нравится. Новые фичи FB2, которые раньше бы меня свалили в кому, добавляются без проблем. Нет, проблемы конечно есть, но не такие страшные.
Обработка ошибок в OLEDB повлияла на мое понимание исключений — как без напрягов, с обеспечением локализации, доставлять информацию о произошедшем сбое. Так, что бы конечный пользователь (или программер), смог понять что не так. В провайдере больше 200 шаблонов сообщений об ошибках.
Я помню, с каким пылом я спорил с тобой относительно реализации точек уведомлений — так вот, только недавно, когда реализовывал уведомления о коммитах и откатах, понял как должна выглядеть реализация комовских точек подключений. И как обеспечить реентерабельность.
Структура интерфейсов. Хотя их и много, но основная идея заключена в создании коротких специализированных интерфейсов. Хотя, на мой взгляд, в наборе IRowset-подобных интерфейсов перестарались с наследованием.
Концептуальных ошибок, влиящих на устойчивость, я знаю только одну — передача COM-объектов в качестве параметров команды. Но это было сглажено качественной документацией.
Возможно, если сказать честно — мне прет не сколько эта технология, сколько мой подход к её реализации — C++ был заюзан под самое нехочу. Но тут надо отдать должное возможностям и самого сервера IB/FB.
КД>>И если раньше я жался насчет каждого вызова к провайдеру/сервер,
VD>Это ты вот тут расскажи: VD>История одной оптимизации
Да ну их в баню
VD>Ох уж эти аналогии. И почему ты ОЛЕДБ к внедорожникам отнес? Работает ОЛДБ при доступе к сиквелу медленее. Используется наверно уже тоже реже чем нэйтивный провайдер. Так о чем разговор то?
Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. Сейчас вот победили проблему с .NET (люблю я Борланд, но странною любовью). Маленький, но все таки еще один шаг к новом и светлому будущему, где пишутся по-настоящему интересные программы
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Я c ODBC ни разу не общался, но исхожу из того, что это набор функций, которые управляют ресурсами через дескрипторы.
C API и эмуляция ООП. Что же ты хочшь?
КД>Дескипторы этой согласованности не предоставляют, а компоненты OLEDB — как раз для этого и придумывались.
Да? С чего бы это?
КД>По-моему в ODBC сильно хромает масштабируемость системы типов.
Нет там таких проблем.
КД>Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
А зачем?
КД>А потом понял, что через IOpenRowset::OpenRowset тоже можно запросы выполнять. Полгода перестраивал хоровод объектов, управляющих выполнением запросов, отделяя интерфейсы от реализации. Но, в конечном итоге, получил такую конфету, что самому нравится. Новые фичи FB2, которые раньше бы меня свалили в кому, добавляются без проблем. Нет, проблемы конечно есть, но не такие страшные.
Боюсь, что это не конфетка, а тортик. Тольк вот ингридиенты подвели. Сложность черезмерная и не нужная.
Я тоже рашьне думал, что так инадо. Но вот видимо с годами приходит озарение.
КД>Обработка ошибок в OLEDB повлияла на мое понимание исключений — как без напрягов, с обеспечением локализации, доставлять информацию о произошедшем сбое. Так, что бы конечный пользователь (или программер), смог понять что не так. В провайдере больше 200 шаблонов сообщений об ошибках.
Прочесть локаль пользователя и сформировать стрку.
КД>Возможно, если сказать честно — мне прет не сколько эта технология, сколько мой подход к её реализации — C++ был заюзан под самое нехочу. Но тут надо отдать должное возможностям и самого сервера IB/FB.
Я понимаю твою гордость и удовольствие. Ты действительно сделал огромный труд, и я не сомневаюсь, что сделал его хорошо. Но это никак не оправдывает того что тебе пришлось написать такие горы кода. И никак не оправдывает того, что без АДО использование твоего провайдера привращается в муку.
Попробуй написать родной АДО.НЭТ-провайдер. А потом опишешь ощущения. Боюсь, тебя постигнет разочарование. Ты поймшь, что все что ты с успехом поборол было всего лишь созданные другими бессмысленные припоны.
КД>Да ну их в баню
Не, в баню слишком радикально.
КД>Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. Сейчас вот победили проблему с .NET (люблю я Борланд, но странною любовью). Маленький, но все таки еще один шаг к новом и светлому будущему, где пишутся по-настоящему интересные программы
Ну, если это доставляет удовольстие...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
КД>>Навороченность интерфейсов, которая всех так сильно пугает, меня наоборот убивает своей дальновидностью Я в начале этого года соорудил в своем провайдере поддержку вложенных транзакций. Так вот внутренние объекты практически полностью продублировали структуру OLEDB-ных.
VD>А зачем?
Зачем что? Продублировали? Да кто его теперь уже знает Интерфейсы внутренних объектов я проектирую и тестирую отдельно. В случае транзакций, оказалось что все (в виде ITransaction, ITransactionLocal и их отношения) придумали до меня
В свете этого знания, такие интерфейсы как этот, вызывают у меня желание биться головой о стену.
VD>Боюсь, что это не конфетка, а тортик. Тольк вот ингридиенты подвели. Сложность черезмерная и не нужная.
Ага, у меня уже пару лет вся рожа в креме
VD>Я тоже рашьне думал, что так инадо. Но вот видимо с годами приходит озарение.
Ну что бы понять интерфейс, с ним нужно прожить очень долго. OLEDB, это еще ничего. Тут иногда встречаешься с более мощными шедеврами.
Например, недавно я порадовался набору dbExpress. Мой диагноз — нужно меньше курить траву. И ввести наркологический контроль при приеме на работу. Я бы его сжал если не 50, то на 30% однозначно.
КД>>Обработка ошибок VD>Прочесть локаль пользователя и сформировать строку.
Не все так просто. Локаль ты подставляешь не в точке генерации исключения. Но это не важно. Важно то, сколько усилий нужно приложить для инициализации объекта исключений. У меня можно в одну строчку. Я описывал
как это выглядит. Второе — ошибка, пока едет наверх, может включиться как составная часть другой ошибки, а может попасть в коллекцию. Для того что бы это граммотно спроектировать реализацию такого поведения исключений пришлось выпить не одну бутылку.
VD>И никак не оправдывает того, что без АДО использование твоего провайдера привращается в муку.
Я не использую ADO, при программировании на плюсах. Мои враперы дают более сжатый исходник и быстрый бинарник. Проверено временем У ADO есть ценные трюки, но я основные подсмотрел и слямзил
и в примерах на нашем сайте. Жаль, правда, что когда я её планировал и писал у меня не было моего текущего опыта
VD>Попробуй написать родной АДО.НЭТ-провайдер. А потом опишешь ощущения. Боюсь, тебя постигнет разочарование. Ты поймшь, что все что ты с успехом поборол было всего лишь созданные другими бессмысленные припоны.
ADO.NET это просто виток с начала. И явное разделение этого слоя на два уровня — на тот, который общается с сервером, и тот, который потом эти данные хранит на клиенте. Разумно, но не интересно. Особенно, когда напишешь репликатор и осознаешь технологию выгрузки/загрузки данных.
Это с одной стороны. С другой — проще вряд ли получиться. Я тоже когда то думал, что запросы я могу просто подготовить и выполнить. Увы, сейчас для каждого типа запроса (DDL, select, insert, execute procedure, start transaction, commit, rollback, точки сохранений и т.д. и т.п.) пишется специализированная поддержка. Как я уже писал, со временем начинаешь управлять таким огромным числом мелких деталей, что приходится переходить на многоуровневую реализацию. Иначе наступает смерть проекта. Трое уже померли. Я про конкурентов
Так что подобие твоего ADO.NET у меня работает внутрях провайдера Процентов 10 от общего объема работы.
Главное, постоянно помнить, что пишешь всего лишь провайдер, а не сам сервер
КД>>Да я не вообще OLEDB, а конкретно свой провайдер. Мы его юзаем везде, где только можно. VD>Ну, если это доставляет удовольстие...
Ну вот, записали в садомазохисты
OLEDB это фигня. Вот программирование на BCB3 вставляло гораздо сильнее — натуральная "игра в сапера". Правда, потом я все таки переполз на BCB5 — нервы не выдержали
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, VladD2, Вы писали:
VD>Когда появлися дотнет, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо. Сначало я подумал, что дело тут в отсуствии указателей и т.п. Но потом понял, что дело в основном в намного более серьезном и грамотном отношеии к проектированию.
Сергей Губанов с Обероном...
Влад с .NET...
Ничего личного... просто пописал на 1С... много думал...
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>А что тут думать — Антон Батенев с ЯБУН'ом ...
Д>а что это за страшный зверь такой?
Пользуйтесь поиском по сайту
Кстати мысль вот.
Первого апреля на RSDN создать конференцию на один день. Посвященную проблеме программирования на этом самом
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Anton Batenev, Вы писали:
AB>>Сергей Губанов с Обероном... AB>>Влад с .NET... AB>>Ничего личного... просто пописал на 1С... много думал... КД>А что тут думать — Антон Батенев с ЯБУН'ом ... КД>Ничего личного ...
ЯБУН — "язык бухгалтерский — универсального назначения", если что...
Перечитал еще раз фразу Влада, но подставил этот самый:
Когда появлися ЯБУН, я с удивлением обнаружил, что и АПИ может иметь человеческое лицо.
[...]
VD>---------- VD>Leonardo Blanco VD>Windows Client Platform Group, Microsoft Corporation VD>This posting is provided "AS IS" with no warranties(Выделено мной. — ГВ), and confers no rights. VD>[/q]
Ну английским же по белому было сказано!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
вот почитал ветку и подумал — у MS — WinAPI, захотела — будем под .net писать и ни куда не денемся — вспомните хотя бы переходный период dos->win. Хоть я и не поклонни Java но обидно, что альтернативная платформа остается в тени... хотя ведь может ?? Очередной раз убеждаюсь — у кого деньги и рынок — тот владеет всем. Ситация почти как из поговорки "если гора не идет к Магомеду, то Магомед пойдет к горе" — почти про MS и dev .NET
Здравствуйте, DivnenkoIvan, Вы писали:
DI>вот почитал ветку и подумал — у MS — WinAPI, захотела — будем под .net писать и ни куда не денемся — вспомните хотя бы переходный период dos->win. Хоть я и не поклонни Java но обидно, что альтернативная платформа остается в тени... хотя ведь может ?? Очередной раз убеждаюсь — у кого деньги и рынок — тот владеет всем. Ситация почти как из поговорки "если гора не идет к Магомеду, то Магомед пойдет к горе" — почти про MS и dev .NET
Деньги и рынок — это бабушкина логика. Каждый получает ровно столько результатов, сколько усилий и ума он вложил.
Или это философский вопрос про то, что старое остаеться старым, пока не перепишиться заново. 
ICQ#: 198114726
Мы уже победили, просто это еще не так заметно...
* thriving in a production environment *
при попытке обратиться к COM3 
по моему тут явный перебор... "слишком многа обуви!" (с) 
