Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си.
Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера?
Здравствуйте, 11molniev, Вы писали:
1>Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си.
1>Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера?
Майкрософт уже никого и никуда не поведёт. Майкрософт лишь следует за трендом.
Здравствуйте, 11molniev, Вы писали:
1>Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си. 1>Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера?
1. Поскольку любая OS работает с теми или иными объектами — их API и так объекто-ориентрованное, — вместо this существует хэндл/дексриптор. То что функции экспортируются без группировки на классы — лишь деталь реализации.
2. WinRT так или иначе является обёрткой над старым добрым миром.
3. Конечно, что-то будет доступно только под WinRT, так же как и сейчас целый ряд API доступен только через COM. Как нибудь переживём.
+ При наличии нормальной метаинформации — генерированные биндинги этих API скорее всего можно будет сделать практически к любому языку.
PS: А что с судьбой ассемблера не так? Очень даже жив. Разумеется всё подряд на нём не пишут.
Здравствуйте, mrTwister, Вы писали:
F>> 2. WinRT так или иначе является обёрткой над старым добрым миром. T>Если под "старым добрым миром" ты имеешь ввиду Win32, то нет.
А что ты подразумеваешь под Win32? Есть замена CreateFile?
Здравствуйте, 11molniev, Вы писали:
1>Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си.
Из простого Си вполне нормально работается с COM (или псевдо com тип DirectX) . C WinRT большой разницы
быть не должно, внутри он тот же COM.
Здравствуйте, 11molniev, Вы писали:
1>Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си.
Это обычный COM.
1>Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера?
Нет никаких проблем писать под COM на С. Посмотри что генерит MIDL-компилятор для случая C. Вся разница в том, что таблица ф-ий объекта объявляется явно, а в С++ — автоматически в виде подразумеваемой таблицы виртуальных ф-ий.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, mrTwister, Вы писали:
F>>> 2. WinRT так или иначе является обёрткой над старым добрым миром. T>>Если под "старым добрым миром" ты имеешь ввиду Win32, то нет. F> А что ты подразумеваешь под Win32? Есть замена CreateFile?
fopen на си перестанет работать? а системно-зависимые фичи они на то и системно-зависимые, чтобы меняться от системы к системе. какая разница -- менять целиком API или только флаги в CreateFile? все равно старые программы воспользоваться новыми фичами не смогут, а новые пишутся с учетом обратной совместимости (если это необходимо).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, fddima, Вы писали:
F> 2. WinRT так или иначе является обёрткой над старым добрым миром.
Скорее всего, только на первых порах, как первые OLEDB дрова шли как обертка над существующим кодом. Но буквально через 5 лет ситуация поменялась до наоборот. Внутри-то всё равно всё больше и больше объектности, выгоднее давать непосредственные интерфейсы прямо "изнутри" без лишней АПИ-шной прослойки, утяжеляющей вызовы. См. DirectX.
Сдается мне, что MS задумала развивать внутренности своей ОСи, а для этого им надо малость развязать самим себе руки. Там же унутре сейчас тонны сишного кода, которые ждут, когда их перепишут.
F> 3. Конечно, что-то будет доступно только под WinRT, так же как и сейчас целый ряд API доступен только через COM. Как нибудь переживём. F> + При наличии нормальной метаинформации — генерированные биндинги этих API скорее всего можно будет сделать практически к любому языку.
Да, на сегодня COM понимается почти всеми. Поэтом такой переход будет безболезненный.
Здравствуйте, 11molniev, Вы писали:
1>Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера?
в XXI веке затачивать программу под винду можто только с целью освоения бюджетных средств. коммерческие компании вынуждены учитывать наличие растущего рынка маков, а так же мобильных устройств и всяких там планшетов. веб-версии так же не помешают.
проснитесь, время когда "программа" по умолчанию подразумевала "программа под операционную систему ms-dos/ms-win на IBM PC" _давно_ прошли и сейчас у нас не цирк, а сплошной зоопарк.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Mazay, Вы писали:
M>Майкрософт уже никого и никуда не поведёт. Майкрософт лишь следует за трендом.
+1 к предыдущим "авторам". Эти парни раз в 6-7 лет "переизобретают" то, что уже сами изобрели в прошлом или сделали их более успешные конкуренты. Бизнес.
Готов поспорить, что они также будут переизобретать С в будущем.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, 11molniev, Вы писали:
1>>Майкрософт хочет всех перевести на плюсы? А Си суждено разделить судьбу ассемблера? М>в XXI веке затачивать программу под винду можто только с целью освоения бюджетных средств. коммерческие компании вынуждены учитывать наличие растущего рынка маков, а так же мобильных устройств и всяких там планшетов. веб-версии так же не помешают.
Или наоборот их экономить, не пытаясь перенести по сразу на все платформы.
М>проснитесь, время когда "программа" по умолчанию подразумевала "программа под операционную систему ms-dos/ms-win на IBM PC" _давно_ прошли и сейчас у нас не цирк, а сплошной зоопарк.
программа в моем понимании это как раз программа под конкретную среду. И неважно что это за среда (ОС или ВМ) и на какой платформе работает — но конкретная.
Си сейчас самый переносимый из коробки. И уход от него в WinRT как раз частично нарушает идеологию один код — под все платформы.
Здравствуйте, vdimas, Вы писали:
V>Сдается мне, что MS задумала развивать внутренности своей ОСи, а для этого им надо малость развязать самим себе руки. Там же унутре сейчас тонны сишного кода, которые ждут, когда их перепишут.
Основная задача у них была — обеспечить изоляцию метрокода. С Win32 этого сделать не получится. На дотнет у Синовского идиосинкразия. СОМ протух. Остается что то новое. А если уж новое API изобретать, то, естественно, надо что то посовременнее сделать.
P.S. Когда то давно Синовский изобретал СОМ 2.0. Его жестоко обломали и перенесли акцент на дотнет. Теперь он дорвался до власти. Вот и имеем что имеем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Основная задача у них была — обеспечить изоляцию метрокода. С Win32 этого сделать не получится. На дотнет у Синовского идиосинкразия. СОМ протух. Остается что то новое. А если уж новое API изобретать, то, естественно, надо что то посовременнее сделать.
И в чем на ваш взгляд именно принципиальная новизна? Т.е. конечно есть несколько новых фич, но в целом складывается ощущение что это очередной эволюционный base win framework. И не факт, что в итоге, в данном случае эволюция не пойдет в обратную сторону
Здравствуйте, мыщъх, Вы писали:
М>fopen на си перестанет работать?
Кто его под виндой использует то? Он убог чуть менее чем полностью
М>а системно-зависимые фичи они на то и системно-зависимые, чтобы меняться от системы к системе. какая разница -- менять целиком API или только флаги в CreateFile?
Ты не понимаешь о чём говоришь.
М> все равно старые программы воспользоваться новыми фичами не смогут, а новые пишутся с учетом обратной совместимости (если это необходимо).
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, мыщъх, Вы писали:
М>>fopen на си перестанет работать? Т>Кто его под виндой использует то? Он убог чуть менее чем полностью
Я использую периодически.
Дайте-ка подумать еще — Microsoft, Oracle, Google, Cisco, etc...
Там где требования к производительности, мобильности и масштабируемости максимально высоки — там С.
Здравствуйте, a_g_99, Вы писали:
М>>>fopen на си перестанет работать? Т>>Кто его под виндой использует то? Он убог чуть менее чем полностью __>Я использую периодически. __>Дайте-ка подумать еще — Microsoft, Oracle, Google, Cisco, etc... __>Там где требования к производительности, мобильности и масштабируемости максимально высоки — там С.
Я про fopen
Здравствуйте, okman, Вы писали:
Т>>Кто его [C] под виндой использует то? Он убог чуть менее чем полностью O>Дрова под виндой пишутся на C. В подавляющем, если не сказать абсолютном, большинстве.
Полностью неправильно.
Следует читать так: Кто его [fopen] под виндой использует то? Он убог чуть менее чем полностью
Здравствуйте, мыщъх, Вы писали:
М>fopen на си перестанет работать? а системно-зависимые фичи они на то и системно-зависимые, чтобы меняться от системы к системе. какая разница -- менять целиком API или только флаги в CreateFile? все равно старые программы воспользоваться новыми фичами не смогут, а новые пишутся с учетом обратной совместимости (если это необходимо).
Что сказать то хотел?
Я и сказал, что в основном — это всё будет обёртка над старым добрым миром. Системно специфичное — в 99% никто не юзает. Именно поэтому в temp собираются горы мусора. Хм. Нет, не поэтому. Извиняюсь — там просто проблемы с головой.
А совсем уж OS специфичные функции — ну так пожалуйста.
Ну и пункт 3 ты почему-то не дочитал. Что конкретно будет в WinRT обёрнуто, конкретно CreateFile или ZwCreateFile или ещё какая-нибудь дрянь — ну пофигу же.
Сама идея — хороша, но на практике — это ещё один свой собственный мирок. Приживётся оно или нет — я не знаю. Надо оно? Я думаю надо.
Но зная МС — будет как всегда всё через задний проход, поэтому энтузиазма особого в этом я лично пока не испытываю.
Будут ли критичные API доступные только лишь под WinRT в ближайшие 2-5 лет? Ой ли.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, мыщъх, Вы писали:
F> Что сказать то хотел?
хотел сказать откуда ветер дует. берем ореентиацию на кросс-платформ. кто еще этого не понял, тот обречен. даже психиатр не поможет. а кто пишет системно-зависимые вещи типа драйверов, то там глобальный перетрах даже между сервис-паками.
F> Я и сказал, что в основном — это всё будет обёртка над старым добрым миром.
не знаю как вы, а я этими обертками сыт до невозможности. слава аллаху, что сейчас программирую под никсы. ни переход на 64-бита, ни поддержка IPv6 не колбасит и не травмирует психику.
> Системно специфичное — в 99% никто не юзает.
да ну? в винде редкая программа долетит до середины. даже инсталлятор не написать без учета всех изысков последнего писка моды.
> Именно поэтому в temp собираются горы мусора. Хм. Нет, не поэтому. Извиняюсь — там просто проблемы с головой.
вы какой temp имеете ввиду? по непонятным причинам в винде их слишком много. на счет проблем с головой согласен. есть api-функция создания временных файлов, удаление которых система гарантирует с той или иной вероятностью. так же в гайдлайнах сказано, что если в temp файл не залочен, то его удаление не должно нарушать работоспособность приложений. давайте возьмем Microsoft Security Essentials и попробуем определить сорт травы, который они курили, заглянув в temp. там лог. формат лога жуткий. но это ладно. сообщение о кол-ве найденных угроз не совпадает с показаниями log файла. легко определить, что некоторые угрозы считаются дважды, а то и трижды. типа негр с пистолетом, мекс с автоматом и мекс с гранотометом. сколько преступников? правильный ответ -- два. вот только этот ответ не там, где его ожидает увидеть юзер.
F> Ну и пункт 3 ты почему-то не дочитал. Что конкретно будет в WinRT обёрнуто, конкретно CreateFile или ZwCreateFile или ещё какая-нибудь дрянь — ну пофигу же. F> Сама идея — хороша, но на практике — это ещё один свой собственный мирок. Приживётся оно или нет — я не знаю. Надо оно? Я думаю надо. F> Но зная МС — будет как всегда всё через задний проход, поэтому энтузиазма особого в этом я лично пока не испытываю.
дочитать-то я дочитал, но оберток и так хватает. например, PyDbg это обертка над виндовым API, но независимая. вообще, обертку можно создать и свою. точно так можно выкинуть в топку всю оконную подсистему и рисовать окна и контролы вручную. не самая дебильная идея, т.к. такой подход позволит запустить ваше приложение не только на винде.
F> Будут ли критичные API доступные только лишь под WinRT в ближайшие 2-5 лет? Ой ли.
а если и будут, то что? это же вам не дет-сад. нормальная программа представляет собой сэндвич. слой сопряжения с системой обычно тонкий и уже давно написанный. мой пример с fopen не такой уж и дебильный. большинству программ ничего большего и не требуется. файлы, проецируемые в память и прочая абракадабра обычно используется в составе библиотек, реализующих, в частности, разряженные массивы. зачем вам вызывать API напрямую?
напрямую API вызывают разработчики библиотек. и для них новый API означает новые продажи...
да и вообще мода на новые API... а как со старыми программами быть? как-то попалась одна программа (название не помню) которая зачем-то вызывала API, которые появились только в хрюше, но которых не было в моей w2k. грохнул их в импорте -- на основной функционал это никак не сказалось.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, fddima, Вы писали:
F> Сама идея — хороша, но на практике — это ещё один свой собственный мирок. Приживётся оно или нет — я не знаю. Надо оно? Я думаю надо.
Так а в чем "хорошесть"? Я верчу ее и так и этак, пытаясь понять, отчистить от любимой ms маркетинговой шелухи, и пока не вижу достойных фич на базовом уровне.
То что это будет native? Так mfc, atl и wtl тоже native, уже имеют проверенную сбалансированную архитектуру. На wtl есть и удачные примеры разработки интерфейсов — напр. Chrome, которые потом с винды перебрасывали удачно на младших и старших братьев.
interopability? есть com, там вроде все ок
metro style? ну там и .net вклинится удачно, если ms препятствовать не будет
modern fcl для с++ с упором на gui для венды? в принципе интересно (на фоне Qt), но там нет переносимости на другие платформы. это отпугнет большую часть с++-ров. F> Но зная МС — будет как всегда всё через задний проход, поэтому энтузиазма особого в этом я лично пока не испытываю.
+1. Как это было с wpf. Понятно было что framework не лучше, а скорее хуже winforms. но все равно пиарили по полной, закапывая в землю winforms. Глупые люди, сами себе могилу роют. F> Будут ли критичные API доступные только лишь под WinRT в ближайшие 2-5 лет? Ой ли.
Уже сейчас понятно что нет. Чтобы сделать это, ms придется целенаправленно обеспечивать защиту от своих же frameworks. Developers, Developers, Developers не поймут.
Здравствуйте, мыщъх, Вы писали:
М>хотел сказать откуда ветер дует. берем ореентиацию на кросс-платформ. кто еще этого не понял, тот обречен. даже психиатр не поможет. а кто пишет системно-зависимые вещи типа драйверов, то там глобальный перетрах даже между сервис-паками. М>не знаю как вы, а я этими обертками сыт до невозможности. слава аллаху, что сейчас программирую под никсы. ни переход на 64-бита, ни поддержка IPv6 не колбасит и не травмирует психику.
Дык с драйверами то всё понятно. Но в целом я в общем-то согласен.
>> Системно специфичное — в 99% никто не юзает. М>да ну? в винде редкая программа долетит до середины. даже инсталлятор не написать без учета всех изысков последнего писка моды.
Гм. Инсталлятор делается и без изысков моды. Хотя говорить о windows installer вне винды как бы не приходится (кстати — неужели нельзя было сделать всё тоже самое только проще?!).
UI — да — всегда и везде очень сильно платформозависим. При чём очень очень сильно. При чём виндовые окна выигрывают в гибкости (возможность иметь несколько UI потоков, простой репарентинг окон).
Но если у тебя вполне себе сервер, то платформозависимый код — это инфраструктура, как раз как ты говоришь, поставляемая библиотеками. И то только если обобщенное/стандартное/кросс-платформенное решение не устраивает.
>> Именно поэтому в temp собираются горы мусора. Хм. Нет, не поэтому. Извиняюсь — там просто проблемы с головой. М>вы какой temp имеете ввиду? по непонятным причинам в винде их слишком много. на счет проблем с головой согласен. есть api-функция создания временных файлов, удаление которых система гарантирует с той или иной вероятностью. так же в гайдлайнах сказано, что если в temp файл не
Да любой темп. Я имел ввиду мой юзерский, но и в Windows\Temp недавно нашел хлама на 4 гига. Если уж и нет возможности использовать тот самый флаг, то позаботится об удалении вполне возможно...
F>> Но зная МС — будет как всегда всё через задний проход, поэтому энтузиазма особого в этом я лично пока не испытываю. М>дочитать-то я дочитал, но оберток и так хватает. например, PyDbg это обертка над виндовым API, но независимая. вообще, обертку можно создать и свою. точно так можно выкинуть в топку всю оконную подсистему и рисовать окна и контролы вручную. не самая дебильная идея, т.к. такой подход позволит запустить ваше приложение не только на винде.
Мне видится, что это правильно, — GTK на винде кстати так и делает. Поэтому что бы нормально вставить туда нативное виндовое окно — вэлкам к хакам с переопределением wndproc. Но это то как раз понятно. Проблемы только в этом случае возникают с реализацией стандартных поведений.
Здравствуйте, a_g_99, Вы писали:
__>И в чем на ваш взгляд именно принципиальная новизна?
По сравнению с WinAPI — ОО, изоляция от опасных вещей. По сравнению с СОМ — спилены некоторые острые углы, существенно более гладкий интероп с дотнетом.
Здравствуйте, vdimas, Вы писали:
НС>>Основная задача у них была — обеспечить изоляцию метрокода.
V>Что значит "изоляцию"?
Метро-приложениям доступен несколько меньший набор API, что позволяет более вольготно обращаться с инсталляцией софта из windows store. Метро это нечто среднее между десктопом и совсем урезанным API Windows Phone.
Здравствуйте, 11molniev, Вы писали:
1>программа в моем понимании это как раз программа под конкретную среду. И неважно что это за среда (ОС или ВМ) и на какой платформе работает — но конкретная. 1>Си сейчас самый переносимый из коробки. И уход от него в WinRT как раз частично нарушает идеологию один код — под все платформы.
Не могу представить как можно написать один раз программу которая будет работать(удовлетворять требованиям) на Win и iOS.
Здравствуйте, __SPIRIT__, Вы писали:
1>>Си сейчас самый переносимый из коробки. И уход от него в WinRT как раз частично нарушает идеологию один код — под все платформы. __S>Не могу представить как можно написать один раз программу которая будет работать(удовлетворять требованиям) на Win и iOS.
Классический сценарий — общее ядро/бэкэнд и абсолютно разные фронты.
Здравствуйте, fddima, Вы писали:
1>>>Си сейчас самый переносимый из коробки. И уход от него в WinRT как раз частично нарушает идеологию один код — под все платформы. __S>>Не могу представить как можно написать один раз программу которая будет работать(удовлетворять требованиям) на Win и iOS. F> Классический сценарий — общее ядро/бэкэнд и абсолютно разные фронты.
В таком случае ядро можно изолировать от внешней среды. И для него ничего не поменяется. Только разные платформы диктуют разный подход к созданию приложений, для логики разбора файла или логики подсчета чего-либо это не проблема, но если это логика работы софта... Будут проблемы с юзабилити и внешним видом.
Здравствуйте, __SPIRIT__, Вы писали:
__S>В таком случае ядро можно изолировать от внешней среды. И для него ничего не поменяется. Только разные платформы диктуют разный подход к созданию приложений, для логики разбора файла или логики подсчета чего-либо это не проблема, но если это логика работы софта... Будут проблемы с юзабилити и внешним видом.
Это не совсем так. По крайней мере кардинальной разницы нет. Всё зависит от требований: что бы работало везде, что бы работало везде и выглядело как родное приложение, что были родными приложениями. Идеального единственно правильного пути — не существует.
Для приложения с 3-мя формами — может быть проще под винду, под GTK, под Mac накидать совершенно независимые реализации UI. И никаких проблем с юзабилити не будет, ядро ессно будут делить все. Но для более сложных приложений, — едва ли такой подход был бы оправданым. Ну вот взять хромиум (особенно сейчас, когда нативные формы искоренены) — не смотря на то, что там есть полное разделение на платформы, и не такой уж и богатый нативный интерфейс — тем не менее внутри там самописных обобщенных прослоек предостаточно.
Сделать в общем можно всё что угодно — были бы ресурсы.
PS: Да, забыл — QT там не используется — потому что QT — говно.
Здравствуйте, 11molniev, Вы писали:
1>Вот WinRT это вроде как очень хорошо и все в том же духе. Но вместе с тем WinRT — это объектно ориентированное API, причем с управлением ресурсами через счетчики (new ref) что несколько противопоставляется обычному Си.
1. C устарел и не нужен
2. ООП и ref-counted GC совершенно ортогальны С, единственная проблема — вызовы release() надо писать руками
3. WinAPI — это тоже ОО API, с тем же ref-counted GC
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, a_g_99, Вы писали:
__>>И в чем на ваш взгляд именно принципиальная новизна?
НС>По сравнению с WinAPI — ОО, изоляция от опасных вещей.
Вы не могли бы пояснить конкретнее, о чем вы здесь? Речь идет о конкретных фичах типа hat pointers, boxing, type conversion или о FCL WinRT в общем?
Просто если смотреть в целом то те же MFC и ATL/WTL имели продвинутую и устоявшуюся ОО иерархию над обширной частью winapi (особенно хороша на мой взгляд wtl).
Про изоляцию сложнее — натив есть натив.
НС>По сравнению с СОМ — спилены некоторые острые углы,
Немного спилены. Но в целом это тот же API c упором на COM (не пропадать же добру придуманному в 90-ые) с теми же концепциями midl-интерфейсов, фабриками объектов
>существенно более гладкий интероп с дотнетом.
так надо было делать в дотНете, а не придумывать еще один framework
У меня просто складывается ощущение что парни из MS движутся по кругу, вместо того чтобы включать голову. Похоже нет достойных визионеров с нормальными идеями
Здравствуйте, мыщъх, Вы писали:
F>> Что сказать то хотел? М>хотел сказать откуда ветер дует. берем ореентиацию на кросс-платформ. кто еще этого не понял, тот обречен. даже психиатр не поможет.
кроссплатформ не нужен. точка.
вот допустим, есть хорошая удобная программа, у нее 1 миллион обычных юзеров.
делаем версию под никсы — появляется еще сколько? пара тысяч юзеров?
кода станет больше, придется отказаться от удобных MSVS-specific фич, поддерживать код станет сложнее, тестировать надо будет под разные системы
— и оно того стоит?
программы для профессионального использования могут быть кроссплатформенными, а массовый юзер сидит только под одной платформой — win32(x32)
Здравствуйте, a_g_99, Вы писали:
__>У меня просто складывается ощущение что парни из MS движутся по кругу, вместо того чтобы включать голову. Похоже нет достойных визионеров с нормальными идеями
Предложи идею.
COM действительно критиковали многократно, но совсем по другому поводу, а именно — предлагалось разнести понятие объекта и интерфейса. Предлагалось сие для того, чтобы держать жесткую ссылку только на объект (с соотв. приращением AddRef), но интерфейсы предлагалось пользовать как слабые ссылки, с целью удешевления получения интерфейса (без лишнего AddRef). Но фиг его знает... Мне такая схема кажется потенциально более опасной, т.к. легко допустить рассогласованность времени жизни указателя на объект и указателя на интерфейс... Сейчас в COM эти вещи однородны, ИМХО правильно. В COM есть понятие "класса", но этот класс немного не так связан с объектом, как в привычном ООП, скорее является лишь идентификатором к аргументу фабрики.
Здравствуйте, fddima, Вы писали:
F> fopen годен чуть менее, чем всегда.
Зачем он вообще нужен, при наличии open? По факту лишь имеем добавочный мьютекс, утяжеляющий вызовы и дурацкий самописный буфер, который на современных операционках лишний. По крайней мере до тех пор, пока не на надо извлекать по 1-му символу. Но это лучше делать в клиентском коде, без всех этих мьютексов.
Здравствуйте, Abyx, Вы писали:
A>1. C устарел и не нужен
Это ложь.
A>2. ООП и ref-counted GC совершенно ортогальны С, единственная проблема — вызовы release() надо писать руками
Способы подсчета ссылок и GC никак с ООП не связаны. И тем более с языком программрования. Ведь и ява и C# как языки могут существовать без своего родного рантайма и GC — просто это никому не нужно.
A>3. WinAPI — это тоже ОО API, с тем же ref-counted GC
По сути — +1.
Единственное, что очень бесит — это то, что открытые (исполнимые, запущенные) файлы "блокируются" в отличии от unix-like систем. Хотя на NTFS ничего не мешает их не блокировать — по сути теже самые inode или как оно там у них.
Здравствуйте, a_g_99, Вы писали:
НС>>По сравнению с СОМ — спилены некоторые острые углы, __>Немного спилены. Но в целом это тот же API c упором на COM (не пропадать же добру придуманному в 90-ые) с теми же концепциями midl-интерфейсов, фабриками объектов
Тут есть нюанс — WinRT имеет метаинформацию в виде типа дотнетных сборок. Это ECMA стандарт. С этим работать в разы легче из-за обилия тулзов и т.п. Что делать с midl при необходимости интерфейсы программно обработать — это ховайся.
>>существенно более гладкий интероп с дотнетом. __>так надо было делать в дотНете, а не придумывать еще один framework
Нет. "Завтра" при неоходимости возможно могут появлятся биндинги к WinRT API под питон и яву, чего невозможно достичь затачиваясь на конкретный CLR рантайм. На самом деле и сейчас любая приличная библиотека имеет ABI. Хорошим примером может служить WebKit2 — очень интероперабельно и COM-о независимо. Это реально необходимая вещь. Но проблема на практике в том, что разработчки часто не предоставляют abi (т.е. например V8 — исключительно C++ и ещё хорошо обвешанный минами (templates)). Ну и гора других. Ну и главное фиаско в целом — это то, что нет единого стандарта. Я сам работаю над ABI для одного фреймворка, пока времени особо нет и оно сильно никому не надо — но тем не менее его отсутствие — это реальная проблема, и автор фреймворка согласен с этим, но мы работаем исходя из практических нужд. Более того текущее C-like API как минимум требует по 2-3 лишних malloc/mfree против нормального ABI. Но ещё раз повторюсь — проблема не в том как оно внутри — проблема в том, что у всех свой зоопарк. COM не любили и не любят потому что он излишне извращен ненужной (зачастую ненужной) сложностью — но в остальном COM — был и есть хорош — по сути COM — это то, что делают наши любимые языки за нас, только в "бинарном" виде. Просто переусложнили.
__>У меня просто складывается ощущение что парни из MS движутся по кругу, вместо того чтобы включать голову. Похоже нет достойных визионеров с нормальными идеями
Ощущение конечно такое есть. Но, нам — парням из не MS — их картинки не видно. Вполне может быть стратегически их решения верны, я не утверждаю — время само покажет.
Здравствуйте, vdimas, Вы писали:
V>Предложи идею.
Да нечего там предлагать. Максимум байты местами переставить, что бы было не так как у них.
По поводу интерфейсов — я лично согласен с тобой.
В общем-то давайте вспомним VB в котором никого особо не парила сложность COM, многие и не знали что такое COM и опосредственно его использовали. То что C++ как и другие языки не особо заточены под работу с ним — ну дык — вроде как никто ж и не обещал.
Ой, да и стоит ли далеко ходить — я сам ленив — настолько лень было освобождать дотнетные обёртки вручную, что проще было позвать GC
.
Хотя мне лично COM в таком виде каком он есть — люто не нравится. Недостаток тулзов, слабая контроллируемость.
PS: У меня есть сервер один, в нём регулярно in-proc com сервер отваливается — второй год не могу найти причину. Я не эксперт в COM — но и не полный дурак. Проблема решена в общем-то, путём вообще замены сервиса, т.к. наличие COM сервера там вообще не нужно, прикладной код сервера написан в лучших традициях магии указателей, разумеется это неясно как работает, ещё и сбоит, и полное отсутсвие вменяемых абстракций и вдобавок как выяснилось в ходе переписывания этого сервисы "с нуля" — игнорирования некоторых принципов обмена. В обшем — COM сам по себе и не причём, эмоции...
Давайте не будем отождествлять себя и массового юзера?
Я знаю примеры из жизни когда у кастомера есть собственные клиенты которые сидят под линуксами. При чём достаточно массово выходит, что проигнорировать ну никак нельзя.
Здравствуйте, vdimas, Вы писали:
F>> fopen годен чуть менее, чем всегда. V>Зачем он вообще нужен, при наличии open? По факту лишь имеем добавочный мьютекс, утяжеляющий вызовы и дурацкий самописный буфер, который на современных операционках лишний. По крайней мере до тех пор, пока не на надо извлекать по 1-му символу. Но это лучше делать в клиентском коде, без всех этих мьютексов.
Откуда мьютекс? Впрочем даже ежели так — то как бы пофиг. На винде гораздо раньше стоит заботится о том что FS пишет last access time и создаёт короткие имена, а не то, что ты говоришь. При этом куда более реальная проблема и реагирует и на CreateFile тоже.
Хотя может у тебя и не так, а мы пишем файлы тысячами. Такова наша реальность. Я не спорю, что может быть иначе.
В любом случае — критика тут в треде о том — что стандартные API на подобии fopen или berkley sockets должны работать одинаково хорошо везде, а не так, как схалтурири в нашей любимой компании.
За сим, разрешите откланяться.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, мыщъх, Вы писали:
A>вот допустим, есть хорошая удобная программа, у нее 1 миллион обычных юзеров. A>делаем версию под никсы — появляется еще сколько? пара тысяч юзеров?
про никсы я не говорил. если это программа не переводчик с русского на иврит и продается в сша, то поддержка мака по самым-самым скромным оценкам добавит еще 100,000 юзеров на данный момент (и еще больше в перспективе). пусть под мак она стоит $20. поддержка мака принесет два миллиона долларов.
A>программы для профессионального использования могут быть кроссплатформенными, а массовый юзер сидит только под одной платформой — win32(x32)
как минимум есть рынок смартфонов и планшетов. конечно, планшеты и смартфоны не для всех программ подходят, но это рынок. браузеры -- вполне себе платформа, куда сейчас пытаются засунуть и 3D графику и все остальное. кстати, для браузеров появляется множество кросс-платформенных сэндвичей с установкой приложений на серверной стороне. во всяком случае facebook очень активно работает в этом направлении. для гугла это похоже что-то вроде хобби (вы можете написать свой гаджет, загрузить на гугл и его увидят и установят миллионы, пусть он будет стоить $0.99, у вас уже набирается миллион спокойно).
даже если вы в танке и смотрите на мир через узкое забрало, то не можете отрицать, что за пределами win есть жизнь. причем, там весна и стремительное развитие, на котором делают деньги, а под win -- осень переходящая в зиму.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Abyx, Вы писали:
A>кроссплатформ не нужен. точка.
Это вас сильно занесло.
A>вот допустим, есть хорошая удобная программа, у нее 1 миллион обычных юзеров. A>делаем версию под никсы — появляется еще сколько? пара тысяч юзеров?
Речь о десктопе, насколько я понял?
Давайте глянем с вами на реальные цифры в штатах (которые являются основным потребителем этого рынка):
Рынок смартфонов — ~50% Android/Linux, ~30% Apple,..., ~5% Microsoft
Рынок планшетов — ~65% Apple, ~30% Android/Linux
Рынок ОС — ~15% Apple, 0.7-1% Linux, 83% Microsoft
Гуглил, старался для вас.
Если мобильные платформы будут продолжать свой взрывной рост, то win platform очень скоро придется потесниться, разделив первое место с Apple и Google.
Отсюда вывод — кроссплатформ хотя бы в ядре/бэкэнде очень важен, соотвественно будет спрос на таких специалистов (сейчас уже можно видеть по вакансиям)
A>кода станет больше, придется отказаться от удобных MSVS-specific фич, поддерживать код станет сложнее, тестировать надо будет под разные системы A>- и оно того стоит?
Стоит, если это достойно оплачивается
Здравствуйте, fddima, Вы писали:
F>В общем-то давайте вспомним VB в котором никого особо не парила сложность COM, многие и не знали что такое COM и опосредственно его использовали.
C VB и VBA история вообще отдельная. Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release и генерит такой код, какой был бы при ручном управлении COM без смарт-поинтеров. Я вообще одно время заинтересовался и просматривал ассемблерные листинги VB6 — очень неплохой ход генерится в случая полных аннотаций типов (без использования VARIANT или авто-определений переменных).
F>То что C++ как и другие языки не особо заточены под работу с ним — ну дык — вроде как никто ж и не обещал.
Вот, специально под WinRT заточили C++ новыми расширениями. Посмотрим, поможет ли это им нивелировать избыточные парные AddRef/Release.
Здравствуйте, a_g_99, Вы писали:
A>>кроссплатформ не нужен. точка. __>Это вас сильно занесло.
__>Речь о десктопе, насколько я понял?
__>Рынок смартфонов — ~50% Android/Linux, ~30% Apple,..., ~5% Microsoft __>Рынок планшетов — ~65% Apple, ~30% Android/Linux
__>Если мобильные платформы будут продолжать свой взрывной рост, то win platform очень скоро придется потесниться, разделив первое место с Apple и Google
А приложения для десктопов и смартфонов хоть как-то пересекаются?
Здравствуйте, vdimas, Вы писали:
V>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release
Брр. "Привычный код" что нить кроме присваивания поинтеров делал?
Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
Здравствуйте, a_g_99, Вы писали:
НС>>По сравнению с WinAPI — ОО, изоляция от опасных вещей. __>Вы не могли бы пояснить конкретнее, о чем вы здесь? Речь идет о конкретных фичах типа hat pointers, boxing, type conversion или о FCL WinRT в общем? __>Просто если смотреть в целом то те же MFC и ATL/WTL имели продвинутую и устоявшуюся ОО иерархию над обширной частью winapi (особенно хороша на мой взгляд wtl).
MFC, и, в особенности ATL — это просто библиотеки. Никто не мешает мимо них ходить в Win32API. А вот WinRT мешает — ничем другим ты пользоваться не можешь.
>>существенно более гладкий интероп с дотнетом. __>так надо было делать в дотНете, а не придумывать еще один framework
Надо было. Но у Синовского идиосинкразия к нему.
__>У меня просто складывается ощущение что парни из MS движутся по кругу, вместо того чтобы включать голову.
Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет.
А что плохого в WinRT? Очевидно, что идея полностью управляемых приложений не прошла. Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками.
Здравствуйте, Cyberax, Вы писали:
C>А что плохого в WinRT?
В нем самом — ничего. Плохое в NIH.
C>Очевидно, что идея полностью управляемых приложений не прошла.
Со слова "очевидно" как правило начинаются демагогические высказывания. Нет, не очевидно. Во-первых есть винфон, который демонстрирует что вопли про обязательную ресурсоемкость managed — не соответствуют действительности. Во-вторых можно было не СОМ на дотнет в очередной раз натягивать, а наоборот, чуть подправить ABI дотнета, чтобы с минимумом проблем можно было под него писать на разных языках, а не только на VC++. Это был бы существенно более логичный и понятный шаг. А с WinRT лично у меня есть серьезные опасения, что, если вдруг Синовский сольется (а такое вполне может быть, если, к примеру, восьмерка не пойдет), этот WinRT задвинут куда подальше. Чехарда в системных API до добра не доводит — и так каша из Win32, FCL и COM местами аццкая, а тут еще и WinRT.
C>Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME
Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут.
C> и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками.
Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В нем самом — ничего. Плохое в NIH. C>>Очевидно, что идея полностью управляемых приложений не прошла. НС>Со слова "очевидно" как правило начинаются демагогические высказывания. Нет, не очевидно. Во-первых есть винфон, который демонстрирует что вопли про обязательную ресурсоемкость managed — не соответствуют действительности.
Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки.
C>>Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME НС>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут.
А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин.
C>> и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками. НС>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить.
А что там не так? Те же объекты со счётчиком ссылок и рефлексией.
Здравствуйте, Cyberax, Вы писали:
C>Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки.
Так нативный код совсем запрещать никто и не предлагает.
НС>>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут. C>А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин.
Так ты первый поиски начал.
НС>>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить. C>А что там не так?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки. НС>Так нативный код совсем запрещать никто и не предлагает.
Ну так ещё пример — Андроид. Там совершенствуют NDK, так как для многих приложений просто делать прослойку на Java только для интерфейса нет смысла и неудобно.
В общем, я поверю в сказки про нативный код как только увижу, что MS Office под него переписали.
НС>>>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут. C>>А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин. НС>Так ты первый поиски начал.
Просто конкретно сейчас это как раз самый используемый архитектурный аналог WinRT.
НС>>>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить. C>>А что там не так? НС>А ты попробуй.
Пробовал. Мне не особо API у GTK нравится сам по себе, но код на GTK# не особо отличим от кода на Python'е.
Здравствуйте, Трололоша, Вы писали:
V>>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release Т>Брр. "Привычный код" что нить кроме присваивания поинтеров делал? Т>Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
"Что-то" полезное — это тоже оперирование интерфейсами. Если натравить импорт на библиотеку, то получение любого объекта превращается в возврат _com_ptr_t<> по значению, вместо подачи &ptr как последнего аргумента. В этих возвратах и сидят лишние парные AddRef/Release. Соответственно, пробежаться по какой-нить иерархии на плюсах вдвое дороже, чем на VB.
Здравствуйте, Cyberax, Вы писали:
C>Ну так ещё пример — Андроид. Там совершенствуют NDK
И пишут кучу кода самого андроида на жабе. При этом JVM в андроиде на редкость убога.
C>В общем, я поверю в сказки про нативный код как только увижу, что MS Office под него переписали.
Переписать офис под нативный код? Ты хотел сказать на managed? Никто ничего переписывать не будет, это не окупится.
НС>>Так ты первый поиски начал. C>Просто конкретно сейчас это как раз самый используемый архитектурный аналог WinRT.
Самый используемый архитектурный аналог WinRT называется СОМ.
C>Пробовал. Мне не особо API у GTK нравится сам по себе, но код на GTK#
GTK# это уже готовая обертка, причем совсем не тривиальная. Для WinRT такие обертки не нужны.
Здравствуйте, Abyx, Вы писали:
A>1. C устарел и не нужен
ИМХО язык программирования устаревает и не нужен, когда им практически не пользуются. А С используется поактивней многих "новых" "не устаревших" языков. Так что нужен.
Здравствуйте, vdimas, Вы писали:
V>>>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release Т>>Брр. "Привычный код" что нить кроме присваивания поинтеров делал? Т>>Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
V>"Что-то" полезное — это тоже оперирование интерфейсами. Если натравить импорт на библиотеку, то получение любого объекта превращается в возврат _com_ptr_t<> по значению, вместо подачи &ptr как последнего аргумента. В этих возвратах и сидят лишние парные AddRef/Release.
Это архитектурный просчёт библиотеки поддержки импорта, а не C++. Сам С++ позволяет писать как тебе захочется.
Да и туда (_com_ptr_t) достаточно ИМХО добавить move-constructible чтоб убрать кучу лишних addref/release.
Здравствуйте, Трололоша, Вы писали:
V>>"Что-то" полезное — это тоже оперирование интерфейсами. Если натравить импорт на библиотеку, то получение любого объекта превращается в возврат _com_ptr_t<> по значению, вместо подачи &ptr как последнего аргумента. В этих возвратах и сидят лишние парные AddRef/Release. Т>Это архитектурный просчёт библиотеки поддержки импорта, а не C++. Сам С++ позволяет писать как тебе захочется.
Не уверен что просчет. Семантически получается именно так, как предполагалось использовать.
Т>Да и туда (_com_ptr_t) достаточно ИМХО добавить move-constructible чтоб убрать кучу лишних addref/release.
Эта простейшая фича опоздала лет на 15 минимум. Хотя, лучше поздно, чем никогда...
А вообще, специальные move-constructible не нужны. Я еще лет 10 назад местами активно пользовал простейшую библиотеку смарт-поинтеров, в которой их было 2 — один из них специально для возвращаемого значения и прочих времененных сценариев. Т.е. получалась система из двух взаимодействующих типов, один из которых unique, другой shared. Не понимаю, что помешало сделать так же для _com_ptr_t.
Здравствуйте, fddima, Вы писали:
F> Откуда мьютекс? Впрочем даже ежели так — то как бы пофиг.
Он один на все потоки, это серьезное бутылочное горлышко в многопоточной программе.
F>На винде гораздо раньше стоит заботится о том что FS пишет last access time и создаёт короткие имена, а не то, что ты говоришь.
Буфер в 256 символов тебя не спасет. Лучше планировать буферирование самому.
F>При этом куда более реальная проблема и реагирует и на CreateFile тоже.
CreateFile довольно-таки нетривиален, особенно с учетом обыгрывания всех прав доступа. Таки пользоваться CRT несравненно проще.
F>Хотя может у тебя и не так, а мы пишем файлы тысячами. Такова наша реальность.
Тем более, нельзя использовать fopen — тормоза необыкновенные.
Надо пользовать posix open, а затем под виндами так:
handle_ = HANDLE(_get_osfhandle(file_));
И дальше уже ReadFile/WriteFile.
А под линухами продолжать пользоваться целочисленным file descriptor.
F>В любом случае — критика тут в треде о том — что стандартные API на подобии fopen или berkley sockets должны работать одинаково хорошо везде, а не так, как схалтурири в нашей любимой компании.
Виндовые сокеты совместимы с BSD. И да, в той же posix сокет является таким же точно file descriptor, к которому применимы все операции, наподобие read/write/poll. Т.е. posix open сделает твою программу более однородной концептуально. А fopen заметно выбивается из струи. ИМХО, это наитупейшая часть CRT, как по дизайну, так и по реализации.
Здравствуйте, vdimas, Вы писали:
F>>При этом куда более реальная проблема и реагирует и на CreateFile тоже. V>CreateFile довольно-таки нетривиален, особенно с учетом обыгрывания всех прав доступа. Таки пользоваться CRT несравненно проще.
Ой йа вас умоляю.
Если "без учёта обыгрывания прав доступа": CreateFile (filename, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);
Где тут нетривиальность?
Пачка флагов и всё.
Изобрази на CRT например вот это
CreateFileW (L"\\\\?\\C:\\...длинный путь....\\file.bin", GENERIC_WRITE, FILE_SHARE_DELETE, NULL, TRUNCATE_EXISTING, FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_WRITE_THROUGH, NULL);
V>Тем более, нельзя использовать fopen — тормоза необыкновенные. V>Надо пользовать posix open, а затем под виндами так:
Надо сразу пользовать WinAPI функцию, а не её убогую обёртку.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>MFC, и, в особенности ATL — это просто библиотеки. Никто не мешает мимо них ходить в Win32API. А вот WinRT мешает — ничем другим ты пользоваться не можешь.
И где преимущество ? Получается очередная ограниченая поделка, да еще без возможности обращения к ядровым функциям системы?
НС>Надо было. Но у Синовского идиосинкразия к нему.
Так а у менеджмента на плечах головы есть или там все поголовно люди гуманитарного образования? Классическая проблема MS — один парень вдруг воображает себя идеологом и начинает делать новую супервещь, выбрасывая на помойку все старые концепции. А потом получается что этот framework вдруг неработоспособен. И еще здорово когда они могут это признать, как в случае winfs. А ведь по большей части нет.
НС>Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет.
Наоборот. Посмотрите по годам — сначала был COM, потом они вопили, что "король умер, встречайте нового короля", то бишь .Net, потом они решили что .net не хватает dl fcl и выпустили доп. каркасы. А сейчас снова откапывают COM. Получается спираль.
Здравствуйте, a_g_99, Вы писали:
__>Наоборот. Посмотрите по годам — сначала был COM, потом они вопили, что "король умер, встречайте нового короля", то бишь .Net, потом они решили что .net не хватает dl fcl и выпустили доп. каркасы. А сейчас снова откапывают COM. Получается спираль.
COM это в первую очередь объектно-ориентированный интероп между языками, причём низкоуровневый, без всяких виртуальных машин. .NET это в первую очередь C#, виртуальная машина, CLR и только очень во вторую очередь общая среда для разных языков. По-моему это совсем не альтернативы. Если надо взаимодействовать между С++ и .NET, COM — самый естественный вариант. И никто его не закапывал.
Здравствуйте, mrTwister, Вы писали:
T>Если под "старым добрым миром" ты имеешь ввиду Win32, то нет.
Вот тут утвержадется, что WinRT реализовано поверх Win32, не параллельно к нему.
Здравствуйте, Yoriсk, Вы писали:
Y>А приложения для десктопов и смартфонов хоть как-то пересекаются?
Конечно пересекаются. Скажем, необходимость открывать файлы Excel сейчас есть на всём.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, vsb, Вы писали:
vsb>>.NET это в первую очередь [...] виртуальная машина
A>я бы таки писал не "виртуальная машина", а "байткод" или "MSIL", а то получается что в .NET действительно есть какая-то ВМ
Из контекста очевидно, что речь идет о моделях вычисления и управления памятью, но никак не виртуализации ОС.
Здравствуйте, a_g_99, Вы писали:
НС>>MFC, и, в особенности ATL — это просто библиотеки. Никто не мешает мимо них ходить в Win32API. А вот WinRT мешает — ничем другим ты пользоваться не можешь. __>И где преимущество ?
WinRT позволяет ставить приложения только из Windows Store, что, если говорить о пользователе, гарантирует хоть какой то уровень качества, по крайней мере в плане стабильности системы. Для совсем мелких устройств типа планшетов это критично.
__> Получается очередная ограниченая поделка, да еще без возможности обращения к ядровым функциям системы?
Получается ОС, подходящая для ARM планшетов.
НС>>Надо было. Но у Синовского идиосинкразия к нему. __>Так а у менеджмента на плечах головы есть или там все поголовно люди гуманитарного образования?
Синовский и есть менеджмент. Круче него только лысый.
НС>>Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет. __>Наоборот. Посмотрите по годам — сначала был COM, потом они вопили, что "король умер, встречайте нового короля", то бишь .Net, потом они решили что .net не хватает dl fcl и выпустили доп. каркасы. А сейчас снова откапывают COM. Получается спираль.
Я вообще для кого все это писал выше? Перечитай еще раз, внимательно, и не только последнюю фразу.
Здравствуйте, vsb, Вы писали:
vsb>COM это в первую очередь объектно-ориентированный интероп между языками, причём низкоуровневый, без всяких виртуальных машин. .NET это в первую очередь C#, виртуальная машина, CLR и только очень во вторую очередь общая среда для разных языков. По-моему это совсем не альтернативы. Если надо взаимодействовать между С++ и .NET, COM — самый естественный вариант. И никто его не закапывал.
.NET + COM жостко сливает против специализированных биндингов. Лиж бы нативная "ответка" была адекватной. Сгодится и COM, но только не то, что получается в дотнете из коробки.
Здравствуйте, vdimas, Вы писали:
Т>>Да и туда (_com_ptr_t) достаточно ИМХО добавить move-constructible чтоб убрать кучу лишних addref/release.
V>Эта простейшая фича опоздала лет на 15 минимум. Хотя, лучше поздно, чем никогда...
В общем то и move конструкторы не нужны. для случая с возвратом _com_ptr_t неплохо работает и древний RVO.
для забивания гвоздя надо выбирать правильный микроскоп.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, mrTwister, Вы писали:
T>>Если под "старым добрым миром" ты имеешь ввиду Win32, то нет. 0>Вот тут утвержадется, что WinRT реализовано поверх Win32, не параллельно к нему.
Ес-но, в первых версиях так и будет. Но тебе недоступны заголовки и библиотеки импорта системных DLL, как они доступны Skype и прочим избранным.
Хотя... они не нужны, положа руку на.. АПИ расписан в MSDN и есть заголовки для виндов. А проэмулировать библиотеки импорта для нужных DLL не проблема вовсе, там обычный PE-формат, вес экспорт торчит наружу. А сигнатуры мы знаем. ))
Здравствуйте, Трололоша, Вы писали:
F>>>При этом куда более реальная проблема и реагирует и на CreateFile тоже. V>>CreateFile довольно-таки нетривиален, особенно с учетом обыгрывания всех прав доступа. Таки пользоваться CRT несравненно проще. Т>Ой йа вас умоляю. Т>Если "без учёта обыгрывания прав доступа": CreateFile (filename, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); Т>Где тут нетривиальность?
Нетривиальность ты описал как NULL, что является багом в общем случае.
Т>Пачка флагов и всё.
Этого мало.
Т>Изобрази на CRT например вот это Т>CreateFileW (L"\\\\?\\C:\\...длинный путь....\\file.bin", GENERIC_WRITE, FILE_SHARE_DELETE, NULL, TRUNCATE_EXISTING, FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_WRITE_THROUGH, NULL);
Я не спорю, что АПИ ОС можно и нужно использовать для специфичных для оси вещей, но не для банального же временного файла, так?
V>>Тем более, нельзя использовать fopen — тормоза необыкновенные. V>>Надо пользовать posix open, а затем под виндами так: Т>Надо сразу пользовать WinAPI функцию, а не её убогую обёртку.
Ну так ты пока не продемонстрировал, что умеешь пользовать WinAPI. У тебя прога не выставит текущие права на операцию открытия хендла, не разобралась с наследованием хендла в порожденных процессах и т.д., а CRT всё это сделает... Твой код — никому не нужный мусор, обычная коровья лепешка в коде, источник неожиданных багов на стороне клиента.
Здравствуйте, vdimas, Вы писали:
V>Нетривиальность ты описал как NULL, что является багом в общем случае.
Там два NULL. И оба не являются багом.
Т>>Пачка флагов и всё. V>Этого мало.
Мало для чего? Как будет "не мало"?
Т>>Изобрази на CRT например вот это Т>>CreateFileW (L"\\\\?\\C:\\...длинный путь....\\file.bin", GENERIC_WRITE, FILE_SHARE_DELETE, NULL, TRUNCATE_EXISTING, FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_WRITE_THROUGH, NULL);
V>Вот и выросло поколение, CRT в руках не державшее.
Святая простота!
V>http://msdn.microsoft.com/en-us/library/z0kc8e3z%28v=vs.80%29.aspx
Ты читал вообще что надо сделать?
Специально покажу пальцем: FILE_FLAG_WRITE_THROUGH. Ну или чтоб совсем стало всё интересно поменяем на FILE_FLAG_NO_BUFFERING.
V>Я не спорю, что АПИ ОС можно и нужно использовать для специфичных для оси вещей, но не для банального же временного файла, так?
Да пожалуйста, давай поменяем FILE_FLAG_DELETE_ON_CLOSE на FILE_FLAG_OVERLAPPED, чтоб не считать это больше временным файлом.
V>Ну так ты пока не продемонстрировал, что умеешь пользовать WinAPI.
Не учите деда кашлять, вьюноша. Судя по написанному ви таки в CRT ручки не запускали никогда.
Щас будем проводить ликбез. Звиняй, сам нарвался.
V> У тебя прога не выставит текущие права на операцию открытия хендла V> не разобралась с наследованием хендла в порожденных процессах и т.д.
Перед тем как писать ерунду бывает полезно почитать документацию.
А в ней в частности английским по белому написано следующее:
lpSecurityAttributes
If this parameter is NULL, the handle returned by CreateFile cannot be inherited by any child processes the application may create and the file or device associated with the returned handle gets a default security descriptor.
V> а CRT всё это сделает...
Дааааа!!!! С разбегу и апстену.
Смотрим:
_CRTIMP int __cdecl _wopen(const wchar_t * path, int oflag, int pmode /* = 0 */)
{
int fh;
/* Last parameter passed as 0 because we don't want to validate pmode from _wopen */
errno_t e = _wsopen_helper(path, oflag, _SH_DENYNO, pmode, &fh, 0);
return e ? -1 : fh;
}
#define_tsopen_helper _wsopen_helper
errno_t __cdecl _tsopen_helper (
const _TSCHAR *path,
int oflag,
int shflag,
int pmode,
int * pfh,
int bSecure
)
{
... cut ...
__try {
retval = _tsopen_nolock( &unlock_flag,
pfh,
path,
oflag,
shflag,
pmode,
bSecure );
}
__finally {
... cut ...
}
... cut ...
return retval;
}
static errno_t __cdecl _tsopen_nolock (
int *punlock_flag,
int *pfh,
const _TSCHAR *path,
int oflag,
int shflag,
int pmode,
int bSecure
)
{
... cut ...
SECURITY_ATTRIBUTES SecurityAttributes;
char tmode = __IOINFO_TM_ANSI; /* textmode - ANSI/UTF-8/UTF-16 */
errno_t retvalue = 0;
SecurityAttributes.nLength = sizeof( SecurityAttributes );
SecurityAttributes.lpSecurityDescriptor = NULL;if (oflag & _O_NOINHERIT) {
SecurityAttributes.bInheritHandle = FALSE;
fileflags = FNOINHERIT;
}
else {
SecurityAttributes.bInheritHandle = TRUE;
fileflags = 0;
}
... cut ...
/*
* try to open/create the file
*/if ( (osfh = CreateFile( (LPTSTR)path,
fileaccess,
fileshare,
&SecurityAttributes,
filecreate,
fileattrib,
NULL ))
== (HANDLE)(-1) )
{
... cut ...
exit:
return retvalue;
}
Ну и где там выставление прав? Всё что оно делает — ставит inheritance флаг, если он нужен. Если не нужен — то можно просто передавать NULL, как это сделано у меня, эффект будет тот же. Ликбез тут: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379560(v=vs.85).aspx
Сурсы CreateFileW сюда скопировать или сам проверишь?
V> Твой код — никому не нужный мусор, обычная коровья лепешка в коде, источник неожиданных багов на стороне клиента.
Ай пацталом.
Ты сейчас кидаешь пальцы перед человеком, который лет 10 уже с WinAPI на "эй ты!".
Здравствуйте, vsb, Вы писали:
vsb>COM это в первую очередь объектно-ориентированный интероп между языками, причём низкоуровневый, без всяких виртуальных машин. .NET это в первую очередь C#, виртуальная машина, CLR и только очень во вторую очередь общая среда для vsb>разных языков.
Я бы сказал так, COM это сложный высокоуровневый ipc протокол/интероп, так как позволяет шарить не просто данные (как это делают более простые ipc), а реализовать передачу метаданных о типе через нейтральный для языка контракт (напр. idl). Про .net вы в целом норм. обобщили (кто хочет узнать больше, прочтет единственную хорошую книжку по .net serge lidin).
Я (к счастью, пока из ума не выжил) и не говорил что это одно и тоже.
vsb>По-моему это совсем не альтернативы. Если надо взаимодействовать между С++ и .NET, COM — самый естественный вариант.
Не согласен с вашим утверждением. Прямые биндинги сильно эффективнее.
vsb>И никто его не закапывал.
Во напр. известная статья тех времен. Конечно никто напрямую не "хоронил" COM. Просто у них акценты сменились
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>WinRT позволяет ставить приложения только из Windows Store, что, если говорить о пользователе, гарантирует хоть какой то уровень качества, по крайней мере в плане стабильности системы. Для совсем мелких устройств типа планшетов это критично. __>> Получается очередная ограниченая поделка, да еще без возможности обращения к ядровым функциям системы? НС>Получается ОС, подходящая для ARM планшетов.
Можно пруф в студию относительно WinRT и ARM?
НС>Я вообще для кого все это писал выше? Перечитай еще раз, внимательно, и не только последнюю фразу.
Давайте-ка я буду вас цитировать:
"Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет."
Причем тут Джобс, не понимаю, но прослеживаю следующую цепочку в разработке флагманских API MS.
1) начиная с 94 года активно пропагандировалась идея COM. API развивалась начиная с OLE до COM+ (вкл. DCOM, MTS и пр.), это была не просто концепция, а целый набор сервисов в этой парадигме. Напр. поглядите на шикарный набор статей rsdn по COM
2) потом начиная с 99 MS следуя тренду, разработала свою vm-среду like java. разработку vb6 (основной "клиент" com) свернули, и com продолжали тихо обновлять (но как-то вяло). Для непосвященных парни на конференциях вещали про
"ужасный" COM dll hell, "небезопасный" DCOM и "тяжелый и ненадежный" COM+/MTS и всех уверяли, что в .Net все будет круто
3) в 2006 году они поняли, что .net недостаточно крут. прикрутили доп. каркасы (по большей части бесполезные или вредные), допилили c# до состояния linq (ну правильно, мы же хотим с утреца запустить свою программу так чтобы она загружалась до обеда)
3) 2012 год. круто не стало. На сцене WinRT — который в первую очередь снова пытается воплотить идею COM (парни зачем ?).
И мне как девелоперу все равно, кто там внутри MS за что борется. Синовский это будет или наш Маловолосатый плясун. Я наверное, как и миллионы др. разработчиков хочу увидеть простой эффективный framework для разработки под win64 (native + vm based). А если не умеют сами делать, пусть тупо копируют (напр. с linux), у них это очень хорошо получается.
Или на наличие WinRT в Windows RT? Так тут совсем просто — метро в Windows RT есть, очевидно, а без WinRT метро в принципе не бывает.
__>И мне как девелоперу все равно
Ты если обсуждаешь политические вопросы, то либо ты как девелопер вообще в них не лезешь, либо все таки ты не как девелопер к ним подходишь.
__>кто там внутри MS за что борется. Синовский это будет или наш Маловолосатый плясун. Я наверное, как и миллионы др. разработчиков хочу увидеть простой эффективный framework для разработки под win64 (native + vm based)
У каждого свое понимание такого фреймворка. Лично для меня такой фреймворк есть и никуда в восьмерке не девается. Называется .NET.
__> А если не умеют сами делать, пусть тупо копируют (напр. с linux), у них это очень хорошо получается.
В линуксе еще хуже получается — куча ОО ABI и все какие то кособокие и недолгоживущие. Я бы еще понял, если бы ты Java в пример привел.
Здравствуйте, vdimas, Вы писали:
V>Ес-но, в первых версиях так и будет.
Про .net тоже сначала говорили, что это лишь "пока" нашлепка на Win32, а потом будет прямая работа с ядром и .net гордо станет в один ряд с "нативными" подсистемами окружения — Win32 и POSIX. Однако воз и ныне там. Готов поставить, ну... тыщ пять рублей, что через 5 лет RT так и будет оберткой на старым добрым WinApi.
Здравствуйте, мыщъх, Вы писали:
М>для гугла это похоже что-то вроде хобби (вы можете написать свой гаджет, загрузить на гугл и его увидят и установят миллионы, пусть он будет стоить $0.99, у вас уже набирается миллион спокойно).
А есть в сети что-нть типа GreaseMonkey, чтоб работала как прокси?
Потому что на всякие убогие браузеры типа Safari никакие рулезы типа GreaseMonkey не поставить
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, мыщъх, Вы писали:
J>А есть в сети что-нть типа GreaseMonkey, чтоб работала как прокси? J>Потому что на всякие убогие браузеры типа Safari никакие рулезы типа GreaseMonkey не поставить
GreaseMonkey это ICAP сервер, который работает с ICAP-proxy, в качестве которого можно использовать сквида или поискать что-то более легковесное. сквид и icap нормально работают на лаптопе. из вкусностей -- кнопка "сохранить" видео в ютубе работает из коробки. и работает со всеми браузерами, включая сафари.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, мыщъх, Вы писали:
J>>А есть в сети что-нть типа GreaseMonkey, чтоб работала как прокси? J>>Потому что на всякие убогие браузеры типа Safari никакие рулезы типа GreaseMonkey не поставить М>GreaseMonkey это ICAP сервер, который работает с ICAP-proxy, в качестве которого можно использовать сквида или поискать что-то более легковесное. сквид и icap нормально работают на лаптопе. из вкусностей -- кнопка "сохранить" видео в ютубе работает из коробки. и работает со всеми браузерами, включая сафари.
Ну это понятно, что можно поднять свое полноценное решение, просто я думал, может, уже в инете что-то на эту тему есть работающее.
Потому что вот у меня чудо-айфон, который вообще нифига не умеет, и ессно, ни о каком сквиде на нем речи не идет,а поднимать дополнительно сервак где-то на стороне тоже кажется оверкиллом на первый взгляд.
J>Потому что вот у меня чудо-айфон, который вообще нифига не умеет,
в японии разве не 3g? если 3g то там нет прокси. прокси только для wifi. или я что-то не понимаю.
а что нужно-то? часть приложений для айфона устанавливается на стороне провайдера (в штатах это AT&T и верайзон), не знаю кто у вас провайдер в японии. приложения можно писать самостоятельно. в случае с айфоном требуется аппрув от яблока. ведроид ничего такого не требует. кстати, тут забавная ситуация. вот я от не фиг делать написал еще одно приложение для просмотра погоды. на стороне провайдера скачиваются карты со спутника в высоком разрешении, из них вырезается мой город и на телефон по 3g посылается анимация только того, что мне нужно. получается, что провайдер реально качает намного больше мегабайт, чем передает мне по 3g. причем _намного_ больше. погодные сайты (ну вы их знаете) не позволяют вырезать произвольные куски из карты. они тупо показывают то, что видит радар. и там можно задавать только радиус от радара, а не от произвольной точки пространства. качаешь с разных радаров и склеиваешь. очень простая программная операция. и качается из тырнета до AT&T по каналам самой AT&T, которые смотрят в интернет. а на телефон мне приходит уже обработанная моим софтом анамация. с точки зрения AT&T это обычно приложение для телефона, которое я взял и установил. у меня блакберри и оно аппрува не требует. ставь что хочешь. хотя, конечно, выдает жуткие предупреждения при установке самописных приложений, типа "вы точно доверяете этой программе?".
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>а что нужно-то?
нужен сервис типа mygreasemonkey.com, на который бы я логинился, закидывал нужные скрипты и после этого на яблофоне в адресной строчке писал бы просто
mygreasemonkey.com/?url=www.rsdn.ru и она отдавала бы мне контект, перемочаленный моими скриптами. Ну и чтоб линки переписывались, ессно.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, мыщъх, Вы писали:
М>>а что нужно-то? J>нужен сервис типа mygreasemonkey.com, на который бы я логинился, закидывал нужные скрипты и после этого на яблофоне в адресной строчке писал бы просто J>mygreasemonkey.com/?url=www.rsdn.ru и она отдавала бы мне контект, перемочаленный моими скриптами. Ну и чтоб линки переписывались, ессно.
такое просто. вот чтобы она перехватывала прямой запрос rsdn.ru и перенаправляла его на другой сервис -- я такое только на wifi могу сделать средствами телефона. 3g игнорирует настройки прокси. но если вы указываете mygreasemonkey.com/?url=www.rsdn.ru, то по идее проблем никаких не должно быть.
вроде бы готовые есть утилиты... не знаю как для айфона для блакберри точно есть и они ищутся по ключевым словам gateway + icap + script. правда, за это приходится чуть-чуть больше платить, т.к. в этом случае телефон говорит с энтерпрайз-сервером блак-берри, на котором у вас акк и на котором что-то вроде продвинутого гибрида фаера с DLP системой, которая позволяет фильтровать контент скриптами, написанными на любом скриптовом языке (руби, питон, js, java...), аккаунтом можно управлять прямо с телефона, по крайней мере в теории можно написать скрипт и отправить его емайлом. хотя, на моем блак-бери "торч" экран хоть и большой, но все же не настолько большой для комфортного написания скриптов.
но сам процесс фильтрации поддерживается точно. насколько я в курсе такое есть и для айфона. во всяком случае люди, с которыми я работаю, пишут слой абстракции, который унифицирует блак-берри, ведроид и айфон в корпоративной среде. в сша разница между обычным и энерпрайз акком что-то меньше $50. в энтерпрайзе сто процентно есть возможность фильтрации контента по желанию. поддержка вообще афуенная. я вот создал акк для одного юзера (меня). и мне неожиданно звонят и говорят, что у них идут работы и что мой акк может некоторое время не работать. "сколько?" спрашиваю я. они -- "в худшем случае 5 минут, между 2 PM и 2:30 PM, так что будьте на чеку". фигасе думаю я. позвонили и предупредили. связь, кстати, точно пропала. на минуту. или около того. так что оно стоит $50. а на свой акк я могу что угодно ставить.
так что пинайте провайдера. за доплату по идее должны предоставить возможность установить на вашем акке на стороне прова ваши собственные скрипты для фильтрации трафика, т.к. сама система фильтрации у провайдера должна быть, а вот скрипты и полиси на нее загружают энтерпрайзные владельцы. энтерпрайзный акк ничего не стоит. зато дает возможность загрузки своих полисей. полезно, кстати, для удаления некоторые приложений. я вот с дуру установил приложение для работы с linkedin (зачем?! я же все равно туда раз в год захожу. ну идиот, я. идитот). а оно не только не удаляется, но и висит в фоне и никак из фона не выгружается даже когда делает log out. а через управление полисями удалилось как миленькое. ну и там синхронизация адресной книги и контактов намного более продвинутая по типу системы контроля версий. в обычном (не энтерпрайз акке) при синхронизации удаляются удаленные данные. на энерпрайзе всегда есть возможность просмотреть историю изменить и выборочно смержить что-то. ну вот типа подруга удалила у меня на телефоне адрес другой моей подруге. я не заметил это и синхронизовал адресную книгу с AT&T. на не энтерпрайз AT&T удаляет адрес и на своей стороне и все. и где теперь его искать? на энтерпрайзе -- хрен. в момент удаляения чего-то с телефона он сначала идет в сеть, говорит, что собирается удалить такую-то запись, если нет возражений, то удаляет. а если сеть недоступна, то телефон вообще ничего не позволит сделать, даже если его грохнуть об асфальт. удобно же и всего за +$50/mo.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, 0x7be, Вы писали:
V>>Ес-но, в первых версиях так и будет. 0>Про .net тоже сначала говорили, что это лишь "пока" нашлепка на Win32, а потом будет прямая работа с ядром и .net гордо станет в один ряд с "нативными" подсистемами окружения — Win32 и POSIX. Однако воз и ныне там. Готов поставить, ну... тыщ пять рублей, что через 5 лет RT так и будет оберткой на старым добрым WinApi.
Через 5 может и будет, ведь он еще даже не вышел (или только вышел, не слежу). Но можешь и проиграть, бо, в отличие от дотнета, у которого всё коренным образом иначе устроено и работает, здесь будет смена одной нейтивной технологии на другую. Без каких-либо серьезных изменений. Внутри там и так уже сплошной COM, поверь на слово — я давно уже ковырял эти сборки с новыми темами или контролами от Висты. Им оставалось допилить свои наработки до уровня, когда не стыдно будет отдать в публичное АПИ... и таки отдать.
Ну и пример с OLEDB дровами я уде приводил: поначалу они шли как обертки на существующими ODBC-дровами, а уже через 5 лет стало ровно наоборот, ODBC дрова шли как обертки над OLEDB. Так удобнее.
и всего за +$50/mo.
