В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?
Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:
Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.
Для начала попытаемся поточнее выяснить, что же происходит. Откроем или введём какой-нибудь текст с длинными строками, чтобы они переносились. Сохраним файл. Если теперь попытаться его редактировать, например, добавив слово «синими», строки будут переноситься неправильно, ломая форматирование:
Если уменьшать окно блокнота, строки разрезаются (это видно на заглавной картинке), а при растягивании остаются на месте, не заполняя увеличивающееся окно. Как будто в каждой строке появился жесткий «перевод строки» в том месте, где она заканчивалась в момент сохранения. Видимо текст каким-то образом портится в памяти:
Если же теперь снова сохранить файл, станет ещё хуже. Все строки переформатируются, но окно не обновится. Поэтому курсор может переместиться в другое место, а если начать вводить текст, окажется, что вы вводите его не в то место, где находится курсор, а совсем в другое. Программисты, которые писали notepad, рассуждали логично: при сохранении файла ничего в окне не должно поменяться, поэтому и нет смысла его обновлять. Но в нашем случае с учётом этой ошибки весь текст меняется. Воспроизвести ситуацию может каждый пользователь windows, потому что последняя версия, где этой ошибки не было — Windows'98, и вряд ли у кого она ещё осталась.
Итак, по всей видимости, при сохранении файла что-то идёт не так и текст портится. Как найти это место в коде? Откроем notepad.exe в каком-нибудь отладчике. Как известно, в 64-битной системе для совместимости имеется два блокнота: 32- и 64-битный, надо не перепутать их.
Введём текст, на котором легко будет увидеть, как он портится при переносе строк. Наберём в одну строку «first text line second text line», а затем уменьшим окно так, чтобы она разрезалась посередине.
Резонно будет предположить, что запись делается с помощью функции WriteFile. Оказывается, она вызывается в коде целых 6 раз. Недолго думая, поставим точки останова на все 6 вызовов. Запускаем блокнот и нажимаем «сохранить». Выполнение останавливается здесь:
Посмотрим все регистры, где содержатся параметры вызова. В rcx у нас 104, это непонятно что. A rdx = 002D45E0, это похоже на адрес в памяти. Посмотрим, что там.
Отлично. Отсюда у нас идёт запись. Попробуем выполнить код дальше, чтобы посмотреть, где он портится. Однако почти сразу данные затираются, а это значит, что это всего лишь временный буфер, а сам текст хранится где-то ещё. Посмотрим выше по программе.
Ага, перед сохранением текст видимо преобразовывается из многобайтовой кодировки в однобайтовую. Точно так же, как в прошлый раз, посмотрим параметры. rax = 002D45E0, здесь у нас пока нули. Это как раз то место, куда попадёт результат. esi = 20, это длина текста. есх = 4еЗ, без комментариев. edx = 400, то же самое. А вот r8 = 002D6780:
Снова продолжим выполнение, наблюдая за содержимым этого участка памяти. Через несколько десятков команд мы выходим из подпрограммы, выполняются какие-то переходы, вызовы, но мы, не обращая на это внимания, продолжаем давить на «step over», выполняя код по шагам, и следя только за окном с текстом. И вот в какой-то момент он изменяется. Как видим, между 1 и 2 строкой появились коды 0d, 0d, 0a:
Как обычно бывает, мы проскочили нужную команду, постоянно давя на кнопку, поэтому придётся повторить всё ещё раз, запомнив, где примерно это произошло. Теперь по мере приближения к нужному месту в коде, замедляемся, и точно определяем, что текст испортился вот на этом вызове:
Можно попробовать, что будет, если не делать этот вызов. Снова доходим до этого места, и прямо тут, в отладке, изменяем RIP (регистр, где хранится адрес выполняемого в данный момент кода) на 00000000FFA38EE1, как будто мы пропустили этот call, который нам всё испортил. Удивительно, всё работает, текст не ломается!
Тут надо сказать, что в таких случаях обычно не разбираются, что это за подпрограмма, что она делает и зачем, а просто выкидывают её из EXE-файла. Это можно сделать разными способами, например, забить её всю NOP'ами, или изменить условный переход по равенству «je», который так кстати имеется сразу перед ней, на безусловный «jmp».
Но нам сейчас не столько нужно исправить эту ошибку, как интересно выяснить, откуда же она вообще взялась. Поэтому заходим внутрь и смотрим:
Вот такая замечательная маленькая подпрограмма. Проходим её по шагам. Сначала сравниваются какие-то две переменные с нулём, в результате первый вызов неизвестно чего не делается, а делаются подряд для вызова SendMessage. То есть, всё, что происходит, это посылается два каких-то виндовых сообщения, причём текст портится сразу же после первого (выделен зеленым). Невооруженным глазом видно, что в EDX передаются их коды (выделен красным). Поищем код 0C8h.
Это оказывается сообщение EM_FMTLINES. Довольно похоже, посылаем сообщения для форматирования строк, вот и доформатировались. Пришло время почитать документацию. MSDN сообщает нам следующее:
Это сообщение определяет включение «мягких» переводов строки в многострочный элемент редактирования. «Мягкий» перевод строки представляет из себя два символа [CR] и один [LF] и вставляется в строку там, где она разрезается при переносе по словам.
Параметр wParam: true — вставить символы, false — удалить их.
Сообщение влияет только на буфер, возвращаемый сообщениями EM_GETHANDLE и WM_GETTEXT, и не влияет на текст, отображаемый в элементе редактирования. Также оно не влияет на «жёсткие» переводы строки, которые состоят из одного [CR] и одного [LF].
Кроме того, мы узнаём, что данное сообщение было введено не позднее чем в Windows 95. Ну вот всё и стало понятно. В 95 году предполагалось, что оно не влияет, а сейчас видим, что влияет, да ещё как. Немного поизучав код, находим несколько аналогичных вызовов, и нашему мысленному взору предстаёт следующая картина:
Давным-давно, в первой половине 90-х годов, программисты Microsoft писали блокнот для Windows 95. Чтобы реализовать замечательную функцию переноса строк, они придумали посылать окну (или его элементу) сообщение, чтобы оно само переформатировало себя, навставляв специальных символов. Чтобы эти символы отличить от нормального перевода строки, они придумали последовательность 0d, 0d, 0а. Чтобы она не попадала в файл, перед сохранением все такие коды удалялись, а после сохранения добавлялись обратно.
Позже, когда делали windows ХР, элемент стал сам всё переносить как надо, и ему уже не нужно было это сообщение. Однако, никто уже не помнил, зачем оно было нужно, и поэтому решили на всякий случай оставить как было. Тем более, вроде бы всё работало, а проблем после сохранения никто не заметил. С тех пор этот код так и остался, дойдя до самых последних версий Windows 7 и 8. Десятку я не ставил, но скорее всего, там он тоже есть.
Перейдем теперь к исправлению ошибки. После сообщения 0С8h посылается ещё OB1h, а это EM_SETSEL — установка выделения. Похоже, выкидывать эту подпрограмму целиком всё же неправильно, да ещё там есть какой-то непонятный вызов в начале. Поэтому лучше удалить только первый вызов SendMessage, или поменять его параметр с 1 на 0, или изменить переход на другой адрес, чтобы после проверки переменной [0FFA40054h] сразу переходить ко второму вызову. Вариантов много, но результат будет одинаковый.
Где же здесь параметр, равный 1? Всё очень просто — он в регистре r8. Для сокращения кода компилятор никогда не использует прямую пересылку нуля в регистры. Такая команда занимает б байтов: 2 байта код операции, 4 байта — 32-битный ноль. Вместо этого регистр XOR-ится сам с собой, в итоге получается ноль, и это занимает всего 3 байта. После этого r9, который равен нулю, пересылается в r8 с добавлением единицы (выделена зеленым). Эта операция тоже занимает всего 4 байта. Вот эту зеленую 1 нам и надо поменять на 0, и тогда текст не будет портиться.
А теперь найдём эту же процедуру в 32-битной версии блокнота. Если не хочется повторять все те же манипуляции с отладкой, её можно найти простым поиском числа 0C8h.
Как видим, совершенно аналогичный код, только 32-битный. Теперь, чтобы исправить ошибку, осталось только найти это место в ехе-шнике и поменять нужный байт. Перед этим не забудьте стать владельцем файла и дать себе права на его изменение.
64-битный notepad.exe (193536 байт) поменять байт по адресу [80FC] с 1 на 0
32-битный notepad.exe (179712 байт) поменять байт по адресу [6FC8] с 1 на 0
Не сомневаюсь, где-то в недрах майкрософтовского кода еще много таких мест, где спят древние баги, которые, скорее всего, никто никогда не исправит. Нам остаётся только надеяться, что все они такие же безобидные как этот, и ничего страшного не случится, когда они будут перенесены в следующую операционную систему, которую с удовольствием установят себе пользователи по всему миру.
kentastik
Или я что-то делаю не так или в десятке такого бага нет — yadi.sk/i/kW8wzzDDiFMhH
wapmorgan
Сначала сохраните, а потом уже меняйте размер.
Есть баг
kentastik
точно, поторопился :)
Chijikson
Подтверждаю, в 10 такого бага не наблюдается.
Nikobraz
Win10, баг наблюдаю
amdf
Ещё у notepad.exe есть секретный ключ в командной строке, который вызывает странное поведение.
notepad /.SETUP
turbo_exe
а что происходит при таком ключе?
middle
происходит странное поведение.
xpert13
На окно невозможно навести фокус. Как только кликаешь на него — оно прячется. По Alt+Tab так же нельзя переключится, его банально нету в списке
EvilFox
Нашёл такую страницу, а там:
stas404
Подозрительная активность.
perfectdaemon
Вы наверняка знаете, какой антивирус вас спасет
ForeverYoung
Предлагаю баг на исправление — выделяю строчки в текстовом файле, начиная снизу, двигаясь вверх (с shift'ом). Переключаюсь в другую программу, потом обратно, опять зажимаю shift — курсор уже внизу блока. Windows XP, другие не проверял.
lolmaus
Предлагаю баг на исправление: bugs.launchpad.net/ubuntu/+bug/1.
bodqhrohro
Чем-то напоминает проблему с переносом текста в Opera Mini. Только там переносы не временные, а самые что ни на есть обычные, и при копировании текста их приходится вручную заменять пробелами или удалять. Что характерно, для новых версий обновляется и формат OBML, но воз и ныне там, хотя обратную совместимость, казалось бы, поддерживать не нужно.
Gorodnya
У меня в Excel на работе нельзя лист назвать словом с большой буквы «Ж» ) Другие буквы он принимает в начале слова, эту — нет, «Ж» в названии первой буквой может быть только маленькой)
xpert13
Судя по всему оно вообще не принимает большую «Ж», ни в начале, ни в середине
Gorodnya
Почему же, принимает строчную вначале и дальше нормально.
xpert13
Office 2013 — при попытке ввода в имени листа большой «Ж» (Shift+Ж) ничего не происходит, вне зависимости от того где находится курсор, проверил несколько раз. Но что самое интересное, так это то, что CAPS, а потом «ж» ставит большую «Ж» (опять таки вне зависимости от положения курсора, в том числе и в начале).
Gorodnya
Хм. Странно. Завтра проверю: кажется, у меня её можно было установить с зажатым шифтом (главное, чтобы не первой). Но согласитесь, всё равно странно — это же не твёрдый знак, не мягкий. Единственный вариант, который мне приходит в голову (но наверняка это просто совпадение) — буква находится на клавише с двоеточием в английской раскладке, поэтому и невозможно.
xpert13
Кстати да, вы правы: единственные клавиши в буквенном рядку клавиатуры, которые не добавляют символы с зажатым шифтом — это «Ж»(английская клавиша ":") и "," (английская "?"). В обеих случаях не ставится и в русской и в английской раскладке и в обеих случая то, что находится в русской раскладке можно добавить через копи-паст
khim
Почему не вставляется в английской раскладке — понятно (эти символы запрещены в именах файлов), а вот кто и каким местом написал проверку так, что она не зависит от раскладки — науке неведомо.
ID_Daemon
Они сначала отбрасывают 13 комбинаций по скан-коду, в том числе shift-Ж, а потом уже фильтруют запрещенные символы. То есть если убрать этот скан-код из списка, то 'Ж' можно будет ввести, а ':' по-прежнему нельзя, я проверил. Думаю не стоит по этому поводу писать статью, как это найти и где исправить.
ID_Daemon
Как оказалось, всё было сложнее — habrahabr.ru/post/264313
SVlad
Если она ставится с caps, но не ставится с шифтом, то, похоже, это какой-то хоткей «shift + ;» который перехватывает события клавиши.
dj_raphael
её нельзя туда напечатать но можно вставить
petuhov_k
У меня разрешает. Office 2013 en, Win7 en.
dMetrius
Можно вставить с помощью Alt+134 в русской раскладке.
habrastorage.org/files/e21/fdd/326/e21fdd326fba4c12ac97bb83d9b1f2cc.png
mayorovp
Уже где-то на хабре была статья с разбором.
Кажется, такое происходит, если первое нажатие любой клавиши при активном Excel выполнялось при включенной английской раскладке. В таком случае комбинация SHIFT+; оказывается заблокированной (потому что двоеточие — невалидный символ для названия листа), русская же буква «Ж» блокируется вместе с ним заодно.
Mingun
Да вот же она, написана как раз в «ответ» на родительский комментарий автором этой же статьи :)
mayorovp
Хм, даже и не заметил как месяц прошел… :)
roboter
Ещё баг на исследование.
Заметил нелогичное поведение иконок на десктопе.
Иконки появляются на десктопе столбиком, но, если выделять с шифт то выделяются по строкам.
Заметил когда случайно распаковал зип на дескоп и хотел удалить.
Mulin
Есть еще один забавный баг, который никто и не думает исправлять. Во всех Windows что я ипользовал, в трее сохраняется значек закрытой программы до тех пор, пока не проведешь по нему мышкой. С чем это связано не знаю, но как-то где-то и от кого-то слышал такую информацию, что, дескать, в винде единственное что поддерживается на уровне железа видеокартой, это курсор мыши. Уж не знаю что это значит и правда ли это, но как-то навевает.
EvilFox
Насколько помню, это происходит потому что проводник подписывается на событие программы касаемо значков в области уведомления, если программа завершается неправильно то событие разрегистрации значка не приходит, наведение указателем иницирует какую-то функцию где видимо проверяется существование процесса. Что им мешало раз в некоторое время дёргать проверку существования процессов хз.
cjfynjy
MrShoor
А эксепшн бросает / код ошибки возвращает кто? Разве не код, проверяющий существование процесса?
a553
Это происходит, если насильно убить процесс, не отправляя ему сообщений о терминации. Нет сообщений — нет и обработчиков событий, вот иконка и не пропадает.
Mulin
В том-то и баг, что это не всегда обязательное условие. Иногда я подозреваю Nvidia, с радеонами таких проблем вроде не замечал.
a553
Видимо у вас какой-то обработчик вылетает по таймауту. Антивирус, драйвер клавиатуры или мыши, ещё что-нибудь такое.
Mulin
На трех поколениях процессоров и 6 различных версиях Windows? Тут скорее биополе у меня того-этого)).
a553
Ну, может вы смотрите на него как-то не так (шутка конечно). У меня тоже парк машин и нигде спонтанного проявления бага не было :)
Bringoff
У меня такое постоянно и с разными программами, которые я «насильно» не завершаю. И кстати, у меня в ноуте интел и радеон видяхи, нвидиа отсутствует.
a553
Да у меня тоже куча сетапов со всевозможными конфигурациями. И везде баг проявляется только с насильным убийством через таск менеджер. Может, какое-то конкретное приложение это делает. Что-нибудь сильно внедряющееся в систему типа AltDrag или Punto Switcher (не они).
Зато у меня на ноутбуке периодически выбранный элемент на таск баре «подвисает» — система думает, что мышь на него всё время наведена. Баг пережил две чистых переустановки системы 8 > 8.1 > 10. Подозреваю какой-то софт от вендора.
TheRaven
Win 7 x64, Intel, Nvidia
Стабильно наблюдаю этот баг при использовании Mozilla Thunderbird. Когда приходит письмо генерится значок и оповещение, после закрытия программы значок остается. При чем их можно несколько накопить.
silvansky
Скорее, это баг в Thunderbird, может туда зарепортить?
Я остающиеся иконки наблюдал много раз ещё в XP, но обычно это было при неправильном завершении программы. Бывало и просто так, кажется, но это, видимо, из-за кривизны софта.
Когда я делал мессенджер под винду с иконкой в трее, тоже нарывался на этот баг при каждом креше мессенджера или остановкой в дебаге. И тоже накапливал, бывало, 5-10 значков, убиваемых одним привычным взмахом мышки по трею.
silvansky
Разумеется, меня это бесило. И я не понимаю, почему MS не сделали эту работу за меня. В OS X я наблюдал подобное, но значок в трее висел после снятия программы от силы секунд 5-10, видимо, всё же там таймаут есть системный. Хотя и тут не всё гладко: иногда значок пропадает, а место от него остаётся, и убрать его можно лишь кликом мыши.
TheRaven
Возможно их баг, отписался на support@mozilla-russia.org
Посмотрим что ответят.
edogs
Нам всегда помогало при такой проблеме отключить режим переноса строк, а потом снова его включить.
evocatus
А если написать в Microsoft и попросить исправить?
varnav
Теперь ведь есть windows.uservoice.com
spmbt
Всегда помогало пользоваться другим текстовым редактором.
spmbt
Почему? С чем не согласны? В самом деле же помогало. Сумма багов и неудобств. У Notepad есть ещё более мощный баг — непоказ LF как перевода строки, благодаря чему пользоваться им почти не приходилось — сразу заменялся на AkelPad и другие более ранние аналоги — BrEd3, UE32. Плюс заворот строк делает несколько нетрадиционно (то ли на минусах не заворачивает, то ли на подобном), поэтому вид строк с заворотами отличается от всех других редакторов. И зачем таким пользоваться или исправлять, если установить дружественный и нормальный — крайне просто? Никогда проблемы, как с Vim не возникает, когда нельзя что-то установить на удалённый сервер. Всякая установка Windows предполагает доустановку: редактор, Эксплорер, Калькулятор, Просмотр картинок, видео. Иногда — редактор реестра и донастройку. Это как 2*2.
Kanick
Очевидно, с тем, что пост не о том, чем кому-то пользоваться, а о баге в популярной программе. Да и калькулятор не всем нужно доустанавливать.
poxu
Таки не популярной, а широкоизвестной :)
Zveroloff
Действительно, а что не так с калькулятором?
Palomnik
Если у вас винда виста, семь, восемь или может даже десять (не проверял), любой редакции, переключитесь на инженерный вид, разделите единицу на число двести пятьдесят два и нажмите на функцию «F-E» (она в левом нижнем углу). Приложение упало. Забавно, что если делить, например, на двести пятьдесят один, то функция отработает корректно. Чисел на которых падает эта функция достаточно много, не одно.
Что, разумеется, означает, что калькулятор необходимо доустановить сторонний — потому что пользоваться этим невозможно! :)
Zveroloff
Не воспроизводится. Win 8.1 x64
TheRaven
Win XP Professional, не воспроизводится.
Win 7 x64, воспроизводится.
TheRaven
Попросил проверить на 8.1 — воспроизводится.
a553
Win 8.1 x64, i7 3770k — нет
Win 10 x64, i5 4200u — нет
EvilFox
Win 8.1 x64 Pro — не воспроизводится. Может в каком-то обновлении исправили?
Palomnik
Я на 32-х битной проверял. Очевидно, что это ошибка с плавающей запятой, так что, разрядность системы может влиять на эту ошибку, как мне кажется.
ID_Daemon
Нет, все вычисления там целочисленные, и ошибка происходит от бесконечной рекурсии. Этот баг уже был проанализирован www.exploit-db.com/docs/30416.pdf
MaximChistov
падает) Win 7 x64
Bringoff
Windows 10 не воспроизводится, ибо калькулятор там полностью переписали, судя по всему :) Старого я в системе не обнаружил.
olekl
А еще постоянная необходимость виды калькулятора переключать. Т.к. в програмерском невозможно обычное нецелочисленное деление выполнить.
maybe_im_a_leo
Мне лично в notepad очень не нравится как Ctrl-Z отменяет само себя. Т.е. отмена возможна на один шаг только.
Может там тоже такой же досадный баг, до которого нет никому дела…
Kozack
Всегда помогало пользоваться другой ОС.
Kanick
Да, этот баг — это что-то. Когда и в Windows 8 его увидел, захотелось плакать.
Тут же смешно что. У Микрософта дофига сотрудников — и что, никто из них не пользуется Блокнотом в режиме с переносом по словам или не мог сделать баг-репорт? Ох уж эта неповоротливость крупных компаний.
andreishe
Простите, а каков по вашему мнению сценарий использования блокнота сотрудником Microsoft?
SkidanovAlex
Как бывший сотрудник Microsoft, который пересекался с другими сотрудниками Microsoft, могу вам сказать, что как и все, сотрудники Microsoft иногда используют блокнот.
AllexIn
С переносом строк? Это зачем?
Mr_well
Перенос по словам удобен когда вы пишите литературный текст. Из всех примеров использования блокнота сотрудниками MS я заметил только редактирование скриптов и создание быстрых заметок. И там и там перенос по словам не используется.
Сам пользуюсь блокнотом практически каждый день для снатия форматирования когда надо текст скопипастить, например из браузера в аутлук ну или подправить какие конфиг-файлы.
raacer
А что, Ctrl+Shift+V не снимает форматирование?
Mr_well
В аутлуке/линке не работает. Для других офисных продуктов есть гайды как настроить горячие клавиши для этого действия, но это уже костыли. В LotusNotes помнится надо было какую-то dll прикрутить.
А блокнот это железный вариант вот уже больше 10 лет для меня.
ploop
Один из костылей — плагин для браузера, копирующий текст без форматирования. К примеру:
А так да, простым блокнотом или другим текстовым редактором.
safari2012
в офисе (включая outlook) хорошо работает Ctrl+Alt+V
Mr_well
Работает, но это спец. вставка. В линке она действительно убирает форматирование, но в других продуктах вылетит меню.
safari2012
Не понял проблемы. В аутлуке, word-e и т.п. действительно вылезает меню спец.вставки, выбираешь там «неформатированный текст» и задача решена.
Mr_well
Да нет никакой проблемы, есть привычка. Ctrl+V это всегда вставка текста из буфера. А вставка неформатированного текста может поддерживаться горячими клавишами, а может и нет. Где-то это Ctrl+Shift+V, где-то Ctrl+Alt+V. А блокнот, он всегда блокнот. В любом случае топик не про это.
darkdaskin
С Punto Switcher во всех программах работает Ctrl+Win+V (можно сменить).
qwerty1023
Пользуюсь блокнотом еще со времен Windows 95, но как-то не разу не приходилось в нем включать режим переноса по словам. Честно говоря до этого даже не подозревал, что там такой режим есть :). И пользуюсь блокнотом при этом очень часто.
Zveroloff
Пользуюсь Windows уже лет 20, в т.ч. Блокнотом. Про этот баг узнал из этой статьи.
Ununtrium
Извините конечно, но когда есть нормальные редакторы типа Notepad++, стандартный блокнот ни один опытный юзер (тем более программист) в своем уме использовать не станет. При условии, что можно ставить сторонний софт, конечно.
Для любых заметок WordPad раз в 10 удобнее.
Smerig
Да ладно? Вообще не перевариваю notepad++. Когда хватает обычного блокнота — использую его, когда не хватает — VS.
rock
Месье знает толк в извращениях.
Ole
Это да. Но когда ты приходишь к бухгалтеру, чтобы помочь ему отправить бухгалтерскую отчетность, то не станешь ставить ему Notepad++ только для того, чтобы исправить в XML-файле отчетности пару символов.
Приходится открывать notepad и править XML-файл там. А строки там бывают очень большой длины.
gnmb
Notepad ставит время+дату на F5. Только ради этого и использую. А для сохранения есть комба Ctrl+(S, A).
Vokkz
Нашёл баг в Windows 10, зарепортил в инсайдер хабе, но результата пока никакого.
В трее среди системных значков есть индикатор ввода, который показывает РУС или ENG. Из-за того, что я пользуюсь Punto Switcher, индикатор этот привык отключать, ибо у Punto есть собственный.
Так вот, после перезагрузки Windows, системный индикатор возвращается на место. Всегда. Проверял как Home, так и на Pro-версиях, как на русской редакции, так и на американской — баг есть везде.
silvansky
Этот баг я ещё в XP ловил.
mayorovp
На XP этот индикатор сам собой включается даже если уже был включен…
vbif
А ещё, он до сих пор не понимает ctrl+backspace
nehaev
Всегода недоумевал, почему так происходит в блокноте. Теперь наконец все стало на свои места. Спасибо за такое подробное расследование!
Londoner
Просто оставлю это здесь
vbif
Всего каких-то 8 лет против более чем 14
khim
Вы б ещё на сам баг №20786 взглянули! Он из разряда вот этих: начиная с версии MySQL 5.1.11 информация, которая раньше терялась начала запоминаться в дампе. Что, разумеется, немедленно испортило кому-то жизнь. Это совсем другая история, нежели то, что в здешней статье обсуждается!
Psychosynthesis
У меня баг не воспроизводится. Файл сохранял, пересохранял, как только не изгалялся — глюка нет, строки разрезаются при уменьшении окна и возвращаются на место при увеличении.
ЧЯДНТ?
vbif
А попробуй сначала уменьшить окно, потом сохранить, а потом увеличить.
Psychosynthesis
Попробовал. Уменьшает, сохраняется уменьшенный вариант форматирования, после этого растягивание окна эффекта не даёт, а уменьшение и последующее растягивание работают корректно. Бага нет.
vbif
Так в том-то и баг, что после сохранения растягивание окна должно давать эффект.
Psychosynthesis
Окей, я понял.
Мне просто казалось такое поведение логичным.
safari2012
К стати, Microsoft планирует включить Notepad в Windows Store.
Можно будет все баги зарепортить туда в отзывы и наставить всем сообществом по 1*.
Пусть попробуют не отреагировать :)
delure
Баг с периодическим залипанием ctrl, т.е. клавиша физически не нажималась, но система считает, что клавиша зажата. Закономерности возникновения не выявил. Лечится многократным нажатием сей клавиши.
EvilFox
Скорее всего клава отвалилась (провод где-то перебит) в момент нажатия клавиши. Ещё такое можно словить с тимвиевером.
В остальных случаях не наблюдал.
miriarder
«В rcx у нас 104, это непонятно что»
На самом деле 104 это hFile типа HANDLE. Что бы понять параметры функции достаточно посетить страницу по API и Calling convention.