Слушайте этот .NET SDK найденный внутри Windows не отображается в списке системных компонентов. Визуально внутри больше библиотек чем в обычном, скачиваемом с сайта Microsoft, поэтому как официально он называется понятия не имею.
Внутри также есть определенные нестыковки, например лежат части ASP.NET (в частности админка) и компилятор ASP страниц, но нет самого сервера приложений, те собрать полноценное ASP.NET приложение не получится.
Так что ".NET SDK" это скорее условное название, чтобы хоть как-то это обозначать.
Какой-либо официальной информации по этой версии нет, описания тоже. Если у вас получится раскопать больше деталей по этой штуке — дайте знать, буду благодарен.
C моей программисткой точки зрения доступ к компилятору безусловно опасней, поскольку даже без игр с API всегда можно устроить DDOS перегрузкой процессора или забить диск случайными данными, что точно также может вызвать аварийную ситуацию.
Но как бы для PowerShell есть готовые скрипты и векторы атак, создаваемые и обкатываемые именно со злонамеренными целями.
Еще можете писать против ветра, только проверять не советую.
Речь не о том что можно а что нет, речь о полной замене компилятора csc.exe (видимо вместе с дебагером) на скрипт PowerShell — вот эту мысль пытаются продвигать комментаторы.
Угу, а отлаживать этот код вы как собираетесь? С божьей помощью? Как взаимодействовать с ним после запуска?
Люди пишут дословно «полная замена компилятору» и «вызов любых функций и методов», чем вводят в заблуждение, поскольку вызывается на самом деле динамически скомпилированная программа, не имеющая никакого отношения к самому скрипту на PowerShell.
Не совсем так. Внутри этой папки есть еще с номерами версий, вот то что внутри уже SDK.
Рантайм для приложения на .NET это просто библиотека, либо поставляемая вместе с приложением либо взятая из системы.
Разделение на SDK и рантайм ни разу не формальное а очень даже реальное, можете посмотреть внутрь .cab архива обновления с обоими чтобы увидеть разницу.
Запускабельные бинарники вроде csc.exe точно есть только в SDK, но сами функции динамической компиляции скорее всего есть и в самом рантайме, который в виде библиотеки.
На обычной пользовательской винде из коробки стоит только рантайм или SDK тоже?
Присутствует (не установлен как компонент и не удаляем стандартными средствами) и .NET SDK и рантайм, причем нескольких версий.
Я выше по треду уже ответил что на самом деле это не PowerShell такой умный, это код на C# с динамической компиляцией внутри. Но для вас полагаю разницы нет.
Винапи доступен из штатного повершелла, без всяких компиляторов.
Вы точно программист а не сисадмин и понимаете что такое вызов процедур?
Из PowerShell доступен вызов только того что поддерживается авторами PowerShell, думать что с его помощью можно реализовать вообще любой вызов WinAPI — откровенный перебор.
Даже в этой статье с максимально упрощенным кодом большая часть логики про заполнение структур данных, их передачу и получение в ответ такой же структуры данных - как вы собрались все это делать на PowerShell ?
Покажите, повторите хотя-бы описанную в статье логику на PowerShell.
Компилятор C# (там еще компиляторы Visual Basic и JScript) есть только в .NET SDK, поэтому без него скомпилировать .exe не выйдет.
Но вот с рантаймом все сложнее: сам запуск осуществляет ОС по сигнатуре исполняемого файла, вне зависимости от того есть ли на машине установленный рантайм .NET. А вот уже дальше если рантайма нужной версии нет то произойдет ошибка.
При этом рантайм .NET это динамическая библиотека (несколько), разные версии которой обязательно присутствуют в Windows.
Статья отмечена как сложная, но рассуждения во вступлении не очень умные.
С козырей зашли, браво.
Какие такие задачи Google отличаются от обывательских, и как это проявляется в языке общего назначения?
У вас дома есть распределенный геокластер с тысячей сервисов обработки данных? Есть задачи централизованного управления и мониторинга всей этой кухни?
Соседи не жалуются? А то жужжит наверно адски.
Дальше статья обещает, что в Go работа с Win32API проще, чем в С и C++,
Лаконичнее, это когда исходного кода меньше, сам он чище и не вызывает приступов паники при просмотре.
Это биндинги к тем же самым функциям,
Есть всего один способ не использовать "биндинги к тем самым функциям" при работе с WinAPI из любого языка: устроиться в Microsoft и заняться там разработкой WinAPI.
Только в этом единственном случае вы не будете работать с клиентской стороны.
Что за чушь? Нет ничего сложного в Win32API.
Обожаю такой слог, сразу видно профессионала.
Если серьезно то WinAPI это отдельная область знаний, разбирающихся в этом разработчиков крайне мало — собственно как и в любой узкой нише.
Для иллюстрации этой сложности, в статье приведен официальный пример «Hello world» на C++ под Windows с отображением пустого окна через вызовы WinAPI функций.
Если для вас лично это просто то для большинства обычных (и тем более начинающих) разработчиков — нет.
И чего такого разработчики под Windows не знают в "обычном" C ?
Ситуация ровно обратная: обычные С-разработчики, писавшие для Linux или встариваемых систем мало чего поймут при разработке под Windows.
Для иллюстрации приведен пример с отдельной точкой входа WinMain. Опять же нет сомнений что для вас лично это прописные истины.
Ещё одно враньё статьи - это обещанная работа с Win32API «из коробки». Судя по примеру в главе "WinAPI и графический интерфейс" из коробки есть только syscall, и приходится пользоваться либами, которые спрячут преобразования типов.
Видимо не разобрались, преобразования типов как раз из коробки — обратите внимание на типы полей (их нет).
Почему вы всё время ссылаетесь на CEdit, это же класс из MFC ? В Win32API этот класс окна называется "Edit".
Ну потому что биндинги для CEdit уже были в готовом виде, реализовывать их самому для просто Edit в рамках статьи было бы слишком объемно.
Насчёт того, что он не поддерживает добавление текста - это вы плохо искали .
Ну ок, немного через одно место но возможно. Плюсую.
Но вообще спасибо за толковый разбор, хоть кто-то еще может такое на Хабре ;)
Это вы меня жизни учите чтоли? Не стоит, я уже старенький.
Слушайте этот .NET SDK найденный внутри Windows не отображается в списке системных компонентов. Визуально внутри больше библиотек чем в обычном, скачиваемом с сайта Microsoft, поэтому как официально он называется понятия не имею.
Внутри также есть определенные нестыковки, например лежат части ASP.NET (в частности админка) и компилятор ASP страниц, но нет самого сервера приложений, те собрать полноценное ASP.NET приложение не получится.
Так что ".NET SDK" это скорее условное название, чтобы хоть как-то это обозначать.
Какой-либо официальной информации по этой версии нет, описания тоже. Если у вас получится раскопать больше деталей по этой штуке — дайте знать, буду благодарен.
Нууу тут сложно однозначно сказать что страшнее.
C моей программисткой точки зрения доступ к компилятору безусловно опасней, поскольку даже без игр с API всегда можно устроить DDOS перегрузкой процессора или забить диск случайными данными, что точно также может вызвать аварийную ситуацию.
Но как бы для PowerShell есть готовые скрипты и векторы атак, создаваемые и обкатываемые именно со злонамеренными целями.
Так что однозначного ответа тут нет.
Еще можете писать против ветра, только проверять не советую.
Речь не о том что можно а что нет, речь о полной замене компилятора csc.exe (видимо вместе с дебагером) на скрипт PowerShell — вот эту мысль пытаются продвигать комментаторы.
Что для меня звучит как откровенная дичь.
Версия v4 это точно не Core, внутренних версий старше 4й внутри Windows я пока не встречал, так что видимо оно называется Net Framework.
Мне лично внутренний голос подсказывает. Так в чем вопрос?
Что и событийную обработку? И асинхронщину с многопоточностью? Неужели до работы с отладчиком так и не дошли за годы практики?
Ну там ввод-вывод, передача данных. Через внешние файлы будете реализовывать?
Я же написал уже что неграмотный, так что поделитесь откровением.
Ну так я вам и говорю: повторите это в современном окружении и напишите статью - зумеры от разработки будут в восторге, для них же это магия.
"Пусть говорят" , вам-то лично какое дело?
Угу, а отлаживать этот код вы как собираетесь? С божьей помощью? Как взаимодействовать с ним после запуска?
Люди пишут дословно «полная замена компилятору» и «вызов любых функций и методов», чем вводят в заблуждение, поскольку вызывается на самом деле динамически скомпилированная программа, не имеющая никакого отношения к самому скрипту на PowerShell.
Не совсем так. Внутри этой папки есть еще с номерами версий, вот то что внутри уже SDK.
Рантайм для приложения на .NET это просто библиотека, либо поставляемая вместе с приложением либо взятая из системы.
Разделение на SDK и рантайм ни разу не формальное а очень даже реальное, можете посмотреть внутрь .cab архива обновления с обоими чтобы увидеть разницу.
Туда столько всего понапихано что наверное скорее нет чем да.
Но вызов динамической компиляции кода на С#, забитого внутрь строкой точно не повод говорить о «поддержке работы с WinAPI», извините.
Запускабельные бинарники вроде csc.exe точно есть только в SDK, но сами функции динамической компиляции скорее всего есть и в самом рантайме, который в виде библиотеки.
Присутствует (не установлен как компонент и не удаляем стандартными средствами) и .NET SDK и рантайм, причем нескольких версий.
А пойти чуть дальше гугления не смогли?
Я выше по треду уже ответил что на самом деле это не PowerShell такой умный, это код на C# с динамической компиляцией внутри. Но для вас полагаю разницы нет.
Вот в этом и отличие между практикой и теорией:
Вы ведь не понимаете как оно работает правда? И что делает код на C# одной строкой забитый внутрь скрипта? Никаких вопросов это не вызвало?
Вы точно программист а не сисадмин и понимаете что такое вызов процедур?
Из PowerShell доступен вызов только того что поддерживается авторами PowerShell, думать что с его помощью можно реализовать вообще любой вызов WinAPI — откровенный перебор.
Даже в этой статье с максимально упрощенным кодом большая часть логики про заполнение структур данных, их передачу и получение в ответ такой же структуры данных - как вы собрались все это делать на PowerShell ?
Покажите, повторите хотя-бы описанную в статье логику на PowerShell.
Компилятор C# (там еще компиляторы Visual Basic и JScript) есть только в .NET SDK, поэтому без него скомпилировать .exe не выйдет.
Но вот с рантаймом все сложнее: сам запуск осуществляет ОС по сигнатуре исполняемого файла, вне зависимости от того есть ли на машине установленный рантайм .NET. А вот уже дальше если рантайма нужной версии нет то произойдет ошибка.
При этом рантайм .NET это динамическая библиотека (несколько), разные версии которой обязательно присутствуют в Windows.
Никто не мешает, осталось только это сделать )
Так стоп )
Пропустил сразу этот момент: вы точно понимаете разницу между линковкой и динамической загрузкой библиотеки?
Какой вообще был смысл приводить пример на Си в статье по Golang?
С козырей зашли, браво.
У вас дома есть распределенный геокластер с тысячей сервисов обработки данных? Есть задачи централизованного управления и мониторинга всей этой кухни?
Соседи не жалуются? А то жужжит наверно адски.
Лаконичнее, это когда исходного кода меньше, сам он чище и не вызывает приступов паники при просмотре.
Есть всего один способ не использовать "биндинги к тем самым функциям" при работе с WinAPI из любого языка: устроиться в Microsoft и заняться там разработкой WinAPI.
Только в этом единственном случае вы не будете работать с клиентской стороны.
Обожаю такой слог, сразу видно профессионала.
Если серьезно то WinAPI это отдельная область знаний, разбирающихся в этом разработчиков крайне мало — собственно как и в любой узкой нише.
Для иллюстрации этой сложности, в статье приведен официальный пример «Hello world» на C++ под Windows с отображением пустого окна через вызовы WinAPI функций.
Если для вас лично это просто то для большинства обычных (и тем более начинающих) разработчиков — нет.
Ситуация ровно обратная: обычные С-разработчики, писавшие для Linux или встариваемых систем мало чего поймут при разработке под Windows.
Для иллюстрации приведен пример с отдельной точкой входа WinMain. Опять же нет сомнений что для вас лично это прописные истины.
Видимо не разобрались, преобразования типов как раз из коробки — обратите внимание на типы полей (их нет).
Ну потому что биндинги для CEdit уже были в готовом виде, реализовывать их самому для просто Edit в рамках статьи было бы слишком объемно.
Ну ок, немного через одно место но возможно. Плюсую.
Но вообще спасибо за толковый разбор, хоть кто-то еще может такое на Хабре ;)
Так а управление правами происходит разве не через нее? gpedit.msc же?