Pull to refresh

Comments 22

А зачем это надо?
Статья про IDisposable была полезной. Спорной, но сама тема была полезной любому разработчику на шарпе.
Статья про боксинг — тоже, но уже меньше, ибо в идеале разработчик и не должен о таком думать.

Эта же статья мне совсем непонятна. Зачем она?
На уроке математики:
— Учитель, мне в жизни пригодится всё, что Вы рассказываете?
— Нет, математика нужна только умным детям.
Ненене, не будьте тем самым отвратительным учителем, который неспособен найти хороший пример.

Зачем нужны форки тредов? В шарпе я таких кейсов пока не встречал, запускать одинаковый код проще тасками, и от объектов, а не от клонированных хз кого.
Так я же написал:
Согласитесь, концепт интересный. Конечно же, тут можно много спорить про целесообразность таких действий, но задача этого примера — поставить жирную точку в понимании работы этой структуры данных

и еще:
Конечно же, в общем виде нам нет надобности редактировать стек в продуктовом коде: только если захочется занять свое свободное время интересной задачкой


Целей преследовалось несколько и я их, пожалуй, внесу в раздел:
  1. .NET работает поверх а не вместо чего-либо. Т.е. в пока что самом общем случае — на Windows под управлением Intel. Скоро будет далеко не только так, но пока что почти всегда так
  2. Почему если C/C++ разработчик обязан думать про безопасность приложения с точки зрения атак по стеку, а .NET — обязан не думать? Я так не считаю. Много приложений, имеющих возможность расширять собственный функционал не имеют настроенной песочницы. Просто потому что было лень этим заниматься. До недавних пор этим грешил Paint.NET. Чтобы не забывать это делать, человек должен понимать,
    зачем он это делает. Я тут не пишу инструкций по взлому, тут задачка мирная. Но поверьте, если осилить этот пример, взломать вы сможете любое приложение с проблемой в безопасности
  3. Ну и если знать ниже уровня платформенной абстракции, начинаешь решать задачи более широкого спектра нестандартными подходами. Что тоже хорошо.
.NET работает поверх а не вместо чего-либо. Т.е. в пока что самом общем случае — на Windows под управлением Intel. Скоро будет далеко не только так, но пока что почти всегда так
Интересно, о чем вы говорите?
Ну .NET Core ведет экспансию на другие платформы, а большой .NET — на ARM. Так что скоро все будет далеко не так однозначно )
1. И в чём проблема? У меня спокойно работает на Моно в Линукс-минте, ни разу не под управлением интел. И давно уж.
2. ДотНет просто тяжело защитить. Большинство самописных «защит» какой нибудь dnSpy спокойно обойдет. При чем тут Paint.NET — не понял, он же редактор картинкок, зачем ограничивающая песочница то? Увести фоточки?
Ну фоточки как раз мало интересуют, а вот выйти на файловую систему, прослушать пароль, забрать все пароли из кэша Chrome и вообще все что можно — вполне себе цель. Плагин не обязательно делать рабочим, достаточно в месте где он выложен написать что он решает некоторую очень популярную для Photoshop задачу, которой нет в Paint.NET: люди сами скачают
Да люди что угодно скачают. Можно так выкладывать и просто вирус.
Условно «нормальной» песочницей будет в дотНете разве что ограниченный AppDomain, и то не уверен, что этого будет достаточно для реальной работы и не придётся городить костыли.

Так и не понял, какую проблему решает статья или хотя бы какую проблему поможет решить статья.
Вы не ответили на вопрос
Зачем нужны форки тредов?
Я тоже считаю данную статью бессмысленной, потому что в ней разжевуется что-то, что я никогда не использовал и даже после прочтения статьи — использовать не буду. Банально потому, что я не понимаю что это.

Да, знать больше интересно и полезно, но без хороших примеров эти знания нигде не откадываются и не применимы. Что там такое Paint.Net c Fork.CloneThread делал неправильное?
Дополнительно, моя книга строится по следующему принципу: любая тема объясняется таким образом, чтобы человек, прочтя ее мог настолько глубоко понять тему, что смог бы не только пользоваться тем, что объяснено, но и менять то, что объяснено. Потому в каждой теме дополнительно объяснено как можно поменять поведение CLR, внося туда изменения.
Из минусов статьи: есть проблема с 32/64-битным кодом. И в перспективе другими архитектурами.
на x64 будет расширено несклько позже, там, да, другое строение вызовов методов.
Раздел про SEH не актуален для x64 (то, что на стек кладётся структура, являющаяся узлом односвязного списка, вершина которого лежит в TEB).

На Хабре есть прекрасный цикл статей Исключения в Windows x64. Как это работает. Часть 1-4, где хорошо описан SEH для x64.
И это тоже. Так сильно расписывать, конечно, не буду. Этот материал, скорее для разработчиков более низкого уровня

Обязательно стоит упомянуть это в тексте статьи (и в книге тоже)! Это крайне важная ремарка. Без неё у моих коллег сразу возникло резкое недоверие к материалу.

Кейсы использования у этого действительно только академические КМК. Хотя я видел когда-то в своей практике что-то подобное — Дельфийская библиотека в рантайме АСМом патчилась для исправления некоторых досадных багов… Но это край, не надо до такого доводить!
P.S. За краткое объяснение SEH — спасибо, освежил в памяти.
Ну я и не говорю что пример практический :) Мало того, он частично не работающий ))
Пока ваша книга недописана, какую литературу рекомендуете почитать на эту тему? Ну кроме CLR via C#, конечно.
Sign up to leave a comment.