"
Означает ли 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?
22.04.08 04:32: Перенесено модератором из 'Прочее' — Кодт
Здравствуйте, dipso, Вы писали: D>Я так понимаю что .NET Framework с первой версии базировались на Windows API(потому и быстрее не стали,потому и абсолютно схожая функциональность,обёрнутая в удобные классы).Сейчас вроде есть взгляд в сторону других(но своих же) интерфейсов,но в итоге все равно это будет строительство на собственных костях .Я так думаю хорошим вариантом было бы -- полный отказ от старой платформы,в виде создания дотнетпроцессора+соответвусщая windows без старого наследия.Понимаю утопия.Понимаю что на это микрософт не решится.Но х е р знает ))) Кудаж идёт Windows?
В ближайшие десять лет отказаться от Windows API не удастся.
Для того, чтобы понять почему, надо немножко разбираться в архитектуре ОС.
Пока что нет никакого способа для пользовательского процесса позвать системный сервис, кроме как загрузить библиотеку, найти экспорт, и сделать вызов.
Эту процедуру можно обернуть в классы на управляемом либо неуправляемом языке, но от этого API никуда не денется.
Для того, чтобы совсем "отказаться от старой платформы" нужно сначала придумать какую-то другую платформу, с другой моделью изоляции и взаимодействия процессов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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 и управляемыми. Не с чем ведь было поддерживать обратную совместимость.
Увы, всё осталось нативным.
Так что твоя точка зрения как минимум не совпадает с точкой зрения ответственного руководства в МС.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
[]
VD>То же Win API на самом деле не более чем набор переходников которые в конечном итоге все равно дергают низкоуровневые сервисы ОС. Так же надо понимать, что функциональность может реализоваться и в оберточном коде.
Ну переходники там нифига не легкие. Кроме того, нормальный interop появился только с выходом c++/cli. Все остальное — трах с маршалингом. И никто не будет с этим связываться.
Здравствуйте, Sinclair, Вы писали:
S>Для того, чтобы совсем "отказаться от старой платформы" нужно сначала придумать какую-то другую платформу, с другой моделью изоляции и взаимодействия процессов.
А что разве еще не придумали? Теже Singularity или Active Oberon, который был выпущен ранее первой.
Конечно, это не промышленные разработки, а исследовательские, но они показывают, как можно строить ОС на безопасных языках по другим принципам.
Здравствуйте, Стэн, Вы писали:
S>>Для того, чтобы совсем "отказаться от старой платформы" нужно сначала придумать какую-то другую платформу, с другой моделью изоляции и взаимодействия процессов. С>А что разве еще не придумали? Теже Singularity или Active Oberon, который был выпущен ранее первой. С>Конечно, это не промышленные разработки, а исследовательские, но они показывают, как можно строить ОС на безопасных языках по другим принципам.
Угу. Обеим разработкам еще ехать до промышленного применения — как Оке до колец Сатурна.
По поводу Singularity авторы неоднократно комментировали, что она никогда не рассматривалась иначе как proof of concept, и для построения full blown OS нужно продумать еще очень-очень много принципиальных моментов. Не думаю, что это случится быстрее, чем к 2020 году.
По поводу активного оберона у меня вообще очень скептическое мнение. Пытаться реализовывать софтную изоляцию на неуправляемой платформе можно было двадцать лет назад. Сейчас это уже даже в качестве шутки не шибко смешно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Можно посмотреть, как постепенно трансформировалась и исчезала поддержка DOS- и Win16-приложений. Поскольку винды конечно сильны именно приложениями и наработанными во всем мире workflow, то само собой никуда Win32 по-быстрому не денется. Вот если MS заявит о новой ситеме с "поддержкой совместимости с Win32", где этот api уже будет жить в отдельной песочнице, вот тогда, имхо, самое время постепенно начинать волноваться.
Еще можно вспомнить, для примера, как начиналось победное шествие виндов. Тогда цены на софты взлетели очень существенно. Мне кажется, сейчас радикальная смена платформы ничего настолько не изменит для конечного пользователя, поэтому и такой резкий переход скачком должен выглядеть как-то иначе, мягче. Опять же сравнивая, тогда смена быстрая платформы сулила многим девелоперам (тем, кто пошустрее) огромные выгоды. Сейчас, имхо, это не так.
1. Вы не забывайте, что есть тонны софта написанного на WinAPI. Врядли вы найдете огромный энтузиазм у разработчиков резко ринутся переписывать все это хозяйство на новые рельсы.
2. Кроме прикладного софта, существует еще и системный, например Vmware. Я себе очень слабо представляю как (?!?!) сделать динамическую бинарную трансляцию на .NET (да впрочем как и на Java).
Здравствуйте, Dio Elaclaire, Вы писали: DE>2. Кроме прикладного софта, существует еще и системный, например Vmware. Я себе очень слабо представляю как (?!?!) сделать динамическую бинарную трансляцию на .NET (да впрочем как и на Java).
Ну, VMWare уже умеет работать поверх bare metal, так что ей более-менее всё равно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Вообще согласен, но небольшие уточнения.
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.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, c-smile, Вы писали:
CS>Да, были проблемы у VB когда сложность систем основанная на массивном использовании COM интерфейсов (ref counting) привела к детерминированному хаосу. Известным решением является GC. Поэтому и возник .NET.
хм, мне почему-то казалось, что главной причиной появления .net стала зависть мс к успеху java.
Так как большая часть данного ответа состоит из доказывания до слов и их вольной реинтерпретации, то я их просто проигнорирую (сори) и отвечу только на один вопрос:
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 выше.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>Через какое-то время управляемы API наберут критическую массу и с ними вообще трудно будет не считаться. VD>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше, а значит переносить на новые платформы будут именно его. Собственно Моно уже это демонстрирует.
Собственно это уже давно продемонстрировал сан на примере джавы
Здравствуйте, goorov, Вы писали:
VD>>Через какое-то время управляемы API наберут критическую массу и с ними вообще трудно будет не считаться. VD>>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше, а значит переносить на новые платформы будут именно его. Собственно Моно уже это демонстрирует. G>Собственно это уже давно продемонстрировал сан на примере джавы
А также перл, питон и куча остальных скриптовых языков, для которых надо портировать только рантайм.
Какое отношение это имеет к управляемым API.
Не кажется ли вам, господа, что вы путаете теплое с мягким?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, goorov, Вы писали:
G>Здравствуйте, c-smile, Вы писали:
CS>>Да, были проблемы у VB когда сложность систем основанная на массивном использовании COM интерфейсов (ref counting) привела к детерминированному хаосу. Известным решением является GC. Поэтому и возник .NET.
G>хм, мне почему-то казалось, что главной причиной появления .net стала зависть мс к успеху java.
Java продемонстрировала большую устойчивость в больших сборках компонентов по сравнению с VB6 (COM, ActiveX).
COM замечательная технология для описания периметров — внешних интерфейсов.
Для внутреннего связывания большого количества небольших компонент COM подходит слабо — одна проблема cyclic references чего стоит.
Поэтому и совершенно естественно решение перейти на GC based component integration.
VS6 = VC + ATL + VB.COM + InterDev(ASP.COM), VisualJ как отдельная сущность но с поддержкой COM.
VS7 = VC + VC.NET + VB.NET + ASP.NET + С#.NET.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше, а значит переносить на новые платформы будут именно его. Собственно Моно уже это демонстрирует.
Не знаю кто там далёк или нет, но я не понимаю почему управляемость должна повышать портабельность. Вот, скажем, надо нам перенести с 32-битной платформы с одним эндианом на 48-битную с другим. При этом с циска на риск. И чем управляемость кода облегчит нам жизнь?
Кроме того мне не совсем понятно что такого демонстрирует моно, чего не демонстрирует вайн? То, что моно труднее дописать до юзабльного сосотяния?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
VD>Ага. Но вот как раз их то выгодно переписать в управляемом коде. И примеры такие есть. Хорошо, что ты не споришь с тем, что основная часть Win API занимается банальным изменением интерфейса низкоуровневых и не документированных библиотек ОС.
Я бы сказал — вызовами. А спорить тут не с чем. Правда, считать ntdll.dll документированным интерфейсом или нет — как сказать. Но уж USER/GDI точно не документирован.
PD>>В принципе нет ничего невозможного в переносе .Net в ядро.
VD>Реально — есть. Прийдется сделать очень функциональное ядро. А главное не ясно зачем это делать, ведь проблему межпроцессных вызовов это не решит.
А зачем процессы переносить ? Им и так хорошо, да и .Net процесс ничем от других процессов в смысле ядра не отличается. А вот прочее вполне можно было бы перенести. Например, GDI+. Методы его могли бы напрямую реализоваться через net.sys вместо того, чтобы идти по цепочке gdiplus.dll — gdi32.dll — win32k.sys. Правда, не совсем ясно, как к этому csrss.exe отнесется, ему все же положено знать.
Да и других примеров сколько угодно.
>А уж если ее решить, то практически получится новая ОС.
Видимо, да.
PD>>Кстати, и прецедент есть — в Windows NT 3.x GDI/USER были в 3 кольце, а в NT 4.0
VD>Ты что-то путаешь. Видео подсистема — да была частично убрана в ядро. GDI/USER?
GDI и USER именно и были убраны в ядро. А что такое видеоподсистема — я не понял.
PD>>В исходной Win32 была лишь одной из подсистем наряду с OS/2 и POSIX. Сейчас эти 2 тихо исчезли, ...
VD>POSIX доступен для отдельной инсталляции. А 16-битная OS/2 2.х просто никому не нужна. Вот и не тащат ее, чтобы не заниматься ненужной поддержкой ненужного API.
POSIX именно доступен, но практически никому не нужен.
PD>>а Win32 стала обязательной.
VD>Она всегда была обязательной. Читай своего любимого Русиновича внимательнее.
Она была, верно, но исходная идея была в том, что это только подсистема. То есть в принципе могло быть без нее.
PD>>И видимо, не пока, а окончательно. Дотнету уже больше 5 лет, а серьезные производители ПО на него переходить не спешат.
VD>Это заблуждение.
Влад, я понимаю, что ты патриот этой системы . Но если честно — какие из пакетов , являющихся хребтом нынешней ИТ, были перенесены в .Net ? MS Office — ты сам писал, что нет и не будет. Другие MS продукты ? PhotoShop ? Corel ? AutoCad ? Ничего ведь нет, и не собираются. Пора уж взглянуть правде в лицо.
PD>>Просто он еще слишком молод. Вот проживет он столько, сколько Win API, и тоже окривеет. Просто потому, что модификации (а без них не обойтись) понемногу разъедают стройность, заложенную в исходной модели. Win16 был тоже менее кривым,чем Win32.
VD>Не. Дотнетные API проектируются и при проектировании явно видна забота об удобстве потребителей, а не только о наличии функциональности. К тому де в дотнете все принципиально типобезопасное и понятное. Вещей вроде передачи чего угодно в виде указателя на void там нет. И это дает надежду, на то, что время не уделает управляемы API как бог черепаху, а Microsoft Win API .
Здравствуйте, Sinclair, Вы писали:
S>В ближайшие десять лет отказаться от Windows API не удастся. S>Для того, чтобы понять почему, надо немножко разбираться в архитектуре ОС. S>Пока что нет никакого способа для пользовательского процесса позвать системный сервис, кроме как загрузить библиотеку, найти экспорт, и сделать вызов.
Кстати, в Windows это совсем не так. Windows задумывалась как модульная система с различными подсистемами (Win32, OS/2, POSIX). Часть Win32 реализована в виде отдельного процесса (csrss.exe), коммуникация с которым идёт с помощью LPC (Local Procedure Call).
И вполне можно представить себе реализацию LPC на нативном .NET. Тогда получим в итоге что-то типа микроядерной системы — приложения на .NET будут общаться с системным сервером посредством LPC. Ну и прямые системные вызовы тоже никто не мешает обернуть в PInvoke.
Другое дело, что за долгие годы монополизма в Windows появилась куча недокументированых лазеек между слоями, которые фиг сейчас исправишь.
Здравствуйте, Alexander G, Вы писали:
AG>Что-то много новых функций старого WinAPI добавилось в Висте, на отказ это никак не похоже
И не только. Микрософт готовит новую версию MFC, RC уже выложен. Это не шутки — от той команды, что MFC когда-то делала, уже и воспоминаний не осталось, значит, новую совсем команду собрали. А MFC — это враппер над Win32. Судя по всему, Микрософт поняла, что затея с .Net для серьезных десктопных приложений провалилась.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
S>>В ближайшие десять лет отказаться от Windows API не удастся. S>>Для того, чтобы понять почему, надо немножко разбираться в архитектуре ОС. S>>Пока что нет никакого способа для пользовательского процесса позвать системный сервис, кроме как загрузить библиотеку, найти экспорт, и сделать вызов. C>Кстати, в Windows это совсем не так. Windows задумывалась как модульная система с различными подсистемами (Win32, OS/2, POSIX). Часть Win32 реализована в виде отдельного процесса (csrss.exe), коммуникация с которым идёт с помощью LPC (Local Procedure Call).
Я наверное слишком тупой. Что такое LPC? Вроде бы это часть недокументированного Native API.
То есть для того, чтобы сделать вызов LPС, я один хрен загружаю некую DLL, импортирую символ, и выполняю call.
То, что за кадром происходит какое-то злое шаманство — пусть происходит. Но от этого факт наличия DLL и символа никуда не исчезает.
C>И вполне можно представить себе реализацию LPC на нативном .NET. Тогда получим в итоге что-то типа микроядерной системы — приложения на .NET будут общаться с системным сервером посредством LPC. Ну и прямые системные вызовы тоже никто не мешает обернуть в PInvoke.
Ага. И никому не говорить, что это PInvoke Типа народ не догадается, что можно обернуть то же самое в, к примеру, Delphi7 Unit с точно такими же импортами. C>Другое дело, что за долгие годы монополизма в Windows появилась куча недокументированых лазеек между слоями, которые фиг сейчас исправишь.
Мы говорим не про лазейки, а про API.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
VD>>В том-то и дело, что все больше и больше API предоставляются Microsoft-ом исключительно в управляемом виде. А те что предоставляются в неуправляемом виде в большинстве случаев снабжаются управляемыми обертками. Таким образом выбирая неуправляемые API прийдется отказываться от всего того что не продублировано в неуправляемом коде. А это в большинстве случае случаев отказ от высокоуровневых и удобных в использовании API в пользу неуклюжих и низкоуровневых API с ужасно спроектированным интерфейсом. CC>Ты не понял.
Я не понял, что я не понял.
CC>Приведи пример управляемого доступа к файлам, который не использует внутри себя вызовы неуправляемых базовых API ОС. Т.е. не является оберткой.
Примером тому может служить API IO ОС Сингулярити, но какое это отношение имеет к делу? Я не ясно выразился? Вроде — нет. Прочти еще раз то, что я написал.
CC>Вернемся к проигнорированным тобой вопросам:
Я проигнорировал вольную реинтерпретацию своих слов и докапывание (не по делу) к одным. Так что возвращаться не к чему.
CC>1) Что есть API?
http://en.wikipedia.org/wiki/API
В приведенной ссылке очень рекомендую внимательно прочесть раздел "API versus ABI".
CC>2) Что есть управляемый API?
То же что и п. 1, но реализовано на управляемой платформе вроде дотнета или Явы. Если речь идет о платформах МС, то естественно речь идет о дотнете.
CC>Мне например такое чудо природы неизвестно.
Изучать новое никогда не поздно . "managed API"
CC>3) в каком виде "все больше и больше API предоставляются Microsoft-ом исключительно в управляемом виде"? CC> а) В виде библиотек в составе .NET (которые являются просто библиотеками и могут быть переписаны в любом виде)
API и есть просто библиотеки предоставляющие программный интерфейс к некоторому сервису.
CC> б) В составе базовых сервисов ОС (которые особо не перепишешь, т.к. ниже них попросту не на что опереться).
Я не говорил ни про какие базовые сервисы. Я даже не понимаю что ты под этим имеешь в виду. Собственно, вот поэтому мне и не хочется отвечать на подобные "вопросы". Потому как за меня придумывают то о чем я говорил и начинают критиковать собственные домыслы.
Теперь о "которые особо не перепишешь, т.к. ниже них попросту не на что опереться".
Ты просто не разбираешься в вопросе которые пытаешься обсуждать. API редко работает с железом напрямую. Оно обычно взаимодействует с системой через ABI или другие API. Win API не исключение. Так что опираться конечно же есть на что. Скажем API под названием WPF опирается на Direct X и на Win API (в части взаимодействия с пользователем), но при этом предоставляет более высокоуровневый интерфейс не доступны (в полном объеме и без траха) в неуправляемом коде.
VD>>Через какое-то время управляемы API наберут критическую массу и с ними вообще трудно будет не считаться. CC>Ага, коммунизм не за горами. Будем надеяться что он все же не наступит в том виде как ты его тут предлагаешь.
Надежда — ваш компас земной. Кто же тебе запретит надеяться? Я выражаю свое мнение. И то на что ты надеешься меня интересует очень мало.
VD>>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше CC>Угу. Прям как в сообщениях ТАСС: "Общеизвестно...". CC>Требую обосновать по пунктам и с аргументацией. Но без демагогии в стиле "только очень недалекие люди не понимают"... CC>Но сперва ответь на вопрос №1 выше.
Требовать ты будешь от своей жены. Тут же ты можешь только соглашаться со мной или нет. Мне в общем-то и это совершенно монопенесуально.
Если же тебе интересен вопрос портируемость, то читай базовую информацию по дотнету и Яве. Там все очень доходчиво сказано и хорошо обосновано. Повторять ее бессмысленно, на мой взгляд.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, goorov, Вы писали:
VD>>Ну, и думаю, что только очень недалекие люди не понимают, что портируемость управляемых API гораздо выше, а значит переносить на новые платформы будут именно его. Собственно Моно уже это демонстрирует.
G>Собственно это уже давно продемонстрировал сан на примере джавы
Так точно. А так же Новел на примере Моно и МС на примере Компакт-фрэймворк (он у меня на телефоне очень неплохо работает).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
G>>Собственно это уже давно продемонстрировал сан на примере джавы CC>А также перл, питон и куча остальных скриптовых языков, для которых надо портировать только рантайм.
В общем — да. Только у них очень ограниченный АПИ. Своя песочница. Скажем та же графика зачастую основана на разных GTK и т.п. Ну, и естественно круг решаемых задач тоже очень ограниченный.
CC>Какое отношение это имеет к управляемым API.
Никакого. Это же ты их сюда приплел... по созвучию. Речь шла о АПИ к ОС...
CC>Не кажется ли вам, господа, что вы путаете теплое с мягким?
Мы — нет. Вы... возможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
E>Не знаю кто там далёк или нет, но я не понимаю почему управляемость должна повышать портабельность.
Это прискорбно.
E>Вот, скажем, надо нам перенести с 32-битной платформы с одним эндианом на 48-битную с другим. При этом с циска на риск. И чем управляемость кода облегчит нам жизнь?
Если программа будет использовать только управляемые API доступные на обоих платформах, то достаточно будет просто скопировать исполнимые файлы.
Я вот не понимаю, что тут не понимать?
E>Кроме того мне не совсем понятно что такого демонстрирует моно, чего не демонстрирует вайн? То, что моно труднее дописать до юзабльного сосотяния?
Как раз демонстрирует бинарную переносимость программ. Компилируешь программу с помощью VS 2008 и запускаешь ее под Моно на RISC-процессоре. Ну, и соответственно наоборот.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Другое дело, что за долгие годы монополизма в Windows появилась куча недокументированых лазеек между слоями
...Сумрака :-)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И не только. Микрософт готовит новую версию MFC, RC уже выложен. Это не шутки — от той команды, что MFC когда-то делала, уже и воспоминаний не осталось, значит, новую совсем команду собрали.
Судя по слухам — никого они там не набрали. Сидят индусы и потихоньку подлатывают. Кстати, winforms тоже уже находится в состоянии вялотекущей поддержки (я этого не говорил )..
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>МС пока что боится писать на дотнете что-то серьезное.
Уже нет. По крайней мере в девтулах грядет революция. Уже в Dev10 кое что из старого неуправляемого кода будет переписано под .NET. А уж в Dev11 ... Но про это я пока не могу ничего говорить.
VD> Тот же офис как я понял, так и не будет переписан.
Это слишком дорого — вряд ли на это выделят деньги. По крайне мере текущая ситуация такая.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Э-э, по мне так итог совсем другой — при разработке новых API, которые должны вызываться всеми, удобнее сделать их неуправляемыми. Тогда можно иметь обертки обоих типов — управляемые и неуправляемые.
Вопрос ведь не в управляемости, а в WinAPI. Тут показательна ситуация с DCE — есть некое нативное API (неуправляемое), а к нему есть управляемая обертка и эмуляция GDI. ИМХО именно об этом и говорит Влад.
S>Так что твоя точка зрения как минимум не совпадает с точкой зрения ответственного руководства в МС.
Точка зрения руководства МС — понятие в большей степени виртуальное.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Константин Л., Вы писали:
КЛ>Ну переходники там нифига не легкие. Кроме того, нормальный interop появился только с выходом c++/cli. Все остальное — трах с маршалингом.
Маршалинг нужен не для работы языков, отличных от C++, а для написания верифицируемого safe кода (в том числе и на с++/cli).
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Sinclair, Вы писали:
C>>Кстати, в Windows это совсем не так. Windows задумывалась как модульная система с различными подсистемами (Win32, OS/2, POSIX). Часть Win32 реализована в виде отдельного процесса (csrss.exe), коммуникация с которым идёт с помощью LPC (Local Procedure Call). S>Я наверное слишком тупой. Что такое LPC? Вроде бы это часть недокументированного Native API.
LPC — это что-то типа RPC, но оптимизированое для локальной работы (оно умеет делать remap между адресными пространствами для крупных блоков данных и т.п.)
Оно хоть и недокументированое, но очень хорошо изученое и широко применяемое.
S>То есть для того, чтобы сделать вызов LPС, я один хрен загружаю некую DLL, импортирую символ, и выполняю call. S>То, что за кадром происходит какое-то злое шаманство — пусть происходит. Но от этого факт наличия DLL и символа никуда не исчезает.
Никто не мешает сделать этот один метод в виде магического хука внутри .NET. Кроме того, есть и Quick LPC, который вообще после начальной установки соединения работает на сегменте расшареной памяти и паре семафоров — тут даже никакие хуки не понадобятся.
S>Ага. И никому не говорить, что это PInvoke Типа народ не догадается, что можно обернуть то же самое в, к примеру, Delphi7 Unit с точно такими же импортами.
Можно. А смысл? Ты сейчас при (большом) желании сам можешь новую подсистему для Windows сделать.
Здравствуйте, VladD2, Вы писали:
E>>Вот, скажем, надо нам перенести с 32-битной платформы с одним эндианом на 48-битную с другим. При этом с циска на риск. И чем управляемость кода облегчит нам жизнь?
VD>Я вот не понимаю, что тут не понимать?
Ты знаешь что такое endian?..
VD>Как раз демонстрирует бинарную переносимость программ. Компилируешь программу с помощью VS 2008 и запускаешь ее под Моно на RISC-процессоре. Ну, и соответственно наоборот.
Да? И если у тебя что-то перестало в int помещаться, то что нам даст управляемость?
А вот ещё пример. У меня есть файл из 16-битных целых. Я хочу сортировтаь их парами, для этого я читаю их как 32-ные, и сортирую, потом пишу в другой файл. Как эта программа отрабаотет по твоему на платформе с другим endian?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
D>Но разработчики должны медленно отходить от устаревших API и перемещаться к управляемому коду и .NET Framework – но мы будем поддерживать обе модели долгое, очень долгое время.
Использование дотнета в Висте есть одна из причин, почему в ней многое отвратно тормозит и люди от нее отворачиваются.
У MS уже сейчас проблемы из-за низкого принятия Висты рынком, если они еще совместимость назад бросят — то им будет еще хуже, больше причин не апгредиться для людей.
Но новые вещи да, на дотнете все будут, ибо винду уже поджимает Wine, а покаааа еще линуксоиды склонируют весь дотнет с авалоном и прочими радостями...
VD>Если же тебе интересен вопрос портируемость, то читай базовую информацию по дотнету и Яве. Там все очень доходчиво сказано и хорошо обосновано. Повторять ее бессмысленно, на мой взгляд.
Портируемость .NET определяется только волей микрософта, а ему нафиг не надо куда-то ее портировать с виндов.
Впрочем, Win32 тоже не портируем ни на что, кроме Вайна и ВинМобайла.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Но новые вещи да, на дотнете все будут, ибо винду уже поджимает Wine, а покаааа еще линуксоиды склонируют весь дотнет с авалоном и прочими радостями...
Линуксоиды сделают "ход конём" и научат .NET FW работать под Wine Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит.
VD>Ты что-то путаешь. Видео подсистема — да была частично убрана в ядро. GDI/USER?
Почти все имплементация USERа, в частности, глобальный список всех окон и любой код, который его апдейтит — в ядре. DefWindowProc, возможно, нет, как и стандартные классы типа button. Вызовы GetXxx тоже нет — список окон замаплен read-only в юзер моду.
Примерно то же самое и с GDI. Весь DIB engine — "базовый класс" для видеодрайверов — в ядре.
В CSRSS остались только консольные окна и внутренности ExitWindowsEx, с окошками program not responding и так далее.
VD>Она всегда была обязательной. Читай своего любимого Русиновича внимательнее.
Да, всегда.
VD>Этого не будет просто потому, что это ничего не даст.
+1
VD>Это заблуждение.
Переходят медленно и плохо (кроме самого микрософта, а у них это политика). Думаю, что с 06 года процесс вообще крайне замедлился.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Впрочем, Win32 тоже не портируем ни на что, кроме Вайна и ВинМобайла.
Когда-то NT была на многих архитектурах доступна. Просто оказалось что это не особо кому-то надо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Cyberax, Вы писали:
C>Линуксоиды сделают "ход конём" и научат .NET FW работать под Wine Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит.
Зверски засудят. Всех поимённо по копирайтам в исходниках и по анализу логов CSV...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Да? И если у тебя что-то перестало в int помещаться, то что нам даст управляемость?
int в .NET всегда 32 бита
E>А вот ещё пример. У меня есть файл из 16-битных целых. Я хочу сортировтаь их парами, для этого я читаю их как 32-ные, и сортирую, потом пишу в другой файл. Как эта программа отрабаотет по твоему на платформе с другим endian?
endian тоже фиксированный.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит. AVK>Лицензия этого не позволяет
Эти пункты лицензии могут быть признаны ничтожными. Прецеденты (в области железа) есть.
Сейчас какие-то камикадзе в США начали выпускать клоны Mac'ов — вот и посмотрим что будет.
Здравствуйте, Erop, Вы писали:
C>>Линуксоиды сделают "ход конём" и научат .NET FW работать под Wine Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит. E>Зверски засудят. Всех поимённо по копирайтам в исходниках и по анализу логов CSV...
Кого и за что? WINE абсолютно легален. .NET FW тоже будут ставить пользователи.
Может быть проблема у самих пользователей из-за лицензии .NET FW, но это уже вопрос отдельный.
Здравствуйте, Cyberax, Вы писали:
C>>>Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит. AVK>>Лицензия этого не позволяет C>Эти пункты лицензии могут быть признаны ничтожными. Прецеденты (в области железа) есть.
На основании чего, собственно?
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
C>>>Линуксоиды сделают "ход конём" и научат .NET FW работать под Wine Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит. E>>Зверски засудят. Всех поимённо по копирайтам в исходниках и по анализу логов CSV... C>Кого и за что? WINE абсолютно легален.
разве? они же, вроде, многое реверс-инжинирингом добились
AVK>int в .NET всегда 32 бита AVK>endian тоже фиксированный.
.NET пока что на одной платформе, так что о переносимости говорить вообще странно, но если таки возникнет вопрос о переносе на платформу в 48-бит и другим endian я на тебя посмотрю...
В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Cyberax, Вы писали:
C>Кого и за что? WINE абсолютно легален. .NET FW тоже будут ставить пользователи.
Того, кто будет целенаправленно добиваться запуска .Net под WINE. За разработку ПО для пиратства.
C>Может быть проблема у самих пользователей из-за лицензии .NET FW, но это уже вопрос отдельный.
У пользователей тоже будут. И у продавцов-распространителей, кстати, тоже...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
AVK>>int в .NET всегда 32 бита AVK>>endian тоже фиксированный. E>.NET пока что на одной платформе
Да ну брось ты. Сам дотнет есть на x86, x64, IA64. CF есть на ARM. Кроме того есть Моно, которое под кучу платформ.
E>, так что о переносимости говорить вообще странно, но если таки возникнет вопрос о переносе на платформу в 48-бит и другим endian я на тебя посмотрю...
Не надо смотреть на меня, надо смотреть на Java.
E>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
У них нет бинарной совместимости.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mamut, Вы писали:
C>>>>Линуксоиды сделают "ход конём" и научат .NET FW работать под Wine Собственно, .NET FW 2.0 под ним прекрасно работает, а в .NET FW 3/3.5 только инсталлятор глючит. E>>>Зверски засудят. Всех поимённо по копирайтам в исходниках и по анализу логов CSV... C>>Кого и за что? WINE абсолютно легален.
M>разве? они же, вроде, многое реверс-инжинирингом добились
Да пофик как они добились. .NET в лицензии трактуется как компонент ОС производства Microsoft.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Эти пункты лицензии могут быть признаны ничтожными. Прецеденты (в области железа) есть. AVK>На основании чего, собственно?
Незаконный bundling и всё такое. Т.е. признают .NET FW отдельным самостоятельным продуктом, который может работать на системах конкурентов.
Тем более, что что-то подобное есть в соглашении между MS и DOJ.
Здравствуйте, Erop, Вы писали:
C>>Кого и за что? WINE абсолютно легален. .NET FW тоже будут ставить пользователи. E>Того, кто будет целенаправленно добиваться запуска .Net под WINE. За разработку ПО для пиратства.
С чего бы? В DMCA даже специальное разрешение есть для интероперабельности.
C>>Может быть проблема у самих пользователей из-за лицензии .NET FW, но это уже вопрос отдельный. E>У пользователей тоже будут. И у продавцов-распространителей, кстати, тоже...
Не будет. WINE абсолютно чисто в этом плане. Думаешь они такие идиоты и не подумали об этом?
Здравствуйте, Erop, Вы писали:
E>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
Ты наверное будешь удивлен, но в Лиспе и Прологе GC как раз таки есть
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Cyberax, Вы писали:
C>Незаконный bundling и всё такое. Т.е. признают .NET FW отдельным самостоятельным продуктом, который может работать на системах конкурентов.
Для этого сперва это надо в суде доказать, в чем я очень сомневаюсь.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, yumi, Вы писали:
Y>Ты наверное будешь удивлен, но в Лиспе и Прологе GC как раз таки есть
Там это всего лишь особенность реализации вроде?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
C>>>Кого и за что? WINE абсолютно легален.
M>>разве? они же, вроде, многое реверс-инжинирингом добились
AVK>Да пофик как они добились. .NET в лицензии трактуется как компонент ОС производства Microsoft.
Именно поэому возникают сомнения в абсолютной легальности WINE
Здравствуйте, Erop, Вы писали:
Y>>Ты наверное будешь удивлен, но в Лиспе и Прологе GC как раз таки есть E>Там это всего лишь особенность реализации вроде?
Действительно, в стандарт CL не входит GC. Но ты мне покажи пальцем на реализацию Лиспа без GC, которым пользуются в промышленной разработке софта.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, AndrewVK, Вы писали:
E>>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
AVK>У них нет бинарной совместимости.
У питона есть, правда в пределах версии, у Ocaml'а байт код вполне переносим.
Здравствуйте, FR, Вы писали:
E>>>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
AVK>>У них нет бинарной совместимости.
FR>У питона есть, правда в пределах версии, у Ocaml'а байт код вполне переносим.
Ты откуда питон и OCAML вообще вытащил?
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>>>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
AVK>Ты откуда питон и OCAML вообще вытащил?
Возможно из многточия?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Maxim S. Shatskih, Вы писали:
C>>Незаконный bundling и всё такое. Т.е. признают .NET FW отдельным самостоятельным продуктом, который может работать на системах конкурентов. MSS>Вероятностей того, что запретят WINE, намного больше, она правда на реверс-инжиниринге основана, и наверняка еще и на утекших исходниках.
Нет, большая часть Wine была сделана ещё задолго до того знаменитого утекания. Какие-то разработчики их может и смотрели, но очень аккуратно этого не показывают.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И не только. Микрософт готовит новую версию MFC, RC уже выложен. Это не шутки — от той команды, что MFC когда-то делала, уже и воспоминаний не осталось, значит, новую совсем команду собрали.
AVK>Судя по слухам — никого они там не набрали. Сидят индусы и потихоньку подлатывают. Кстати, winforms тоже уже находится в состоянии вялотекущей поддержки (я этого не говорил )..
Судя по без слухов, я его релиз скачал неделю назад. Еще не пробовал. Что же касается национальной принадлежности его авторов — не знаю, знаю только, что кусок был сделан в Санкт-Петербурге, о чем здесь проскакивала информация. Судя по описанию, на вялотекущую поддержку не похоже. Вот ей они как раз и не занимались, из-за чего MFC и отстала от жизни.
Overview
The Visual C++ 2008 Feature Pack extends the VC++ Libraries shipped with Visual Studio 2008 and is fully covered under Microsoft's standard support policies.
The VC++ 2008 MFC libraries have been extended to support creation of applications that have:
Office Ribbon style interface
Office 2007, Office 2003 and Office XP look and feel
Modern Visual Studio-style docking toolbars and panes
Fully customizable toolbars and menus
A rich set of advanced GUI controls
Advanced MDI tabs and groups
And much more!
This feature pack also includes an implementation of TR1. Portions of TR1 are scheduled for adoption in the upcoming C++0x standard as the first major addition to the ISO 2003 standard C++ library. Our implementation includes a number of important features such as:
Smart pointers
Regular expression parsing
New containers (tuple, array, unordered set, etc)
Sophisticated random number generators
Polymorphic function wrappers
Type traits
And more!
Note: This feature pack does not include C99 compatibility or support for special math functions.
E>>>>В некотормо смысле есть ещё более переносимые среды, тогда. Скажем BASIC, например, LISP, Prolog... Зачем вообще с какими-то GC заморачиваться?
AVK>>>У них нет бинарной совместимости.
FR>>У питона есть, правда в пределах версии, у Ocaml'а байт код вполне переносим.
AVK>Ты откуда питон и OCAML вообще вытащил?
Здравствуйте, Cyberax, Вы писали:
C>Нет, большая часть Wine была сделана ещё задолго до того знаменитого утекания. Какие-то разработчики их может и смотрели, но очень аккуратно этого не показывают.
Так пока никто и не судился вроде и док-ва всерьёз не собирал...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Судя по без слухов, я его релиз скачал неделю назад. Еще не пробовал.
И что?
PD> Что же касается национальной принадлежности его авторов — не знаю, знаю только, что кусок был сделан в Санкт-Петербурге, о чем здесь проскакивала информация.
В РФ у Microsoft центра разработки нет и не планируется.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
VD>>МС пока что боится писать на дотнете что-то серьезное. AVK>Уже нет. По крайней мере в девтулах грядет революция. Уже в Dev10 кое что из старого неуправляемого кода будет переписано под .NET. А уж в Dev11 ... Но про это я пока не могу ничего говорить.
А сроки появления Dev10 есть (хотя бы примерные)? И вобще ссылками на тему будущей VS не поделишься?
Здравствуйте, Дьяченко Александр, Вы писали:
ДА>А сроки появления Dev10 есть (хотя бы примерные)?
Нету. Чисто теоретически стоит рассчитывать где то на конец 2009.
ДА> И вобще ссылками на тему будущей VS не поделишься?
Нету ссылок. Более того, даже то что я знаю, пока что не подлежит разглашению. Могу только сказать, что следующий релиз будет больше нацелен именно на студию, нежели на новый CLR и C# 4 (т.е. в последних изменения будут нефундаментальные).
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
ДА>>А сроки появления Dev10 есть (хотя бы примерные)? AVK>Нету. Чисто теоретически стоит рассчитывать где то на конец 2009.
А beta версии будут?
ДА>> И вобще ссылками на тему будущей VS не поделишься? AVK>Нету ссылок. Более того, даже то что я знаю, пока что не подлежит разглашению. Могу только сказать, что следующий релиз будет больше нацелен именно на студию, нежели на новый CLR и C# 4 (т.е. в последних изменения будут нефундаментальные).
