Pull to refresh
0
0.1
Перикл Фемиди@pfemidi

Домосед

Send message
Не бойтесь, не угадали.
Это не ересь, я же сказал что
А это уже привычка, в именах файлов/директорий после точки может быть лишь расширение.

Так что для меня всё что после точки то расширение.
Почему же, живут больше года, гораздо. Только поддержкой старого не занимаюсь, это да. Специфичные проекты просто.
Ещё раз. Я живу в России и для меня предпочтительнее принятый в России порядок день, месяц, год. Да, сортировка будет лучше, но у меня нет ни одного долгостроя, который продолжался бы более года, так что у меня сортировка не страдает. И т.к. я работаю один, то предпочтения других мне совсем не интересны.
А это уже привычка, в именах файлов/директорий после точки может быть лишь расширение. Но в дате всегда сначала идёт день, после месяц, после год, по-другому — от лукавого.
Мне нет никакого дела до этого ISO8601, я в России живу, а в России формат даты ДЕНЬ МЕСЯЦ ГОД.
Может быть. Это было давно, с тех пор у меня в этом практики никакой не было и я уже не помню, успешно всё забыл.
Было время я пользовался Microsoft Visual SourceSafe, год, с 2000-го по 2001-й год когда работал в команде, там это был корпоративный стандарт. Но там было просто, мне показали что надо нажимать в начале рабочего дня чтобы скачалась последняя версия проекта и что нажимать в конце рабочего дня чтобы другие увидели что я там за день наделал, это я и нажимал. А ни до этого, ни после этого никакими системами контроля версий я никогда не пользовался, непонятны они мне, а посему неудобны. Сейчас меня закидают тухлыми яйцами, но мне удобно по-старинке: добился работоспособности — «закоммитил» директорию с проектом у себя в ProjectName.dd-mm-yyyy и продолжил делать в ProjectName. Не получается — сделал «checkout» путём переноса из ProjectName.dd-mm-yyyy обратно в ProjectName. Получилось — «закоммитил» директорию с проектом в следующую директорию опять с указанием даты ProjectName.dd-mm-yyyy. И время от времени бекаплю всё это дело на внешний диск, удаляя у себя на локале наиболее старые ProjectName.dd-mm-yyyy, но оставляя на внешнем диске все. И нет никакой головной боли что там лучше делать merge или rebase, и не надо придумывать никакие commit messages, и не надо синхронизировать никакие ветки. А историю изменений по ходу изменений записываю (с указанием что менял и даты) в обычный текстовый файл Changelog.txt в корне проекта. По этому Changelog.txt в случае чего необходимую директорию ProjectName.dd-mm-yyyy найти не просто, а очень просто и без всяких bisect. И да, в команде я с 2001-го года больше не работаю, работаю один. Из git я освоил только clone чтобы иногда скачивать что-нибудь с гитхаба. В принципе init, add, checkout, и commit я могу в Git использовать, но зачем? Если моё версионирование через директории ProjectName.dd-mm-yyyy делает в принципе то же самое, только [для меня] гораздо более прозрачно и устраивает меня на 100%. А вот про всякие cherry-pick, revert, tag, submodule и прочие, а ещё какие-то жуткие, нечеловеческие, сделанные явно для того чтобы в конец запутать способы указания номера коммита через немыслимые HEAD, HEAD~1, HEAD^ и т.д. — я только знаю что такое есть, но что это, зачем это нужно и как этим пользоваться понятия не имею и побаиваюсь. И некогда мне это изучать. Вот как-то так.

Сказал как есть и поэтому к приёму очереди из тухлых яиц готов.
Занимаюсь программированием с 1988-го года, то есть 30 с лишним лет, с интересом читаю статьи с описанием всяких хитростей Git, думаю «Надо всё же когда-нибудь попробовать! Раз уж от этого Git все так тащатся!», но… Некогда мне Git изучать, работать надо, поэтому пробы всё откладываю и откладываю из раза в раз. Позор мне. Пойду убьюсь об стену.
Изначально Virttual Pascal делался для OS/2, уже позже он был портирован для Windows. Я знаю, я с Миряновым переписывался ещё в то время когда он в Киеве жил и в Британию для работы на fPrint UK Ltd не уехал.
Грубо говоря это как процессоры CISC которые умеют практически всё и RISC которые умеют только байты в памяти двигать и простыня инструкций RISC делает то, что на CISC выполняется за одну инструкцию. Но те же RISC процессоры ARM дешёвые и используются даже в мобильных телефонах, а AMD и Intel зато умеют за одну инструкцию выполнить шифрование Rijndael (AES-NI)
Решил вспомнить былое, достал свои дискеты 5.25" с дистрибутивом Turbo Pascal 7.0 (у меня ещё и дистрибутив Borland C++ 3.1 имеется, тоже официально купленный в своё время и тоже, увы, на дискетах 3.5", но о каких CD в то время речи не было, а флешек вообще не существовало в природе), посмотрел на них грустно — читать их мне давно уже не на чем, нет у меня дисководов и скачал дистрибутив Turbo Pascal 7.0 из интернета. Загрузил в IDA сначала tpc.exe. Тут (и если смотреть далее) невооружённым взглядом видно что это именно ассемблер, ни один компилятор такой код не сделает, это явно творение рук человеческих:

image

После загрузил в IDA turbo.exe. Тут уже не чистый ассемблер:

image

Правда если дальше углубиться/посмотреть то становиться ясно что тут больше не ассемблерные вставки в HLL на Паскале, а паскальные вставки в программу на ассемблере. IDA даже честно нашла стандартные функции из RTL всё того же Turbo Pascal. Как я и предполагал сам компиляторный движок такой же как в tpc.exe, отладчик на ассемблере, а на Паскале написан только UI. Вот что говорит по этому поводу википедия:
Начиная с 6-й версии в поставку TP/BP включалась объектная библиотека Turbo Vision, представляющая собой полноценную инфраструктуру (англ. framework) для создания оконных приложений, работающих в текстовом режиме. В частности, интерфейс самой среды разработки TP/BP был реализован средствами этой библиотеки.

Похоже что сначала был написан на ассемблере строчный компилятор tpc.exe, а после был написан уже turbo.exe, который был скомпилирован уже при помощи имеющегося tpc.exe ну tasm.exe само собой :-)
Строчный компилятор tpc.exe точно был на ассемблере, а вот IDE turbo.exe уже на самом паскале, во всяком случае весь UI в нём был на основе Turbo Vision из этого самого паскаля. Хотя backend занимающийся не междумордием, а именно компиляцией, вполне мог быть и тот же, который был в tpc.exe, то есть ассемблерный. Не знаю, turbo.exe я не смотрел, но внутри tpc.exe в своё время покопался. Привлекло именно то, что не использовались никакие yacc или bison, всё чистый ассемблер. Поэтому [бинарный] код читался лёгко и непринуждённо.
Виталий Мирянов в своё время написал полный аналог Turbo Pascal под названием Virtual Pascal именно на ассемблере. Но изначально для OS/2. Потому что для DOS Turbo Pascal был, для Windows Turbo Pascal был, а для OS/2 не было, вот он и сделал.
Потому и не использовалась что выполнялась гораздо медленнее чем последовательность

push bp
mov bp,sp,
sub sp,local_size


или с сохранением ещё адресов предыдущих фреймов в зависимости от уровня вложенности. Вот в Turbo C 2.0 (или даже ещё в Turbo C 1.5, за давностью лет не помню) если в установках компилятора выставить процессор выше чем чем x86 использовалась. В Borland C++ 3.1 AFAIR эта инструкция уже не применялась, leave остался, а вот enter уже не использовался. А leave используют до сих пор. В принципе инструкции хорошие, годные, вот если бы они такое бешеное количество тактов не занимали по сравнению с последовательностью обычных команд, получилось бы вполне православно. Но как говорил Черномырдин: «Хотели как лучше, а вышло как всегда» :-)
Однако во внутренней процедуре нет адреса стекового кадра внешней процедуры — внутренняя процедура не знает, от чего отсчитывать адрес искомой переменной. Этот адрес приходится всякий раз передавать во внутреннюю процедуру через дополнительный скрытый параметр.

А как же неиспользуемая из-за её тормознутости (но однако тем не менее существующая) инструкция ENTER? Для этого в принципе и была создана.
За других не скажу, но я бы подписал. Потому что

1) лично у меня нет мобильного телефона и не планируется, приходится каждый раз к банкомату бегать чтобы оплатить тот же ЖКХ и хотя раз в месяц это не особо критично, но всё же неудобно, лучше уж online не выходя из дома как я и делал раньше пока самый популярный в России банк не отказался от листочков с одноразовыми TAN-кодами.
2) как ниже сказал ssh24:

И как тогда телефон выносить из дома? Его можно потерять, или могут украсть

И чем тогда данный поворот событий лучше «листик может потеряться, его могут найти вместе с Вашим ID, его может сожрать собака или маленький ребенок, в конце концов»? IMHO ничем не лучше, но геморроя по сравнению с наличием листочка с одноразовыми TAN-кодами гораздо больше хотя бы в том, что обязательно надо иметь мобильный телефон.
В некоторых «особо продвинутых» европейских банках до сих пор пор можно разжиться листиком с одноразовыми TAN-кодами.

IMHO это самый нормальный способ, именно листочек с одноразовыми паролями. И двухфакторная авторизация есть, и пользователи, физически не имеющие мобильного телефона (да, я такой! :-) ) не остаются в стороне. Жаль что вот уже два года как (или больше??? уже не помню) самый популярный в России банк отказался от этих одноразовых листочков, которые ранее можно было в любом банкомате этого самого популярного в России банка получить.
Похоже я ошибся, это не PKCS#11
Но потом я решил обратить внимание на константы 0x12, 0x112, 0x212, 0x312 (без хекса 18, 274, 536… не очень похоже на что-то необычное)

А это не PKCS#11? Уж больно похоже на одну из реализаций CRYPTOKI.

Information

Rating
4,410-th
Location
Москва и Московская обл., Россия
Registered
Activity