как сегодня выяснил я =) бугога не пашет под вистой и под 2000... в смысле нет эффекта "рандомно скачущего курсора", но проц так же грузится (у меня шкалит до 100% и в добавок ядро загружено где-то на 50%) оперативка не грузится вообще. в бездне нашел, что если вместо bugoga написать abassaka - эффект будет такой же. кста, на википедии появилось вполне внятное дополнение... ждем продолжения...



взял там же:

читать у меня:Три дня непрерывного чтения башорга показало, что достаточно написать b и любую букву, и курсор начнет скакать. Так же выяснилось, что удерживание ctrl увеличивает скорость. Там даже кто то дизасм делал))



File: bugoga.exe Path: C:\ Size: 6 Type: Binary



* Entry Point:



00000000: 627567 bound si, [di+67] 00000003: 6F outsw 00000004: 6761 popa



Интересный факт все таки) Имхо) Знатоки ассемблера - разъясните ситуевину)



Во, народ даже исследование провел



Прочитав неоднократно про bugoga в exe-шнике на bash.org.ru и попробывав сам, я задумался - а фигли? Первая идея - символы bu в hex-кодах (В одной из цитат - достаточно "bu" для достижения такого же эффекта) являются неким необходимым хеадером для формата exe. Однако эксперименты показали - достаточно символа b для подвисания консольки и рандомного перемещения курсора. Да и формат exe похитрее. + почему запускается консолька? Тут я вспомнил, что в винде ваще много выполняемых форматов - bat, wsc, vbs, и... досовский com. Вспомнив это, я опять же вспомнил, что эксперементируя со строками, я наткнулся на то, что если написать "Бугага" (по-русски, без кавычек, с болькой буквы), то винда выдает ошибку с сообщзением что процесср нашел неправильный код операции и проч, но! в заголовке - "16-битная система MS-DOS"! ЭТО ФОРМАТ COM. Т.е. винда запуская exe видит, что оный exe не соответствует формату и, в отличие от wine, просто доунгрейдит его до com, которому, видимо, никакой формат не нужен. Ком - это просто набор инструкций процессора, без излишеств. Однако нормальное поведение com'а - это дойти до конца и завершится, а не гадить на принтер, а тут оно зацикливается. От одной буквы! От hex-кода 62.



Рассмотрев повнимательнее "рандомно скачующий курсор" и поведение моего матричного принтера я понял - прога выкидывает ВО ВСЕ ВЫХОДНЫЕ ПОТОКИ пустые строки в случае с "b", а в случае с "bu" что-то типа tab'ов. А в винде есть поток принтера! И курсор скачет просто от того, что виндовая консоль поддтормаживает от такого кол-ва инфы и посему двигает курсор рывками. А принтера, ибо умные, пробелы не печатают, а просто двигают головку. Т.е. в случае с b - двигают понемногу, поэтому, бумага ездит медленно, а с bu - помногу. Вот оно!



Возникает справедливый вопрос "почему от одной буквы такой эффект"? Подозреваю от бага в ms-dos'е винды. Комманда 62 (кто знает ассемблер, что за комманда?), подозреваю, вызывает какую-то системную фичу (прерывание?) передавая ей что-либо (указатель на строку), которая кадает эту (строку?) во все существующие выходные потоки. Однако если переданно ничего не было или переданно что-то не то, фичу глючит и она циклется, а прога честно ждет окончания ее работы. Почему нельзя удаить файл? Это как раз просто - com программы должны заканчиватся на специальную комманду возврата управления (ret?), аки return в Си. А этой комманды нет. В результате, из-за очередного бага в ms-dos'e, даже после убиения процесса, прога остается в памяти. Или эксплорер не разлочивает файл.



За сим очередь любителей ассемблера и дебаггеров - пусть они попробуют запихать это дело в SoftICE (у мну он не встанет - Daemon Tools, а винду переставлять неохота) и посмотреть че там происходит конкретно. И незабудте сообщить о результатах на новый форум психов-программистов - bash.org.ru - Взгляд в Безду!]