Вопрос к знающим людям.

"
Означает ли Windows Vista конец собственных Windows API?
В блоге MSDN опубликована на эту тему заметка одного из разработчиков Windows Vista:

Мне часто задают подобный вопрос и, кажется, пришло время дать публичный ответ…

Вопрос обычно звучит так:
«Происходит ли отказ Microsoft от Windows API в Vista в пользу классовых API?»

Или:
«Все ли в Windows Vista теперь требует разработок на .NET Framework 3.0 и мне никогда не придется вернутся к старым добрым временам?»

Собственные Windows API все еще присутствуют в Vista. В то время как .NET Framework 2.0 и .NET Framework 3.0 дают отличные классовый интерфейс, мы понимаем, что очень многие приложения (в том числе и наши) работают на базе Windows API и будут продолжать их использовать. Фактически собственные API в Vista даже обрели новый возможности – начиная от настольного поиска и расширяемости Explorer вплоть до таких элементов интерфейса, как TaskDialog. Некоторая новая функциональность Windows Vista использует исключительно собственные Windows API.

Но разработчики должны медленно отходить от устаревших API и перемещаться к управляемому коду и .NET Framework – но мы будем поддерживать обе модели долгое, очень долгое время.

"

Я так понимаю что .NET Framework с первой версии базировались на Windows API(потому и быстрее не стали,потому и абсолютно схожая функциональность,обёрнутая в удобные классы).Сейчас вроде есть взгляд в сторону других(но своих же) интерфейсов,но в итоге все равно это будет строительство на собственных костях .Я так думаю хорошим вариантом было бы -- полный отказ от старой платформы,в виде создания дотнетпроцессора+соответвусщая windows без старого наследия.Понимаю утопия.Понимаю что на это микрософт не решится.Но х е р знает ))) Кудаж идёт Windows?

Здравствуйте, dipso, Вы писали:
D>Я так понимаю что .NET Framework с первой версии базировались на Windows API(потому и быстрее не стали,потому и абсолютно схожая функциональность,обёрнутая в удобные классы).Сейчас вроде есть взгляд в сторону других(но своих же) интерфейсов,но в итоге все равно это будет строительство на собственных костях .Я так думаю хорошим вариантом было бы -- полный отказ от старой платформы,в виде создания дотнетпроцессора+соответвусщая windows без старого наследия.Понимаю утопия.Понимаю что на это микрософт не решится.Но х е р знает ))) Кудаж идёт Windows?
В ближайшие десять лет отказаться от Windows API не удастся.

Для того, чтобы понять почему, надо немножко разбираться в архитектуре ОС.
Пока что нет никакого способа для пользовательского процесса позвать системный сервис, кроме как загрузить библиотеку, найти экспорт, и сделать вызов.
Эту процедуру можно обернуть в классы на управляемом либо неуправляемом языке, но от этого API никуда не денется.

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

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

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

Странно слышать от тебя такое. АПИ не имеет никакого отношения ни к платформе, ни к тому как оно реализовано.

То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС. Так же надо понимать, что функциональность может реализоваться и в оберточном коде. Причем управляемые обертки могут спокойно дергать любой неуправляемый код, а вот наоборот сделать куда сложнее (и на практике практически не делается). В итоге через некоторое время управляемые API "обрастут мясом", заматереют и повторить их в неуправляемых API будет уже невозможно. Потом (возможно... очень возможно) появятся управляемые ОС и управляемые API будут перенесены на них. Программы написанные с использованием управляемых API возможно даже не прийдется перекомпилировать для запуска на других платформах, а вот неуправляемые программы просто невозможно будет перенести на новые платформы.

Так что Win API конечно будет жить еще очень долго. Возможно более десяти лет (это не так уж и много), но это будет происходить исключительно из-за того, что много программ его используют. МС пока что боится писать на дотнете что-то серьезное. Тот же офис как я понял, так и не будет переписан. Но потихоньку управляемые API будут отедать рынок и в конечном итоге окажутся более функциональными. Так что надеяться на то, что Win API будет вечным я бы не стал. К тому же он очень кривой. В общем, дотнет бы я выбрал только за то, что кривостью он не страдает.

D>Я так понимаю что .NET Framework с первой версии базировались на Windows API(потому и быстрее не стали,потому и абсолютно схожая функциональность,обёрнутая в удобные классы).Сейчас вроде есть взгляд в сторону других(но своих же) интерфейсов,но в итоге все равно это будет строительство на собственных костях .Я так думаю хорошим вариантом было бы -- полный отказ от старой платформы,в виде создания дотнетпроцессора+соответвусщая windows без старого наследия.Понимаю утопия.Понимаю что на это микрософт не решится.Но х е р знает ))) Кудаж идёт Windows?

До тех пор пока ядро пишется на C никаких серьезных изменений в роли Windows API не предвидится.

Здравствуйте, VladD2, Вы писали:
S>>Для того, чтобы совсем "отказаться от старой платформы" нужно сначала придумать какую-то другую платформу, с другой моделью изоляции и взаимодействия процессов.
VD>Странно слышать от тебя такое. АПИ не имеет никакого отношения ни к платформе, ни к тому как оно реализовано.
Не очень понимаю, что ты имеешь в виду.
VD>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС.
Ок, что такое "низкоуровневые сервисы ОС"?
Афаик, это всё те же DLL с экспортами.

VD>Так же надо понимать, что функциональность может реализоваться и в оберточном коде.
Ну, может. Но это уже как бы библиотеки, а не сервисы. В том смысле, что библиотека находится в адресном пространстве клиентского процесса, и ничего "военного" не делает — можно загрузить другую библиотеку, которая делает то же самое.

VD>Причем управляемые обертки могут спокойно дергать любой неуправляемый код, а вот наоборот сделать куда сложнее (и на практике практически не делается).
Совершенно верно.
VD>В итоге через некоторое время управляемые API "обрастут мясом", заматереют и повторить их в неуправляемых API будет уже невозможно.
Э-э, по мне так итог совсем другой — при разработке новых API, которые должны вызываться всеми, удобнее сделать их неуправляемыми. Тогда можно иметь обертки обоих типов — управляемые и неуправляемые.

VD>Потом (возможно... очень возможно) появятся управляемые ОС и управляемые API будут перенесены на них. Программы написанные с использованием управляемых API возможно даже не прийдется перекомпилировать для запуска на других платформах, а вот неуправляемые программы просто невозможно будет перенести на новые платформы.

VD>Так что Win API конечно будет жить еще очень долго. Возможно более десяти лет (это не так уж и много), но это будет происходить исключительно из-за того, что много программ его используют. МС пока что боится писать на дотнете что-то серьезное. Тот же офис как я понял, так и не будет переписан. Но потихоньку управляемые API будут отедать рынок и в конечном итоге окажутся более функциональными. Так что надеяться на то, что Win API будет вечным я бы не стал. К тому же он очень кривой. В общем, дотнет бы я выбрал только за то, что кривостью он не страдает.
Хм, я скептически отношусь к этой перспективе. Ок, давай оставим в покое старые API. Ежу понятно, что банальный GetProcessInfo() никто не будет отменять, потому что им пользуются миллионы приложений.
Ок, давай посмотрим на новые API.
Что у нас там появилось в Win2k3? Новый API для HTTP серверов. HTTP Server API
Он был расширен в win2k8.
Что 1.0, что 2.0 — набор функций в httpapi.dll, + набор структур, объявленных в C хидерах.
Хотя в 2003 году можно было, наверное, сделать эти API и управляемыми. Не с чем ведь было поддерживать обратную совместимость.
Увы, всё осталось нативным.

Так что твоя точка зрения как минимум не совпадает с точкой зрения ответственного руководства в МС.

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

[]

VD>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС. Так же надо понимать, что функциональность может реализоваться и в оберточном коде.

Ну переходники там нифига не легкие. Кроме того, нормальный interop появился только с выходом c++/cli. Все остальное — трах с маршалингом. И никто не будет с этим связываться.

[]

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

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

А что разве еще не придумали? Теже Singularity или Active Oberon, который был выпущен ранее первой.
Конечно, это не промышленные разработки, а исследовательские, но они показывают, как можно строить ОС на безопасных языках по другим принципам.

Здравствуйте, Стэн, Вы писали:

S>>Для того, чтобы совсем "отказаться от старой платформы" нужно сначала придумать какую-то другую платформу, с другой моделью изоляции и взаимодействия процессов.
С>А что разве еще не придумали? Теже Singularity или Active Oberon, который был выпущен ранее первой.
С>Конечно, это не промышленные разработки, а исследовательские, но они показывают, как можно строить ОС на безопасных языках по другим принципам.
Угу. Обеим разработкам еще ехать до промышленного применения — как Оке до колец Сатурна.
По поводу Singularity авторы неоднократно комментировали, что она никогда не рассматривалась иначе как proof of concept, и для построения full blown OS нужно продумать еще очень-очень много принципиальных моментов. Не думаю, что это случится быстрее, чем к 2020 году.
По поводу активного оберона у меня вообще очень скептическое мнение. Пытаться реализовывать софтную изоляцию на неуправляемой платформе можно было двадцать лет назад. Сейчас это уже даже в качестве шутки не шибко смешно.

Можно посмотреть, как постепенно трансформировалась и исчезала поддержка DOS- и Win16-приложений. Поскольку винды конечно сильны именно приложениями и наработанными во всем мире workflow, то само собой никуда Win32 по-быстрому не денется. Вот если MS заявит о новой ситеме с "поддержкой совместимости с Win32", где этот api уже будет жить в отдельной песочнице, вот тогда, имхо, самое время постепенно начинать волноваться.

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

<skip>

1. Вы не забывайте, что есть тонны софта написанного на WinAPI. Врядли вы найдете огромный энтузиазм у разработчиков резко ринутся переписывать все это хозяйство на новые рельсы.
2. Кроме прикладного софта, существует еще и системный, например Vmware. Я себе очень слабо представляю как (?!?!) сделать динамическую бинарную трансляцию на .NET (да впрочем как и на Java).

Здравствуйте, Dio Elaclaire, Вы писали:
DE>2. Кроме прикладного софта, существует еще и системный, например Vmware. Я себе очень слабо представляю как (?!?!) сделать динамическую бинарную трансляцию на .NET (да впрочем как и на Java).
Ну, VMWare уже умеет работать поверх bare metal, так что ей более-менее всё равно.

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

Вообще согласен, но небольшие уточнения.

VD>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС.

Не всегда. Некоторые функции Win API не переключают в ядро. Так что в .Net их придется реализовать самому дотнету.

>Так же надо понимать, что функциональность может реализоваться и в оберточном коде. Причем управляемые обертки могут спокойно дергать любой неуправляемый код, а вот наоборот сделать куда сложнее (и на практике практически не делается). В итоге через некоторое время управляемые API "обрастут мясом", заматереют и повторить их в неуправляемых API будет уже невозможно.

В принципе нет ничего невозможного в переносе .Net в ядро. Кстати, и прецедент есть — в Windows NT 3.x GDI/USER были в 3 кольце, а в NT 4.0 их утащили в ядро. Вообще исходная концепция Windows NT претерпела довольно существенные изменения по сравнению с исходной. В исходной Win32 была лишь одной из подсистем наряду с OS/2 и POSIX. Сейчас эти 2 тихо исчезли, а Win32 стала обязательной. Но ничто не мешает реализовать подсистему .Net, хотя скорее всего этого не будет.

>Потом (возможно... очень возможно) появятся управляемые ОС и управляемые API будут перенесены на них. Программы написанные с использованием управляемых API возможно даже не прийдется перекомпилировать для запуска на других платформах, а вот неуправляемые программы просто невозможно будет перенести на новые платформы.

Анекдот вспомнился, старый

Никсон — богу. Когда в Америке исчезнут проблемы с неграми ? Лет через 30, ответил бог. Жаль, сказал Никсон, я не доживу.
Голда Меир — богу. Когда прекратится арабский терроризм ? Лет через 50, ответил бог. Жаль, сказала Голда, я не доживу
Брежнев — богу. Когда в СССР будет порядок ?
Бог подумал и сказал — я не доживу.


VD>Так что Win API конечно будет жить еще очень долго. Возможно более десяти лет (это не так уж и много), но это будет происходить исключительно из-за того, что много программ его используют. МС пока что боится писать на дотнете что-то серьезное.

И видимо, не пока, а окончательно. Дотнету уже больше 5 лет, а серьезные производители ПО на него переходить не спешат. В сущности, можно подводить уже итог. В области web-приложений дотнет имеет определенный успех, ASP.NET решительно потеснил ASP и, возможно, откусил кое-что от PHP, Java и т.д. (точнее судить не берусь). В области десктопных приложений дотнет оказался заменой не C++, а Visual Basic 6.0 (и, может быть, Delphi), вытеснив их в той нише, которую они занимали. Ниша это определяется очень просто — это приложения, делаемые под заказ. Что же касается приложений обще-ИТ характера, то там успехи дотнета если не нулевые, то очень незначительные.


>Тот же офис как я понял, так и не будет переписан. Но потихоньку управляемые API будут отедать рынок и в конечном итоге окажутся более функциональными. Так что надеяться на то, что Win API будет вечным я бы не стал. К тому же он очень кривой.

+1

>В общем, дотнет бы я выбрал только за то, что кривостью он не страдает.

Просто он еще слишком молод. Вот проживет он столько, сколько Win API, и тоже окривеет. Просто потому, что модификации (а без них не обойтись) понемногу разъедают стройность, заложенную в исходной модели. Win16 был тоже менее кривым,чем Win32.

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

D>Я так понимаю что .NET Framework с первой версии базировались на Windows API(потому и быстрее не стали,потому и абсолютно схожая функциональность,обёрнутая в удобные классы).

Т.е. предполагается что если сделать всё строго на .NET то будет всё быстрее?
А за счет чего собственно?

Постоянно эта мулечка всплывает но непонятно почему.

D>Сейчас вроде есть взгляд в сторону других(но своих же) интерфейсов,но в итоге все равно это будет строительство на собственных костях.

Что имеется ввиду?

D>Я так думаю хорошим вариантом было бы -- полный отказ от старой платформы,в виде создания дотнетпроцессора+соответвусщая windows без старого наследия.

Что такое "дотнетпроцессор" — это железяка или программа.

В любом случае "полный отказ от старой платформы" это другими словами "полный абздольц". Есть старое китайское проклятие: "желаю вам жить в эпоху перемен". Это оно.

D>Понимаю утопия.Понимаю что на это микрософт не решится.

Я думаю ты правильно все понимаешь.

D>Кудаж идёт Windows?

Говорят Наполеон сказал следующее "Китай — спит. Пускай он спит. Не дай нам бог если он проснется".
Так вот про Windows API: пускай оно себе спит.

Менять что-то имеет смысл если есть некий набор требований размер которого превышает некий порог.
Таким образом приходим к главному вопросу современности: а собственно какие проблемы в Windows API и вообще в Windows как desktop OS? Вот этот вопрос на который нужно отвечать.

Да, были проблемы у VB когда сложность систем основанная на массивном использовании COM интерфейсов (ref counting) привела к детерминированному хаосу. Известным решением является GC. Поэтому и возник .NET.
Но только причем здесь ОС?

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

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

Тем прискорбнее.

VD>>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС.

S>Ок, что такое "низкоуровневые сервисы ОС"?
S>Афаик, это всё те же DLL с экспортами.

Для NT — да, но это не Win API. Это недокументированные длл.

VD>>Так же надо понимать, что функциональность может реализоваться и в оберточном коде.
S>Ну, может. Но это уже как бы библиотеки, а не сервисы. В том смысле, что библиотека находится в адресном пространстве клиентского процесса, и ничего "военного" не делает — можно загрузить другую библиотеку, которая делает то же самое.

API — это в первую очередь стандарт. Это гарантия того, что написанный код не прийдется серьезно изменять при переносе на новую версию ОС или на другую ОС. Загрузить другую библиотеку == выбрать другой API.

К примеру, загрузи другую библиотеку вместо WPF, WWF, WCF или ASP.NET. Ты будешь вынужден переписать все приложение основанное на этих управляемых API. Более того функциональность имеющаяся, например, в WPF вообще не доступна в Win 32. Там только низкоуровневые обертки. WPF же уже работает по верх Direct X разных версий что позволяет ему запускаться на разных версиях ОС. Так что вместо WPF прийдется написать свой WPF. Другой такой библиотеки нет! Так что ориентация на неуправляемый API будет:
1. Пришиванием себя гвоздями к конкретным версиям, конкретной ОС. (работы над WPF для Linux ведутся полным ходом).
2. Необходимостью реализовать огромную функциональность этого API.
3. Несовместимость с программами и кодом использующими WPF.
А ведь казалось бы "Но это уже как бы библиотеки" и "ничего 'военного' не делает — можно загрузить другую библиотеку".

Вот потому и странно слышать такую ересь от тебя. Если бы это сказал какой-нить Dvorkin или minorlogic, я бы даже не обратил на это сообщение никакого внимания. Но ты для меня товарищь авторитетный.

VD>>В итоге через некоторое время управляемые API "обрастут мясом", заматереют и повторить их в неуправляемых API будет уже невозможно.
S>Э-э, по мне так итог совсем другой — при разработке новых API, которые должны вызываться всеми, удобнее сделать их неуправляемыми. Тогда можно иметь обертки обоих типов — управляемые и неуправляемые.

Может у меня со зрением плохо, но новые API уже сдесь. ASP.NET, WWF, WCF, WPF и другие W — это уже существующие и используемые новые управляемые API. Может быть ты это не осознаешь, но в словах процитированных в исходном сообщении темы имелись в виду именно эти API. И твой призы фактически означает не использовать их в пользу того ужасного бардака который имеется сечас в Windows.

Я надеюсь, что ты просто неверно используешь термины (почему-то не считаешь, что приведенные API почему-то не API), а не реально считаешь, что надо предпочитать неуправляемые API управляемым.

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

VD>>Так что Win API конечно будет жить еще очень долго. Возможно более десяти лет (это не так уж и много), но это будет происходить исключительно из-за того, что много программ его используют. МС пока что боится писать на дотнете что-то серьезное. Тот же офис как я понял, так и не будет переписан. Но потихоньку управляемые API будут отедать рынок и в конечном итоге окажутся более функциональными. Так что надеяться на то, что Win API будет вечным я бы не стал. К тому же он очень кривой. В общем, дотнет бы я выбрал только за то, что кривостью он не страдает.
S>Хм, я скептически отношусь к этой перспективе. Ок, давай оставим в покое старые API. Ежу понятно, что банальный GetProcessInfo() никто не будет отменять, потому что им пользуются миллионы приложений.
S>Ок, давай посмотрим на новые API.
S>Что у нас там появилось в Win2k3? Новый API для HTTP серверов.

Давай. Но зачем смотреть по мелочам. Взгляни на все те же WPF, WCF, ASP.NET и иже с ними. Что, есть хоть какие-то основания не использовать эти API?

S>Так что твоя точка зрения как минимум не совпадает с точкой зрения ответственного руководства в МС.

Это на на что мне плевать в первую очередь, хотя это совершенно не так... по факту.

Здравствуйте, Pavel Dvorkin, Вы писали:

VD>>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС.

PD>Не всегда. Некоторые функции Win API не переключают в ядро. Так что в .Net их придется реализовать самому дотнету.

Ага. Но вот как раз их то выгодно переписать в управляемом коде. И примеры такие есть. Хорошо, что ты не споришь с тем, что основная часть Win API занимается банальным изменением интерфейса низкоуровневых и не документированных библиотек ОС.

PD>В принципе нет ничего невозможного в переносе .Net в ядро.

Реально — есть. Прийдется сделать очень функциональное ядро. А главное не ясно зачем это делать, ведь проблему межпроцессных вызовов это не решит. А уж если ее решить, то практически получится новая ОС. Собственно Сингулярити и есть такая реализация, только не встроенная в ядро Виндовс, а самостоятельная. Для серверных задач ее может очень даже хватить (если конечно портировать хотя бы ASP.NET и некоторые другие API под эту ОС, а то и SQL Server написать для нее).

PD>Кстати, и прецедент есть — в Windows NT 3.x GDI/USER были в 3 кольце, а в NT 4.0

Ты что-то путаешь. Видео подсистема — да была частично убрана в ядро. GDI/USER?

PD>В исходной Win32 была лишь одной из подсистем наряду с OS/2 и POSIX. Сейчас эти 2 тихо исчезли, ...

POSIX доступен для отдельной инсталляции. А 16-битная OS/2 2.х просто никому не нужна. Вот и не тащат ее, чтобы не заниматься ненужной поддержкой ненужного API.

PD>а Win32 стала обязательной.

Она всегда была обязательной. Читай своего любимого Русиновича внимательнее.

PD>Но ничто не мешает реализовать подсистему .Net, хотя скорее всего этого не будет.

Этого не будет просто потому, что это ничего не даст. Если даст, и это будет ценно, то сделают.

VD>>Так что Win API конечно будет жить еще очень долго. Возможно более десяти лет (это не так уж и много), но это будет происходить исключительно из-за того, что много программ его используют. МС пока что боится писать на дотнете что-то серьезное.

PD>И видимо, не пока, а окончательно. Дотнету уже больше 5 лет, а серьезные производители ПО на него переходить не спешат.

Это заблуждение.

>>В общем, дотнет бы я выбрал только за то, что кривостью он не страдает.

PD>Просто он еще слишком молод. Вот проживет он столько, сколько Win API, и тоже окривеет. Просто потому, что модификации (а без них не обойтись) понемногу разъедают стройность, заложенную в исходной модели. Win16 был тоже менее кривым,чем Win32.

Не. Дотнетные API проектируются и при проектировании явно видна забота об удобстве потребителей, а не только о наличии функциональности. К тому де в дотнете все принципиально типобезопасное и понятное. Вещей вроде передачи чего угодно в виде указателя на void там нет. И это дает надежду, на то, что время не уделает управляемы API как бог черепаху, а Microsoft Win API .

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

VD>API — это в первую очередь стандарт. Это гарантия того, что написанный код не прийдется серьезно изменять при переносе на новую версию ОС или на другую ОС.

An application programming interface (API) is a source code interface that an operating system, library or service provides to support requests made by computer programs

Гарантий на самом деле никто не обязался давать. Читайте agreements.

VD>Загрузить другую библиотеку == выбрать другой API.
А бывает что загрузив новую версию той же библы обнаруживается, что API изменился.

VD>К примеру, загрузи другую библиотеку вместо WPF, WWF, WCF или ASP.NET. Ты будешь вынужден переписать все приложение основанное на этих управляемых API.
В случае смены библиотеки управлемость вообще никаким боком. Переписывать придется в любом случае — мы ведь меняем библиотеку, и новая совершенно не обязана обеспечивать тот же API что и старая. Или для тебя уже "нет API кроме как из .NET, и микрософт пророк его"?

VD> Более того функциональность имеющаяся, например, в WPF вообще не доступна в Win 32.
В Win32 или все таки в WinAPI? Потому как выходит что WPF работает только в Win64.
Если речь про WinAPI — то в нем и не должно быть всех этих рюшечек. WinAPI это экспорты из kernel32, ntdll и прочих системных библиотек. Shell и прочие exlplorer.exe радости в WinAPI НЕ входят.

VD>Там только низкоуровневые обертки.
Потому как WinAPI это базовый функционал ОС.

VD>WPF же уже работает по верх Direct X разных версий что позволяет ему запускаться на разных версиях ОС.
Да пожалуйста. Игры вон давно используют "Direct X разных версий" и могут "запускаться на разных версиях ОС".
Будем игровой движок сравнивать с WinAPI?

WPF это просто библиотека. Вспомогательная, дополнительная библиотека из .NET фреймворка. Которая занимается отрисовкой картинок, видео и проигрывания звука. Как ее можно сравнивать с базовым API ОС — мне лично не понятно. У меня она проходит по категории "одна из библиотек для мультимедиа и ГУИ".

Может ли Windows "разных версий" работать без WPF? А без WinAPI?

VD>Так что вместо WPF прийдется написать свой WPF. Другой такой библиотеки нет!
Это только если ты переписываешь прогу, написанную с использованием WPF.
Симметрично:
"Так что вместо DirectX прийдется написать свой DirectX. Другой такой библиотеки нет!"
"Так что вместо OpenGL прийдется написать свой OpenGL. Другой такой библиотеки нет!"
"Так что вместо QT прийдется написать свой QT. Другой такой библиотеки нет!"
.......

VD>Так что ориентация на неуправляемый API будет:
VD>1. Пришиванием себя гвоздями к конкретным версиям, конкретной ОС. (работы над WPF для Linux ведутся полным ходом).
Управляемость тут не при чем. Если вдруг по какой либо причине в новой версии WPF поменяют да хотя бы названия функций — будет геморрой.

VD>2. Необходимостью реализовать огромную функциональность этого API.
Несвязуха какая то. Т.е. если программа использует некий API то она должна сама реализовывать "огромную функциональность этого API"?

VD>3. Несовместимость с программами и кодом использующими WPF.

VD>Так что ориентация на управляемый API будет:
VD>1. Пришиванием себя гвоздями к конкретному фреймворку, конкретной ОС.
VD>2. Необходимостью реализовать огромную функциональность этого API в случае если придется спрыгивать с этого фреймворка.

VD>Я надеюсь, что ты просто неверно используешь термины (почему-то не считаешь, что приведенные API почему-то не API), а не реально считаешь, что надо предпочитать неуправляемые API управляемым.
Вопрос в удобстве. Управляемой проге лучше пользоваться управляемыми библиотеками. И наоборот соответственно.
Если какой либо API предоставляет функционал, который никакими иными способами получить нельзя — будешь вынужденно пользоваться этим API.

Здравствуйте, c-smile, Вы писали:

CS>Да, были проблемы у VB когда сложность систем основанная на массивном использовании COM интерфейсов (ref counting) привела к детерминированному хаосу. Известным решением является GC. Поэтому и возник .NET.

хм, мне почему-то казалось, что главной причиной появления .net стала зависть мс к успеху java.

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

VD>а вот наоборот сделать куда сложнее (и на практике практически не делается).

PInvoke в обратном направлении тоже действует, только эту фичу почему-то очень глубоко запрятали

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

Так как большая часть данного ответа состоит из доказывания до слов и их вольной реинтерпретации, то я их просто проигнорирую (сори) и отвечу только на один вопрос:

CC>Если какой либо API предоставляет функционал, который никакими иными способами получить нельзя — будешь вынужденно пользоваться этим API.

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

Через какое-то время управляемы API наберут критическую массу и с ними вообще трудно будет не считаться.
Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше, а значит переносить на новые платформы будут именно его. Собственно Моно уже это демонстрирует.

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

VD>Так как большая часть данного ответа состоит из доказывания до слов и их вольной реинтерпретации
Потрудитесь излагать свои мысли яснее

VD>, то я их просто проигнорирую (сори)
Нда...

VD>и отвечу только на один вопрос:
CC>>Если какой либо API предоставляет функционал, который никакими иными способами получить нельзя — будешь вынужденно пользоваться этим API.
VD>В том-то и дело, что все больше и больше API предоставляются Microsoft-ом исключительно в управляемом виде. А те что предоставляются в неуправляемом виде в большинстве случаев снабжаются управляемыми обертками. Таким образом выбирая неуправляемые API прийдется отказываться от всего того что не продублировано в неуправляемом коде. А это в большинстве случае случаев отказ от высокоуровневых и удобных в использовании API в пользу неуклюжих и низкоуровневых API с ужасно спроектированным интерфейсом.
Ты не понял.
Приведи пример управляемого доступа к файлам, который не использует внутри себя вызовы неуправляемых базовых API ОС. Т.е. не является оберткой.

Вернемся к проигнорированным тобой вопросам:
1) Что есть API?
2) Что есть управляемый API?
Мне например такое чудо природы неизвестно. Есть управляемый код. Предположу, что управляемым API ты называешь API к этому управляемому коду.
3) в каком виде "все больше и больше API предоставляются Microsoft-ом исключительно в управляемом виде"?
а) В виде библиотек в составе .NET (которые являются просто библиотеками и могут быть переписаны в любом виде)
б) В составе базовых сервисов ОС (которые особо не перепишешь, т.к. ниже них попросту не на что опереться).

VD>Через какое-то время управляемы API наберут критическую массу и с ними вообще трудно будет не считаться.
Ага, коммунизм не за горами. Будем надеяться что он все же не наступит в том виде как ты его тут предлагаешь.

VD>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше
Угу. Прям как в сообщениях ТАСС: "Общеизвестно...".
Требую обосновать по пунктам и с аргументацией. Но без демагогии в стиле "только очень недалекие люди не понимают"...
Но сперва ответь на вопрос №1 выше.