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

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

R Zaghi
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
T: +44 1223 421 311



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