| |
|
|
|
| |
|
| |
|
|
| |
What's News in the PlayBasic world ? - Find out here.
|
PlayBasic V1.64O - WIP Round Up #2
|
|
By: Kevin Picone Added: April 14th, 2013
|
|
Category: All,Upgrade,Beta Testing
|
The following excerpts are taken from the current PlayBasic V1.64O Work in Program blog.
PlayBasic V1.64O Beta 5- Dll Binding Tests
In PlayBasic we can use system & custom external DLL's in a handful of ways, from dynamically calling the functions (CallDLL) through to binding them (via LinkDLL) so they appear as if they're internal functions. The latter is the better solution since the function pointers are resolved before program execution starts. When we use CallDLL, the operation has to solve the function pointer each call. It's not a huge overhead, but an overhead none the less.
Using DLL's can have a few issues tho, most notably that windows doesn't provide native 'load from memory' functionality. So If you write a custom expansion dll, then you're basically giving this code away every time you share the final program. In newer prototypes of the runtime (VM3) we've solved this problem already, but i've been wondering if it'd work in the legacy runtime at all ? And Yes.. it does.. sort of 
So tonight's testing has been focusing on wedging the alternative loader layer into the runtime. In the test any dll linked with linkdll, is pre loaded into a chunk of memory and then manually initialized for execution. It's just defaulting to this behavior since it's the least amount of work required. After a few little catch 22 hiccups the test dll's seems to be working as normal.
Therefore, it appears that we should be able to bind custom dll's (dlls your program uses, NOT PB DLL's) into final EXE. There's probably some DLL's where this won't work (like wrappers of wrappers), but ya get that !
PlayBasic V1.64O Beta 5- Resource Manager
Since DLL binding is working in the test, but there needs to be a system where the compiler/runtimes can attach/fetch linkdll resources as need be. To do this, I've got to build a resource manager with searching facilities into the core. Like most things, this turns out to be a little more work than i'd like, but the current incarnation seems to run pretty well (given limited testing). Each resource has it's own name (string), rather than hard pointer, allowing high level services to query the resource buffer for media by name, before continuing on an loading the thing off disc if it's not present. So in theory, pretty much anything could be attached and bundled in the same manner.
Managing the resources at runtime is one part of the problem, but the resource buffers also need to be included the byte code hunk. This is the point i'm at this afternoon, tentatively trying to solve some of the logic problems. But i think we'll get there in some way, shape or form, even if the first solution isn't as clean as I'd like.
PlayBasic V1.64O Beta 5- Dll Resource Binding is a Go
Today's (well last nights) build of Beta 5, has binding up and running. Allowing 3rd party dll's to be packed into EXE modules, and loaded/ initialized from memory during compile and execution time also. To do this, the programmer simply adds an asterix character to the start of the LInkDLL declaration and PB does the rest.
ie
; PlayBasic expects to load this DLL from disc.
linkdll "Test.dll"
Myfunction() alias "NameInDll"
endlinkdll
; This tells PlayBasic to import this dll as a resource
linkdll "*Test.dll"
Myfunction() alias "NameInDll"
endlinkdll
The only thing that I can see that's left to do, is try and drop some error messages in place of some of the little debug messages that can occur when somethings wrong. Namely if the DLL you try and bind can't be found.
READ BLOG
|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
