Я думаю у Xors3D есть определенный опыт взаимодействия нативного кода с блицем - посмотри как там.
Во первых твою задачу нужно чётко разделять на межпроцессное взаимодействие и на взаимодействие в одном адресном пространстве.
Второе решается проще.
Недостаток твоего подхода:
а) Неудобство пользователя: ты его опускаешь до уровня Си. Если ты не сопроводишь хедером с тегами, то пользователю придется самому писать эти теги, по памяти, так что легко ошибиться.
б) Проблема отладки: ты просто передаешь набор байтов без какой либо дополнительной информации. К тому же передача происходит чтением/записью - что не является каким либо структурным разделением выполняемой программы. Если бы ты использовал функцию и
Соглашение о вызовах, дебарег смог бы хотя бы построить фреймы на основе стека и как либо структурировать действия программы. Более того если язык у клиента и библиотеки одинаковый, то я щитаю кощунство не использовать хедер с сигнатурами функций, описанием классов и т.п. потому что это тебе дает возможность отлаживать уже на уровне этого языка, а не ассемблера и компилятор сможет проконтролировать кучу ошибок и обезопасить код.
в) Проблема платформы: вот представь что ты скомпилировал библиотеку где выравнивание по 16 байтам, а у твоего объекта 4 байтные поля, а клиент скомпилирован с 4 байтным выравниванием, в итогде будут неприятности. Если был бы хедер то можно было бы хотябы при описании класса указать как выравнивать. А если были бы функции то вообще не было бы проблем - там оговорено как располагать в стеке или в каких регистрах.
г) Проблема защищенности: ты передаешь непонятно что, а если это является объектом то теоретически еще и методы переданного объекта можно вызывать. Представь себе если ктонибудь подделает тег, перепишет метод, например джампом вызовет вредоносный код и всё испортит тебе в системе. Так что тут не обойтись без протокола который обеспечивает минимальную защиту.