Работаешь работаешь, а оно как бумкнет.
Прямо как в мульфильмах.
Сначала приходят с одной конторы, и долго рассказывают какой же у них заебательский прибор. Вставляется в нужный слот, подключается их любимый драйвер, затем просто тупо пользуешься их интерфейсом, вуаля, простите мой французский, нихера не работает.
Хотя нет, работает, иногда.
Затем приходят другие. Эти просто предоставляют материалы и обещания.
Материалы так же точно соответствуют документации, как и документация не соответствует нашим требованиям. Т.е. абсолютно.
Обещания тверже камня, сроки красивые, вполне себе подходящие.
По прохождении срока даты меняются, красноречивые обещания продолжаются, и так в цикле до тех пор пока не сделаем.
Надоедает быстро.

Берем третьих, все еще проще. Драйвер написан для мультиплатформ. Прекрасно собирается и работает при минимальных усилиях.
Затем некие неустойки с рабочей скоростью, медленно перетекают в отсутствии возможности делать все, что объявлено и написано. Вернее, делать можно, но очень медленно, как в прибалтике.

А потом, потом в драйвере поставщика находится баг. Баг чинится, и в процессе сего действа растет увернность, что незаметить сие безобразие они просто не могли.
Баг с готовой версией починености посылается поставщику. В ответе содержится фраза, которую приведу в очень близком переводе на русский.
Итак внимание:
“Спасибо вам за решение этой проблемы. Да. мы знаем, что такой баг есть, мы обходим его в программе с помощью специального резервирования особого места в памяти, где баг не проявляется. Мы обязательно включим ваше решение в нашу поставку”.

Ощутите великое благородство сего автора.

Если вы думаете, что я это сочинил, вполне могу привести названия фирм и типы картисов с которыми работаю по индивидуальному каналу связи.
И это, кстати, абсолютно нормальная практика работы в хай-тек фирмах. Особенно в маленьких.
Вопрос на засыпку, стоит ли платить деньги за лицензию?

Во что превращается программист во время конца срока разработки?
В механическое чудо с красными, от кофе, глазами. В зомби, которого дети видят либо на фотографиях, либо по телефону.
Вы видели еще более неблагодарное занятие, чем проверка работы всех режимов программы за 2 дня? И не увидите. Зато потом начальство благодарно пожмет руку.
Надо переквалифицироваться в дворники.

Помните, я уже писал о работе с памятью. Там было теоретически.
Сейчас столкнулся с инетересным (тоже теоретически. практически - убил бы) строением пулов. Двунаправленые.
Коротко, имеется два варианта.
1. Есть две разные структуры данных одинакового размера (например 32 байта). Выделенная память отдается обоим. При этом первая получает стартовый адрес в пуле и продвигается ++. Вторая получается самый низкий (т.е. адрес = конец пула - размер одного блока) адрес и продвигается –.
2. Во втором варианте структуры жанных разного размера.

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

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

И много других мелочей, как неявное определение необходимых размеров пулов, свободных остатков.
Плюсов практически не нашел.
В алгоритме отсутствует даже намек, что при равных размерах блоков можно было бы динамически перераспределять свободные блоки между разными по смыслу.
Для этого ничего сложного было бы не нужно, достаточно вместо двух связных списков использовать один. Тогда можно было оправдать такую нестартовую нарезку, в случае дефицита на память в эмбедед системах. Но ее нет. Да и для разноразмерных блоков это не подходит, а перестраивать даже кратные блоки не очень то удобно, при явном перемешивании адресов.
Кроме того нет даже отдельных интерфейсов для работы с такой организацией, все намертво встроено в сам код.
Никак не могу понять, зачем надо было так вот усложнять алгоритмы, когда вполне можно обойтись либо однократным рещзервированием памяти в стандартные связные списки, в списки типа LIFO как я писал раньше. Методов может и не много, но вполне достаточно. Плюсы их известны заранее.
П.С. Странные люди.