Было время я пользовался 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. Тут (и если смотреть далее) невооружённым взглядом видно что это именно ассемблер, ни один компилятор такой код не сделает, это явно творение рук человеческих:
После загрузил в IDA turbo.exe. Тут уже не чистый ассемблер:
Правда если дальше углубиться/посмотреть то становиться ясно что тут больше не ассемблерные вставки в 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 это самый нормальный способ, именно листочек с одноразовыми паролями. И двухфакторная авторизация есть, и пользователи, физически не имеющие мобильного телефона (да, я такой! :-) ) не остаются в стороне. Жаль что вот уже два года как (или больше??? уже не помню) самый популярный в России банк отказался от этих одноразовых листочков, которые ранее можно было в любом банкомате этого самого популярного в России банка получить.
Сделать все функции в обязательном порядке __cdecl или __stdcall (правда тут переменное число аргументов никак не получится, так что для vararg только __cdecl) и полностью запретить __fastcall, вот и получится стабильный ABI.
Дык Audacious же давно существует у которого уши растут ещё из XMMS. Скины винампа умеет, можно сделать так что выглядеть будет практически идентично. Да и умеет не сильно меньше.
А можно ли сделать так чтобы показывались все потоки, кроме GT? Для меня к примеру на GT практически вообще ничего интересного нет, практически сплошная демагогия там, а вот хабр я хочу читать весь.
Сказал как есть и поэтому к приёму очереди из тухлых яиц готов.
После загрузил в IDA turbo.exe. Тут уже не чистый ассемблер:
Правда если дальше углубиться/посмотреть то становиться ясно что тут больше не ассемблерные вставки в HLL на Паскале, а паскальные вставки в программу на ассемблере. IDA даже честно нашла стандартные функции из RTL всё того же Turbo Pascal. Как я и предполагал сам компиляторный движок такой же как в tpc.exe, отладчик на ассемблере, а на Паскале написан только UI. Вот что говорит по этому поводу википедия:
Похоже что сначала был написан на ассемблере строчный компилятор tpc.exe, а после был написан уже turbo.exe, который был скомпилирован уже при помощи имеющегося tpc.exe ну tasm.exe само собой :-)
push bpmov 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-кодами гораздо больше хотя бы в том, что обязательно надо иметь мобильный телефон.
IMHO это самый нормальный способ, именно листочек с одноразовыми паролями. И двухфакторная авторизация есть, и пользователи, физически не имеющие мобильного телефона (да, я такой! :-) ) не остаются в стороне. Жаль что вот уже два года как (или больше??? уже не помню) самый популярный в России банк отказался от этих одноразовых листочков, которые ранее можно было в любом банкомате этого самого популярного в России банка получить.
А это не PKCS#11? Уж больно похоже на одну из реализаций CRYPTOKI.
Оригинал:
Перевод:
А если другой нет? У меня вот к примеру другой нет.
Неудобно, картой намного удобнее. И со сдачей проблем никаких, и кешбеки всякие, и акции… Не, картой расплачиваться IMHO намного удобнее.