On Wed Nov 23 14:38:50 2022 +0000, Hugh McMaster wrote:
Hi Eric, These are good questions.
what is the application we need refer to? it's not 100% clear its the
first application attached to console, as this is not only used at conhost startup, but during all lifetime (for also saving the properties); add to make things simple, the app could have terminated, or some other could have been created - attached to the same console As far as I can tell, Windows always loads console settings for the first process attached to conhost.exe.
- Creating a new console process (CREATE_NEW_PROCESS flag) creates a new
instance of conhost.exe, so registry settings are loaded as normal.
- Creating a new inherited console (no process creation flags) uses the
existing parent console and settings.
according to
https://devblogs.microsoft.com/commandline/understanding-windows-console-hos..., both title and process' path could be used; it's not clear why one of the two is used (load & store) (or said in another words, why the configuration based on console's title isn't sufficient?) It is true that both process path and title can be used to load and store console settings in the registry, although I've never seen any application use the title method. We can support both methods, although I think we should focus on the process path method now and add the lpTitle method later.
do we need to modify the server protocol here? assuming conhost
parent's process is the one of interest, NtQueryInformationProcess + ProcessBasicInformation would get you the parent pid `NtQueryInformationProcess` takes a HANDLE to a process as its first argument. conhost.exe doesn't have the calling process' HANDLE, nor does it know which console process it is working with. The server knows the ID of the calling process, so we can pass the PID to conhost.exe. Do note that I expect there there will be other uses for this information in conhost.exe. On Wine, conhost.exe and the console process are children of wineconsole. On Windows, conhost.exe is the child of the console process, but from I understand, Windows fakes that parent-child relationship.
for the title bits, just a wild guess: - if the console title is set via CreateProcess STARTUPINFO.lpTitle then the configuration is bound to the title - otherwise the configuration is bound to the first process path (AFAICS loading/storing configuration based on title is already present in window.c)
you're right in Wine conhost / created process relationship can be tricky (to say the least):
``` $ wine cmd ``` both cmd.exe and conhost.exe are children of start.exe (and we'd expect to use cmd.exe and not start.exe for the configuration path, as they should be both attached to console)
``` $ wine programs/cmd/cmd.exe ``` conhost.exe is a child of cmd.exe
(things are slightly different when allocating console at first with wineconsole)
so picking the 'right' program may not be an easy task (note GetConsoleProcessList may help)