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



Pzz>Кроме того, большая часть низкоуровневой работы, навроде писания драйверов, интересна только первые три раза, а потом, как руку набьете, обнаружите, что это довольно скучная рутина.
Вы имеете ввиду написание драйверов на Windows? Если да, то вы меня повеселили. Это можно сказать более или мение для одного типа драйвера но если переходишь на другой тип драйвера то приходится многое изучать сначала. И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.
Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

static void interchange_equal_blocks(int *b1, int *b2, unsigned int len)
{
    int tmp, *p1 = b1, *p2 = b2;

    for (; p1 < b1 + len; ++p1, ++p2)
    {
        tmp = *p1;
        *p1 = *p2;
        *p2 = tmp;
    }
}

void interchange_blocks(int *b1, unsigned int b1_len, int *b2, unsigned int b2_len)
{
    if (b1_len < b2_len)
    {
        interchange_equal_blocks(b1, b2, b1_len);
        interchange_blocks(b2, b1_len, b2 + b1_len, b2_len - b1_len);
    }
    else if (b1_len > b2_len)
    {
        interchange_equal_blocks(b1, b2, b2_len);
        interchange_blocks(b1 + b2_len, b1_len - b2_len, b2, b2_len);
    }
    else interchange_equal_blocks(b1, b2, b1_len);
}

Не, лучше так:

void interchange_blocks(int *ptr, unsigned int b1_len, unsigned int b2_len)
{
    if (b1_len < b2_len)
    {
        interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
        interchange_blocks(ptr + b1_len, b1_len, b2_len - b1_len);
    }
    else if (b1_len > b2_len)
    {
        interchange_equal_blocks(ptr, ptr + b1_len, b2_len);
        interchange_blocks(ptr + b2_len, b1_len - b2_len, b2_len);
    }
    else interchange_equal_blocks(ptr, ptr + b1_len, b1_len);
}

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

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

You make my day(c) Этой задачкой ))) Есть школьный вариант... завести второй массив )
Но вообще, как я поняла, point в том, чтобы сразу ставить элемент на нужное место... ) Пока в процессе...( но в целом грустно... давно я таки в своем баг-фиксе с алгоритмами не сталкивалась(

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

x64>А обниматься лучше с любимым мужем и ребёнком, правда.
Обниматься с мужем таки пока подожду... ибо своего нет, а с чужим — могут не понять

R>>В общем, как вы думаете имеет смысл соваться в эту область?

x64>Если ты не понимаешь чётко, что делаешь и зачем тебе это, если не чувствуешь, что "лежит душа" к этому, — то однозначно не надо. Как ни крути, всё же это весьма объёмная область и нужно быть готовым к тому, что можешь не стать здесь "гуру" даже и через 5 лет.

Если бы мне это не было интересно — я бы и не задумалась даже. Но интересно что в области творится... чужие мнения, а не через мои "розовые очки" ))))

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

Pzz>Если вы целитесь в программисты, лучше все же искать работу по созданию нового кода, пусть не очень сложного и не за очень большие деньги, чем по починке чужого кода. Ибо работа программиста заключается именно в создании кода.

Pzz>Ищите, такие места есть. Многие большие компании, типа Интела и Гугля, сознательно набирают неопытных но талантливых студентов "на вырост" — при наличии ресурсов, в т.ч. временнЫх, это более надежный способ получить квалифицированного специалиста, чем попытаться найти готового. Поработаете годика два за умеренную зарплату, но зато уму-разуму научитесь.

Дык как бэ уже и не студент((( Но все равно спасибо! буду стараться найти что-то интересное...

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

R>You make my day(c) Этой задачкой ))) Есть школьный вариант... завести второй массив )

Ну еще одно наивное решение заключается в том, чтобы крутить массив по кругу, пока он не станет в правильное положение. А с конечной дополнительной памятью и за время O(n) слабо решить?

R>Но вообще, как я поняла, point в том, чтобы сразу ставить элемент на нужное место... ) Пока в процессе...( но в целом грустно... давно я таки в своем баг-фиксе с алгоритмами не сталкивалась(

Сразу ставить на нужное место не получится. Но тем не менее, решение существует — я даже знаю два разных

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

E>Вы имеете ввиду написание драйверов на Windows? Если да, то вы меня повеселили. Это можно сказать более или мение для одного типа драйвера но если переходишь на другой тип драйвера то приходится многое изучать сначала.

Типов виндузовых драйверов существует конечное количество.

E>И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.

Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

Документация, да, так себе. Документации о том, как писать линуксные драйвера, вообще не существует в природе. Однако писать драйвера для линуха не слишком сложно.

E>Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы

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

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

E>>Вы имеете ввиду написание драйверов на Windows? Если да, то вы меня повеселили. Это можно сказать более или мение для одного типа драйвера но если переходишь на другой тип драйвера то приходится многое изучать сначала.

Pzz>Типов виндузовых драйверов существует конечное количество.

И вы писали все типы драйверов?
Я ежедневно мониторю главные форумы по Windows drivers. В основном конечно OSR так как там много крутится людей с Microsoft. Вернее они принимают часто участие в дискусиях. А принимают потому что очень часто даже MVP не могут ответить на некоторые вопросы.Только люди с Microsoft, которые знают определенные и специфичные детали, могут ответить.


E>>И изучать в основном по примерам с WDK которые плохо документированны и часто buggy.И конечно собирать по крохам информацию с разных форумах, которых к сожелению не так много. Не говоря о том что програмировать для Windows kernel просто тяжело потому что Microsoft все пытается сделать чтобы ограничить свободу в design and development. Ну а programming for file system и filter file system и остальными типами Windows driverы это полностью два различных мира. На OSR даже существуют различный форум для file system drivers.

Pzz>Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

Я как то раз был на семинаре OSR "File system drivers" который читает Tony Manson. Это довольно крутой специалист в своей области так как он часто консультирует Microsoft.Он расказывал что он несколько лет подряд читал этот курс в Европе и эти несколько лет на этом курсе были люди с одной голандской фирмы. Эта фирма планировала сделать какой то проэкт связанный с файл систем. Консультантов из US они не хотели брать, наверное считали что дорого. Пытались сделать все своими силами за меньшую европейскую зарплату. Рассказ он закончил тем что этот проэкт небыл закончен по нехватке квалификации. Вы случайно не в Голландии живете?

Pzz>Документация, да, так себе. Документации о том, как писать линуксные драйвера, вообще не существует в природе. Однако писать драйвера для линуха не слишком сложно.
Потому что source code. А это все.
E>>Ну а если надо сделать какое нибудь не стандартное решение, которое выходит за понимание Microsoft что можно делать на Windows на системном уровне, то начинается такое веселье и такая "рутина" что мозги плавяться.

Pzz>Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы
Вопрос только за какое время и какими силами

Pzz> А с конечной дополнительной памятью и за время O(n) слабо решить?

Точно O(n), а не O(nLogn) ?

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

Pzz>> А с конечной дополнительной памятью и за время O(n) слабо решить?

M>Точно O(n), а не O(nLogn) ?

Про уже приведенное здесь решение не возьмусь утверждать, но существует решение, которое очевидно O(n)

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

Pzz>>Типов виндузовых драйверов существует конечное количество.

E>И вы писали все типы драйверов?

Нет конечно. А что, неужели их все же существует бесконечное количество?

E>Я ежедневно мониторю главные форумы по Windows drivers. В основном конечно OSR так как там много крутится людей с Microsoft. Вернее они принимают часто участие в дискусиях. А принимают потому что очень часто даже MVP не могут ответить на некоторые вопросы.Только люди с Microsoft, которые знают определенные и специфичные детали, могут ответить.

Ну, если бы бумажка MVP автоматически делала человека волшебником...

Pzz>>Если бы я не написал ни одного вендового драйвера, возможно ваши слова произвели бы на меня впечатление

E>Я как то раз был на семинаре OSR "File system drivers" который читает Tony Manson. Это довольно крутой специалист в своей области так как он часто консультирует Microsoft.Он расказывал что он несколько лет подряд читал этот курс в Европе и эти несколько лет на этом курсе были люди с одной голандской фирмы. Эта фирма планировала сделать какой то проэкт связанный с файл систем. Консультантов из US они не хотели брать, наверное считали что дорого. Пытались сделать все своими силами за меньшую европейскую зарплату. Рассказ он закончил тем что этот проэкт небыл закончен по нехватке квалификации. Вы случайно не в Голландии живете?

Нет, не в Голландии. Мне приходилось как-то иметь дело с крутыми специалистами из US. Настолько крутыми, что один из написанных ими драйверов входит в состав виндового DDK в качестве примера. Я написал драйвер для некоторой железяки под линух, а у них заказали "профессионально написанный" драйвер под венду, а мой выдали в качестве документации. В общем, эти бедолаги решили спортировать мой, вместо того, чтобы свой написать, и этот проект так бы и закончился по нехватке ихней квалификации, если бы я сдуру не взялся помочь им удержать ихний драйвер на плаву. Это был мой первый вендовый драйвер, жалко, что не последний

Pzz>>Микрософтовское понимание мира, при всех его недостатках, является Тьюринг-полным. Поэтому всё, что требуется, можно сделать, не выходя за его пределы
E>Вопрос только за какое время и какими силами

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

x64>Драйверописец

Сразу вспомнил одного персонажа .

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

Pzz>Ну еще одно наивное решение заключается в том, чтобы крутить массив по кругу, пока он не станет в правильное положение. А с конечной дополнительной памятью и за время O(n) слабо решить?

И вот кто-то здесь думает, что я прямо и скажу "слабо"? Пока думаю... )

Pzz>Сразу ставить на нужное место не получится. Но тем не менее, решение существует — я даже знаю два разных

Почему не получится? О_о у меня получилось... ) только работает не для всех случаев Вот поэтому пока и в процессе

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

Pzz> Мне приходилось как-то иметь дело с крутыми специалистами из US. Настолько крутыми, что один из написанных ими драйверов входит в состав виндового DDK в качестве примера.

Аааааааааа

Нашёл, блин, чем похвастаться, гы! DDKшные примеры кишат ошибками и индусо-кодом может только чуть менее чем семплы в MSDN.

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

R>В общем, как вы думаете имеет смысл соваться в эту область?

Имеет смысл заниматься своим делом, а какое оно — вряд ли кто то лучше тебя знает. В 93м один умник мне рассказал, что ассемблер нигде не нужен, и я поверил

Где он точно не нужен — это разработка драйверов. И вообще любой development на ассемблере экономически не выгоден уже несколько лет, с тех пор как появилось 64 бита для default platform. Знаю всего 2-3 случая когда недостаточно С.

Где нужно знание ассемблера:

1. Более глубокое понимание С (как диалекта ассемблера ). ИМХО полезно почитать "Дизайн и эволюция" Страуструпа и "Алгоритмические трюки" Генри Уоррена. Востребовано во всех сферах применения языка. Может значительно упростить отладку. Вы писали, что занимаетсь отладкой — можно развиваться в этом направлении, по-моему хороших специалистов меньше, чем нужно, а у женщин потенциально должно лучше получаться.

2. Reverse code engineering. Это нужно всегда, как знания COBOL сейчас Думаю, что пик спроса будет после массового перехода на упровляемые ОС, так что время учиться есть но нужно еще понимать, что это дело всё лучше автоматизируется.
Номинально RCE — создание понятных человеку исходников по бинарному файлу без его запуска, а junior пишет код по готовым спецификациям, коих здесь нет... Возможно это соответствует вирусному аналитику, который изучает сэмплы как чёрный ящик, логируя побочные эффекты API мониторами (созданными старшими коллегами). Детально изучается небольшой % малвари, но это может быть очень ресурсоёмким и сложным процессом.
Учиться можно так же в отладчике, дебажа свой софт без исходного кода. Рости можно до уровня архитектора, чем и является RE в общем.

3. Защита от предыдущего пункта (а в силу сходных методов и автоматизация RCE). Самое перспективное и сложное направление. Трансляторы (дизассемблеры), виртуальные машины, изоморфы, DRM, watermarking, MITM атаки, NP-полные проблемы... ассемблер в этом списке идет маловажной деталью ближе к концу, после интуиции Тема очень многогранна, не знаю, существуют ли всеобъемлющие гуру. Видел вакансии непосредственно у разработчиков протекторов, можно поискать работу и в смежных областях.

R>Не так давно испытала в себе желание заняться низким уровнем и сейчас радостно обнимаюсь с книжкой по Ассемблеру.
R>Хотелось бы узнать, на сколько сложно не сильно опытному программисту найти работу в области низкоуровневого? И какие соопутствующие темы имеет смысл подтянуть? Имею С/С++ ный опыт 2 года.

Имеет смысл подтянуть ассемблер для всяких-разных архитектур, например, ARM, и податься в embedded. Там знание ассемблера довольно часто
нужно, правда тоже не как основной скилл.

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

Pzz>Вот например, способны вы самостоятельно решить следующую задачу? Есть массив целый чисел, состоящий из двух частей, не обязательно одинакового размера. Надо переставить эти части местами. Т.е.,

Pzz>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

Что-то мне подсказывает, что перестановка распадается на X = НОД(N,M) циклов одинаковой длины с примерно регулярной структурой, т.е. что числа a1, a2, ..., aX принадлежат разным циклам. Доказывать этот факт лень, но если это получится доказать, то решение должно быть таким:

0. Выводим формулу для индекса новой позиции по старой позиции. Не сложно.
1. Запоминаем стартовый индекс очередного цикла (изначально, 1).
2. Переставляем число, на которое смотрим на свое место по формуле из (0), а число с нового места запоминаем где-то.
3. Повторяеем 2, пока не придем в начало цикла из (1).
4. Если еще не все числа переставлены (считаем количесво операций сделаных в п.2), то увеличиваем стартовый индекс на 1 и переходим к (1).

Ну, конечно, стоит отсечь сразу всякие вырожденные случаи типа M<=0, N<=0, M>=N превратить в (M mod N), N.

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

Pzz>>Было: a1 a2 a3 ... aM aM+1 aM+2 ... aN
Pzz>>Стало: aM+1 aM+2 ... aN a1 a2 a3 ... aM

Au1>Что-то мне подсказывает, что перестановка распадается на X = НОД(N,M) циклов одинаковой длины с примерно регулярной структурой, т.е. что числа a1, a2, ..., aX принадлежат разным циклам. Доказывать этот факт лень, но если это получится доказать, то решение должно быть таким:

Есть решение гораздо проще, и еще одно решение, совсем тривиальное.

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


Pzz>Есть решение гораздо проще, и еще одно решение, совсем тривиальное.

Да вроде куда уж проще. Примерно в полэкрана кода, если не меньше. Только теории много выкладок получается.

PS: то есть это уже третье решение из имеющихся за O(n)?