Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Debugging .NET and other LSAPI applications

You can generate a trace of all the LSAPI calls thusly:

apitrace = on
logfile = c:/temp/amzilog.txt (or something like that)

in the amzi.cfg file. That will show you what’s going back and forth. This will let you know how far the program gets and where, if any, problems are.


  • I use this way to show yout messages in the tracelog:

    Amzi! Log File August 14, 2016 05:43 PM

    Using Locale: Spanish_Panama.1252
    lsInit(000001D5E4C07330, )
    returns OK
    lsLoad(000001D5E4C07330, C:\Users\Luis\Desktop\PROYECTO TESIS MSE\Proyecto_VBNET\Pruebas de Concepto\PruebaAmziFull\pets.xpl)
    lsInitLSX(000001D5E4C07330, 0000000000000000)
    returns OK
    returns OK
    lsRetractStr(000001D5E4C07330, sound(_))
    returns FALSE
    lsAssertaStr(000001D5E4C07330, sound(woof))
    returns OK
    lsExecStr(000001D5E4C07330, 0000009F6E9BE110, pet(X))
    returns TRUE,
    term bound to: pet(dog)
    time in milliseconds = 0
    lsStrArgLen(000001D5E4C07330, FFFFFFFFE50186B0, 1)

    Any ideas or suggestions..???
  • Thanks for your patience! This did reveal a bug in the amzinet interface. You can see that the pointer is smashed in the second argument to lsStrArgLen. Prolog 'TERM's, which are pointers internally, are cast to and from integers in amzinet.cpp. Mistakenly, 'long' was used for all of these, but 'long' in Visual Studio C++ is 32-bits in 64-bit machines. (It's 64-bits in C#.) So pointers were being truncated. But, this only manifested itself as a problem when the actual addresses needed more than 32-bits. Otherwise the truncation didn't hurt anything.

    I've updated the source on github for amzinet.cpp. You can download it and rebuild it yourself if you would like. I'll also send you an email with the new DLL in case you don't want to rebuild yourself. Please test it and let me know if it works, because the problem does not manifest itself on my machine, but will on yours.

    Note also, that in PetForm.cs in line 140 the term needs to be defined as 'long', which is 64-bits in C#.

  • Ok.Dennis.. don't worry about it... i figured out that you was working on solution...Could you share with me the dll file...? please..... Regards
  • It's on the way! Send me a private email if you haven't gotten it.
  • Hi Dennis... the issue is fixed.... i executed project with a new dll file... and run without problem and return correct value.... Thank u so much...
  • edited August 2016
    I created a new 64-bit distribution, 10-0-5, that includes the fix mentioned above.
  • I recently had this conversation on email with a user:

    I have just signed up to the forum and down loaded and installed the new x64 bit 10.0.05 release from the web site. No problems so far however the LS reports as 10.0.04 64bit. Can I assume that this is an error and the release is actually 10.0.05?

    The reason for the interest is that on one of the forum threads I notice that 10.0.05 64bit is a recent release which fixed a problem with longs which sounds similar to the problem you help me to resolve on 9.5.2 64bit last year.

    Correct. Seems I have a versioning problem. The core engine did not change, so the release number didn’t go up. The fix was only in amzinet.dll, the 64-bit version of the Windows DLL implementing the .NET interface to Amzi!. It should really have it’s own release number, as should the other such modules.

    I put this out as maybe an open source project one might wish to take on? When maintaining the system as a whole, the one version number for everything worked. But now, with people able to update, for example, the .NET amzinet.dll file independent of the rest…

Sign In or Register to comment.