On Sep 23, 2005, at 4:41 AM, Jonathan Worthington wrote: > "Ross McFarland" <rwmcfa1@neces.com> wrote: > >> there's also a really hacky win32 thing tacked on the end that >> removes the lib from the front, but it would only work for cases >> without a path. i can do the same, but that's pretty broken as is >> and it would seem you'd need to do the opposite if the lib was >> specified in win32 speak and you're running on unix-y system. >> >> > Taking the "lib" off the start on Win32 always felt a little hacky > to me...it's certainly not a hard and fast rule but does apply in > some cases. I guess it's a last-ditch effort - that whole chunk of > code feels very "let's try everything we can possibly think of". I > think it's worth remembering that NCI = *Native* Calling Interface, > so by using it you are inherently doing something platform specific > anyway. We can only hide away platform differences so far...the > question is how far should we go. yeah and no, it's native as in C not really platform. something like libm would be a good, though trivial, example. it's likely on every system you come across and if you want to get at something in it you should be able to. there's nothing platform specific about libm other than the file name. if we allow to code to say either loadlib libm or loadlib m then bindings for it would work on any platform that had lib m. i'm all for not trying every perm, in fact there's several of them that aren't handled in the current code as it stands. i think the real solution is to define what loadlib expects more thoroughly so that a reasonable and completely set of things can be attempted. -rmThread Previous