bdr> Если первый пример мне понятен, то со вторым:
bdr> <Ещё, Если Вы хотите загружать динамически какие то библиотеки то не
bdr> <используёте LoalLibrary, а используйте Cla$LoadLibrary, прототипы те-же
Угу. Только чуточку по другому:
MAP
LoadLib(LONG _LibNameAddr),LONG,NAME('Clw$LoadLibrary')
END
_LibNameAddr — адрес строки CSTRING с именем библиотеки.
bdr> А можно хоть небольшой комментарий.
bdr> Что это дает?
bdr> Александр Бирюков
По большому счету, эта — простая надстройка над API-шной LoadLibrary:
- сохраняет регистры CX,DX
- забрасывает адрес строки из AX в стек
- вызывает LoadLibraryA
- востанавливает DX,CX
- возвращает AX
По своему опыту общения с Кларионом на низком уровне могу сказать, что Кларион ОЧЕНЬ чувствителен к регистрам. Поэтому, когда идет вызов ЛЮБОЙ процедуры, компилятор предполагает, что после возврата из этой процедуры все основные регистры (BX,CX,DX,SI,DI) имеют тоже значение, что и до вызова. Не «закладывается» компилятор только на AX, и то, только для функций, которые возвращают результат через AX.
Я таким образом уже несколько раз «влетал» со своими asm-процедурами. Пока не стал сохранять/восстанавливать регистры, постоянно «лезли» какие-то левые глюки. Удалось «вычислить» только после кропотливого анализа сбойного участка с откатом назад, до места-источника проблем.
В принципе, компилятор должен учитывать, что процедуры с атрибутами C или PASCAL могут иметь другое поведение по отношению к регистрам. Но, очевидно, иногда где-то он все-таки «прокалывается» или вообще не принимает этого в расчет.
Так что, если по хорошему, то стоит для всех используемых API-шных процедур писать кларионовскую процедуру-надстройку, в которой будет только вызов API-шной процедуры. При генерации Кларионовской процедуры компилятор сам анализирует, какие используются в процедуре регистры и их сохраняет/восстанавливает.