With Cygwin, you are running a POSIX emulation layer on top of the Win32 OS,
so your app gets all of the initialisation support you'd expect from a true
POSIX system. There is no need for us to concern ourselves with the details
of how this happens; some very clever people have set it up for us, so that
it just works. The aspects of it that are relevant to this discussion are:
1) The environment that is passed to your app is again a *verbatim* copy of
that which was defined in the bash shell.
2) When you access command line arguments in argv, they are again *verbatim*
copies of what you typed on the command line.
So, what's the difference from the cmd.exe case? The *significant* difference
is that when your app refers to any file system entity, the reference no longer
needs to be specified in native Win32 format; it can just as well be in Cygwin's
POSIX compatible format, and the emulation layer will take care of mapping it to
the proper file system entity, without you needing to even know or care how.
1) Cygwin's bash.exe assumes that the execed process will know how to use the
Cygwin POSIX emulation layer to map Cygwin specific entity references to
their native counterparts; if this isn't the case, as in the case of a Win32
native app, then the onus falls squarely on the user to ensure that all
references, and file system references, are specified in the proper *native*
format; there is no assistance provided to perform the translation.