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

Т>>Кто его [C] под виндой использует то? Он убог чуть менее чем полностью
O>Дрова под виндой пишутся на C. В подавляющем, если не сказать абсолютном, большинстве.
Полностью неправильно.
Следует читать так: Кто его [fopen] под виндой использует то? Он убог чуть менее чем полностью

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

Т>Я про fopen
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. грохнул их в импорте -- на основной функционал это никак не сказалось.

Здравствуйте, 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

Автор: fddima
Дата: 25.04.12

.
Хотя мне лично COM в таком виде каком он есть — люто не нравится. Недостаток тулзов, слабая контроллируемость.

PS: У меня есть сервер один, в нём регулярно in-proc com сервер отваливается — второй год не могу найти причину. Я не эксперт в COM — но и не полный дурак. Проблема решена в общем-то, путём вообще замены сервиса, т.к. наличие COM сервера там вообще не нужно, прикладной код сервера написан в лучших традициях магии указателей, разумеется это неясно как работает, ещё и сбоит, и полное отсутсвие вменяемых абстракций и вдобавок как выяснилось в ходе переписывания этого сервисы "с нуля" — игнорирования некоторых принципов обмена. В обшем — COM сам по себе и не причём, эмоции...