Process.ProcessName acts differently on different platforms (bug or as expected)? [Using "System.Diagnostics.Process.GetCurrentProcess().ProcessName" on different platforms]

Hi guys

I have noticed that using
"System.Diagnostics.Process.GetCurrentProcess().ProcessName"
shows different values on different platforms even though the executable
names, paths and command lines and links are exactly identical.

Is this a bug, or expected or nobody cares because it's undefined!?

On a MacOSX this value is Mono's virtual machine executable file name (e.g.
mono-sgen...).
But on Linux/Ubuntu this value the assembly exe filename (e.g.
myprogram.exe)!

I felt this should not be the case and tried to find the root cause but
with only a couple of hours in my hand I could only trace it so far - see
below.
Is this worth fixing or is there too much legacy to change a system value
like this !?

I traced it down to "./mono/metadata/w32process.c":
"ves_icall_System_Diagnostics_Process_ProcessName_internal()"
and that seems to be the root of where the calls split into the various
platform specific implementations such as
"mono_w32process_get_name()"
which is different in:
./mono/metadata/w32process-unix-osx.c
and in
./mono/metadata/w32process-unix-default.c
and
./mono/metadata/w32process-unix-bsd.c

It might take me several days before I understand all the details but if
someone gives me a pointer I might be able to work this out...


The other matter is about figuring whether we are running a mkbundle
executable or running an assembly directly. I figured using the process
name is perhaps one of the only ways because at least on the OSX this value
is set to the runtime executable rather than my program's name unless if we
have a mkbundle package. But unfortunately this logic breaks due to the
above mis-match in the platform specifics... Any other suggestions!?


Thanks




Ramin Zaghi

*Mosaic3DX™ | User Interface Technology*
St John's Innovation Centre,
Cowley Road,
Cambridge,
CB4 0WS, UK
*E*: [email protected]
*T*: +44 1223 421 311
http://linkedin.com/in/raminzaghi

_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.dot.net/mailman/listinfo/mono-devel-list