Layered cmd (2 adontz) - WIN API

Здравствуйте, kero, Вы писали:

A>>>>Любая NT поддерживает Layered Windows
M>>>Расскажите, как мне стандартными средствами Windows 2000 сделать полупрозрачную консоль [...]
A>> [...] Собственно даже самому написать делов на пол-часа.
K>Не покажете ?

Со стандартной консолью (которая CMD.EXE) такого никак не сделать. Windows очень сильно защищает консольные окна, на них нельзя, например, вешать клавиатурные хуки. Но, ничто не мешает сделать своё окошко, а CMD.EXE передавать весь ввод-вывод. Так же во всех запускаемых процессах можно перехватывать вызовы консольных функций, чтобы поддерживать задание цвета символов и размера консоли. Делов, конечно, не на пол-часа (это я погорячился) но за день написать вполне реально. Естественно, такая консоль не будет защищена Windows от клавиатурных хуков.

В принципе, я не исключаю что можно как-то заставить SetWindowLong работать с консольными окнами, хотя это и сомнительно.

Здравствуйте, adontz, Вы писали:

A>Со стандартной консолью (которая CMD.EXE) такого никак не сделать

Так потому и спросил (спасибо, что ответили)...

A>В принципе, я не исключаю что можно как-то заставить SetWindowLong работать с консольными окнами, хотя это и сомнительно.

Ну, SetWindowLong можно в некотором роде "обойти", назначая cmd-окну layered папу (SetParent)...

Но в общем — получить четкое доказательство того, что в Win32 layered консоль невозможна, было бы не менее интересно, чем саму такую консоль

K>Ну, SetWindowLong можно в некотором роде "обойти", назначая cmd-окну layered папу (SetParent)...

Просто первая примерка, с неподшитой подкладкой и прочими недоделками, перемещать — с кнопки таскбара.

Здравствуйте, kero, Вы писали:

Шикарно!

Про родительское окно я несколько не догадался.

дело не в "защите" а в том что консольные окна в винде рисуются полностью в ядре, без участия юзерспесовского кода в user32.dll

Здравствуйте, adontz, Вы писали:

A>Шикарно!

Спасибо на добром слове

Здравствуйте, Аноним, Вы писали:

А>дело не в "защите" а в том что консольные окна в винде рисуются полностью в ядре, без участия юзерспесовского кода в user32.dll

Да, но доказывает ли это одно это невозможность layered console ?
Ведь вот как легко присобачить к консоли, скажем, регион...

K>>Ну, SetWindowLong можно в некотором роде "обойти", назначая cmd-окну layered папу (SetParent)...

K>Просто первая примерка, с неподшитой подкладкой и прочими недоделками, перемещать — с кнопки таскбара.

На win2k не работает.

K>>Просто первая примерка, с неподшитой подкладкой и прочими недоделками, перемещать — с кнопки таскбара.

AS>На win2k не работает.

К сожалению, win2k сейчас не имею. Поэтому просьба пояснить: "не работает" — в смысле вообще не запускается, или консоль не удочеряется, или что ?

Вот этот тестовый вариант чуть почище + скомпилен без merge итд, — как с ним-то дела на 2k ?

K>>>Просто первая примерка, с неподшитой подкладкой и прочими недоделками, перемещать — с кнопки таскбара.

AS>>На win2k не работает.

K>К сожалению, win2k сейчас не имею. Поэтому просьба пояснить: "не работает" — в смысле вообще не запускается, или консоль не удочеряется, или что ?

Первый вариант вел себя странно. Под родительским окном не перерисовывались кнопки, оставались следы на других приложениях.
Этот ведет себя не менее странно, см скриншот

тута — 12 кб.

При перетаскивании консоли внути родительского окна остаются следы везде — на окнах, десктопе и т.п. В общем, объяснить сложно — это надо видеть

Видимо, действительно, частично консоль перерисовывается внутри win32k, поэтому, как любил говорить Ося Бендер — ваше дело не выгорит...

K>>>>Просто первая примерка, с неподшитой подкладкой и прочими недоделками, перемещать — с кнопки таскбара.

AS>>>На win2k не работает.

K>>К сожалению, win2k сейчас не имею. Поэтому просьба пояснить: "не работает" — в смысле вообще не запускается, или консоль не удочеряется, или что ?

AS>Первый вариант вел себя странно. Под родительским окном не перерисовывались кнопки, оставались следы на других приложениях.
AS>Этот ведет себя не менее странно, см скриншот

AS>тута — 12 кб.

AS>При перетаскивании консоли внути родительского окна остаются следы везде — на окнах, десктопе и т.п. В общем, объяснить сложно — это надо видеть
AS>Видимо, действительно, частично консоль перерисовывается внутри win32k, поэтому, как любил говорить Ося Бендер — ваше дело не выгорит...

Видимо, зря я не выделил жирным-прежирным, что "просто первая примерка", что перемещать — с кнопки таскбара...

В приложенном коротеньком исходнике второго варианта не трудно же заметить, что код перемещений консоли внутри родительского окна — откровенная рыба, причем — дважды закомментированная

Т.е. меня интересовало не движение консоли внутри нового родителя, а движение родителя по экрану.

Т.е. я рассчитывал, что:
в меню соответствующей кнопки на таскбаре выберете и нажмете строку "Переместить", потом нажмете одну из клавиш-стрелок,
а потом — не прижимая кнопку мышки — подвигаете мышку (и соответственно — окно родителя), причем хорошо бы не по пустому экрану, и не с однородным фоном...

Интересует — глючит ли на 2k такое действо ? И вообще — что с полупрозрачностью родителя и удочеренной консоли ? Вот бы какой скриншотик...

P.S. Еще раз: не надо перетаскивания консоли внутри родительского окна

. Они и по идее-то должны быть вроде как единым целым.

K>Интересует — глючит ли на 2k такое действо ? И вообще — что с полупрозрачностью родителя и удочеренной консоли ? Вот бы какой скриншотик...

K> P.S. Еще раз: не надо перетаскивания консоли внутри родительского окна

. Они и по идее-то должны быть вроде как единым целым.

Изначально консоль я там не перетаскивал, а перетащил из-под нее окошко архиватора. При перетаскивании из таскбара — на экране остается заголовок консоли + если там было что введено, то и часть этого.
Сама консоль с экрана исчезает при деактивации окна. Соответственно, прозрачность только сначала — при запуске. При любых действиях вне окна — все становится немедленно плохо + остаются следы на экране. На winxp таких проблем нет.
В общем, на вин2к не работает совсем.

AS>В общем, на вин2к не работает совсем.

Мда, ясно. Спасибо за экспертизу

P.S. Все это лишний раз показывает, как все-таки много глюков вокруг layered на 2k. Вот вспомнился еще один, препротивнейший:
если у диалога — WS_EX_LAYERED + SetLayeredWindowAttributes + (LWA_ALPHA + LWA_COLORKEY), а у его Edit-а — ES_MULTILINE + WS_V/HSCROLL,
то не дай бог поскроллить текст такого Edit-а ! Наверняка WS_EX_COMPOSITED ввели в XP именно как лекарство от этого глюка.

Здравствуйте, kero, Вы писали:

AS>>В общем, на вин2к не работает совсем.

K>Мда, ясно. Спасибо за экспертизу

K>P.S. Все это лишний раз показывает, как все-таки много глюков вокруг layered на 2k. Вот вспомнился еще один, препротивнейший:
K>если у диалога — WS_EX_LAYERED + SetLayeredWindowAttributes + (LWA_ALPHA + LWA_COLORKEY), а у его Edit-а — ES_MULTILINE + WS_V/HSCROLL,
K>то не дай бог поскроллить текст такого Edit-а ! Наверняка WS_EX_COMPOSITED ввели в XP именно как лекарство от этого глюка.

что будет то? Нам интересно...

Вижу тут много юмористов

чтож откройте исхоники винды и убедитесь что в винде 3 "графические" подсистемы — GDI, User и Console

Здравствуйте, Константин Л., Вы писали:

K>>P.S. Все это лишний раз показывает, как все-таки много глюков вокруг layered на 2k. Вот вспомнился еще один, препротивнейший:
K>>если у диалога — WS_EX_LAYERED + SetLayeredWindowAttributes + (LWA_ALPHA + LWA_COLORKEY), а у его Edit-а — ES_MULTILINE + WS_V/HSCROLL,
K>>то не дай бог поскроллить текст такого Edit-а ! Наверняка WS_EX_COMPOSITED ввели в XP именно как лекарство от этого глюка.

КЛ>что будет то? Нам интересно...

Прочувствовать можно и на XP, попробуйте эту комбинацию (без WS_EX_CPMPOSITED)

Короче, система тормозит так, что кажется — виснет.

(кстати, пассаж о "наверняка" — конечно, шутка)

Покопался сам

. В пространство консольного процесса не загружается user32.dll, как минимум прямым следствием для этого является невозможность работы хуков поставленных через SetWindowsHookEx с ним. Далее. Консольное окно реально создается и отрисовывается csrss'ом (который работает под system аккаунтом), в то время как GetWindowThreadProcessId возвращает пид и тид консольного процесса (те процесса который и не создавал вобщемто окно). Короче это все туфта на самом деле. Проблема в том что созданное окно получается со стилем WS_CHILD а таковые не могут быть layered

А>Покопался сам

Кто там получается со стилем WS_CHILD?

хм в ноликах обсчитался. Не WS_CHILD а WS_CLIPSIBLINGS|WS_BORDER|WS_DLGFRAME|WS_TABSTOP|WS_GROUP|WS_THICKFRAME|WS_SYSMENU
Надо еще покопаться. Окно то создается таки в userspace. Security descriptor'ов на него не стаивться особенных. Что же в нем особенного? Разве что что создано оно одним пидом/тидом а прописано в его инфе другие.

А>хм в ноликах обсчитался. Не WS_CHILD а WS_CLIPSIBLINGS|WS_BORDER|WS_DLGFRAME|WS_TABSTOP|WS_GROUP|WS_THICKFRAME|WS_SYSMENU
А>Надо еще покопаться. Окно то создается таки в userspace. Security descriptor'ов на него не стаивться особенных. Что же в нем особенного? Разве что что создано оно одним пидом/тидом а прописано в его инфе другие.

Особенного в нем то, что оно не child, а overlapped. Скорее всего, в win2k нормально работают только layered родители + WS_CHILD дети.
Заголовки для overlapped в win2k отрисовываются в win32k.sys, вероятно, там же сделаны костыли и для layered. Так что проблема скорее всего не в юзер.
Да, и самое главное — класс окна имеет стиль CS_OWNDC.

WS_EX_LAYERED Also, this cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.

AS>Особенного в нем то, что оно не child, а overlapped. Скорее всего, в win2k нормально работают только layered родители + WS_CHILD дети.
overlapped пофиг. Вообще говоря это обычное окно и есть

AS>Да, и самое главное — класс окна имеет стиль CS_OWNDC.
А слона то я и не заметил

Все тогда элементарно должно фиксится на самом деле, всего делов написать длл-перехватчик CreateWindowExW и засунуть ее в csrss

AS>>Да, и самое главное — класс окна имеет стиль CS_OWNDC.
А>А слона то я и не заметил

Элементарно — не фиксится. Если сделали OWNDC, значит, на то были свои причины. Например, одновременный доступ из разных потоков или еще что. А во-вторых, просто так засунуть хук в csrss вам тоже не дадут. В общем, проблема нормально под win2k не решается.

Здравствуйте, Andrew S, Вы писали:

AS>>>Да, и самое главное — класс окна имеет стиль CS_OWNDC.
А>>А слона то я и не заметил

AS>Элементарно — не фиксится. Если сделали OWNDC, значит, на то были свои причины. Например, одновременный доступ из разных потоков или еще что. А во-вторых, просто так засунуть хук в csrss вам тоже не дадут. В общем, проблема нормально под win2k не решается.
Дадут,я засовывал. насчет OWNDC — надо будет просто поэкспериментировать. Просто времени ща нету(

AS>>Элементарно — не фиксится. Если сделали OWNDC, значит, на то были свои причины. Например, одновременный доступ из разных потоков или еще что. А во-вторых, просто так засунуть хук в csrss вам тоже не дадут. В общем, проблема нормально под win2k не решается.
А>Дадут,я засовывал.
Поясню как именно я засовывал. Через OpenProcess/CreateRemoteThread загружал свою длл во нужные процессы и она делала банальный API hooking. Проблемы тольео с smss.exe тк это не win32 процесс. в csrss инжектится на ура, главное — получить права на открытие системных процессов, что под админом не проблема (поднять дебажные привилегии), а под сервисом и так есть.

AS>Да, и самое главное — класс окна имеет стиль CS_OWNDC.
AS>

WS_EX_LAYERED Also, this cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.

А вот и нет, это НЕ самое главное

Мне уже доводилось (на другом форуме) приводить контрпример, причем — из практики MS же:

помощник в MS Word 2002 — это как раз WS_EX_LAYERED+CS_OWNDC.

Так что MSDN тут подвирает

А>Проблема в том что созданное окно получается со стилем WS_CHILD а таковые не могут быть layered

Опять привет MSDN.
А вот и могут, см. тот же контрпример . А лучше — этот

AS>>Да, и самое главное — класс окна имеет стиль CS_OWNDC.
AS>>

K>WS_EX_LAYERED Also, this cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.

K>А вот и нет, это НЕ самое главное

K>Мне уже доводилось (на другом форуме) приводить контрпример, причем — из практики MS же:

K>помощник в MS Word 2002 — это как раз WS_EX_LAYERED+CS_OWNDC.

То, что это работает в одном случае, совершенно не означает, что будет работать во всех. Кто знает, как именно реализовано рисование в помощнике, и чем это отличается от cmd. Однако я вижу то, что вижу — прозрачное окно в качестве родителя для cmd на win2k не канает, тогда как на XP все работает нормально. А что там будет в висте — вообще непонятно, мне даже смотреть там это неохота, поскольку хочется просто плеваться от ейной красоты... Кроме того — откуда вы знаете, каким образом использует layered помощник? Я там, например, альфы не вижу, а вижу колоркей, а значит, почти наверняка, это UpdateLayeredWindow, что прилично отличается от извращения с cmd.

K>Так что MSDN тут подвирает

MSDN много где "подвирает", однако, в большинстве случае, если начать разбираться, выясняется, что этому есть вполне интересные причины...

PS Честно говоря, не вижу никакой практической применимости от ковыряния с альфой, разве только вытаскивание очередных багов в user\windowing — ну так их и так известно много, а m$ на это дело глубоко положить... Кому нафиг нужен прозрачный cmd, да и вообще прозрачные окна вне контекста приложения? А уж в самом приложении прозрачность можно и windowless реализовать, и будет работать везде, в отличие от.. Имхо, все эти изыски со слоями, а теперь еще и 3d в виста — от лукавого

Лучше б, блин, реализовали нормальную подгрузку веток реестра для имперсонируемых потоком пользователей — куда не ткни в вин32, одни заплатки и костыли. А в m$, блин, GUI рабочего стола улучшают шейдерами, вбухивая в это дело кучу времени, сил и средств. К чему все это, а?

А>>Проблема в том что созданное окно получается со стилем WS_CHILD а таковые не могут быть layered

K>Опять привет MSDN.
K>А вот и могут, см. тот же контрпример . А лучше — этот

Оба примера на win2k не работают. Альфы нет и в помине, а глюки напоминают cmd. Выводы — может, стОит таки прислушиваться иногда к MSDN?

Вот скриншоты. Первый — сразу после старта, а второй — после перемещения окна-родителя.
Адын
Два

Сделал тестовую версию в свободную минутку на основе инжекта в csrss.exe . К сожалению полных сырцов приложить не могу ибо для инжекта юзается наш проприетарный код (писать его с нуля лень). Но основная логика и бинарник — в архиве

Требует админа. Насчет 2к — не проверял. Под ХР — торрррмозит безбожно. Заметил минорные глюки перерисовки (но думаю фиксабельные). SetWindowLong так же фэйлится(думаю изза приколов с создавшим окно процессом), SetLayeredWindowAttributes работает на ура. Развивать врядли буду если не найду метода побороть тормоза.
http://slil.ru/23887383

поковырялся еще чутарь и похоже нашел чего тормозит и глючит прорисовка. Консольнок окно инвалидейтится полностью при любом изменении. А глюки прорисовки изза того что вывод содержимого буфера консоли делается не на окно, а прямо на экран через спец вызовы в указанную позицию экрана. Так вот винда сделана

не все ок рисуется таки на hdc, Значит не безнадежно

K>>помощник в MS Word 2002 — это как раз WS_EX_LAYERED+CS_OWNDC.

AS>То, что это работает в одном случае, совершенно не означает, что будет работать во всех.

Совершенно не означает. А кто здесь такое утверждал ? Речь о другом: когда в MSDN читаем

WS_EX_LAYERED Also, this cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC

то стоит держать в уме, что MSDN-овский и обычный cannot — две большие разницы.
Кстати, в упомянутом выше другом форуме я даже предложил "поправку":
>WS_EX_LAYERED — как нельзя, так и можно использовать совместно со стилями CS_OWNDC и CS_CLASSDC .

Короче, цитаты из MSDN — не всегда надежная опора. К сожалению.

AS>Кроме того — откуда вы знаете, каким образом использует layered помощник?

Это что, возражение на то, что WS_EX_LAYERED+CS_OWNDC — НЕ cannot be ?

AS>Я там, например, альфы не вижу, а вижу колоркей, а значит, почти наверняка, это UpdateLayeredWindow, что прилично отличается от извращения с cmd.

В этой вот учебной утилитке отображаются, кроме прочих, и параметры DcOrg, RtVis.
При отсутствии стиля WS_EX_COMPOSITED у видимого WS_EX_LAYERED-окна — непостоянство DcOrg (как и =0 RtVis) говорит о UpdateLayeredWindow,
а если наоборот — то о SetLaeyeredWindowAttributes. Если проверите, то увидите, что не ошибаетесь насчет UpdateLayeredWindow у помощника из Word-а.

Но опять-таки — какое отношение это имеет к качеству формулировок в MSDN ?

AS>MSDN много где "подвирает", однако, в большинстве случае, если начать разбираться, выясняется, что этому есть вполне интересные причины...

Начать разбираться — обязательно, интересные причины — само собой, но факт-то останется фактом: подвирает

AS>PS Честно говоря, не вижу никакой практической применимости от ковыряния с альфой [...]

Сердцу-то не прикажешь...

AS>Оба примера на win2k не работают. Альфы нет и в помине, а глюки напоминают cmd.

Не сыпьте соль на раны, о 2k уж понял из прошлых ваших сообщений...

AS>Выводы — может, стОит таки прислушиваться иногда к MSDN?

Таки прислушиваюсь, только не припомню, где о layered сказано, что на 2k — так, а на XP — этак...

AS>Вот скриншоты. Первый — сразу после старта, а второй — после перемещения окна-родителя.

В отсутствии 2k они мне очень интересны, спасибо.

Andrew,
а не посмотрите ли заодно, имеет ли место на 2k то, что описано (для XP) здесь ?
Ведь это ж все одно к одному...

K>Andrew,
K>а не посмотрите ли заодно, имеет ли место на 2k то, что описано (для XP) здесь ?
K>Ведь это ж все одно к одному...

Не, это разные баги

Я вроде уже говорил по этому поводу — там, похоже, проблема в PaintDesktop. Скажу честно, разбираться во всем этом у меня сейчас просто нет времени, да и причин

там уже все разобрано. Проблема изза того что GetDCOrgEx возвращает позицтю относительно левого верхнего угла ока а не экрана для layered окон. А это в свою очередь изза того что для layered окон создаюся оттедльные участки видеопамяти-спрайти который потом накладываются на общий фреймбуфер

2Andrew S что насчет работы под 2к вот этого: http://slil.ru/23887383

А>2Andrew S что насчет работы под 2к вот этого: http://slil.ru/23887383

Да, так работает. Но вот только по поводу убирать OWNDC, на мой взгляд, чревато непредсказуемыми глюками.

AS>Да, так работает. Но вот только по поводу убирать OWNDC, на мой взгляд, чревато непредсказуемыми глюками.
Вобщемто то говоря понятно зачем там было OWNDC — винда сразу по создании окна берет его DC и потом просто рисует в него. С layered окнами это должно нормально работать без CS_OWNDC

btw у моего способа есть еще один вкусный эффект. Это ведь еще и полноценный сабклассинг консольных окон

А>там уже все разобрано. Проблема изза того что GetDCOrgEx возвращает позицтю относительно левого верхнего угла ока а не экрана для layered окон. А это в свою очередь изза того что для layered окон создаюся оттедльные участки видеопамяти-спрайти который потом накладываются на общий фреймбуфер

Аноним 790 — он же 59, он же 357 ?

Ну, это же только ваши предположения...

Так я не понял: на 2k — есть или нет ?

А>btw у моего способа есть еще один вкусный эффект. Это ведь еще и полноценный сабклассинг консольных окон

Суперклассинг, олднако

А>>там уже все разобрано. Проблема изза того что GetDCOrgEx возвращает позицтю относительно левого верхнего угла ока а не экрана для layered окон. А это в свою очередь изза того что для layered окон создаюся оттедльные участки видеопамяти-спрайти который потом накладываются на общий фреймбуфер
K>Аноним 790 — он же 59, он же 357 ?

Он самый

K>Ну, это же только ваши предположения...
нет. Это анализ утекших исходных кодов w2k фрагмент которых (где определяется позиция куда рисовать на экран через GetDCOrgEx) я вам показал.
Если сразу не догадались могу уточнить:
\private\ntos\w32\ntuser\kernel\dtbitmap.c — xxxInternalPaintDesktop:

BOOL xxxInternalPaintDesktop(
    PWND    pwnd,
    HDC     hdc,
    BOOL    fPaint)
{
    BOOL fRet;

    CheckLock(pwnd);

    if (fPaint) {
        RECT rcOrg, rcT;
        POINT pt;

        /*
         * For compatiblity purposes the DC origin of desktop windows
         * is set to the primary monitor, i.e. (0,0). Since we may get
         * either desktop or non-desktop DCs here, temporarily reset
         * the hdc origin to (0,0).
         */
        GreGetDCOrgEx(hdc, &pt, &rcOrg);        CopyRect(&rcT, &rcOrg);
        OffsetRect(&rcT, -rcT.left, -rcT.top);
        GreSetDCOrg(hdc, rcT.left, rcT.top, (PRECTL)&rcT);

        fRet = xxxEnumDisplayMonitors(
                hdc,
                NULL,
                (MONITORENUMPROC) xxxDesktopPaintCallback,
                (LPARAM)pwnd,
                TRUE);

        /*
         * Reset the DC origin back.
         */
        GreSetDCOrg(hdc, rcOrg.left, rcOrg.top, (PRECTL)&rcOrg);

Как видите PaintDesktop рисует прямо на экран получая координаты через GetDCOrgEx
Даже если бы GetDCOrgEx нормально определял экранные координаты все равно бы отрисовка произошла бы на экран под окном безо всякой прозрачности. Тк про реализацию layered окон я вам уже писал, мои предположения о которой так же подтверждается private\ntos\w32\ntuser, где они кстати даже назвываются спрайтами

K>Так я не понял: на 2k — есть или нет ?
Andrew S говорит есть, я не поверял

А>>btw у моего способа есть еще один вкусный эффект. Это ведь еще и полноценный сабклассинг консольных окон

K>Суперклассинг, олднако

гг надоже, даже такое придумали..

малеьнкий апдейт: http://slil.ru/23893320
пофиксил томрза при перетаскивании (однако некрасивым способом, но вроде работает) и глюки прорисовки при разворачивании окна. Добавил пунктики в системное меню консольного окна для смены уровня прозрачности (по дефолту окна создаются не прозрачные теперь). Прорисовка по прежнему притормаживает, особенно заметно когда юзаешь какой нить FAR, думаю это неизлечимо и возможно зависит от системы (у меня ноут с ATI Mobility Radeon X1400, на ближайшие полтора мец это моя почти единственная рабочая машина)

	От:	kero
	Дата:	01.02.07 12:29
	Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	01.02.07 14:08
Оценка:

	От:	kero
	Дата:	02.02.07 07:52
	Оценка:

	От:	kero
	Дата:	03.02.07 05:52
	Оценка:	39 (2)

От:	adontz	http://adontz.wordpress.com/
Дата:	03.02.07 06:29
Оценка:

От:	Andrew S	http://alchemy-lab.com
Дата:	05.02.07 08:17
Оценка:

	От:	Константин Л.
	Дата:	06.02.07 17:13
	Оценка:

	От:	Аноним
	Дата:	07.02.07 05:59
	Оценка:	15 (1)