#exult@irc.freenode.net logs for 8 Jul 2003 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[01:05:47] --> Kirben has joined #exult
[01:05:47] --- ChanServ gives channel operator status to Kirben
[01:54:34] --> ShadwChsr has joined #exult
[01:54:36] <ShadwChsr> hey :)
[02:15:04] <-- Eclair has left IRC ("Who turned out the lights?")
[02:56:37] <-- Matt_O has left IRC (Remote closed the connection)
[02:58:19] --> animeloe has joined #exult
[02:58:25] --- animeloe is now known as Eclair
[03:05:29] <-- Eclair has left IRC (Remote closed the connection)
[03:22:14] <-- ShadwChsr has left IRC ()
[03:28:33] --> animeloe has joined #exult
[03:28:39] --- animeloe is now known as Eclair
[03:37:54] <-- Eclair has left IRC (Read error: 104 (Connection reset by peer))
[03:43:43] --> Matt_O has joined #exult
[03:54:11] --> animeloe has joined #exult
[03:54:17] --- animeloe is now known as Eclair
[04:39:38] <-- Eclair has left IRC (Read error: 54 (Connection reset by peer))
[04:41:30] --> animeloe has joined #exult
[04:41:36] --- animeloe is now known as Eclair
[05:33:59] <-- Eclair has left IRC ("Who turned out the lights?")
[05:57:24] --> animeloe has joined #exult
[05:57:30] --- animeloe is now known as Eclair
[07:42:10] <-- Matt_O has left IRC (Remote closed the connection)
[08:00:27] --> Matt_O has joined #exult
[08:38:00] <-- Matt_O has left IRC (Remote closed the connection)
[10:36:22] <-- DarkeZzz has left IRC (calvino.freenode.net irc.freenode.net)
[10:36:59] --> DarkeZzz has joined #exult
[10:45:59] --> Fingolfin has joined #exult
[10:45:59] --- ChanServ gives channel operator status to Fingolfin
[10:46:57] <Fingolfin> yo
[13:14:20] <-- Fingolfin has left IRC ("42")
[13:25:09] --> Colourless has joined #Exult
[13:25:09] --- ChanServ gives channel operator status to Colourless
[13:25:45] <Colourless> hi
[13:53:20] <Colourless> Artaxerxes: no, such a thing will not work in windows with dynamic link. There are 'hacks' that you could use, but i really wouldn't want to do them i.e. get the plug to be linked to the exe file as if it were a library. Doing that is not a good idea, even though it
[13:53:23] <Colourless> 's possible
[14:21:25] <Colourless> i will not port smooth until you clean up all the undefined references (to functions). Your code as it currently stands, is not portable
[14:22:10] <Colourless> you also tend to be changing return types of the functions pointers
[14:22:18] <Colourless> last things to make it easy to port
[14:22:36] <Colourless> make the handle to the dynamic library a typedef'd type
[14:23:46] <Colourless> don't directly use dlsym. instead make a function that calls it in plugin.c
[14:24:27] <Colourless> in the plugins, themselves, __attribute__ ((constructor)) and __attribute__ ((destructor)) are not portable
[14:24:48] <Colourless> if you want init functions for your plugin, create another file that can be imported by all the plugins.
[14:25:33] <Colourless> in that file include the constructor and destructor functions, which then call functions like init_plugin() and deinit_plugin().
[14:26:14] <Colourless> that will make it easy to call the same functions in windows to init/deinit the plugin
[14:56:10] <DarkeZzz> Avoid __attribute__((constructor)) like he plague. If you use it you've essentially made your application non-deterministic as to how/when/if that particular constructor is actually called in relation to shared libraries. Depending upon compiler version used, compiler version used for the libraries, patches to compiler, and I wouldn't be surprised the phase of the moon. *grin*
[14:56:15] <DarkeZzz> s/he/the/
[14:56:44] <-- Kirben has left IRC ("System Meltdown")
[14:57:22] <DarkeZzz> IIRC, there's a couple of bugs in the gcc bug tracker in relation to this, one relating to gcc3.2, which is included in the latest redhat, so it's probably not wise to rely on this feature at all. *grin*
[14:58:20] * DarkeZzz returns to his sleep after uttering his Dire Prophercies Of Doom(tm), or incoherent rambling. It
[14:58:31] <DarkeZzz> 's often hard to tell the difference between a prophet and a lunatic. *noddle*
[14:58:49] <Colourless> yeah well, i totally agree :-)
[15:01:42] <DarkeZzz> The fact that Colourless can't compile it because he doesn't use the One True Compiler(tm), is also an additional problem which may cause you to rethink this __attribute__ stuff. *grin*
[15:02:20] <DarkeZzz> Colourless: Yup! From my random prophetic ramblings, you'd be easily fooled to think I was a prophet or something!
[15:02:38] <Colourless> the one true compiler that still supports non standard extensions, despite the fact it's users like to complain no end about the users of other compilers doing non standard things ;-)
[15:05:21] <DarkeZzz> Of course! The obvious difference is one allows you to optionally do non-standard things (if you're just, like, silly or something *grin*), vs. the other which does non-standard things by default, and you have to force it not to. (Take non standard, block scoping, for instance. *Please* take it! As far away from me as possible! *grin*)
[15:05:54] <Colourless> hey, it gone!
[15:06:43] <DarkeZzz> And all the people (or at the very least this bunny!) rejoiced when he tried it and found it to be vaguely sane. *grin*
[15:08:14] <DarkeZzz> Anyway, got to go and sacrifice to the Great God Z. See you again, if you're sufficiently unlucky. *grin* Night!
[15:08:23] <Colourless> nameless compiler now only has 9 standards compliance issues
[15:09:39] <Colourless> of course it has some issues with limits such as ([] = amount recommended by standard)
[15:09:41] <Colourless> Parameters in one macro definition [256] (127).
[15:09:41] <Colourless> Arguments in one macro invocation [256] (127).
[15:10:02] <Colourless> i mean, don't you just require an additionally 129 macro args!?!
[15:10:24] <Colourless> or how about this?
[15:10:27] <Colourless> Characters in a character string literal or wide string literal (after concatenation) [65536] (65535).
[15:10:36] <Colourless> i'm sure that 1 char is going to make all the difference in the world :-)
[15:11:14] <Colourless> or what about this?
[15:11:16] <Colourless> Member initializers in a constructor definition [6144] (approximately 600, memory dependent, can increase with the /Zm compiler option).
[15:11:39] <Colourless> now, i 'really' would like to see a constructor that has 6144 initializers
[15:11:46] <Colourless> hell, i would like like to see one with 600!
[15:27:50] --> wjp has joined #exult
[15:27:50] --- ChanServ gives channel operator status to wjp
[16:17:58] <-- DarkeZzz has left IRC (calvino.freenode.net irc.freenode.net)
[16:18:18] --> DarkeZzz has joined #exult
[16:39:15] --> Dark-Star has joined #exult
[17:23:56] --> Fingolfin has joined #exult
[17:23:56] --- ChanServ gives channel operator status to Fingolfin
[17:25:07] <Fingolfin> yo
[18:06:01] <-- Fingolfin has left IRC ("42")
[18:37:36] --> artaxerxes has joined #exult
[18:37:36] --- ChanServ gives channel operator status to artaxerxes
[18:37:41] <artaxerxes> hi all
[18:38:12] <Colourless> hi
[18:39:08] <artaxerxes> Colourless: I was able to do sth with linux wrt dynamic libs and I would like to know if it is portable to windows. Would you mind helping me ?
[18:39:31] <Colourless> read logs
[18:39:37] <artaxerxes> ?logs
[18:39:37] <exultbot> Logs are available at http://www.math.leidenuniv.nl/~wpalenst/exultlog.php3
[18:40:07] * artaxerxes is reading logs
[18:43:56] <wjp> oh, that's outdated
[18:47:12] <artaxerxes> Colourless: by undefined refs, you mean those "extern int bla" found in plugins and using data from the main?
[18:47:25] <Colourless> no
[18:47:32] <Colourless> undefined functions
[18:48:00] <artaxerxes> to be honest with you, I don't understand why that happens. I _do_ have the proper includes.
[18:48:10] <Colourless> there are a number of them in smooth
[18:48:22] <Colourless> turn on your compiler warnings
[18:48:34] <artaxerxes> I did and I can see them but I don't see why
[18:49:12] <artaxerxes> I must say the code is fairly ugly though.
[18:49:26] * artaxerxes wonders if I should make it my first real c++ project
[18:49:41] <Colourless> i have to ask. why you have a number of empty header file
[18:49:59] <artaxerxes> accidents.
[18:51:19] <artaxerxes> make the handle to the dynamic library a typedef'd type
[18:51:24] <artaxerxes> why would that be?
[18:51:37] <Colourless> cause windows doesn't use void * as it's handle to dynamic libraries
[18:52:05] <Colourless> it uses HMODULE
[18:52:07] <artaxerxes> so I should make a typdef with #ifdef's in it?
[18:52:16] <Colourless> yes
[18:52:18] <Colourless> just something like
[18:52:40] <Colourless> typedef void *libhandle_t; for you
[18:52:56] <Colourless> i can then just to typedef HMODULE libhandle_t;
[18:53:07] <Colourless> s/to/do/
[18:53:35] <artaxerxes> do you guys want me to convert it to c++?
[18:54:01] <artaxerxes> maybe it's time I jump in the river
[18:54:12] <Colourless> do what you want
[18:54:22] <Colourless> c or c++ makes no difference to me
[18:55:28] <artaxerxes> alright. So instead of making a third plugin (stream is finished as you can see in the forum), I'll clean up my code to remove every single warning. That should help to make it portable
[18:55:49] <artaxerxes> you guys suggest any specific flag during compile time to insure portability?
[18:56:06] <artaxerxes> like forcing ansi c or sth like that?
[18:56:07] <Colourless> nothing you need to do with the compiler
[18:56:21] <Colourless> just separate all system and compiler depentant code from non dependant stuff
[18:56:44] <artaxerxes> k
[18:57:20] <Colourless> writing portable c code is pretty easy
[18:57:44] <Colourless> because generally there isn't much compiler dependant stuff
[18:57:53] <artaxerxes> obviously not!
[18:57:56] <artaxerxes> ;-)
[18:58:18] <Colourless> unlike C++ where things can vary greatly between compilers
[18:58:23] <artaxerxes> ahh
[18:58:40] * artaxerxes is back programming
[18:58:59] <artaxerxes> thx for your help. I'll let you know when I feel satisfied with the result.
[18:59:10] <artaxerxes> to sum up:
[18:59:21] <artaxerxes> * no call to external values in plugins
[18:59:41] <artaxerxes> * separate system and compiler dependant stuff from non-dependant stuff
[18:59:54] <artaxerxes> * no warnings
[19:00:10] <artaxerxes> * typedef'd handles for dlopen
[19:00:26] <artaxerxes> * wrapper functions for dlopen and dlsym (?)
[19:00:41] <Colourless> no, what you have for them is already good enough.
[19:00:53] <Colourless> well, dlopen is fine
[19:01:01] <Colourless> since you only call it in a single function
[19:01:17] <Colourless> that funtion can easily just be rewritten for windows
[19:01:23] <artaxerxes> * no __attribute__ stuff at all
[19:01:44] <Colourless> well, you can use __attribute__ stuff, if you 'must'
[19:01:51] <Colourless> but just do it a little differently
[19:02:12] <artaxerxes> To be honest, I don't really think the load and unload function are critical. It's just to provide some feedback.
[19:02:43] <artaxerxes> They really do nothing useful and as far as I can tell, there is no need to do anything no matter what the plugin can be.
[19:02:45] <Colourless> instead of doing
[19:02:47] <Colourless> void __attribute__ ((constructor)) loading()
[19:02:47] <Colourless> {
[19:02:50] <Colourless> }
[19:02:53] <Colourless> you'd do
[19:03:01] <Colourless> void __attribute__ ((constructor)) on_load()
[19:03:03] <Colourless> {
[19:03:05] <Colourless> loading();
[19:03:07] <Colourless> }
[19:03:10] <Colourless> void loading()
[19:03:13] <Colourless> {
[19:03:13] <Colourless> }
[19:03:37] <Colourless> and make the on_load() function #ifdef's
[19:03:39] <artaxerxes> and if on windows, you'd call loading()
[19:03:42] <Colourless> s/'s/'d/
[19:03:45] <artaxerxes> directly
[19:03:50] <Colourless> yes i can call loading in DLLMain
[19:04:03] <Colourless> and unloading too
[19:04:21] <artaxerxes> but it would be manual, right?
[19:04:31] <Colourless> no
[19:04:37] <Colourless> DLLMain is called automatically be windows
[19:04:44] <artaxerxes> ahhhh
[19:05:35] <artaxerxes> how would you know which to call loading() or unloading() if it is in the same DLLMain. How many times does it get called?
[19:05:54] <artaxerxes> how can you tell it's loading time and unloading time?
[19:05:55] <Colourless> on Process attach (when the library is loaded), Thread attach (when another thread is created), Thread detach (when a thread is killed) and Proces detatch (when the library unloaded)
[19:06:17] <Colourless> DLLMain() isn't like a main function in a program
[19:06:44] <Colourless> it's passed a value that specifies why it was called
[19:06:52] <artaxerxes> ah ok.
[19:06:54] <artaxerxes> interesting
[19:07:55] <Colourless> example:
[19:07:59] <Colourless> BOOL WINAPI DllMain(HANDLE hInst, ULONG ul_reason_for_call, LPVOID lpReserved)
[19:07:59] <Colourless> {
[19:07:59] <Colourless> switch( ul_reason_for_call ) {
[19:07:59] <Colourless> case DLL_PROCESS_DETACH:
[19:07:59] <Colourless> break;
[19:08:00] <Colourless> case DLL_PROCESS_ATTACH:
[19:08:02] <Colourless> break;
[19:08:04] <Colourless> case DLL_THREAD_ATTACH:
[19:08:06] <Colourless> break;
[19:08:08] <Colourless> case DLL_THREAD_DETACH:
[19:08:10] <Colourless> break;
[19:08:12] <Colourless> }
[19:08:14] <Colourless> return TRUE;
[19:08:16] <Colourless> }
[19:08:34] <artaxerxes> I think I'll do what you recommended (or maybe it was wjp): have a struct that holds all the relevant info to the plugin during loading to initialise the plugin's variables.
[19:10:25] <artaxerxes> rephrasing: have all the relevant global variables of main put into a struct that I pass to the plugins so they can use that data too.
[19:10:39] <Colourless> yes
[19:10:50] <artaxerxes> so yeah then, I'll have use for loading()
[19:11:14] <Colourless> being?
[19:12:02] <artaxerxes> I was thinking of passing this struct to the loading() function which would initialise the plugin's global variables with what the struct contains.
[19:12:23] <Colourless> the loading function would then need to be explicitly called by smooth
[19:12:42] <Colourless> meaning you can just get rid of all the attribute stuff
[19:12:43] <artaxerxes> it does always as soon as it is loaded!
[19:12:52] <artaxerxes> oh I see
[19:12:55] <artaxerxes> my mistake
[19:12:58] <artaxerxes> you're right
[19:13:29] <artaxerxes> I would be unable to pass the variable to the constructor since I couldn't control the parameters!
[19:14:00] <artaxerxes> I guess it makes it easy then.
[19:14:56] <artaxerxes> hainvg a loading() and an unloading() functions that get called whenever appropriate with the right parameters.
[19:15:14] <artaxerxes> no need for DLLMain then even1
[19:15:34] <artaxerxes> on to coding!
[19:40:42] --- Eclair is now known as animeloe
[20:05:00] <Colourless> time for me to go
[20:05:02] <Colourless> cya
[20:05:07] <-- Colourless has left IRC ("casts invisibility")
[20:18:02] <artaxerxes> bye
[20:48:28] <artaxerxes> gotta go too
[20:48:33] <artaxerxes> see ya all
[20:48:36] <-- artaxerxes has left #exult ()
[21:35:19] <-- wjp has left IRC ("Zzzz...")