Здравствуйте, 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>>
вместо того, чтобы идти по цепочке gdiplus.dll — gdi32.dll — win32k.sys. Правда, не совсем ясно, как к этому csrss.exe отнесется, ему все же положено знать.
