Виндовые библиотеки всё равно можно будет запускать только если написать для КОС все библиотеки, ими используемые (то-есть windows api). У меня была идея помочь ей ещё летом, но потом решил не метаться из стороны в сторону, и сначала доделать запись в ntfs.

[quote="Pathoswithin"]Виндовые библиотеки всё равно можно будет запускать только если написать для КОС все библиотеки, ими используемые (то-есть windows api)[/quote]
Ну я это понимаю! Но насколько я понимаю, если в виндовой длл не будут использованы функции windows api АБСОЛЮТНО, ведь она по идее запустится ?
Т.е. буду использовать исключительно конструкции Дельфи и её самые простые стандартные переменные и т.д..... ну ведь должна же работать я та понимаю ?

Вопрос может странноватый, но я просто никогда такого не делал ...
Вот какие есть соглашения по передачи данных через процедуры (DLL) в Дельфи
register, pascal, cdecl, stdcall, safecall
Допустим есть процедуры "P1","P2".....
Хочу для каждой из процедур сделать абсолютно любой способ вызова, как говорится на все случаи жизни(!), соответственно изменим имя, на P1_register , P1_pascal, P1_cdecl..... и т.д.
Основной вопрос: ДОПУСКАЕТСЯ ЛИ ТАКОЕ В DLL ?
ЛЮБАЯ СРЕДА (ПРОГРАММА) КОТОРАЯ МОЖЕТ ИСПОЛЬЗОВАТЬ DLL-МОДУЛИ БУДЕТ "СЧИТАТЬ" DLL КОРРЕКТНЫМ ?
(я просто при экспорте использовал всегда одно соглашения, - cdecl, уже не помню почему именно cdecl. В одном DLL с разными соглашениями не делал и не сталкивался)

Можно, только зачем? Придётся создать несколько оболочек для каждой процедуры.

[quote="Pathoswithin"]Можно, только зачем?[/quote]
Работаю над KOS.dll. Похоже, что надо такое сделать раз и навсегда, на случай использования KOS.dll в разных средах программирования, каждая из которых с разными "заморочками" связанными с приёмом-передачей данных для dll.

[quote="Pathoswithin"]Придётся создать несколько оболочек для каждой процедуры.[/quote]
Это не проблема.
procedure dfSetEAX(c:Cardinal); begin eax_:=c; end; exports dfSetEAX;
procedure rgSetEAX(c:Cardinal); register; begin eax_:=c; end; exports rgSetEAX;
procedure psSetEAX(c:Cardinal); pascal; begin eax_:=c; end; exports psSetEAX;
procedure cdSetEAX(c:Cardinal); cdecl; begin eax_:=c; end; exports cdSetEAX;
procedure stSetEAX(c:Cardinal); stdcall; begin eax_:=c; end; exports stSetEAX;
procedure sfSetEAX(c:Cardinal); safecall; begin eax_:=c; end; exports sfSetEAX;

=============
Можно ли создать тему посвященную KOS.dll ? Если да, то где её можно создать?
KOS.dll постоянно буду дорабатывать и совершенствовать, но пока результаты не велики :-(
Пока попытки использовать в CB6 не увенчались успехом. :-( Думаю, что и в VS6 тоже самое, хотя еще толком не пробовал. В FASM вроде что-то получается её прикрутить и использовать.
Тему хочу создать, для вопросов, возможной поддержки, а также для тех, (в частности новичков), которых может однажды заинтересовать использование KOS.dll , для проб и экспериментов с функциями КОС. Хочу довести её до такого уровня, чтобы при помощи её можно было бы написать игру подобную "Косилка", думаю, такое вполне реально и вполне, может быть, мной реализовано. Заканчиваю работы по функции 2, скоро будет возможным пример, с использованием клавиатуры, пример типа, - передвигания "кубика" стрелками и т.д. :-) Ожидаю утверждения названий процедур :-), чтобы знать как и на что "опираться" или какие делать аналоги процедур, т.е. с какими именами "подточенными" под KOS.dll

Зачем изобретать велосипед? Делаешь все функции в одной нотации на выбор cdecl/stdcall/fastcall(?) и в документации об этом описываешь. Все остальные языки умеют работать с ними, особенно с первыми двумя

[quote="Veliant"]Зачем изобретать велосипед? Делаешь все функции в одной нотации на выбор cdecl/stdcall/fastcall(?) и в документации об этом описываешь. Все остальные языки умеют работать с ними, особенно с первыми двумя[/quote]
Да пусть будут все! На всякий случай, чтобы никогда не возникало никаких вопросов ни с чем!

Veliant, вот в фасме испытываю ддл-модуль...
как показала практика для передачи в процедуру нужно использовать safecall; (ну возможно и другие, кроме register; по-моему так)
а вот для приёма из функции register; вот и ответ на вопрос "зачем?"

macro SetEAX a { invoke sfSetEAX,eax }
macro GetEAX { invoke rgGetEAX }

Пока так работает другое не испытывал, не вижу необходимости!

Прежде чем городить, советую почитать про конвенции вызова и как они влияют на возвращаемое(!) значение. Если кратко - никак. Разница только в том как передаются параметры функции

Veliant wrote:Прежде чем городить, советую почитать про конвенции вызова и как они влияют на возвращаемое(!) значение. Если кратко - никак. Разница только в том как передаются параметры функции

По началу как получается так и пишу! :-) Главное, чтобы вообще работало! :-) Я выложу архив с модулем, шаблонами и демкой, если захочешь скачаешь рассмотришь. Может действительно можно как-то по другому, более эффективно, я не спорю.

Veliant и другие тоже....
Создана тема “МЭФК ( KOS.dll )» посвященная моему модулю, где он выложен с примером использования.
Это вот здесь: viewtopic.php?f=39&t=3205&p=63460#p63460

ALEXS1983 wrote:Да пусть будут все! На всякий случай, чтобы никогда не возникало никаких вопросов ни с чем!

Всё равно не получится. Например, fastcall у Microsoft и fastcall - оно же register - у Borland - две разные вещи. Например, конвенция вызова, используемая по умолчанию, разная в разных языках и иногда зависит от опций компилятора. Так что перестань страдать фигнёй и используй stdcall. Все функции WinAPI с фиксированным числом аргументов - stdcall, так что любая среда, способная вызывать WinAPI, способна работать с stdcall.

ALEXS1983 wrote:Veliant, вот в фасме испытываю ддл-модуль...
как показала практика для передачи в процедуру нужно использовать safecall; (ну возможно и другие, кроме register; по-моему так)
а вот для приёма из функции register; вот и ответ на вопрос "зачем?"

macro SetEAX a { invoke sfSetEAX,eax }
macro GetEAX { invoke rgGetEAX }

Пока так работает другое не испытывал, не вижу необходимости!

invoke подразумевает конвенцию stdcall. Для cdecl есть cinvoke. safecall - вообще Borland'овская эзотерика, которая в основном ведёт себя как stdcall, но может совершенно неожиданно перестать, так что её вообще между языками использовать не стоит.

P.S. Ты специально ставишь флажок "Отключить в этом сообщении BBCode" при создании сообщения или это какие-то особенности настроек форума?

ALEXS1983 wrote:

Pathoswithin wrote:Виндовые библиотеки всё равно можно будет запускать только если написать для КОС все библиотеки, ими используемые (то-есть windows api)

Ну я это понимаю! Но насколько я понимаю, если в виндовой длл не будут использованы функции windows api АБСОЛЮТНО, ведь она по идее запустится ?
Т.е. буду использовать исключительно конструкции Дельфи и её самые простые стандартные переменные и т.д..... ну ведь должна же работать я та понимаю ?

А что, дельфи уже перестала добавлять неявную ссылку на модуль System?
Вообще, зависимости от WinAPI легко проверить экспериментально - в мире утилит MS есть dumpbin /imports <exe|dll>, в гнутом мире objdump --all-headers <exe|dll>, у Borland вроде что-то похожее называлось tdump.

CleverMouse
У меня в оффтопе вообще всё отключено, хотя ссылки иногда работают.