To clarify the use of banks: you create a string in your dll dynamically with malloc or in the data/code segment of your dll with char buffer[255]. This allocation can not be freed. Thats why you call windows functions like GetUserName (example in Protean, code archives,userlibs) with a pointer to your buffer and the buffer size. The function then fills the buffer and it is your responsibility to free the buffer then. If you return strings in your dll you will have a memory leak, if you do not reuse your buffer. With memory banks, you give the responsibility to the executing program.
If blitz can't find the function, I use the program "nm" from the cygwin tools (www.cygwin.com). Then you are able to use even a c++ dll.
Another problem you could get: the dll has to be in the same directory as your workingdir or in windows\system32 folder. You could get problems, starting your application from an ide. If, e.g. you create your executable from Protean and let Protean start your exe after creation, the workdir is set to protean home dir. That means, you can't load your resources with a relative path and neither a dll.
If blitz can't find the function, I use the program "nm" from the cygwin tools (www.cygwin.com). Then you are able to use even a c++ dll.
Another problem you could get: the dll has to be in the same directory as your workingdir or in windows\system32 folder. You could get problems, starting your application from an ide. If, e.g. you create your executable from Protean and let Protean start your exe after creation, the workdir is set to protean home dir. That means, you can't load your resources with a relative path and neither a dll.