[parrot/parrot] 97aa16: move os.pmc from dynpmc back to static pmc

[GitHub]

  Branch: refs/heads/bdw/move-os
  Home:   https://github.com/parrot/parrot
  Commit: 97aa16a4d827cfe4fd48b23d4556dce601fc8304
      https://github.com/parrot/parrot/commit/97aa16a4d827cfe4fd48b23d4556dce601fc8304
  Author: Reini Urban <rurban at cpanel.net>
  Date:   2012-09-03 (Mon, 03 Sep 2012)

  Changed paths:
    M MANIFEST
    M MANIFEST.generated
    M config/gen/config_pm/config_pir.in
    M config/gen/makefiles/root.in
    M examples/library/md5sum.pir
    M examples/pir/io.pir
    M examples/tutorial/40_file_ops.pir
    M runtime/parrot/library/osutils.pir
    M runtime/parrot/library/parrotlib.pir
    M src/dynpmc/Defines.in
    M src/dynpmc/Rules.in
    R src/dynpmc/os.pmc
    A src/pmc/os.pmc
    M t/compilers/opsc/02-parse-all-ops.t
    M t/dynoplibs/io.t
    M t/dynpmc/file.t
    M t/dynpmc/gziphandle.t
    R t/dynpmc/os.t
    R t/dynpmc/os_unicode.t
    M t/oo/methods.t
    A t/pmc/os.t
    A t/pmc/os_unicode.t
    M tools/dev/dedeprecator.nqp
    M tools/dev/pbc_to_exe.winxed

  Log Message:
  -----------
  move os.pmc from dynpmc back to static pmc

Manually cleaned up pull request 778 by bdw.

Rationale whiteknight:
It's my belief that making OS PMC a dynpmc in the
first place was a mistake.  It is the only real way to access some pretty
fundamental filesystem and other functionality from the user level.
Further, all the real logic is implemented inside libparrot already, but
without OS PMC it isn't exposed to the user at all.

dynpmcs should be used for cases when we want to add new logic to the VM,
not when we already have that logic but want to be stingy about when we
expose it.

All our major users rely on OS pmc also. Winxed, Rakudo, NQP and Rosella all
make some use of it.  It's important and necessary, and it should be in
core.