Compiling and linking on windows, using the instructions for the MS VS 2k8 compiler found on the http://trac.parrot.org/parrot/wiki/Platforms/Windows page, I had a problem with the AR_CR= make variable. Setting this to "lib.exe" corrects the problem, but the step of making the shared library (.dll in Windows parlance) fails because of an external reference to __environ in Env.pmc.
Inspecting env.pmc leads to the conclusion that there is probably a set of -Defines that will work for MSVS to get the code to link correctly, but also to the conclusion that any Windows dll, and probably any *nix shared lib, that is built in this way is going to fail.
Shared libraries generally have a "separate life" in process-space, so that two applications that both link to the shared library will only cause one instance of the library to appear in memory. In this regard, shared libraries act very much like a program running as a daemon.
But such a program, if it tries to interact with the "system" on behalf of a client, has to take special precautions. For example, if it writes to stdout, which stdout should it write to? The stdout of the shared library, or of the client program?
Similarly, references to environment variables are subject to the same question. And for the specific case of environment variables, the answer is probably always "use the client program's environment."
References to environ don't do this. Instead, they reference the environment that was available when the shared library was loaded. The potential bug should be obvious.
For Windows, my research has led me to an API call named 'GetEnvironmentStrings'. I'm not at all clear on the corresponding call for Unix, if there even is such a thing.
Also, it is unclear to me what the protocol for highly-OS-specific code is, w.r.t. PMCs. Parrot is chock full of PMCs that are nothing but wrappers for the various src/foo.c modules, for whatever reason(s).
At any rate, someone smarter than me about Windows, and about Parrot's cross-platform coding approach, will need to take a look at this. (Which is likely to be "anyone with a pulse and a keyboard.")
Tested ok for 5.0 on cygwin, windows msvc, and windows mingw.
I'm not sure how to test for the potential darwin problem (not referenced here) that OS X doesn't allow access to "environ" from within shared libraries. env is not a dynpmc, it is in libparrot.dylib. Such a test would need to use environ from a dynpmc. This is not needed as every dynpmc or dynoplib should go through the Env.pmc to access environ.