Nov. 23, 2022
8:38 a.m.
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-host-settings/, > 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) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1492#note_17178