Chip Salzenberg wrote: > 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. Yeah, people are probably scared that Microsoft drops long file name support. ;-) >> > 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? Just by adding the F<bin> directory to the PATH environment variable, usually the system wide one. >> 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. > 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. Let's see... Parrot_base_vtables pio_stdio_layer op_jit yyin I guess that's it. >> 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.) [good points snipped] > Again, I'm only mildly concerned about these issues. I'm only > spelling them out in detail in an attempt at clarity. I see where you are going. I've never given this too much thought until now. Good that you are wearing the hat, not me. ;-) Ron
