According to Ron Blaschke:
> The idea [of parrot01.dll] was mainly stolen from other projects,
> guess it's some sort of convention on Windows. [...] Adding all
> three parts, with dots, will work nicely, too, I guess.
That'd be great. If you get pushback from something that matters,
like an important Windows tool (e.g. InstallShield), you can revert to
parrot09.dll just before 1.0 and parrot10.dll for 1.0. But I'd be
surprised if it were necessary -- the two-digit naming convention
smells like something invented for 8.3 filenames and never revisited.
> > OK. I haven't done much Windows software work since Win98; what's the
> > standard way of making a command (e.g. "parrot") available from [a]
> > the Win32 command line and [b] the Win32 spawn interface?
>
> Not sure I get your question right, but libraries are mostly located
> in the same directory as the executable [...]
No, sorry; I was changing the subject slightly. When the user types
"parrot" in his Windows command prompt window, how did the Parrot
installer make sure that Windows knows where to find parrot.exe?
[explanation of "__declspec(dll{im,ex}port)"]
> There would be another way to get functions exported, namely by
> providing an C<EXPORTS> section in a separate module definition
> file, which would contain a list of all functions to be exported.
> [...] This would not work with the current implementation, as data
> is accessed as well, eg C<Parrot_base_vtables>, where C<__declspec>
> is the only way to get hold of.
Darn. Last I heard, we have to make an exports file *anyway* to
support AIX. If that same same exports file could support creation of
both Win32 and AIX libraries, we'd be saved from the trouble of the
PARROT_API macro, and I'd be a happy camper.
How many variables need to be exported currently? I'd consider it an
API feature if there were no exported variables whatsoever, and all
the current public data were made available through a public function
API.
> It's a matter of what is inside or outside of a library, I guess. For
> a dynclass, parrot is on the outside, that's why I thought of a
> different macro. That is, when compiling a dynclass, parrot's symbols
> must be imported, and that of the dynclass exported. Am I making any
> sense, or am I getting all confused here?
You're making sense, but perhaps I didn't. Let me stop giving you a
solution and give you a requirement instead, and let you come up with
the solution.
I'm (mildly) concerned about macro namespace issues and portability
encapsulation WRT the API macros. (Macro name conflicts really bite.)
* It would be good if the author of a random DLL could be absolutely
sure that the FOO_API macro name he chooses is globally (and I mean
*globally*) unique; perhaps this is a problem that lay outside the
realm of what you're currently trying to solve, but perhaps not.
* It would also be good if the details of the "export me" and "import
me" macro _expansions_ were not something that the DLL author had to
know or worry about. Ideally, I'd like to see the definition of the
FOO_API macro be handled by the equivalent of Module::Starter or
h2xs, and all the author has to do is make sure he picks a good name
for it.
Again, I'm only mildly concerned about these issues. I'm only
spelling them out in detail in an attempt at clarity.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
