Win32 API замораживается на уровен ХаРэ. На анменеджед-С++ теперь будут писаться низкоуровневые АПИ. Все новые высокоуровневые АПИ: Авалон (графическая библиотека), Индиго (комуникации), ВинФС (интелектуальная файлова система) будут исключительно в менеджед-виде. Для Авалона возможно удастся выковырять низкоуровневые либы (декомпиляторми), а вот Индиго и ВинФС максимум через обертки будут доступны.
Хех, это как раз очень ясный пример того, о чём я говорил в соседней темке. MS пытались продавливать подобную политику практически все 2000-ые и только пару лет назад они поняли ошибочность этого подхода. Но это было уже поздно, т.к. слишком много нативных разработчиков разбежалось с их инструментов на кроссплатформенные и возвращаться сейчас уже нет никакого желание. Не смотря на то, что сейчас работа для нативного кода в MS стала очень интенсивной (включая появление новейших разработок, не имеющих аналогов в .net).
M>Win32 API замораживается на уровен ХаРэ. На анменеджед-С++ теперь будут писаться низкоуровневые АПИ. Все новые высокоуровневые АПИ: Авалон (графическая библиотека), Индиго (комуникации), ВинФС (интелектуальная файлова система) будут исключительно в менеджед-виде. Для Авалона возможно удастся выковырять низкоуровневые либы (декомпиляторми), а вот Индиго и ВинФС максимум через обертки будут доступны.
M>Исполнилось ли предсказание?
Avalon стал WPF
Indigo — WCF
WinFS сдох, его часть — Object Spaces переродилась в EF, но и её выпиливают.
Учитывая что Common Controls в винде так и остались на уровне 2003 года, а сокеты и WinINET не менялись практически с 98 винды, то отчасти правда.
Другое дело, что ни WPF, ни WCF не заменили нативные технологии, то отчасти нет.
Проблема таких предсказаний в том, что они не учитывают что потребности за десять лет изменятся. Это примерно как "640к памяти хватит для всех".
В 2003 году никто не думал, что победит веб и js. Идея rich desktop client была самой сильной на тот момент. Но уже к релизу WPF и WCF в 2006 году стало ясно, что громадных перспектив у этих подходов нет.
ЗЫ. WPF кстати включили таки в Windows 8, но переписав на COM. Немалую роль в переписывании сыграл Синофски, который люто ненавидел managed-код.
M>Win32 API замораживается на уровен ХаРэ. На анменеджед-С++ теперь будут писаться низкоуровневые АПИ. Все новые высокоуровневые АПИ: Авалон (графическая библиотека), Индиго (комуникации), ВинФС (интелектуальная файлова система) будут исключительно в менеджед-виде. Для Авалона возможно удастся выковырять низкоуровневые либы (декомпиляторми), а вот Индиго и ВинФС максимум через обертки будут доступны.
M>Исполнилось ли предсказание?
Ну так не только VladD2 в те времена делал предсказания. Вот мое (2005 год)
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня большие сомнения в том, что .net, позиционирующаяся как некоторая революционная технология, таковой окажется.
лучше jvm на llvm, а то microsoft уже вовсю новую ось лепит
Здравствуйте, gandjustas, Вы писали:
G>Учитывая что Common Controls в винде так и остались на уровне 2003 года, а сокеты и WinINET не менялись практически с 98 винды, то отчасти правда. G>Другое дело, что ни WPF, ни WCF не заменили нативные технологии, то отчасти нет.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Учитывая что Common Controls в винде так и остались на уровне 2003 года, а сокеты и WinINET не менялись практически с 98 винды, то отчасти правда. G>>Другое дело, что ни WPF, ни WCF не заменили нативные технологии, то отчасти нет.
A>я не скажу за UI штуки, но сетевое API серьезно расширялось, почитать можно тут — http://msdn.microsoft.com/en-us/library/windows/desktop/ms740642%28v=vs.85%29.aspx
Чето я там не увидел серьезного расширения. Как использовались функции socket\connect\listen\send\receive еще с 95 винды, так по сути и остались. Появились функции для поддержки новых фич ОСей, но по сути новое появилось только в W8. И все равно вся эта ручная возня с сокетами бесконечно далека от того, что может предложить WCF.
Что сделали, но не задокументировали (но я както по-необходимости расковырял):
— Window bands, и набор следующих API, торчащих из user32:
HWND WINAPI CreateWindowInBand(DWORD dwExStyle, LPCWSTR lpClassName, LPCWSTR lpWindowName, DWORD dwStyle, int x, int y, int nWidth, int nHeight, HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam, DWORD dwBand);
BOOL WINAPI SetWindowBand(HWND hWnd, HWND hwndInsertAfter, DWORD dwBand);
BOOL WINAPI GetWindowBand(HWND hWnd, PDWORD pdwBand);
С помощью них сама винда, и все (сильно) желающие могут впендюривать свои окошки туда, где обычно показываются Win'RT приложения.
— WNF, вероятно расшифровывающийся как Windows Notification Framework. Используется для рассылки "сообщений" подписчикам. Сообщение — это бинарные данные. Имеют своеобразное "имя", которое по сути — 64хбитный идентификатор, который помимо иденцификации еще и указывает scope и security rules сообщений и скорее всего микрософтовский тим генерирует из макросом навроде CTL_CODE, используемого для генерации IOCTL кодов для драйверов. Вот такие вот API юзаются с ним (недоисследовал, но может комуто пригодится):
Здравствуйте, ononim, Вы писали:
O>Ну например после ХР появились: O>- Desktop Window Manager, и API для него O>- Транзакционные операции с файлами и реестром, и API для них. Например раз, два. O>- XPS принтинг, и API для него O>- Аудиоподсистема была переделана, и появился Windows Core Audio API O>- ntdll рантайм обзавелся своим внутренним развитым thread pool, ну и API для него не поленились вытащить наверх
Вот WinRT — это действительно что-то типа революции. Только вот существенно запоздавшей — далеко не факт, что сейчас взлетит. Тем более, что старый api на десктопе никто не запрещает, а metro пока и не особо актуально.
O>Что сделали, но не задокументировали (но я както по-необходимости расковырял): O>- Window bands, и набор следующих API, торчащих из user32: O>
O>HWND WINAPI CreateWindowInBand(DWORD dwExStyle, LPCWSTR lpClassName, LPCWSTR lpWindowName, DWORD dwStyle, int x, int y, int nWidth, int nHeight, HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam, DWORD dwBand);
O>BOOL WINAPI SetWindowBand(HWND hWnd, HWND hwndInsertAfter, DWORD dwBand);
O>BOOL WINAPI GetWindowBand(HWND hWnd, PDWORD pdwBand);
O>
O>С помощью них сама винда, и все (сильно) желающие могут впендюривать свои окошки туда, где обычно показываются Win'RT приложения.
О, очень интересно. Не в смысле нашей дискуссии (это тоже явно не какая-то революция), а просто лично для меня. Это что, позволяет нам из обычного приложения влезть в метро интерфейс или что?
_>Ну как бы это всё прогресс, но даже близко не имеет отношения к каким-то революционным изменениям. _>Вот WinRT — это действительно что-то типа революции. Только вот существенно запоздавшей — далеко не факт, что сейчас взлетит. Тем более, что старый api на десктопе никто не запрещает, а metro пока и не особо актуально.
Ну по моему революция — далеко не всегда то что что видно невооруженным глазом.. Ну да ладно.
O>>С помощью них сама винда, и все (сильно) желающие могут впендюривать свои окошки туда, где обычно показываются Win'RT приложения. _>О, очень интересно. Не в смысле нашей дискуссии (это тоже явно не какая-то революция), а просто лично для меня. Это что, позволяет нам из обычного приложения влезть в метро интерфейс или что?
Да. С учетом некоторых ээ.. хитростей... А именно — не любой процесс может это сделать. Могут похоже лишь подписанные микрософтом, но и то — не все. explorer.exe — может. Потому если хочется влезть в метроинтерфейс, то можно заинжектить в экплорер свою длл, которая должна выполнить примерно такой вот код в нем:
typedef HWND (WINAPI *CreateWindowInBandProc)(DWORD dwExStyle, LPCWSTR lpClassName,
LPCWSTR lpWindowName, DWORD dwStyle, int X, int Y, int nWidth, int nHeight,
HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam, DWORD dwBand);
CreateWindowInBandProc pCreateWindowInBand = (CreateWindowInBandProc)
::GetProcAddress(::GetModuleHandle(TEXT("user32.dll")), "CreateWindowInBand");
if (!pCreateWindowInBand)
{
::MessageBox(0, TEXT("CreateWindowInBand not found"), TEXT("Hello"), MB_ICONWARNING);
return;
}
DWORD cy = ::GetSystemMetrics(SM_CYMAXIMIZED), y = 10, x = 10;
TCHAR txt[0x100] = {0};
for (DWORD i = 0; i<=0x20; ++i)
{
wsprintf(txt, TEXT("Band %u\n"), i);
HWND w = pCreateWindowInBand(WS_EX_TOPMOST, TEXT("Edit"), txt,
WS_VISIBLE|WS_OVERLAPPEDWINDOW, x, y, 200, 40, 0, 0, ::GetModuleHandle(0), 0, i);
if (!w)
{
wsprintf(txt, TEXT("Failed %u\n"), i);
pCreateWindowInBand(WS_EX_TOPMOST, TEXT("Edit"), txt,
WS_VISIBLE|WS_OVERLAPPEDWINDOW, x, y, 200, 40, 0, 0, ::GetModuleHandle(0), 0, 0);
}
if (( (y+= 40 ) +40)>=cy)
{
y = 10;
x+= 200;
}
}
::MessageBox(0, TEXT("In loop.."), TEXT("Hello"), MB_ICONWARNING);
}
Это работало полтора года назад на свежезарелизенной восьмерке — создавались окошки везде где можно А сейчас могли добавить дополнительные ректальные оградки. Но по факту — все это ваше RT — не более чем надстройка над старым добрым вендогуем
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Ну по моему революция — далеко не всегда то что что видно невооруженным глазом.. Ну да ладно.
Я к тому, что хотя winrt — это далеко не только metro ui, но ещё и много другого интересного, переписывать с помощью него приложения всё равно никакого смысла не видно, т.к. собственно сами metro приложения не особо интересны (во всяком случае такой ценой, а не просто перекомпиляцией).
O>Да. С учетом некоторых ээ.. хитростей... А именно — не любой процесс может это сделать. Могут похоже лишь подписанные микрософтом, но и то — не все. explorer.exe — может. Потому если хочется влезть в метроинтерфейс, то можно заинжектить в экплорер свою длл, которая должна выполнить примерно такой вот код в нем: O>... O>Это работало полтора года назад на свежезарелизенной восьмерке — создавались окошки везде где можно А сейчас могли добавить дополнительные ректальные оградки.
Оуу, как всё плохо. Такое вряд ли получится использоваться в каких-то реальных продуктах. Хотя на всякий случая буду иметь в виду этот хак. Спасибо за информацию.
O>Но по факту — все это ваше RT — не более чем надстройка над старым добрым вендогуем
Ну да, точнее не над gui, а над вообще классическим win api. Это известный факт, но вроде как в будущем собирались начинать делать реализации и в самом winrt. Правда пока не понятно взлетит оно как будущий основной win api или нет — сейчас оно актуально только при очень большом желание влезть в их сомнительный магазинчик приложений... )
Здравствуйте, alex_public, Вы писали:
_>Вот WinRT — это действительно что-то типа революции. Только вот существенно запоздавшей — далеко не факт, что сейчас взлетит. Тем более, что старый api на десктопе никто не запрещает, а metro пока и не особо актуально.
Проблема WinRT в магазине MS. До MS ну ни как не доходит что нельзя сужать свободу пользователей.
Если один раз разрешили свободно писать/запускать/распространять ПО, то теперь это не запретить.
Как следствие FOSS сообщество игнорирует WinRT. Нет FOSS — нет бесплатных(без рекламы) программ и библиотек.
Нет бесплатных библиотек, не на чем писать коммерческие программы. Не на чем писать программы под WinRT , бизнес пишет их под WinAPI.
Не помогли MS даже все возможные заманухи с бесплатной студией, грошовой регистрацией в магазине, и возможностью писать программ сразу для десктопа/планшета и в некотором смысле для телефона.
Спасти ситуацию может разрешение устанавливать программы в обход магазина, ну и как следствие разработка без получения всяких сертификатов MS. Только MS на это не пойдёт, не дают покоя лавры Apple и желание получать деньги с каждой запущенной программы под WinRT.
Мой прогноз на будущее, если не будет свободы запуска программ, то WinRT не взлетит и будет похоронен MS после выхода Windows 9 или возможно чуть раньше.
Здравствуйте, ononim, Вы писали:
O>- Транзакционные операции с файлами и реестром, и API для них. Например раз, два.
Для новой файловой системы уже открутили обратно.
O>- XPS принтинг, и API для него
[StartXpsPrintJob is not supported and may be altered or unavailable in the future. ]
O>- Аудиоподсистема была переделана, и появился Windows Core Audio API
С потерей возможности использовать продвинутые аппаратные микшеры.
O>- ntdll рантайм обзавелся своим внутренним развитым thread pool, ну и API для него не поленились вытащить наверх
А смысл?
O>>- Транзакционные операции с файлами и реестром, и API для них. Например раз, два. C>Для новой файловой системы уже открутили обратно.
Судя по некоторым отзывам ReFS — это фэйловая, а не файловая система...
Кстати для нее тоже придумали новые "АПИ": http://hex.pp.ua/refs-novoe-api.php
O>>- XPS принтинг, и API для него C>[StartXpsPrintJob is not supported and may be altered or unavailable in the future. ] O>>- Аудиоподсистема была переделана, и появился Windows Core Audio API C>С потерей возможности использовать продвинутые аппаратные микшеры. O>>- ntdll рантайм обзавелся своим внутренним развитым thread pool, ну и API для него не поленились вытащить наверх C>А смысл?
А я не спорю что в микрософте творицца бардак и индократия (главный придумыватель ReFS). Просили новые апи — вот вам новые апи. Хтож виноват что это самое вендоапи бурлит и самовыпиливается периодически...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>- Транзакционные операции с файлами и реестром, и API для них. Например раз, два. C>>Для новой файловой системы уже открутили обратно. O>Судя по некоторым отзывам ReFS — это фэйловая, а не файловая система...
Это в MS уже давно традиция. NTFS была крутой идеей в 92-м году, когда её задумали, но с тех пор с FS связаны только фейлы.
Новая файловая система уже отчаянно нужна для конкуренции с ZFS и btrfs, но похоже, что ничего не дождёмся.
O>Кстати для нее тоже придумали новые "АПИ": http://hex.pp.ua/refs-novoe-api.php
Ну это как раз нормально, специальный API для доступа к специфичным функциям FS.
O>>>- ntdll рантайм обзавелся своим внутренним развитым thread pool, ну и API для него не поленились вытащить наверх C>>А смысл? O>А я не спорю что в микрософте творицца бардак и индократия (главный придумыватель ReFS). Просили новые апи — вот вам новые апи. Хтож виноват что это самое вендоапи бурлит и самовыпиливается периодически...
А Win32 жил, живёт и будет жить — прямо как Ленин.
Здравствуйте, fdn721, Вы писали:
F>Проблема WinRT в магазине MS. До MS ну ни как не доходит что нельзя сужать свободу пользователей. F>Если один раз разрешили свободно писать/запускать/распространять ПО, то теперь это не запретить.
F>Как следствие FOSS сообщество игнорирует WinRT. Нет FOSS — нет бесплатных(без рекламы) программ и библиотек. F>Нет бесплатных библиотек, не на чем писать коммерческие программы. Не на чем писать программы под WinRT , бизнес пишет их под WinAPI.
F>Не помогли MS даже все возможные заманухи с бесплатной студией, грошовой регистрацией в магазине, и возможностью писать программ сразу для десктопа/планшета и в некотором смысле для телефона.
F>Спасти ситуацию может разрешение устанавливать программы в обход магазина, ну и как следствие разработка без получения всяких сертификатов MS. Только MS на это не пойдёт, не дают покоя лавры Apple и желание получать деньги с каждой запущенной программы под WinRT.
F>Мой прогноз на будущее, если не будет свободы запуска программ, то WinRT не взлетит и будет похоронен MS после выхода Windows 9 или возможно чуть раньше.
Согласен со всем. Но думаю дело не только в анальном рабстве, а ещё и очень важно соотношение затрат ресурсов к потенциальной прибыли. И тут у metro приложений всё очень плохо. По сути их надо переписывать заново (не знаю пока ни одной кроссплатформенной библиотеки, которая бы уже расширилась на winrt), причём больше нигде этот код не пригодится. И при этом сам рынок metro приложений не сказать чтобы очень интересный в данный момент. Т.е. если бы был хотя бы только один из этих двух факторов (например рынок маленький как сейчас, но приложения легко портируются или же наоборот, приложения надо полностью переписывать, но зато открывается огромный и не насыщенный рынок), то наверняка взлетело бы. А вот в таком сочетание очень сомнительно...
Здравствуйте, fdn721, Вы писали:
F>Как следствие FOSS сообщество игнорирует WinRT. Нет FOSS — нет бесплатных(без рекламы) программ и библиотек. F>Нет бесплатных библиотек, не на чем писать коммерческие программы. Не на чем писать программы под WinRT , бизнес пишет их под WinAPI.
Притянуто за уши. Никому просто не впёрся метрошный интерфейс. На десктопе — неудобно, на планшетах — слишком мал виндопланшетный рынок.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Имелись в виду конечно же универсальные фреймворки, которые позволяют свести портирование к простой перекомпиляции. А не какие-то отдельные специфические библиотеки. Да, Qt естественно подходит, просто я слышал, что там всё печально с winrt. Может мои данные устаревшие уже и там всё отладили.
Здравствуйте, fdn721, Вы писали:
_>>Вот WinRT — это действительно что-то типа революции. Только вот существенно запоздавшей — далеко не факт, что сейчас взлетит. Тем более, что старый api на десктопе никто не запрещает, а metro пока и не особо актуально.
F>Проблема WinRT в магазине MS.
Сама идея фильтрации приложений, контроля над качеством, противодействию малварями — не плохая. Пусть бы сделали качественный каталог проверенных фирм и этого было бы достаточно. Но зачем ограничивать разработчиков в рамках одного монопольного стора, оставляя за собой эксклюзивные права запретов, принудительно указывая что можно, а что нельзя запускать в системе?
F>До MS ну ни как не доходит что нельзя сужать свободу пользователей.
Ладно там наивные юзвери — они слабо разбираются, и поэтому со стороны кажется, что они даже рады анальному рабству быть заключёнными эппла, гугла и майкрософта. Страшнее то, что MS — методично, год за годом сужает свободу программистам. Началось это ещё с драйверов. А с кодерами шутки плохи. Их так просто не обведёшь вокруг пальца, как рядовых пользователей. Во времена Билла Гейтса — это хорошо понимали, поэтому раньше создавалась соответствующая дружественная атмосфера для разработчиков, их мнение хотя бы учитывалось. Сейчас MS другая. Решили пойти по пути Apple. Общеизвестно, что теоретически корпорации могут мутировать с целью адаптации. Но не все подобные мутации идут на пользу в конечном итоге.
F>Если один раз разрешили свободно писать/запускать/распространять ПО, то теперь это не запретить.
Вообще-то, как руководство решит, так и будет. Это же их интеллектуальная собственность. После фейла с Нокией — стало очевидно, что решения руководителей бывают не всегда разумны и не всегда оптимальны (даже с точки зрения максимализации прибыли).
F>Как следствие FOSS сообщество игнорирует WinRT. Нет FOSS — нет бесплатных(без рекламы) программ и библиотек.
Потому что, абсурд ситуации: чтобы написать бесплатную программу на WinRT — надо заплатить.
F>Нет бесплатных библиотек, не на чем писать коммерческие программы. Не на чем писать программы под WinRT , бизнес пишет их под WinAPI.
А кому хочется связываться с непредсказуемыми выбрыками, капризами монополиста, который вполне может запретить использовать ваш софт? Многим бизнесам не нужны лишние деструктивные посредники. Поэтому независимый Win32 API — на порядки выгоднее.
F>Не помогли MS даже все возможные заманухи с бесплатной студией, грошовой регистрацией в магазине, и возможностью писать программ сразу для десктопа/планшета и в некотором смысле для телефона.
Эти заманухи рассчитаны на идиотов.
F>Спасти ситуацию может разрешение устанавливать программы в обход магазина, ну и как следствие разработка без получения всяких сертификатов MS. Только MS на это не пойдёт, не дают покоя лавры Apple и желание получать деньги с каждой запущенной программы под WinRT.
Время покажет. Пока MS чешется и поплёвывает на разработчиков, Linux Android и ChromeOS завоёвывают рынки. На подходе полностью свободный Tizen.
F>Мой прогноз на будущее, если не будет свободы запуска программ, то WinRT не взлетит и будет похоронен MS после выхода Windows 9 или возможно чуть раньше.
Они держатся только на маркетинге. Если произойдёт выпиливание Win32 в пользу WinRT, массовый переход на Linux неизбежен. Например, в Steam — этот коварный вариант уже заранее предусмотрели, и на всякий случай подстраховались.
Здравствуйте, ononim, Вы писали:
_>>если хочется влезть в метроинтерфейс, то можно заинжектить в экплорер свою длл, которая должна выполнить примерно такой вот код в нем: O>
O>typedef HWND (WINAPI *CreateWindowInBandProc)(DWORD dwExStyle, LPCWSTR lpClassName,
O> LPCWSTR lpWindowName, DWORD dwStyle, int X, int Y, int nWidth, int nHeight,
O> HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam, DWORD dwBand);
O> CreateWindowInBandProc pCreateWindowInBand = (CreateWindowInBandProc)
O> ::GetProcAddress(::GetModuleHandle(TEXT("user32.dll")), "CreateWindowInBand");
O> if (!pCreateWindowInBand)
O> {
O> ::MessageBox(0, TEXT("CreateWindowInBand not found"), TEXT("Hello"), MB_ICONWARNING);
O> return;
O> }
O> DWORD cy = ::GetSystemMetrics(SM_CYMAXIMIZED), y = 10, x = 10;
O> TCHAR txt[0x100] = {0};
O> for (DWORD i = 0; i<=0x20; ++i)
O> {
O> wsprintf(txt, TEXT("Band %u\n"), i);
O> HWND w = pCreateWindowInBand(WS_EX_TOPMOST, TEXT("Edit"), txt,
O> WS_VISIBLE|WS_OVERLAPPEDWINDOW, x, y, 200, 40, 0, 0, ::GetModuleHandle(0), 0, i);
O> if (!w)
O> {
O> wsprintf(txt, TEXT("Failed %u\n"), i);
O> pCreateWindowInBand(WS_EX_TOPMOST, TEXT("Edit"), txt,
O> WS_VISIBLE|WS_OVERLAPPEDWINDOW, x, y, 200, 40, 0, 0, ::GetModuleHandle(0), 0, 0);
O> }
O> if (( (y+= 40 ) +40)>=cy)
O> {
O> y = 10;
O> x+= 200;
O> }
O> }
O> ::MessageBox(0, TEXT("In loop.."), TEXT("Hello"), MB_ICONWARNING);
O>}
O>
А приходилось ли вам вызывать SetWindowBand?
Вроде как ее можно вызвать без инжекта и хука, перед этим вызвав недокументированную NtUserEnableIAMAccess.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня большие сомнения в том, что .net, позиционирующаяся как некоторая революционная технология, таковой окажется.
Поддерживаю. несмотря на удобство и простоту использования дотнет не стал с годами быстрее как минимум.
Баловался вчера с различными ЯП, в том числе dotnet core 5 F#, просто создание класса Person {Name, Age} и вывод на печать 100 раз.
d(ldc2), rust, gcc, f#(core 5), common lisp (sbcl).
вообщем, скорость отработки бинарника rust === c. это удивляет и радует.
cl все равно быстрее core(причем комплил в релиз под linux-x64 self-container).
d всего в 4 раза медленнее релизного rust (правда я не оптимизировал его сборку).
и кора ну прям расстраивает(старый FW стартовал побыстрее как-то).
Ну конечно у каждго ЯП свои приемущества. вот слегка коснулся пару лет назад с си++ и удивился насколько проще в нем сетевое программирование (по сравнению с сишарпом).
никаких тебе сериализаций. записал память в сокет и на другом конце просто связал память со ссылкой. так кажется. сам яп конечно ужасный. сколько там правил это просто невероятно.
Ну и лисп поражает. ведь это динамический ЯП, а стартует быстрее ВМ разработанной в могущественной МС.
результаты
КОРЭ(5 linux-x64 F#):
real 0m0,167s
user 0m0,133s
sys 0m0,030s
лисп(exe):
real 0m0,008s
user 0m0,008s
sys 0m0,000s
ДИ:
real 0m0,004s
user 0m0,004s
sys 0m0,000s
СИ:
real 0m0,001s
user 0m0,001s
sys 0m0,000s
RUST:
real 0m0,001s
user 0m0,000s
sys 0m0,001s
Можно сделать вывод чтобы писать безопасные приложения не обязательны gc и vm.
при этом оно еще и быстрое получается.
Что такого грузит коснольная апликуха при старте остается загадкой. цифры просто ужасные.
Здравствуйте, ononim, Вы писали:
O>>>- Транзакционные операции с файлами и реестром, и API для них. Например раз, два. C>>Для новой файловой системы уже открутили обратно. O>Судя по некоторым отзывам ReFS — это фэйловая, а не файловая система...
refs — это попытка избавится от чудовищных извращений ntfs, оставив только быстрое ядро.
M>Win32 API замораживается на уровен ХаРэ. На анменеджед-С++ теперь будут писаться низкоуровневые АПИ. Все новые высокоуровневые АПИ: Авалон (графическая библиотека), Индиго (комуникации), ВинФС (интелектуальная файлова система) будут исключительно в менеджед-виде. Для Авалона возможно удастся выковырять низкоуровневые либы (декомпиляторми), а вот Индиго и ВинФС максимум через обертки будут доступны.
M>Исполнилось ли предсказание?
если managed это powershell, то они везде его пихают, хотя менеджер покаетов с зависимостями и версиями так и не придумали. мож он и не нужен в 7й версии я хз.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>У меня большие сомнения в том, что .net, позиционирующаяся как некоторая революционная технология, таковой окажется.
Ну так чё, всё ещё не видишь, как ты облажался??
.NET вполне себе революция, вернее "копия другой революции — Жабы" Другой вопрос, что в ней не было особой потребности — просто ЕЩЁ ОДИН вариант написания программ 1 раз и запуска везде.
Проблема всех революций в том, что идею выдают "самые буйные", да вот воплощают — какие-то долбо****бы. Как можно было умудриться ПСЕВДОКОД сделать windows-only???
Вот вам и революция!
А сейчас могли добавить дополнительные ректальные оградки. Но по факту — все это ваше RT — не более чем надстройка над старым добрым вендогуем 
Другой вопрос, что в ней не было особой потребности — просто ЕЩЁ ОДИН вариант написания программ 1 раз и запуска везде.
