A>Кому придется импортировать? Уж не программисту, точно. Авторам fw. Да какая разница, что там импортируется? Главное — работает!
Точно? Вы уверены? За свои слова отвечаете?
Приходится программисту импортировать довольно часто! И, уверен, придёться в будущем.
Гладко в жизни не бывает. Напрмер слабо найти во фрейворке обёрнутую функцию QueryPerformanceCounter? И таких нереализованных фукций сотни!
МЮ>>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться.. A>Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw.
Да ну? Ещё раз спрашиваю, вы уверены? Всегда что-ли?
>Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет.
Если бы всё было реализовано!
A>Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается.
1. Это пока слухи
2. Среди уже развитого много такого, чего нет в FW
A>Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS.
Не скоро. Пока API актуальней.
A>Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
Редкость говорите?
Вы мне с ходу сможете привести хоть одну популярную и требующую производительности программу, написанную на dotNet?
.
Здравствуйте, Andrbig, Вы писали:
A>А вот это не факт. Это сейчас .NET строиттся на winapi, а что будет дальше — неизвестно. Многие winapi функции переправляют вызовы в ядро. Может в следующей версии .NET будет обращаться в ядро напрямик?
A>winapi — такая гнусь, что пора уж от него избавиться. Кто захочет возразить, пусть вспомнит различное поведение одних и тех же функций под NT и 95. Этого "счастья" в winapi навалом. .NET похоронит winapi. Это вопрос времени.
Неужели будут переписывать весь Win API? Я думаю, что дот нет будет основываться на Вин АПИ еще долгое время =)
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Гладко в жизни не бывает. Напрмер слабо найти во фрейворке обёрнутую функцию QueryPerformanceCounter? И таких фукций сотни!
Сотни, не сомневаюсь.
МЮ>Да ну?ещё раз спрашиваю, вы уверены? Всегда что-ли?
Уверен. Все в специфике задачи. Если надо работать с базой, UI и файлами — .NETа хватит. И я в этом уверен. Если же охота увешаться PerformanceCounter-ами — не хватит. NET расчитан на прикладников, а не для того, чтобы лезть в кишки ОС.
МЮ>Если бы всё было реализовано!
Реализовано не все, это не новость. Вопрос в другом — а нужно ли чтобы было реализовано все? В MS немного поучились на своих ошибках и пошли курсом МАКа: система отдельно, приклад — отдельно. .NET — механизм такого разделения. Прога под .NET сможет работать и под *nix, и под МАК — был бы fw. А если реализовать все, включая не-прикладные вещи типа Performance Counter-ов, то никакой тебе совместимости и переносимости. Логично?
МЮ>Не скоро. Пока API актуальней.
Смотря для каких задач. Я пишу Windows Service, работу с БД? с файлами и UI. Ни разу не возникла необходимость использования winapi.
МЮ>Вы мне с ходу сможете привести хоть одну популярную и требующую производительности программу, написанную на dotNet?
Страшно извиняюсь, но при чем тут популярность? Это нынче основной критерий?
Здравствуйте, Mab, Вы писали:
Mab>Это все чистая теория. Когда-нибудь все полезное, что есть в WinAPI, наверняка переползет под FW. Но писать-то приходится сегодня и сейчас. И пока еще очень много вещей, в которых без импорта WinAPI не обойтись.
Вот, более спокойный ответ. Можно задать более спокойный вопрос: нельзя ли огласить список, в каких случаях "не обойтись"? Перечислять функции не стоит конечно , хватит группировки по функционалу (например Perfomance Counter).
Здравствуйте, Andrbig, Вы писали:
A>Уверен. Все в специфике задачи. Если надо работать с базой, UI и файлами — .NETа хватит. A>Смотря для каких задач. Я пишу Windows Service, работу с БД? с файлами и UI. Ни разу не возникла необходимость использования winapi.
Вот! Это всё что входит в круг прикладных задач? Всё остальное, это драйвера что-ли? Что все прикладные программы вписываются работу в Windows Service, работу с БД, с файлами и UI? У меня, например, свой круг прикладных задач, в котором БД, с файлами и UI — процентов 10, но драйверов я тоже не пишу.
A>Прога под .NET сможет работать и под *nix, и под МАК — был бы fw.
В теории да, в реальном мире — увы нет. И в ближайшее время ситуация не изменится к лучшему.
A>А если реализовать все, включая не-прикладные вещи типа Performance Counter-ов, то никакой тебе совместимости и переносимости. Логично?
1. Её (переносимости) и так нет. Пока это только маркетинговый миф.
2. Поэтому и надо знать API, что совместимости всё равно нет, а всё необходимое в dotNet не реализовано.
A>Страшно извиняюсь, но при чем тут популярность? Это нынче основной критерий?
Я извиниюсь в свою очередь, а что критерием является круг ваших собственных задач? Нет!
Под популярностью я имел ввиду общедоступный продукт, а не программу по заказу организации X
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Ух! чувствую эта тема скоро уйдёт в священные войны!
Да нечего тут воевать. Надо просто понять, для чего .NET годится, а для чего — нет.
МЮ>Вот сходу? Rar, 7z — это драйвера или прикладные программы? Почему они на MSVC до сих пор пишутся? МЮ>А VirtualDub, Canopus ProCoder ? А 3d игры? А Антивирус Касперского может тоже на dotNet написан? МЮ>Или это всё тоже драйвера?
Паковщики — уже давно выжали все возможности. Различия между ними по степени есть, но не критичны. На первый план выходят другие параметры. Например, скорость. Не удивлюсь, если узнаю, что кто-нибудь и ассемблером балуется.
VirtualDub, Canopus ProCoder — не знаю что это
3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Антивирусы — интегрируются в систему, чтобы отлавливать обращения к файлам. Хм, даже и не знаю... вроде бы каждое второе приложение так делает... Нет, все же это ближе к драйверам. Точнее, к системному программному обеспечению.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>Вот! Это всё что входит в круг прикладных задач?
У меня — да.
МЮ>Всё остальное, это драйвера что-ли?
Есть еще системное программирование, т.е. написание прог, плотно интегрированных с системой.
МЮ>Что все прикладные программы вписываются работу в Windows Service, работу с БД, с файлами и UI? У меня, например, свой круг прикладных задач, в котором БД, с файлами и UI — процентов 10, но драйверов я тоже не пишу.
А у меня — практически все. Каждому свое... Кстати, если не секрет, из чего состоят оставшиеся 90%?
МЮ>В теории да, в реальном мире — увы нет. И в ближайшее время ситуация не изменится к лучшему.
Вы видите будущее? А как же .NET for Linux?
МЮ>1. Её (переносимости) и так нет. Пока это только маркетинговый миф. МЮ>2. Поэтому и надо знать API, что совместимости всё равно нет, а всё необходимое в dotNet не реализовано.
1,2 — спорно. Это не миф, более того, делаются реальные шаги в этом направлении. Как далеко зайдут эти шаги — вопрос совсем другой.
МЮ>Я извиниюсь в свою очередь, а что критерием является круг ваших собственных задач? Нет!
Очень решительно! Вах! Для меня критерием является заказчик и его желания.
МЮ>Под популярностью я имел ввиду общедоступный продукт, а не программу по заказу организации X
Пока fw не распространится так же широко, как и Windows (вместе с новыми его версиями), говорить о популярности для .NET программ бессмысленно.
Здравствуйте, Andrbig, Вы писали:
A>Паковщики — уже давно выжали все возможности. Различия между ними по степени есть, но не критичны. На первый план выходят другие параметры. Например, скорость. Не удивлюсь, если узнаю, что кто-нибудь и ассемблером балуется.
Тем не менее, это не драйвера.
A>VirtualDub, Canopus ProCoder — не знаю что это
Работа с видео
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Тем не менее игры — вполне прикланые программы.
A>Антивирусы — интегрируются в систему, чтобы отлавливать обращения к файлам. Хм, даже и не знаю... вроде бы каждое второе приложение так делает... Нет, все же это ближе к драйверам. Точнее, к системному программному обеспечению.
1. У касперского есть конечно служба — монитор, но всё остальное там всё равно не dotNet.
2. Тем не менее это лишь мизерная часть программ, которые не являются БД и т.п.
A>Вот, более спокойный ответ. Можно задать более спокойный вопрос: нельзя ли огласить список, в каких случаях "не обойтись"?
Боюсь, я не компетентен составлять такой "список" . Могу лишь сказать, где самому пришлось развлекаться с pinvoke/MC++:
1) Нестандартные контролы. То, что предлагает WinForms, мягко говоря недостаточно. Тот же самый virtual list view пришлось руками делать.
1') Доступ к GDI, которое практически в FW не представлено (разве что ControlPaint-ом). GDI+ не подходил из-за соображений скорости.
2) Управление процессами (запуск с флагом DEBUG_PROCESS, отслеживание расходуемых ресурсов итп). Класс Process здесь малополезен.
3) Memory mapped files. Часть проекта частично делали на MC++ , часть вообще на unmanaged C++ и подцепляли через pinvoke.
Каждый может дополнить этот список в соответствии с собственным опытом
В общем, все очень сильно от задачи зависит, спорить с этим бессмысленно. Пишут же люди на Java без JNI.
Здравствуйте, Andrbig, Вы писали:
A>У меня — да. A>Очень решительно! Вах! Для меня критерием является заказчик и его желания.
И вы поэтому не рекомендуете другим изучать API?
А если я буду другим рекомендовать например не устанавливать linux,потому как я ей не пользуюсь.
A>Есть еще системное программирование, т.е. написание прог, плотно интегрированных с системой. A>Пока fw не распространится так же широко, как и Windows (вместе с новыми его версиями), говорить о популярности для .NET программ бессмысленно. :
Это всё причины знать API.
A>А у меня — практически все. Каждому свое... Кстати, если не секрет, из чего состоят оставшиеся 90%?
Алгоритмы обработки данных. Ещё поддержка существющих программ на С++ написанных давно, ещё без поддержки COM.
Кроме это частенько я занимаюсь низкоуровневым тестированием процессоров, пишу ассемблерные вставки.
A>Вы видите будущее? А как же .NET for Linux?
Я трезво со здоровым консерватизмом смотрю на это. Linux сообщество всё равно будет отставать, всегда. dotNet FW вышел уже довольно давно, а lin до сих пор не может похвостатся полной совместимостью даже с WinForms версии 1.0
A>1,2 — спорно. Это не миф, более того, делаются реальные шаги в этом направлении. Как далеко зайдут эти шаги — вопрос совсем другой.
Не-а, это вопрос тот-же. Стоит ли не знать API ради .Net? Всё равно API знать нужно.
Кстати вы глубоко заблужадетесь, если вдруг думаете, что я ярый противник dotNet. Он мне на самом деле в чём-то нравится и я иногда пишу в нём простенькие утилитки. Я сам в своё время хотел на него перейти, но когда убедился что у меня частенько связаны руки, я отложил это дело в долгий ящик. Я уверен, что API ещё довольно долго будет нужен.
Здравствуйте, Малич Юрий, Вы писали:
МЮ>И вы поэтому не рекомендуете другим изучать API?
Да. Я рекомендую изучать то, за что платят деньги заказчики. Ну а будут деньги, можно и поразвлекаться популярными и распространенными, но не факт что приносящими деньги программами. Вы лично заплатили за rar?
МЮ>А если я буду другим рекомендовать например не устанавливать linux,потому как я ей не пользуюсь.
Я буду рекомендовать не ставить linux потому как под ней меньше приложений и круг их ограничен. У каждого свои аргументы.
МЮ>Это всё причины знать API.
Знания ради знаний?
МЮ>Алгоритмы обработки данных. Ещё поддержка существющих программ на С++ написанных давно, ещё без поддержки COM. МЮ>Кроме это частенько я занимаюсь низкоуровневым тестированием процессоров, пишу ассемблерные вставки.
Серьезно. Я последний раз писал на ассемблере стековую оконную библиотеку в 80-х годах — 3 кб получилось. Эх, ностальгия... А кстати, где в работе с данными, вызове старого кода и тестировании процессора вызовы winapi?
МЮ>Я трезво со здоровым консерватизмом смотрю на это. Linux сообщество всё равно будет отставать, всегда. dotNet FW вышел уже довольно давно, а lin до сих пор не может похвостатся полной совместимостью даже с WinForms версии 1.0
Ну это проблемы lin сообщества. Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
МЮ>Не-а, это вопрос тот-же. Стоит ли не знать API ради .Net? Всё равно API знать нужно.
Стоит ли знать API ради API?
A>Здравствуйте, Малич Юрий, Вы писали:
A>Да. Я рекомендую изучать то, за что платят деньги заказчики. Ну а будут деньги, можно и поразвлекаться популярными и распространенными, но не факт что приносящими деньги программами. Вы лично заплатили за rar?
Я много за что заплатил. В этом списке кстати ни одной dotNet программы.
Я вообще не рекомендую замыкать свои знания только на том, что нужно заказчику. Заказчики приходят и уходят, а знания остаются.
A>Я буду рекомендовать не ставить linux потому как под ней меньше приложений и круг их ограничен. У каждого свои аргументы.
У приложений dotNet круг тоже ограничен. Весьма. Ваш тому пример.
Звук, видео, САПР, игры — там dotNet не нужен, а разработчики, владеющие API — нужны.
A>Знания ради знаний?
Знания ради умений и опыта. Чтобы написать хорошую программу, которая не ограничевается Button, DBGrid и StoredProg знаний dotNet не дотсточно.
Вообще зачем нужно учится в университете? Выучил дома dotNet по книге и вперёд устраиватся на работу
A>Серьезно. Я последний раз писал на ассемблере стековую оконную библиотеку в 80-х годах — 3 кб получилось. Эх, ностальгия... А кстати, где в работе с данными, вызове старого кода и тестировании процессора вызовы winapi?
Вы очень поверхностно смотрите в корень проблемы, видимо специфика работы такая. Какой смысл мне вам рассказывать, если вам это не пригодится? Знанияния ради знаний?
А почему я например не могу попытатся что-то портировать или написать новое? Если я с этим сталкивался, значит мне это было нужно, а в FW этого не было.
A>Ну это проблемы lin сообщества.
Ага , уже напопятную.
A> Мне больше нравится другое — что fw одинаково работает на различных ОС от MS. win32 этим похвастать не мог.
Really? Одинаково ограниченно вы хотели сказать . Внимание вопрос: Как вызвать из dotNet новые функции , появившиеся в новой операционной системе, новые интерфейсы, новые контролы? Или может прикладным программистам они не нужны?
A>Стоит ли знать API ради API?
API надо знать ради расширения возможностей.
А стоит ли замыкатся на ограниченные возможности dotNet?
Здравствуйте, Kisloid, Вы писали:
K>Вот думаю, стоит ли щас начать изучать Си шарп. Ведь насколько мне известно, окончательной версии этого языка еще не вышло. Я стою перед выбором, изучить Си шарп или писать на MC++. А может вообще стоит не торопиться и писать unmanaged приложения, хочу кстати купить книжку Джеффри Рихтера "Windows для профессионалов, создание эффективных Win32-приложений с учетом специфики 64-разрядной версии Windows".
Окончательной версии C++ тоже ещё не вышло. И никак не выходит каменный цветок уже двадцать лет.
Здравствуйте, Andrbig, Вы писали:
A>3d игры — во-первых, скорость для них часто критична. Во-вторых, там до черта работы с железом. Quake — очень хороший тест (!) для компа. Нет, это не приклад, это системный тест.
Ха, с железом там работают драйвера да прослойки типа OpenGL или директа. Работает же Quake2 .NET, притом почти со скоростью оригинала (где-то 80% от нее по утверждению "переводчиков").
А что до API — это и нормальный Overlapped I/O и scatter/gather, MMF, SSPI, и просто — unmanaged код с оптимизациями под конкретные процессоры и структуры данных.
Здравствуйте, Andrbig, Вы писали:
МЮ>>Всё равно WinAPI наверняка пригодится, а значит настоятельно рекомендуется в нём разбираться.. A>Наверняка пригодится для чего? Для общего образования. Никакой практической пользы в большинстве случаев нет, т.к. эти случаи реализованы в fw. Как именно они реализованы, через winapi, через ядро или через задницу — ни на что не влияет. A>Насколько я слышал, winapi не будет развиваться. Его развитие закончилось и время его кончается. Не исключено, что мы доживем до времени, когда все будет сплошь managed и win32 будет эмулироваться, как сейчас это происходит с DOS. A>Так что изучать winapi можно так же как DOS, с исторической или медотологической точки зрения. Практически — бесполезно (я не рассматриваю редкие специфичные случаи).
Как вы всё красиво расписали, прям утопическое (от слова утопить) будущее какое-то... Вот только почему-то M$ до сих пор не отказалось от поддержки 16-ти разрядных приложений и WinAPI до сих пор тянет груз старых функций ещё из Win 3.11. А вы говорите о смерти Win32 и unmaneged приложениях, а меж тем готово уже Win64 и оно во всю используется. Кстати .NET Framework не содержит и половины того, что доступно под Windows средствами того же WinAPI, а половина из того, что он всё таки содержит — такое убожество, что и говорить не хочется (вспомнить хотя бы Remoting — это называется механизмом коммуникации в распределённых системах?! Не смешите меня — DCOM и то лучше). Просто банальное добавление всех возможностей ОС во Framework поверх WinAPI может растянуться на годы, а уж тем более полная замена WinAPI Framework`ом. Чтобы не быть голословным приведу пример, не далее чем вчера я убил полдня для того, чтобы реализовать банальную вещь — удаление сертификата X509 из хранилища, перелопатив документацию по .NET`у и WSE 2.0, я понял, что штатными средствами это сделать невозможно и полез импортить нужные функции.
Кроме того, а как быть с теми языками, которые не поддерживают .NET и имеют жёсткие стандарты: C (не плюсы, а именно pure C), Fortran какой-нибудь. Перевод этих языков на рельсы .NET`а означает слом их стандартов. Не думаю, что у M$ получиться протащить кардинальные изменения стандартов в ISO, и не думаю, что они решаться похерить тоны кода написанные на этих языках. В конце-концов несмотря на то, что приложения с использованием WinAPI в последние годы писались и пишутся в основном на C++, сам WinAPI был заточен под pure C, потому что он был раньше и на нём писались приложения для Win 3.11!
Зачем же тогда вообще нужен .NET мелкософту? У меня на этот счёт есть пара своих соображений:
1) Полный и окончательный провал COM`а как технологии — ну не удобно его сипользовать, хоть ты тресни, а механизмы объектно-ориентированного доступа к сервисами ОС иметь хочется.
2) Неопределённость разработчиков процессоров x86-ой архитектуры (традиционной для Windows) относительного того, как будет поддерживаться 32-ух разрядный код на их 64-ёх разрядных процах — .NET начал разрабатываться именно тогда, когда Intel объявила о том, что их процы не будут поддерживать старые приложения. И .NET как раз наоборот является тем самым средством, которое позволило бы спасти существующие наработки и осуществить безболезненный переход с 32-ух разрядной на 64-ёх разрядную архитектуру, а не способом похорогить всё что было до него. Но с тех пор AMD заявила о полной обратной совместимости своих процов и Intel был вынужден пойти по этоу же пути...
Всё сказанное чистый IMHO. Выводы делайте сами.
И вот ещё на закуску:
Есть и другое объяснения того, почему Microsoft так решительно отвергла все свои наработки и взялась за новую лучшую концепцию. Лучше всего эту версию изложил Ron Burk из WDJ. Вот его версия:
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Какой смысл мне вам рассказывать, если вам это не пригодится? 
