FOAR EVERYWUN FRUM BOXXY

Ты совершенно не понимаешь сути электроники. Электроника -- это не программирование ПЛИС "о хай, зацените, как я запихал всю МПС в один кристалл". Электроника -- это не дихалт "о хай, посмотрите как я сделал ненужную хуйню на AVR". Это не псевдоинтеллектуальное проектирование микросхем. Это не реле, трансформаторы или усилительные каскады. Электроника Это профессия, в которой люди могут побыть инженерами -- суровыми бородатыми низкоуровневыми фашистами, которыми они на самом деле и являются.
Пробило p-n переход, а мы паяем. Монтажники подожгли коллегу за отказ делать всю логику на транзисторах, а мы паяем. Все три фазы замкнуло на ноль, а мы паяем и просим еще. Преобразователи, приводы, контроллеры -- мы паяем. Макетки со жгутами, КД305, КТ315, К155, КР580 -- мы паяем. Изделие потребляет 50 ампер -- мы паяем. Мы безжалостно вытравим любую плату, наши схемы не основаны здравом смысле, испарения флюса -- наша стихия, мы -- истинное лицо электротехники.

Если вы программировали во времена MS-DOS, то должны помнить, что большинство системных вызовов использовали вызов int 21h(а UNIX-системы используют до сих пор int 80h). К чему бы я начала этот разговор? Да вот общалась я тут на днях с одним разработчиком и зашел разговор о софте с кучей плагинов и как реализовывать надежную работу плагинов и ядра софтины. Мне вспомнился один из приемов который года четыре назад описывал Крис Касперски и насколько я помню еще были упоминания.

Суть приема в том, что код, вызывающий int, не имеет и малейшего представления по какому адресу находится системный обработчик. И самое хорошее здесь то, что адрес может динамически меняться. Стоит сказать, что и Windows вплоть до XP версии использовала int как мостик между userl-land и kernel-land, позволяя прикладному уровню использовать системные вызовы.

Интересно, что использование int позволяет отсечь легальную возможность написания плагинов-фильтров встраивающихся между легальными плагинами и ядром(та часть программы к которой подключаются плагины).

И тут как нельзя кстати подходит int, но, во-первых это системно-зависимо и абсолютно не переносимо. Во-вторых, вызывать int с прикладного уровня на прикладной уровень не кошерно. Существует более красивый способ сделать это:
1. Основная программа устанавливает обработчик исключений
2. Плагин для вызова функций программы производит запись особой структуры по нулевому указателю, что приводит к генерации исключения перехватываемой(и обрабатываемого) основной программой.
В итоге программа может динамически переназначать обработчики исключения в зависимости от текущих режимов работы. Тоже самое могут делать и плагины. Устанавливая свой обработчик, перекрывающий предыдущий обработчик, они перехватывают сообщение основной программы со всей цепочкой плагинов-фильтров.

И в заключении пример структуры.
struct foo
{
   char magic[] = "FFUUU";
   //здесь присутствует сильное колдунство
   int syscall_id;
   //номер системного вызова
   void *list
   //указатель на список аргументов системного вызова
}

Вместо номера системного вызова можно использовать имена. Аргументы передаются и возвращаются через *list, формат которого может изменяться.

Когда побежали финальные титры по экрану я наконец смогла откинуться на спинку кресла и перевести дыхание. Еще одна игра пройдена. На этот раз это был Alan Wake на Xbox 360. Подробней о игре читайте обзоры.

В очередной раз убеждаюсь, что мой выбор консолей был правильный. Как бы не росли мощности PC, сколь бы Крайзисов и прочего некстгена не выходило на PC я буду всегда знать, что действительно клевых, атмосферных, проработанных игр на PC мало! Да и большая часть из тех бриллиантов банальные порты с консолей. А вот на консолях таких игр тысячи! Начиная с классики NES и заканчивая Xbox 360 с Playstation 3.

На каждой консоли которые у меня были(NES, Sega Genesis, PSP(хотя я ее использую для эмуляции старых консолей и поэтому ее сюда писать не стоит), Xbox 360) я смогу назвать 20 - 30 игр действительно крутых и не надоедающих.

А почему на консолях больше крутых игр? Ведь тот же компьютер по сути. Ответ прост: консоли всегда были и остаются мейнстримом игровой индустрии из-за того, что под консоли проще разрабатывать. А это значит, что можно отдаваться написанию крутого сюжета и проработке геймплея, а не придумывать некстген бенчмарк коим был Крайзис. Помните? В нем сюжет лишь способ оценить возможности движка. Вот какие проблемы на PC? Давайте по порядку.

1. Многоядерные процессоры. Попробуйте вылизать движок под многоядерность так, чтоб это работало нормально на всем текущем ассортименте процессоров и периферии. Я имею ввиду, чтоб движок одинаково нормально "переваривал" хоть 2 ядра, хоть 4(а в будущем еще больше), а может даже и 1 ядро на процессоре с другими заморочками. Да и прочие SLI и CrossFire видеокарт. Ведь мы не знаем на какой конфигурации будет играть конечный пользователь. Все эти заморочки отнимают время разработки.

2. Операционные системы. Ну тут по сути выбор не велик. Но приходится учитывать особенности как минимум 3 популярных ОС(да, линейка Windows) и возможно другие(Mac OS). Это так же влияет на скорость разработки. А как мы знаем сроки не бесконечные!

А что же консоли? А тут все просто. Если это Xbox 360, Playstation 3 и другие, то железо и ОС у всех пользователей одно(в рамках типа консоли). Проблемы PC отпадают.
Так же замечено, что консольные игры обладают бюджетами больше чем игры PC. Может это тоже стимул?

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

Хотя я может и не права. Не судите строго. Любите друг друга больше и чаще!

Продолжаем говорить о выборе ПО.

В первой части заметки я писала, что мы выбираем ПО сознательно и не сознательно. Так же я постаралась растолковать причины бессознательного выбора.

Сознательный выбор заключается в том, что когда человек набравшись опыта в своей сфере деятельности(я буду говорить за программиста) начинает выбирать инструменты наиболее оптимально решающие необходимые задачи. В первой части я привела пример с редактором gedit который легко превращается в IDE для любого языка программирования. В этот момент происходит перелом в сознании человека. Этот момент самый тяжелый. Именно он определяет пойдет ли этот человек дальше или останется на том же уровне развития. Почему? Потому что набор ПО выбранный на бессознательном уровне может все и одновременно ничего. Он загоняет человека в рамки шаблона и в этих рамках человека думает(классика жанра Delphi и MS Visual Studio с их VCL и MFC). ПО выбранное в моменты сознательного выбора дает мощный стимул к развитию, т.к. открываются огромные возможности для экспериментирования с любыми инструментами коих предостаточно.

Подведем итоги.

Бессознательный выбор ПО: это ПО которое навязано нам в самом начале пути, когда мы еще дилетанты и получаем базовые навыки. Зависимость от него очень высокая, т.к. она психологическая на подсознательном уровне.

Сознательный выбор: это ПО которое мы выбираем имея опыт и знания. Зависимость низкая, т.к. выбираем на уровне трезвого ума и сознательной деятельности.

Задумайтесь над тем, что вы выбираете ;)

Эта заметка не является агитационной в пользу свободного ПО.

Ищите да обрящете.

Всем привет.

Давайте поговорим о сознательном и бессознательном выборе ПО для вашего компьютера. Начнем пожалуй с бессознательного выбора.
Когда вы покупаете свой первый компьютер, то 99% случаев вы столкнетесь с Windows(опустим пока Mac и его ОС). Это очень важный шаг, т.к. от того, что вы увидите первый раз, зависят ваши предпочтения целиком и полностью. Главное, чтоб эта первая ОС удовлетворила потребности среднего пользователя. А дальше идет привыкание к этой ОС и ее программам. Отказаться от нее будет очень тяжело. Это все равно, что попробовать бросить курить. Это все бессознательный выбор ПО. Вам его навязали. Со временем ваш опыт растет(если вы скажем программист или инженер) и вы хотите более совершенный инструмент. Наступает время сознательного выбора. Но по причинам привязанности к ПО выбранному на бессознательном уровне вы не можете осознано выбирать ПО! Вам кажется, что любой САПР должен быть как AutoCAD или IDE как Visual Studio. Что-то менее функциональное(покажите мне хоть одного человека использующего возможности AutoCAD на 50% и я выставлю пиво) отвергается по причине того, что оно выглядит не как программа к которой вы привыкли. Я 4 года программировала в Visual Studio, но ни разу не использовала множество примочек вроде автоматического рефакторинга кода. Теперь, когда я сделала осознанный выбор в сторону gedit могу с уверенностью сказать, что Visual Studio не нужна.
---
Упс, пора бежать. Вечером допишу.