Уважаемые интересующиеся... Лучше пишите, что это я виноват и чего-то не понимаю, чем сваливать всё на AI-slop. В выводе специально написано, что это моих рук дело. И я за слова в ответе
"NET application startup time and latency can be improved by compiling your application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation"
Имею право полагать, что до выхода Native AOT, возможности -p:PublishReadyToRun=true не было
Цитата "Основное использование IDisposable интерфейса заключается в выпуске неуправляемых ресурсов." Неуправляемые ресурсы это ресурсы к которым CLR не имеет никакого отношения.
Очень хорошая статья. Но, поскольку, я не имею большого опыта в проектах на много человек, мне очень сложно что-то сказать про упоминаемые абстракции.
С одной стороны, мне кажется вопрос остро стоит о проектировании. Чем больше абстракций -- тем сложнее структура -- тем сложнее сообразить "как этим пользоваться?" И постоянная гонка за "идеальной архитектурой" не всегда приводит к чему-то хорошему.
С другой стороны, полностью приземляться и писать в прикладном духе тоже не всегда хорошо. Но, то, что старые учебники и книги рецептов учат нас вникать в процесс -- кажется очень похожим на правду. И это наверное лучшее, что можно вынести.
Вроде бы, для 16-разрядных приложений была подсистема Windows on Windows (syswow.exe), которая работала с ними как с сегментными, и многозадачность для них была организована как в Windows 3x. Хотели же сделать плавный переезд с Windows 3.10...
Если я правильно понял вас, то в разметке Markdown есть возможность написать сырой текст (который не рендрится). В начале строки ставятся "```" и через строку ```.
Я пытаюсь к этому подойти. Через время выпущу пару статей о импортах и экспортах. Мне ужасно интересно было узнать как происходит весь процесс во время выполнения.
Доброго времени суток! Благодарю за отзыв. Я пересмотрю всё и исправлюсь. Про OS/360 однозначно буду читать сегодня.
Это не ABI, это API. API -- набор системных сервисов, которые ОС предоставляет прикладным программам, откуда и его название. ABI же -- это, по сути, соглашения о связях между подпрограммами (через какие регистры передаются параметры и всё такое).
Я сколько понимаю, (почему я писал именно про binary interface, а не API): Дело приходится иметь с уже собранными компонентами системы или внешними модулями, соответственно и вызов функции (или прыжок на метку, как это раньше было?) подразумевает под собой двоичный контекст.
API это условно список функций или служб, которые предоставляет программа для публичного использования.
После компоновки и сборки, программа содержит этот самый список функций, но чтобы его обозначить, надо явно говорить компилятору, что функции будут использоваться во-вне. Итого, как я понимаю, все-таки используется ABI компонента, поскольку это те самые явно отмеченные функции.
Так же сколько я понимаю, Соглашения о вызовах говорят "Что надо делать" до/после вызова функции, поэтому. Но используют их вроде бы уже в модуле, который импортирует что-то извне? Приношу извинения, если я не прав - помогите.
Точка входа в COM-программу -- не "везде", а строго фиксированная -- её первый же байт. Максимальный размер COM-программы -- не 64 Кбайта, а 64 Кбайта минус 256 байт (для PSP). И, кстати, это не "команда", это именно COM-файл или COM-программа. А вот у EXE-программы точка входа как раз не фиксированная, а может находиться в произвольном месте, поскольку её положение указывается в заголовке файла или в иной структуре, уж не помню точно.
Я на эту тему находил много интересных разногласий, и сам не до конца понимаю мысль. Есть материалы, где говорится, что программа-COM может загружаться с любого места. (например https://habr.com/ru/companies/timeweb/articles/880586/)
Вполне уверен, что я мог ошибиться
Вообще-то, эти указатели называются ближними, а не "недалёкими". А far pointers -- дальние указатели.
Я исправлю моменты в статье, чтобы не отлынивать от терминологии, спасибо.
Уважаемые интересующиеся... Лучше пишите, что это я виноват и чего-то не понимаю, чем сваливать всё на AI-slop. В выводе специально написано, что это моих рук дело. И я за слова в ответе
Не даром я сюда затесался
"NET application startup time and latency can be improved by compiling your application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation"
Имею право полагать, что до выхода Native AOT, возможности
-p:PublishReadyToRun=trueне былоНачиная с .net 7.0 - из экспериментального статуса вышла Native AOT для SCD приложений. Это ИИ?
Хорошо, я исправился. IDisposable не игнорируются сборщиком мусора.
Цитата "Основное использование IDisposable интерфейса заключается в выпуске неуправляемых ресурсов."
Неуправляемые ресурсы это ресурсы к которым CLR не имеет никакого отношения.
Ок, тогда как тогда живут IDisposable производные в памяти процесса?
Очень хорошая статья. Но, поскольку, я не имею большого опыта в проектах на много человек, мне очень сложно что-то сказать про упоминаемые абстракции.
С одной стороны, мне кажется вопрос остро стоит о проектировании. Чем больше абстракций --
тем сложнее структура -- тем сложнее сообразить "как этим пользоваться?"
И постоянная гонка за "идеальной архитектурой" не всегда приводит к чему-то хорошему.
С другой стороны, полностью приземляться и писать в прикладном духе тоже не всегда хорошо.
Но, то, что старые учебники и книги рецептов учат нас вникать в процесс -- кажется очень похожим на правду.
И это наверное лучшее, что можно вынести.
Вроде бы, для 16-разрядных приложений была подсистема Windows on Windows (
syswow.exe), которая работала с ними как с сегментными, и многозадачность для них была организована как в Windows 3x. Хотели же сделать плавный переезд с Windows 3.10...Приношу извинения :D
Если я правильно понял вас, то в разметке Markdown есть возможность написать сырой текст (который не рендрится). В начале строки ставятся "
```" и через строку```.Я пытаюсь к этому подойти. Через время выпущу пару статей о импортах и экспортах. Мне ужасно интересно было узнать как происходит весь процесс во время выполнения.
Приветствую! Спасибо за замечания. Скоро обновлю статью. Заодно комментари и в коде поставлю. (внезапно пропали при переносе сюда)
Да, они намеренно там есть. Просто хотел поделиться…
Спасибо большое! Теперь к делу:
Согласно описанию разметки ОЗУ в документах, у MS-DOS есть несколько разделов в ОЗУ
взял из своей первой статьи
Ещё раз спасибо за такую справку. Готовлю исправленную статью
Я помню, что в исходниках какого-то Win16 приложения был комментарий про это. Дословно не передам, но мысль была такова:
Я не стал освещать этот момент, потому что, уж об этом нюансе точно ничего нормального не найдешь.
Доброго времени суток! Благодарю за отзыв. Я пересмотрю всё и исправлюсь. Про OS/360 однозначно буду читать сегодня.
Я сколько понимаю, (почему я писал именно про binary interface, а не API):
Дело приходится иметь с уже собранными компонентами системы или внешними модулями, соответственно и вызов функции (или прыжок на метку, как это раньше было?) подразумевает под собой двоичный контекст.
API это условно список функций или служб, которые предоставляет программа для публичного использования.
После компоновки и сборки, программа содержит этот самый список функций, но чтобы его обозначить, надо явно говорить компилятору, что функции будут использоваться во-вне. Итого, как я понимаю, все-таки используется ABI компонента, поскольку это те самые явно отмеченные функции.
Так же сколько я понимаю, Соглашения о вызовах говорят "Что надо делать" до/после вызова функции, поэтому. Но используют их вроде бы уже в модуле, который импортирует что-то извне? Приношу извинения, если я не прав - помогите.
Я на эту тему находил много интересных разногласий, и сам не до конца понимаю мысль.
Есть материалы, где говорится, что программа-COM может загружаться с любого места.
(например https://habr.com/ru/companies/timeweb/articles/880586/)
Вполне уверен, что я мог ошибиться
Я исправлю моменты в статье, чтобы не отлынивать от терминологии, спасибо.
Так-то весь интерес правда с NTVDM появился. Я просто об этом в статье ничего не указал, и в конце лучше бы не писал про это
Спасибо! Постараюсь в следующий раз при вычитке замечать такое
Спасибо, буду разбираться дальше. Про оверлеи в следующий раз будет написано однозначно.
очень рад видеть такие комментарии. Это не является духотой. Я учту это и буду разбираться дальше