[Bug 50405] Missing ability to read Evironment Block and Environment Block Size from any Process ID kernel32

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50405

--- Comment #3 from Samuel Venable <samuelvenable at hotmail.com> ---
(In reply to Anastasius Focht from comment #2)
> Hello Samuel,
> 
> you're most likely doing something wrong. There are many
> libraries/frameworks/applications using that "undocumented" approach. Also
> you didn't tell if you're running a WoW64 environment which has some
> restrictions (32-bit -> 64-bit process).
> 
> https://stackoverflow.com/questions/7446887/get-command-line-string-of-64-
> bit-process-from-32-bit-process
> 
> 'PhGetProcessPebString':
> 
> https://github.com/processhacker/processhacker/blob/
> 04f18ea9a98374fb5aa4fc0d8c51b93a708eafc4/phlib/native.c#L580
> 
> 'PhGetProcessCommandLine':
> 
> https://github.com/processhacker/processhacker/blob/
> 04f18ea9a98374fb5aa4fc0d8c51b93a708eafc4/phlib/native.c#L733
> 
> 'PhGetProcessEnvironment':
> 
> https://github.com/processhacker/processhacker/blob/
> 04f18ea9a98374fb5aa4fc0d8c51b93a708eafc4/phlib/native.c#L913
> 
> ---
> 
> ProcessHacker 2.x works as intended with Wine, showing remote process'
> command line and environment using that approach (see previous code
> references).
> 
> https://github.com/processhacker/processhacker/releases/download/v2.39/
> processhacker-2.39-setup.exe
> 
> Regards

Hi, what my code does is it creates an output executable, one built for x86 and
one for x64, and depending on the architecture of the target executable based
on its process id, that will determine which exe is launched and used for
reading the printed standard output printing, which will print the environment
block.

the null characters \o are replaced and it ends up forming a string that looks
like this, when the code is behaving as it should:

NAME1="VALUE1"
NAME2="VALUE2"
NAME3="VALUE3"

...and so on. I use most of the same exact code to retrieve the working
directory, and as i said before that does work in WINE, but retrieving the
environment block is not. My guess is that EnvironmentSize isn't implemented
yet, as many users I've seen are getting the size of the Environment block by
other means than the actual struct member for that. Perhaps that is why it is
working in those other applications? I'm going to debug this further by seeing
what EnvironmentSize returns, and if zero, then that's probably the issue.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.