Hi Paul, Thanks for the quick response. One problem is that the module loader loads winapi.dll from ZBS/bin before it checks the current directory, so it is always loading the wrong version. If I try to load a non-existence winapi2.dll, the output is like: no file 'C:\Users\derek.bailey\Documents\ZeroBraneStudio\bin\winapi2.dll' no file 'C:\Users\derek.bailey\Documents\ZeroBraneStudio\bin\loadall.dll' no file '.\winapi2.dll' I assume I could change the package loader function so it searches the local directory first, but that seems a little tacky to me just to solve this one issue. Take Care, Derek On Tue, Mar 24, 2015 at 1:49 PM, Paul K <paul@xxxxxxxxxxxxx> wrote: > Hi Derek, > > > But I get a hard crash from Lua (Windows Messagebox: "lua52.exe has > stopped working") during execution. I am using the Lua 5.2 exe included in > ZBS, and I am running it form a windows machine. > > The crash you see is because winapi.dll that ships with ZBS is > compiled against Lua 5.1 API, which is incompatible with Lua 5.2 API. > Since you are using Lua 5.2, you need to use the version compiled for > Lua 5.2, as you did. Just don't replace the winapi.dll that comes with > ZBS, but instead put winapi.dll into your project folder. > > I expect this to work, but if it doesn't (and ZBS still loads > bin/winapi.dll, which leads to a crash), let me know as I've been > considering moving winapi.dll to bin/clibs/ folder, which should > eliminate this issue. > > > I would prefer to use the one included as I don't have to worry about > installing it. > > I realize that it's convenient to have libraries readily available, > but I'm trying to keep ZBS compact and am only including those > libraries that are either needed for its own work (like wxlua and > winapi) or libraries needed for debugging on Lua interpreters shipped > with ZBS (like luasocket). The former libraries are only available for > Lua 5.1 ABI and the latter are compiled for Lua 5.1, 5.2, and 5.3 > versions (for all supported platforms). I'm also considering packaging > lpeg, but mostly because of its wide use and some of the modules that > depend on it that I plan to use in ZBS. > > Paul. > >