> On 20 Feb 2018, at 4:44 pm, Brian Milby via use-livecode
> <email@example.com> wrote:
> I was finally able to get the init to return a 0 or 1 (success or already
> initialized). I switched to `code\x86-win` - not sure if that had any
> effect based on the other major change I made…
I think it will find both win and win32 in the IDE at the moment. I have just
submitted patches. It’s bug 20991.
> Turns out I was using the wrong version of the dll. If anyone else wants
> to try, here's the path that actually worked:
> \libsodium-1.0.16-msvc.zip\Win32\Release\v100\dynamic\libsodium.dll (2
> other files there that I included as well)
> I was initially trying a different archive, but then switched to the msvc
> version. I started with v141 which didn't work. I went ahead and tried
> v100 which did. There are also v110, v120, and v140. I don't know what
> the differences are, but at this point am just happy that I can get the
> library initialized. I'll eventually try others and try to figure out what
> the numbers mean.
These are VS toolchain versions. v140 is 2015 and v141 is 2017. I’m not sure if
dynamic in that path refers to it being a dll v lib or the CRT linking. If
there’s a folder with static/libsodium.dll then use that. It may be that
resolves your issue with v141...
> @Monte, I was using __safe based on a thread that Mark W commented in on
> the forum. Essentially if the library is returning just an integer then it
> would probably be safe.
Ah, well, I’m not as smart as Mark so I just let everything that’s not in the
engine default to unsafe ;-)
> Thanks on the hints on sending data to the library. I'm also going to need
> to receive keys back from the library. I'm guessing that where it is
> listed as pK that it will overwrite the data in the passed in string.
> There are other calls that use a pointer and a length as separate arguments
> to the function, so the calls provided will be useful there (those are for
> encrypting/decrypting content). I'll probably need to dive into the source
> to understand that a bit more (unless their api docs cover it).
So you need a buffer as inout for the library to write to? Something like this.
__safe foreign handler MCDataCreateWithBytesAndRelease(in pBytes as Pointer, in
pCount as LCUIndex, out rData as Data) returns CBool binds to "<builtin>"
__safe foreign handler MCMemoryAllocate(in pSize as LCUIndex, out rBlock as
Pointer) returns CBool binds to "<builtin>”
__safe foreign handler MCMemoryDeallocate(in pBlock as Pointer) returns nothing
binds to "<builtin>”
variable tBuffer as Pointer
if not MCMemoryAllocate(32, tBuffer) then
throw “uh oh”
variable tData as Data
if not MCDataCreateWithBytesAndRelease(tBuffer, 23, tData) then
throw “uh oh"
> Now that I can actually talk to the code, I should be able to experiment.
> Here's something that I got working to return the version:
> private __safe foreign handler _sodium_library_version_major() returns CInt
> binds to "c:libsodium>sodium_library_version_major"
> private __safe foreign handler _sodium_library_version_minor() returns CInt
> binds to "c:libsodium>sodium_library_version_minor"
> public handler sodiumVersion() returns String
> variable tResult as String
> put "Version " into tResult
> put _sodium_library_version_major() formatted as string after tResult
> put "." after tResult
> put _sodium_library_version_minor() formatted as string after tResult
> return tResult --"Version 10.1"
> end handler
> use-livecode mailing list
> Please visit this url to subscribe, unsubscribe and manage your subscription
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription