Синтаксис:

RMDir [/r] [/REBOOTOK] directory_name

Удалить указанный каталог (полный путь без подстановочных знаков). Без /r каталог будет удален только в том случае, если он полностью пуст. Если указан параметр /r, каталог будет удален рекурсивно, поэтому будут удалены все каталоги и файлы в указанном каталоге. Если указан параметр /REBOOTOK, любой файл или каталог, которые не удалось удалить во время процесса, будут удалены при перезагрузке — если какой-либо файл или каталог будут удалены при перезагрузке, будет установлен флаг перезагрузки. Флаг ошибки устанавливается, если какой-либо файл или директория не могут быть удалены.

Пример:

RMDir $INSTDIR
RMDir $INSTDIR\data
RMDir /r /REBOOTOK $INSTDIR
RMDir /REBOOTOK $INSTDIR\DLLs

Обратите внимание, что текущий рабочий каталог (с экзешником) нельзя удалить. Текущий рабочий каталог устанавливается SetOutPath. Например, следующий пример не удалит каталог:

SetOutPath $TEMP\dir
RMDir $TEMP\dir

В следующем примере удастся удалить каталог:

SetOutPath $TEMP\dir
SetOutPath $TEMP
RMDir $TEMP\dir

Предупреждение: использование RMDir /r $INSTDIR в деинсталляторе небезопасно. Хотя это маловероятно, пользователь может выбрать установку непосредственно в папку Program Files, и поэтому эта команда сотрет всю папку Program Files, включая другие программы, которые не имеют ничего общего с установленной программой.

Доступны решения для более безопасного простого удаления только тех файлов, которые были установлены установщиком.

Перевод: Kolyan Maloy aka Dzhan for tolik-punkoff.com

Источник: NSIS Wiki

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2023/04/16/nsis-udalit-katalog-polnostyu-s-fajlami-i-podkatalogami-rmdir/

Кто не понял из лекции, вот вполне себе годная шпаргалка: Типы данных в ассемблере

Копия в PDF


Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2022/06/05/tipy-dannyh-v-assemblere/

Совсем краткое пояснение. Как театр начинается с вешалки, так программа на ассемблере MASM начинается с указания набора инструкций:

.386

Это ассемблеpная диpектива, говоpящая ассемблеpу использовать набоp опеpаций для пpоцессоpа 80386. Вы также можете использовать .486, .586, но самый безопасный выбоp - это указывать .386. Также есть два пpактически идентичных выбоpа для каждого ваpианта CPU. .386/.386p, .486/.486p. Эти "p"-веpсии необходимы только когда ваша пpогpамма использует пpивилигиpованные инстpукции, то есть инстpукции, заpезеpвиpованные пpоцессоpом/опеpационной системой в защищенном pежиме. Они могут быть использованны только в защищенном коде, напpимеp, дpайвеpами. Как пpавило, ваши пpогpаммы будут pаботать в непpивилигиpованном pежиме, так что лучше использовать не-"p" веpсии. (Из мануала Iczelion'а)

.model flat

.model - модель памяти, используемая вашей программой. Для DOS, например, были модели tiny, small, compact, flat, lagre и т.д. - они выбирались в зависимости от типа программы. По ограничениям DOS сегмент кода не мог занимать пространство, больше размера одного сегмента в памяти. Чтоб это обойти, как раз и использовалась сегментация. Tiny и flat могли быть использованы для оригинальных DOS-программ, с расширением .com, которые могли занимать чуть меньше одного сегмента (64 Кб), на код и данные, и представляли собой просто кусок кода вместе с данными, можно сказать RAW-формат исполняемого файла - просто откомпилированный байткод, даже без всякого заголовка. Для EXE формата, код и данные могли занимать несколько сегментов.

В Win32 сегментация памяти не нужна, во-первых, размер адреса 32-битный, что больше, чем в DOS, во-вторых, менеджментом памяти занимается ОС, потому программа видит все нужные ей внешние библиотеки и функции из них, как если бы они были загружены в адресное пространство программы. Таким образом, программа под Win32 изнутри представляет такой себе очень большой .COM-файл, потому используется только одна модель памяти - flat.

.model flat, stdcall

У директивы .model есть несколько важных параметров, самый главный из них, указание на передачу параметров функций (обычно внешних, из DLL, но никто не мешает для своих функций использовать). Его и указываем через запятую (stdcall).

Есть три способа передачи параметров:
- C (си) способ: вызывающая, т.е. наша программа, должна положить в стек нужные параметры, причем, в обратном порядке. Например, если функция описывается так:

SomeFunction (Argument1, Argument2, Argument3)

То на ассемблере она вызывается так:

push Argument3
push Argument2
push Argument1
call SomeFunction

А далее, вызывающая программа должна почистить стэк (по-научному это называется "уравнять"), push уменьшает значение регистра стека на размер операнда (2 или 4 байта), пусть будет 4, тогда получается, что надо увеличить значение стека на 3x4=12 байт.

add SP, 12

C-поpядок полезен, когда вы не знаете, как много паpаметpов будут пеpеданны функции

- PASCAL - это C соглашение наоборот, параметры передаются в прямой последовательности, т.е. первый параметр кладется в стек первым, а со стеком должна разбираться сама вызываемая функция.

- STDCALL - это гибрид C и PASCAL соглашения, параметры передаются в обратном порядке, но со стеком разбирается вызываемая функция.

Win32 использует практически исключительно STDCALL соглашение для своего API, исключая функцию wsprintf(), потому что она не знает, сколько ей будет передано параметров. При ее вызове следует использовать C-соглашение.

На рассвете цивилизации ПК и примерно до того времени, когда появились инструменты программирования Microsoft Win32, почти все компиляторы для ПК создавали объектные файлы с использованием стандарта Intel Object Module Format (OMF). Позже Intel представила процессоры 386 и 32-разрядный защищенный режим, после чего они также расширили спецификацию OMF для 32-разрядных систем, что привело к появлению «OMF-386», который стал стандартом для большинства сред защищенного режима ПК. Примерно в это же время исходная группа разработчиков Windows NT также разрабатывала код не только для процессоров Intel, но и для поддержки процессоров других производителей. Команда Microsoft NT выбрала более переносимый формат объектных модулей, известный как Common Object File Format (COFF), производный от официального формата объектного кода для UNIX System V. Объектные модули COFF позже стали стандартом де-факто для всех инструментов разработки Microsoft Win32 и получили преимущество в том, что он намного ближе по формату к переносимым исполняемым файлам (PE) - собственному исполняемому формату для Win32 (компоновщику формата COFF требуется гораздо меньше усилий для создания 32-разрядного EXE или DLL из файла COFF, чем из файла формата OMF).

Помимо объектных файлов форматов OMF и COFF (.obj), существуют также файлы библиотек форматов OMF и COFF (.lib). Библиотеки, к счастью, в основном представляют собой просто набор объектных файлов вместе с заголовочной информацией, которая позволяет компоновщику определить, какие объектные файлы из библиотеки использовать. Однако, чтобы усложнить ситуацию, и OMF, и COFF используют одни и те же расширения имен файлов, .obj и .lib, для ссылки на два разных типа форматов файлов объектов и библиотек (из-за этого вы не можете просто посмотреть на расширение имени файла чтобы узнать, является ли объектный модуль или файл библиотеки OMF или COFF).

Проблема со смешиванием объектных файлов и файлов библиотек от разных производителей компиляторов заключается в том, что одни поставщики поддерживают COFF, другие используют OMF, а некоторые могут работать и с тем, и с другим. Borland, например, по-прежнему использует объектные файлы и библиотеки OMF, тогда как 32-разрядные компиляторы Microsoft создают файлы формата COFF. Watcom C/C++ v11.0, по-видимому, предпочитает COFF при компиляции и компоновке приложений Windows, но создает объектные файлы OMF для использования с 32-разрядным DOS-расширителем защищенного режима DOS4GW. Microsoft MASM 6.13 по умолчанию создает файлы OMF, но параметр командной строки /coff указывает компилятору, что он должен создавать объектные файлы COFF.

Когда приходится связывать файлы разных форматов, разные компоновщики делают разные вещи. Например, компоновщик Microsoft Visual C/C++ предназначен для объектных файлов и библиотек формата COFF, но при необходимости попытается преобразовать объектные файлы OMF в файлы COFF. В некоторых случаях это работает, но, к сожалению, Microsoft LINK не поддерживает все типы записей OMF, поэтому во многих ситуациях компоновщик может дать сбой при работе с объектными файлами формата OMF. Кроме того, хотя Microsoft LINK пытается поддерживать объектные файлы OMF, он отказывается обрабатывать любые библиотеки формата OMF. Другие компоновщики, такие как TLINK от Borland, предназначены для объектных файлов OMF и аналогичным образом отказываются работать с объектными или библиотечными файлами формата COFF. Некоторые поставщики расширителей DOS и встраиваемых систем, такие как Phar Lap, предоставляют свои собственные компоновщики, поддерживающие как OMF, так и COFF, что дает вам возможность выбора.

Проблема в том, что смешение OMF и COFF типов объектных файлов и файлов библиотек может привести к хаосу. Вдобавок появляются загадочные сообщения об ошибках от компоновщиков, которые только вносят еще большее непонимание. Если ваш компоновщик не поддерживает определенный формат, вам следует придерживаться рекомендуемого формата объекта и библиотеки для вашего компилятора/компоновщика/платформы и избегать смешивания файлов OMF и COFF.

Перевод: Leha Silent для tolik-punkoff.com
Оригинальный текст (англ., TXT) предоставил Jiang Yap из WeChat
Копия перевода в TXT

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2022/05/23/o-formate-obektnyh-fajlov-i-bibliotek-coff-i-omf-i-ob-opasnosti-ih-smesheniya/

Небольшая шпаргалка по условным и безусловным переходам.

Безусловный переход: выполняется командой JMP <метка>, может использоваться, как для перехода вперед, пропуская некоторые команды в коде, так и для возврата назад, для повторного выполнения инструкций:

1.

	...
	какой-то код
	...
	JMP	label1
	...
	какой-то код
	...
label1:
	...
	другой код
	выполняется после срабатывания
	инструкции JMP
	...

	...
	какой-то код
	...
labelret:
	...
	какой-то код
	...
	JMP	labelret

( Длинно и на буржуйском, потому под катом )

Копия на Mega.nz (TXT, ZIP)
Копия на Google.Drive (TXT, ZIP)

Это репост с сайта http://tolik-punkoff.com
Оригинал: https://tolik-punkoff.com/2022/05/09/writing-win32-programs-in-assembly-language-using-tasm/

По-прежнему, чиним деньгополдощательные терминалы и всякие прочие АРМ, потому понадобилось, заметка от склероза, чтоб не забыть, да и другим полезно будет.

Что делать, и как это порешать. AHCI --> IDE. Инструкция для и по просьбе заводского эникейщика.

Пост из серии "Спрашивали - отвечаем". Спросили, а как сделать на рисунке текст по окружности, как например, на этом плакате. Впрочем, тут я довольно неаккуратно допиливал старый плокад, так что можно было и лучше. Так что начнем сначала.

1. Рисуем круги, логотип в круге, если это надо, помещаем надписи сверху и снизу, или только сверху, или только снизу, в зависимости от того, что вы хотите сделать. Подбираем надписям нужный шрифт.
Пример:

Применимо к линейке ОС Windows NT, начиная, как минимум с Windows 2000, x86 и x64 версий[прим. ред.]

Командный процессор Windows (CMD) содержит встроенную переменную %RANDOM%, которую можно использовать для генерации случайных чисел.

%RANDOM% генерирует случайное целое число от 0 до 32767 (включительно).

echo %RANDOM%

Диапазон генерируемых чисел можно уменьшить с помощью небольшого лайфхака, команда SET не только устанавливает значение пользовательских переменных окружения, но и может производить простейшие арифметические операции.

Например, можно сгенерировать случайные числа в диапазоне от 1 до 500:

@ECHO OFF
SET /a _rand=(%RANDOM%*500/32768)+1
ECHO Random number: %_rand%

Если попытаться сгенерировать случайные числа больше чем 32767, то это приведет к проблемам, хотя с виду все будет работать. Например, если в вышеприведенном коде заменить 500 на 65536, то это приведет к генерации последовательности "случайных" чисел, которая будет состоять только из нечетных чисел.

Распределение возвращаемых чисел определяется, как диапазоном, так и количеством итераций генерации случайных чисел.

Например, если вы генерируете числа в диапазоне от 1 до 100 то в среднем:

- При генерации 10 чисел, примерно 6% будут дублироваться
- При генерации 100 чисел, этот процент вырастет до 63, т.е. 63% сгенерированных чисел будут дубликатами, т.е. совпадать с одним или несколькими из остальных 99 чисел.
- Если сгенерировать 1000 чисел, почти все будут дублироваться, т.к. есть только 100 возможных значений.

Начальство попросило сделать секретарше отдельные настольные часы, чо, нашел старый смартфон с 5 стоковым андроидом и дохлым радиомодулем, т.е. не связи, не вайфая, как раз годен только часы отображать. Была проблема с тем, что телефон засыпал, соответственно, переставал часы показывать.

Как вылечить нашел здесь Копия в PDF

Заодно уж, как зайти в режим разработчика Копия в PDF

Это репост с сайта http://tolik-punkoff.com
Оригинал: http://tolik-punkoff.com/2020/10/28/otklyuchenie-spyashhego-rezhima-na-android/

Или как раскидать результат работы awk по нескольким переменным.

echo "$TMPSTRING"|sed -e 's~'\''~~g'|awk -F "," '{print "LOGIN=" sq $1 sq; 
    print "FULLNAME=" sq $2 sq; print "PHONE=" sq $3 sq; print"ROOM=" sq $4 sq;
    print "WORKTIME=" sq $5 sq}' sq="'"

eval $(echo "$TMPSTRING"|sed -e 's~'\''~~g'|awk -F "," '{print "LOGIN=" sq $1 sq; 
    print "FULLNAME=" sq $2 sq; print "PHONE=" sq $3 sq;
    print"ROOM=" sq $4 sq;
    print "WORKTIME=" sq $5 sq}' sq="'")