dll

[NitE]

есть у кого тутор как писать дллки (для блица) простые вещи но чтоб быстрее работало ? если предположить что я умею писать с директом на с++ (хотя это конечно не так)

[impersonalis]

New DLL interface spec
----------------------

There is now a directory in the root blitzpath called 'userlibs'.

By adding DLLs and '.decls' files to this directory, you can extend blitz's command set.

DLLs contain actually library code, while .decls files contain 'declarations' to be added to the
base command set. These declarations describe the functions contained in the Dll.


Format of decls files
---------------------

Decls files should always start with a '.lib' directive, followed by the quoted name of the DLL to be
loaded, eg:

.lib "mylib.dll"

Following the .lib is a list of function declarations. The syntax of these is identical to
function declarations in Blitz, with the following exceptions:

* No default parameter values are allowed.

* If no function return type is specified, the function is a 'void' function - ie: it returns nothing.

* Instead of object parameters, you can only specify 'void*' parameters using a '*' type tag. Such
parameters can be assigned ANY object or bank, so BE CAREFUL!

* A declaration may be optionally followed by a 'decorated name'. This takes the form of a ':'
followed by a quoted string denoting the decorated name, eg:

MyFunction( text$ ):"_MyFunction@4"
MessageBox%( hwnd,text$,title$,style ):"MessageBoxA"

The decorated name is the name of the function as it appears in the dll, and only needs to be
specified if it is different from the actual function name.


Writing DLLs
------------

All functions MUST use the _stdcall calling convention.

Floats are passed and returned as per standard C/C++ conventions.

Strings are passed and returned in 'C' format - ie: a pointer to a null-terminated sequence of
characters.

Returned strings must be in a 'static' memory buffer. Once the function returns, this string is
immediately copied into an internal Blitz style string, so its OK to share this buffer between
multiple functions.

Both banks and objects can be passed to functions. The value passed is the address of the first byte
of storage. No information is sent regarding the size or type of memory passed so, again, BE CAREFUL!

Neither Banks or objects can be returned from functions.

Arrays are not supported at all.

VisualC decorates symbols quite heavily! If you are coding in 'C', the necessary stdcall specifier
will cause a '_' to be prepended, and a '@' (followed by the number of bytes passed to the function
- ie: number of parameters*4) to be appended. So, something like: 'void _stdcall MyFunc( int x )'
will end up as '_MyFunc@4'. In C++, the name decoration is even messier! But you can supress it by
using the 'extern "C"' feature (see examples below) so you're just left with the 'C' stdcall mess.

Other languages such as Delphi and Purebasic don't appear to suffer from this feature, but it can be
worthwhile looking through dll symbols if you're having problems. Check out PEview at
http://www.magma.ca/~wjr Open your dll and select 'SECTION .rdata'/'EXPORT address table'
to have a look at the exported symbols your compiler has seen fit to bestow upon your dll.

Example
-------

Ok, here's a little C++ example, as it would appear in VisualC.

First, we write the DLL:

//demo.dll
//
#include <math.h>
#include <string.h>
#include <stdlib.h>

#define BBDECL extern "C" _declspec(dllexport)
#define BBCALL _stdcall

//returns a float and has 6 float parameters
BBDECL float BBCALL VecDistance( float x1,float y1,float z1,float x2,float y2,float z2 ){
float dx=x1-x2,dy=y1-y2,dz=z1-z2;
return sqrtf( dx*dx+dy*dy+dz*dz );
}

//returns a string and has one string parameter
BBDECL const char * BBCALL ShuffleString( const char *str ){
static char *_buf;

int sz=strlen(str);

delete[] _buf;
_buf=new char[ sz+1 ];
strcpy( _buf,str );

for( int k=0;k<sz;++k ){
int n=rand()%sz;
int t=_buf[k];_buf[k]=_buf[n];_buf[n]=t;
}

return _buf;
}
After building this, the resultant 'demo.dll' should be placed in the userlibs directory.

Now, we also need to create a 'demo.decls' file, describing the functions in our dll. This file
is also placed in the userlibs directory:

.lib "demo.dll"
VecDistance#( x1#,y1#,z1#,x2#,y2#,z2# ):"_VecDistance@24"
ShuffleString$( str$ ):"_ShuffleString@4"

...Voila! The next time Blitz is started up, the new commands appear within the IDE and can be used.

\Blitz3D\userlibs\UserLibs.txt

[HolyDel]

кстати, заместо:

#define BBDECL extern "C" _declspec(dllexport)
#define BBCALL _stdcall

можно писать:

#define MYDECL(type) extern "C" _declspec(dllexport) type __stdcall

и соответсвенно объявление ф-ии

MYDECL(float) Summ(float a,float b)

[NitE]

ыыы, как я уже говорил я слепой, так-что не увидел сразу ))
да кстати - если я напишу допустим функцию как в описаний (дистанция вектора) то она пойдее будет работать быстрее чем если тоже самое написать в блице ?

[mr.DIMAS]

не думаю что будет, имхо обращение к длл'ке это + время

[HolyDel]

насколько мне известно, обращение к длл-ке не дольше чем обращение к своим ф-ям, как встроенным, так и определенными пользователем.

[mr.DIMAS]

ну тогда какой нах смысл юзать отдельную дллку для вычисления дистанции между векторами? если уж блиц с математикой не дружит, то потеря времени обращения к EntityDistance ( ~20 пс ) и к дллке( ~15 пс) 5 пикосекунд особой разницы не будет.
Об этом спорить также как о том что сможешь ли ты выпить 2^n^n^n банок пива. Имхо нех*й засирать себе мозги

[impersonalis]

2HolyDel, уверен? Я вот хотел бы узнать ответ на этот вопрос. Тратится ли время только при подгрузке длл (запуске ехе-юзателя длл) или на кажом вызове?

[impersonalis]

ну тогда какой нах смысл юзать отдельную дллку для вычисления дистанции между векторами?

ну семпл, на то и семпл - в других случаях использование ДЛЛ может быть оправдано.

[HolyDel]

2HolyDel, уверен?
где то читал нечто подобное, но сам тесты не проводил, поэтому не уверен.

[Venom]

>>Я вот хотел бы узнать ответ на этот вопрос. Тратится ли время только при подгрузке длл (запуске ехе-юзателя длл) или на кажом вызове?
Нет, время тратится только на подгрузку в момент связывания библиотеки с использующим ее процессом. Библиотека подгружается в адресное пространство процесса, затем загрузчик ОСи находит по таблице экспорта (почитай про PE формат) адреса экспортируемых функций и передает их процессу. Дальше они используются процессом как и его родные.

Venom
это одинаково как и для динамического связывания так и для статического ? в блиц3д только динамическое связывание

я не очень люблю динамическое связывание библиотек потому что получается разделённая память - та память которая была выделенна в библиотека обязательно именно в этой библиотека должна быть удалена