Re: Re[2]: NCI Broken On Win32

[Jeff Clites]

On Nov 6, 2003, at 3:59 PM, Jonathan Worthington wrote:

From: "Mattia Barbon" <[EMAIL PROTECTED]>
Il Tue, 28 Oct 2003 18:51:56 +0100 Leopold Toetsch <[EMAIL PROTECTED]> ha
scritto:

Jonathan Worthington <[EMAIL PROTECTED]> wrote:
Hi,

loadlib P1, "user32.dll"
There are 2 errors in that, one is mine :)
- I didn't use the configure define of PARROT_DLL_EXTENSION
- Your's is: don't append ".dll" - parrot does it
  Somebody might wish to load something not named ".dll". For example
MS HTMLHelp API is located in a file suffixed ".ocx" (which exports
both an ActiveX control and raw C API).
This is true, and IMHO needs some thought.  I'm working on a library 
that
gives Parrot access to the entire Win32 API.  Some of them (related to
printing) are in a library called winspool.drv (note .drv, not .dll).
Parrot adds .dll onto the end of this and, of course, it cannot load 
it.
I'd be surprised if Win32 was the only OS where there was more than one
possible extension for a shared library.
Yeah, this would likely be a problem on Mac OS X as well, where 
loadable bundles can have a variety of extensions. I'm of the opinion 
that there's no very good reason to not just have the API take a real 
file name (including the extension).

I can imagine enforcing a per-platform extension for parrot bytecode 
libs specifically, so that you can write platform-independent user code 
which doesn't have to worry about how a parrot add-on lib is named, but 
then again it would be just as sensible to have a cross-platform 
convention for the extension, and just use the file name even here.

JEff