Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Lua ➜ Extending Lua scripting with your own code
Extending Lua scripting with your own code

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 3  

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #15 on Thu 06 Jul 2006 01:45 AM (UTC)
Message
Hmm. Yeah. After some further consideration, you're right. And dlls need to use some "similar" standard method, otherwise you couldn't link them using something like Lua. Without a static or some dynamic way to gain it at runtime, there is no way to determine the entry points at all. Some method is needed to tell the instancing program where the entry points are, even if its not the identical one of QueryInterface. IDispatch is, so far, not even mentioned. This tends to make me suspect that it is an MFC function, not a direct connection to QueryInterface. In essense, when you use the IDispatch methods you are letting MFC handle the dirty work of finding and returning the entry points. This is fine, except MFC doesn't provide a parallel method to the connection point system, nor does it allow "direct" means of handling some, so called, design type properties, which may in some case be useful to have a way to adjust.

Anyway. My main point is that after several false starts, I think I now have a fairly clear idea what the missing bits are that are needed to handle events. Its all in the OLE system. The problem is, you have to use raw C++ to code it, well, besides the OLE parts, because MFC, ATL and nearly every "high level language", buries the functionality behind its libraries, where you can't get to it and don't even know that it exists. Heck, I don't think you can even enumerate properties or interfaces in MFC, without resorting to purer COM functions.

Yeah, I kind of confused things a bit. I took the opertunity to cross over to another subject that I had brought up several times before, without "quite" knowing what I was trying to actually do. I went through two books, ATL Internals, trying to find the ATL solution, which I didn't, and then Essential COM, by Don Box, which helped a lot, but tended to go "way" to much into the theory of how it worked, without quite providing practical examples and tended to gloss over the stuff I wanted to find out about. I am now reading Inside Ole, which unfortunately was written by MS. And if you know anything about how MS writes things, you know that practical examples, instead of comvoluted techinical explanations that can sometimes confuse you more than you started, isn't exactly high on there list. Its like reading a history book, with all the dates and general themese intact, but no names of places, people or context to identify whose history it is refering too. lol

Well, OK, not that bad, but without a compiler to fiddle with the code in, its not as useful as one concrete example, or even some, "Here is a simple program that does X and uses everything you will learn in this book. Now lets see how to do it.", type book. Its more like, "Here are fifty 5-20 line examples, program scraps and fragments of things that don't "quite" do anything. Hopefully you can use this to write a coherent application that *actually* does do something." ;) I am not sure which is worse, the boredom or the incoherent way it skips from one subject to the next, without bothering to "quite" connect it all together. lol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #16 on Thu 06 Jul 2006 11:10 AM (UTC)
Message
No, really, the linking is done by the operating system. What MFC and COM and all that provide is a higher level of abstraction, where you only need to know of one entry point, and from there you can explore the other "exposed" interfaces. But the interfaces are exposed on very different levels.

Standard DLLs on Linux/Unix, for instance, (and, again, on Windows) have none of this MFC/COM/ATL/etc. stuff; the programs simply leave symbols unresolved at compiler-link time, and the symbols are resolved by the operating system (well, the C runtime library might be more accurate) when it loads up the DLL for dynamic linking.

For standard DLLs the linking is also "hidden" (normal quotes, not weird emphasis quotes :P). That might be why you aren't finding it... you won't find it anywhere in the code, because it's a service the environment provides for you.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #17 on Thu 06 Jul 2006 07:01 PM (UTC)
Message
Sigh. pp59 Paragraph 3, of Inside OLE: "First of all, no OLE tool I know, even MFC, has direct and explicit support for absolutely every OLE feature that we'll be covering."

Straight from the horses mouth (its an MS published book). Abstraction layers, whether things like MFC, or higher languages, "Do not support", everything that OLE does. I am not finding it, because unless you use OLE directly, it is not available. Hidden in this case means, "You can't use that at all." MFC doesn't expose connection points at all, ATL does, but you have to do some convoluted things to make them work, *neither* support access to design time properties or user_mode, other than to read it, so you can't make a form that lets you drag and drop objects, at least without faking the whole process and adding your own drag handles. And that is a bit like strapping your inflatable boat to a dingy, because you can't figure out how to inflate it, but you still want to use it to row to across the bay.

I know there just provide different levels of abstraction. The whole point of my research is to figure out how to get around the stuff those abstraction layers "don't allow", so some things in Mushclient can be a) easier, b) possible at all in some cases, or c) done without the user doing the same sort of research I have had to, in order to figure it out in the first place.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #18 on Thu 06 Jul 2006 07:40 PM (UTC)
Message
I think you didn't quite see what I meant. I'm talking about something much more fundamental than MFC, OLE, etc. DLLs use technology that really, honestly, is quite independent of OLE. It just so happens that OLE is basically (emphasis on basically) a layer of abstraction on top of DLLs, and COM etc. are a different layer of abstraction.

Would it be possible for you to give a very short summary of what exactly you're trying to do? I get a little confused reading through your long posts because you mix a lot of terminology and it's hard to follow. Maybe if we keep this really straightforward, things will start coming together.

For example you are using 'linking' when speaking of DLLs in a way that is not appropriate. Linking, as done by DLLs, is something very particular that is independent of all these other techniques. When words are used in ways that aren't their conventional meaning, it's hard to follow.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #19 on Fri 07 Jul 2006 10:41 PM (UTC)
Message
Ok, first, lets drop the whole bloody DLL vs ActiveX stuff. That was "never" the intent of what I was saying, beyond mentioning the similarities, which I only recently have come to understand to a reasonable degree. I simply used the similarity to sideline into another issue.

That said, I take it you haven't read "any" of my other posts on the subject I am trying to talk about? Lets try to put this simply then.. Right now there are three ways to create windows, mappers, or any other feature, and have them talk to Mushclient.

1. Link the TLB for Mushclient into them and use CallPlugin.
2. Use UDP.
3. Create a ghost world and use TCP/IP.

The problem with "all" of these solutions is two fold. First, you can't use a control or program you did not **specifically** write for Mushclient, unless its "only" interfaces are one way. I.e. You can, like a database, pass them the "location" you want the response to go in, if they respond, but not let them respond "later", when they are done with some task. Second, they are all basically work arounds, with CallPlugin being the only one that comes even "close" to letting the applications talk directly to your script. This means that existing applications or controls are unusable, if they expect the client that asks to use them to get their response directly, through and event. Only those you can create a sort of Mushclient aware shell to fit in, or you stick on an application of your own (basically the same thing), can talk to Mushclient, indirectly.

This also has another side effect. Anything like custom windows, new notepad windows, etc., all have to be included "in" Mushclient itself, even of some languages, including Lua, make handling those thing from the script trivial, if often requiring, the right addon libraries. Why? Because even "with" those libraries, there is no way to link something as simple as a button click to your script. The script simply cannot ever tell the connection point, "When someone clicks this button, call this script function."

Think about it. That leaves *huge* gap in what you can do. It also means that any potential solutions have to be hard coded into Mushclient, which leaves Nick as the one that has to decide how they should work, not the people that get the idea in the first place, who are not always happy with the solution Nick comes up with.

What I would like to be able to do is create a plugin that can do roughly the following:

win = createobject("Some window object")
win.parent = GetFrame
button1 = createobject("VBButton")
button1.parent = win
button1.lable = "Press me!"
...
Advise ("Button1_Click", "OnBut1_Click")

function OnBut1_Click ()
  note "Someone clicked me!!"
end function

In other words, skip the whole insane mess needed to indirectly make this work. Have the plugin itself define, say, a window that contains icons, to keep track of your spells, let the script respond to clicks on them that are intended to recast the spell, etc. And **not** require that every poor user that wants to do this has to buy a $600 compiler and either dozens of books on how to do anything, or get a college degree, just to write a completely seperate program, which then has to be installed some place, to stick a few pictures in a window. Imho, this is completely rediculous. And it limits even what those of us that can do these things are able to do with the client, because we spend almost as much time trying to figure out how the program should talk to the script as we do designing the program.

A good example of this is the recent mapper. Why? Because I am sure the zMud mapper uses DLL interfaces of ActiveX, which means it "should be" possible to tie it into a Mushclient script, but not if all out-going intefaces are disabled, because the script can't connect them. The solution will invariably be so Mushclient centric that its non usable for anything else, or so generalized, that we have to resort to TCP/IP or UDP to make the connections instead, one of which doesn't always work well, and the other of which requires a imho bizzare hack that, while it works, simply clutters the client with extra worlds that are not invovled in "any" direct game playing.

However, more to the point.. I wouldn't mind seeing, as part of these plugins, something that could read in a "description" of the window you want and another "design" plugin that uses the user_mode switch for its window, so you can *actually* create, place, resize, rename, relabel, etc. the controls you want, save the result to a file, and then import it to your new plugin to provide a pre-designed window of any kind you want. That also requires more direct access to the controls, since all MFC and ATL solutions "assume" that the code that does this is referring to "the window that the code itself belongs too." Or at least, there is no indication how you tell it to change that for any window except the active one, which we absolutely don't have to have happen. Imagine Every window, control and button in Mushclient's main window suddenly becoming movable... while at the same time "all" of the windows controls, buttons, menus, etc. are diabled and stop working. Very bad idea... lol

So, what we need is:

1. Some way to use IUknown::Advise to link a script to the events.
2. Some way to access Ambient_UserMode, but limit it to only script created windows.

Having those, we can create a form designer plugin *and* build damn near anything we want "in" the client, instead of hoping someone with a Bachelors degree, or better, in programming, and the money to buy the tools, decides to bother making some gadget everyone would like to have.

This is in essense what I would like to see be possible. It bugs me that the script languages "can" be extended with readily available libraries for a lot of it, but two relatively minor limitations prevent it from working at all. Or that when Nick does agree to add something, its by hardcoding it into the client, when imho that should be necessary, or for that matter, always desirable.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #20 on Fri 07 Jul 2006 10:58 PM (UTC)
Message
I find it very hard to read your posts like this one and understand what you mean, but it seems that what you really are asking for is to have MUSHclient provide a VB form design environment of some kind. The reason the "whole bloody DLL vs ActiveX stuff" is important is that you need to get terms right if we're going to communicate meaningfully. I'm starting to realize that I misunderstood a lot of what you've said so far because you're using terms in a rather unconventional and confusing way.

I can't help but think that what you call "relatively minor limitations" are a lot more fundamental than you seem to acknowledge. I mean, this stuff can't just work by magic, and to get this stuff working, Nick would have to hard-code in some kind of well-known interface that everything understands. You can't just get it working without having an interface for things to happen.

For example, if you want to use COM (which seems to be what you want with this 'Advise' stuff) then MUSHclient would have to act as a fully functional COM control server, with all the ups and downs that go with that.

It would help me understand if you didn't go into lengthy discussions about problems, and you instead formulated precisely the requirements of what you're trying to do.

Maybe you could write your own skeletal application that demonstrated some of this in action, so that we could have a proof of concept of how this would actually work?
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #21 on Sat 08 Jul 2006 01:06 AM (UTC)
Message
Quote:

win = createobject("Some window object")
win.parent = GetFrame
button1 = createobject("VBButton")
button1.parent = win
button1.lable = "Press me!"
...
Advise ("Button1_Click", "OnBut1_Click")

function OnBut1_Click ()
note "Someone clicked me!!"
end function


OK, here is the problem. Your plugin has created an object, which is a button. It isn't clear to me right now where that button is going to go but nevermind that.

Now MUSHclient knows absolutely nothing about this button, as it was created by a script. It doesn't know its window address (handle or whatever), its ID or any identifying details. As far as it is concerned the button doesn't exist.

Now you have called a function Advise passing it two strings: "Button1_Click" and "OnBut1_Click". The second is obviously the script you want called, but how is MUSHclient supposed to translate a "click" message on a window about which it knows nothing, and may possibly never even get, to be something to do with "Button1_Click"? The word button1 is just an identifier local to your script.

I can't begin to get my head around how this might work, sorry.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #22 on Sat 08 Jul 2006 04:48 AM (UTC)

Amended on Sat 08 Jul 2006 04:49 AM (UTC) by David Haley

Message
It's a very VBish way of doing things. In VB if your button control is named "Button1" then the click event is "Button1_Click" (or Button1_OnClick, something like that). Basically to get that working you would need control over the windowing components Shadowfyr wants to create, which would mean that you would have to provide the scripting functions, and which basically means you would have to in a sense reimplement a lot of what VB and similar languages provide in terms of a GUI management system.

To clarify, Button1_Click is not really the event, rather, it's the name of the subroutine that is called when the button is clicked. So it's the event in a sense, but it's more than just that because it's truly a function.

Unless Shadowfyr has some tricks up his sleeve that he hasn't revealed yet, I am also completely stumped as to how this is supposed to work without MUSHclient being turned into a full-fledged widget application. (And that seems to go against the stated requirement that the plugin author be free to do whatever s/he wants, because the author would be "stuck" with whatever interface MUSHclient provides.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #23 on Sat 08 Jul 2006 06:18 PM (UTC)

Amended on Sat 08 Jul 2006 06:24 PM (UTC) by Shadowfyr

Message
Ok Nick. Here is the thing. From what I have been reading, Mushclient doesn't **need** to know **anything** about the button at all. Seems strange right? But you have to realize that what COM is really doing, under the hood of MFC, where you can't see it, is getting the entry points for "Mushclient's" functions, then passing those pointers to the Advise function in the ActiveX control. Every single button, window, etc. that Mushclient uses is part of the comctl32.dll or other system components, all of which are ActiveX and all of which use Advise and Unadvise to connect their "out bound" functions to the places in your program that need to be called by them, for you to know if someone clicked on something like the "Reload Script" button in the client.

The *only* difference between creating and object "after" you compile the program or "before" is that the compiler can pre-determine the correct function locations in your application, so that it can "Advise" the controls of the correct place to call, without having to figure that out when the program starts every time.

Now, when ever you create something like a callback for plugins or scripts, you are basically replicating what is being done in COM. You are fining the correct "location" in the script to call for that callback, if it exists, storing that someplace for later use, then calling it when your "event" happens, which in this case is something like OnPluginInstall. With COM this works similarly, only instead of the "client" keeping track of the connections, COM does. My example isn't totally accurate, its an approximation. The Advise step would look more like this:

' I assume for consistency MS uses the same IID here, but I can't be sure.

IID_Click = &h(blah)

' This is the "location" of the script entry point for the function, name it what ever you want,
' but I happen to think VB's way of doing it is clear on what you're getting.

ptr = GetRef("OnBut1_Click")

' Tell button1's COM connection point handler that I want the function at "ptr" called when
' someone performs "IID_Click", or in other words, clicks on the button.
' NOTE: This may be button1.IUnknown::Advise. The documentation isn't "real" clear to
' the point I have read so far, since it tends to give examples of how things "work" not how
' you actually bloody use them. :p

button1.Advise (IID_Click, ptr)


Mushclient, assuming it "had" the ability to do this, "still" would *still* have no idea that the window you created "or" the button exists at all, all it would ever see is a request to pass the correct event number, and the script function pointer, to the buttons own event handler, which is simply an internal table that it uses to track a) which events are connected to other applications and b) which functions to call when those events happen.

In fact, the reason it works this way is that, unless you explicitly code the object to not allow it, it doesn't even care how many different things are being informed (having their functions called), as long as they are all valid pointers. You could just as easilly do something like this:

IID_Click = &h(blah)
ptr = GetRef("OnBut1_Click")
ptr2 = GetRef("OnBut1_Fud")
ptr3 = GetRef("OnBut1_Gunk")
ptr4 = GetRef("OnBut1_Ohwhatthehell")
button1.Advise (IID_Click, ptr)
button1.Advise (IID_Click, ptr2)
button1.Advise (IID_Click, ptr3)
button1.Advise (IID_Click, ptr4)

The button would try to call "all" of them when you clicked on it, assuming that its not designed to return a failure when you request more than one connection.

Now, I can see "one" reason why Mushclient may need to know that the window and button exist. Its highly unlikely that reloading a script will "correctly" unload such objects, which means you could have a window with a button on it, which suddenly no long had the function it needed to call to work properly. Click the button and "boom!!". The fix to this "would" require Mushclient to be aware of things. It would need to create the object itself, or at the bare minimum, keep track of it, so that if someone reloads a script/plugin, it can "Unadvise" the objects of the previous pointer, recalculate the correct pointer for the script function then "Advise" the object of that new location. Same with if someone uninstalls a plugin, it would need to Unadvise, then release the objects. But this is a matter is safety, not an absolute necessity. Assuming no one ever reloaded, reinstalled or uninstalled plugins or scripts, the problem would never arise. And I am only "assuming", based on how I understand things working, that the window and button would remain behind if the script was reloaded, instead of being automatically released. I have certainly had some strange crashes when playing with the ActiveX Winamp control, but I haven't "quite" been able to figure out what caused them. It might be, instead, due to the script trying to call an object it thinks still exists, after Winamp has closed and unloaded the control.

Anyway, I hope I have explained better. Its not the application that handles who talks to who and when, its the object itself doing that. All the applications do is tell the object what they should call, in themselves, or in a script they are running, when something happens. Its the ActiveX object that keeps track of who to call and how many there are that need to be called when something happens. The application, except for a case like above which "may" be a problem, or may just be my paranoia, never even needs to know the object in question exists or what it is.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #24 on Sat 08 Jul 2006 09:52 PM (UTC)
Message
Quote:

Every single button, window, etc. that Mushclient uses is part of the comctl32.dll or other system components, all of which are ActiveX and all of which use Advise and Unadvise to connect their "out bound" functions to the places in your program that need to be called by them, for you to know if someone clicked on something like the "Reload Script" button in the client.


I hate to disillusion you, but most of MUSHclient does not use COM at all. I can prove this to you. One of the first things MUSHclient does (after parsing the command-line parameters) is to check if you used the /wine option, and if not, initialize COM:


// initialise COM

  if (!bWine)
    CoInitialize (NULL);


You can look up this function on the Net, but this is the help that ships with their compiler:


CoInitialize

Initializes the COM library on the current apartment and identifies the concurrency model as single-thread apartment (STA). Applications must initialize the COM library before they can call COM library functions other than CoGetMalloc and memory allocation functions.


Now in case there is confusion, let's check the definition for ActiveX from their help:


ActiveX

A set of technologies that enables software components to interact with one another in a networked environment, regardless of the language in which they were created. ActiveX™ is built on the Component Object Model (COM).


So, the bottom line is, if you run MUSHclient with the /wine option (provided for Linux users) then it doesn't initialize COM, and therefore cannot use ActiveX either.

So, walk over to your PC and run MUSHclient with the /wine option. You won't be able to use VBscript (which uses COM) but 99% of it works - buttons, menus, windows etc.

My point is that MUSHclient does not use COM or ActiveX "underneath" to do everything, and thus there is no "missing link" that I am refusing to provide that will link it to your ActiveX controls.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #25 on Sun 09 Jul 2006 05:39 PM (UTC)
Message
Hmm. Ok. I think there is a secondary way you can get at many of those controls, so I am wrong in that respect. I am not wrong in how COM itself works in this respect. I'm reading the bloody book on it right now, which explains in detail how the COM system was developed, what it does and how it works. I got the comctl32.dll = part of COM detail wrong. So sue me. That doesn't change *why* things won't work when trying to deal with events, or alter the fact that buttons, windows, etc. that "are" accessable as COM objects "do" work the way I am describing.
Top
Posted by Morat   (18 posts)  Bio
Date Reply #26 on Fri 08 Jan 2010 01:36 PM (UTC)

Amended on Sat 09 Jan 2010 03:26 PM (UTC) by Morat

Message
How do I build a working test.dll file with MUSHclient 4.43 using Visual C++ 2008 Express?

test.c

#ifdef _WIN32
#define LUA_API __declspec(dllexport)
#endif

#pragma comment( lib, "lua5.1.lib" )

#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
#include "luaconf.h"

#define PI (3.14159265358979323846)

static int miles_to_km (lua_State *L)
  {
  double miles = luaL_checknumber (L, 1);
  double km = miles * 1.609;
  lua_pushnumber (L, km);
  return 1;   /* one result */
  } /* end of miles_to_km */

static int circle_calcs (lua_State *L)
  {
  double radius = luaL_checknumber (L, 1);
  double circumference = radius * 2 * PI;
  double area = PI * radius * radius;
  lua_pushnumber (L, circumference);
  lua_pushnumber (L, area);
  return 2;   /* one result */
  } /* end of miles_to_km */

static const luaL_reg testlib[] = 
{
  {"miles_to_km", miles_to_km},
  {"circle_calcs", circle_calcs},
  {NULL, NULL}
};

/*
** Open test library
*/
LUALIB_API int luaopen_test (lua_State *L)
 {
  luaL_openlib(L, "test", testlib, 0);
  return 1;
 }


files

lua.h      (www.gammon.com.au/files/mushclient/lua5.1_extras/lua5.1_lib.zip)
lualib.h   (www.gammon.com.au/files/mushclient/lua5.1_extras/lua5.1_lib.zip)
lauxlib.h  (www.gammon.com.au/files/mushclient/lua5.1_extras/lua5.1_lib.zip)
luaconf.h  (www.gammon.com.au/files/mushclient/lua5.1_extras/lua5.1_lib.zip)
lua5.1.lib (C:\Program Files\MUSHclient\lua5.1.lib)
lua5.1.dll (C:\Program Files\MUSHclient\lua5.1.dll)


options in VC++

project type: Win32 Project
application type: DLL
added directories for include and library files
renamed test.cpp to test.c
selected "Not Using Precompiled Headers" in test.c property page
all other settings are default


error message in MUSHclient

assert(package.loadlib("test.dll", "luaopen_test"))()

Error number: 0
Event:        Run-time error
Description:  [string "Command line"]:1: The specified procedure could not be found.
 
stack traceback:
	[C]: in function 'assert'
	[string "Command line"]:1: in main chunk
Called by:    Immediate execution


I built a working test.dll file using MinGW (GCC).

gcc -shared -o test.dll test.c -L.\ -llua5.1
gcc -mno-cygwin -shared -o test.dll test.c lua5.1.dll


And I can get the original test.c working with MUSHclient 3.79 using Visual C++ 2008 Express and also using MinGW (GCC).
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #27 on Fri 08 Jan 2010 07:24 PM (UTC)
Message
Sounds like _WIN32 is not defined. Try adding:


#define _WIN32


... to the very first line of the .c file, or maybe adding in _WIN32 as a define into the project properties.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Morat   (18 posts)  Bio
Date Reply #28 on Sat 09 Jan 2010 09:48 AM (UTC)

Amended on Sat 09 Jan 2010 03:31 PM (UTC) by Morat

Message
MUSHclient gives the same error when #define _WIN32 is at the top.

I read about dependency checkers on the package.loadlib doc page.

http://en.wikipedia.org/wiki/Dependency_Walker

The MinGW test.dll file has an entry point and requires these .dll's:

kernel32.dll
lua5.1.dll
msvcrt.dll
ntdll.dll

The VC++ test.dll file does not have an entry point and requires these .dll's:

kernel32.dll
lua5.1.dll
msvcr90d.dll
msvcrt.dll
ntdll.dll

I guess I'm not settings the correct build options.

Thanks for the response.
Top
Posted by Morat   (18 posts)  Bio
Date Reply #29 on Sat 09 Jan 2010 05:29 PM (UTC)

Amended on Sat 09 Jan 2010 05:31 PM (UTC) by Morat

Message
Okay got it working :)

The following code works with MUSHclient 4.43 using Visual C++ 2008 Express and also using MinGW (GCC).

test.c

#pragma comment( lib, "lua5.1.lib" )

#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
#include "luaconf.h"

#define PI (3.14159265358979323846)

static int miles_to_km (lua_State *L)
  {
  double miles = luaL_checknumber (L, 1);
  double km = miles * 1.609;
  lua_pushnumber (L, km);
  return 1;   /* one result */
  } /* end of miles_to_km */

static int circle_calcs (lua_State *L)
  {
  double radius = luaL_checknumber (L, 1);
  double circumference = radius * 2 * PI;
  double area = PI * radius * radius;
  lua_pushnumber (L, circumference);
  lua_pushnumber (L, area);
  return 2;   /* one result */
  } /* end of miles_to_km */

static const luaL_reg testlib[] = 
{
  {"miles_to_km", miles_to_km},
  {"circle_calcs", circle_calcs},
  {NULL, NULL}
};

/*
** Open test library
*/
LUALIB_API int __declspec(dllexport) luaopen_test (lua_State *L)
 {
  luaL_openlib(L, "test", testlib, 0);
  return 1;
 }
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

126,631 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home