Console icon? #15882

@elsaco commented on GitHub (Nov 15, 2021):

@vefatica if you remove the extension, the icon won't be displayed:

I don't have the knowledge why it behaves like that!

@elsaco commented on GitHub (Nov 15, 2021): @vefatica if you remove the extension, the icon won't be displayed: ![cmd_icon_test](https://user-images.githubusercontent.com/3933920/141712504-9460c611-fbd8-420d-bd96-34be88dc8efe.png) I don't have the knowledge why it behaves like that!

claunia commented

@vefatica commented on GitHub (Nov 15, 2021):

In fact, the code posted by @KalleOlaviNiemitalo is done outside the if (pLinkSettings->GetStartupFlags() & STARTF_TITLEISLINKNAME) block. It doesn't seem right. It's just a title.

@vefatica commented on GitHub (Nov 15, 2021): In fact, the code posted by @KalleOlaviNiemitalo is done outside the `if (pLinkSettings->GetStartupFlags() & STARTF_TITLEISLINKNAME)` block. It doesn't seem right. It's just a title.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Nov 15, 2021):

I assume it is a counterpart to some code in cmd.exe or kernelbase.dll that uses the file name as the window title. Which then makes me wonder if the "Administrator:" prefix can make this not find the correct icon. Perhaps not, because it still has pwszAppName.

@KalleOlaviNiemitalo commented on GitHub (Nov 15, 2021): I assume it is a counterpart to some code in cmd.exe or kernelbase.dll that uses the file name as the window title. Which then makes me wonder if the "Administrator:" prefix can make this not find the correct icon. Perhaps not, because it still has pwszAppName.

claunia commented

@vefatica commented on GitHub (Nov 15, 2021):

Back to my first post ... setting the icon to that of notepad is just plain wrong. It's a title. It is not a specification of where to look for an icon.

@vefatica commented on GitHub (Nov 15, 2021): Back to my first post ... setting the icon to that of notepad is just plain wrong. It's a title. It is not a specification of where to look for an icon.

claunia commented

@zadjii-msft commented on GitHub (Nov 15, 2021):

Why does specifying a title affect the icon?

honestly, I'm not sure anyone on the team is going to have an answer as to why. This is gonna be one of those "features" of the console that's simply always existed, since before we formally owned the console codebase. I don't think we'd really have an answer other than "Huh, yep, it sure does seem to do that".

I'd be extremely reluctant to change that, undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason.

@zadjii-msft commented on GitHub (Nov 15, 2021): > Why does specifying a title affect the icon? honestly, I'm not sure anyone on the team is going to have an answer as to _why_. This is gonna be one of those "features" of the console that's simply always existed, since before we formally owned the console codebase. I don't think we'd really have an answer other than "Huh, yep, it sure does seem to do that". I'd be extremely reluctant to change that, undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason.

claunia commented

@vefatica commented on GitHub (Nov 15, 2021):

since before we formally owned the console codebase

Maybe so, but it doesn't happen in Windows 7. I wish I had more Windows versions to test on.

undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason.

That's humorous.

@vefatica commented on GitHub (Nov 15, 2021): > since before we formally owned the console codebase Maybe so, but it doesn't happen in Windows 7. I wish I had more Windows versions to test on. > undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason. That's humorous.

claunia commented

@zadjii-msft commented on GitHub (Nov 15, 2021):

undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason.

That's humorous.

When you've been here as long as us, you can be 100% sure that someone, somewhere, is relying on all sorts of wacky bugs in your codebase 😄

@zadjii-msft commented on GitHub (Nov 15, 2021): > > undoutably someone somewhere is relying on that behavior to set the icon of their console windows for some reason. > > That's humorous. When you've been here as long as us, you can be 100% sure that someone, somewhere, is relying on all sorts of wacky bugs in your codebase 😄

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Nov 15, 2021):

Changing this seems unlikely to halt a production line though. Unless they are then calling GetConsoleWindow and extracting the icon from there. Or they are using an UNC path as the title and waking up a network device that way.

On the other hand, the current strange use of the title shouldn't really have a business impact, either.

@KalleOlaviNiemitalo commented on GitHub (Nov 15, 2021): Changing this seems unlikely to halt a production line though. Unless they are then calling GetConsoleWindow and extracting the icon from there. Or they are using an UNC path as the title and waking up a network device that way. On the other hand, the current strange use of the title shouldn't really have a business impact, either.

claunia commented

7b775684e8/src/interactivity/win32/SystemConfigurationProvider.cpp (L174-L182)

@DHowett commented on GitHub (Nov 15, 2021):

It is too early for me to be reading code -- this is all wrong.

Kept for posterity

It looks like this was an "intent error" (like, we may not have understood the original code.) when we brought the v2 console online!

The v1 console loads the icon from:

The title, treated as a link, and resolved via the shell APIs
Resolving the App Name ("base DLL name", likely the PE file that caused console allocation) by SearchPath against the current directory, and using that as the icon source if it exists
The app name directly (if it couldn't be found in the search path)

The v2 console does the exact same thing, except in step 2 it overwrites the resolved app name with the title. Oops.

Here's the v2 code-

Note the copy from title into IconLocation just after IconLocation was filled and validated, on line 181.

Here's the v1 code-

        dwLinkLen = RtlDosSearchPath_U(CurDir,
                                       AppName,
                                       NULL,
                                       sizeof(LinkName),
                                       LinkName,
                                       NULL);
        if (dwLinkLen > 0 && dwLinkLen < sizeof(LinkName)) {
            pszIconLocation = LinkName; // there is no equivalent in v2-- the else block is omitted for linkLen being valid
        } else {
            pszIconLocation = AppName;

@DHowett commented on GitHub (Nov 15, 2021): It is too early for me to be reading code -- this is all wrong. <details> <summary>Kept for posterity</summary> It looks like this was an "intent error" (like, we may not have understood the original code.) when we brought the v2 console online! The v1 console loads the icon from: 1. The title, treated as a link, and resolved via the shell APIs 2. Resolving the App Name ("base DLL name", likely the PE file that caused console allocation) by `SearchPath` against the current directory, and using that as the icon source if it exists 3. The app name directly (if it couldn't be found in the search path) The v2 console does the exact same thing, **except** in step 2 it overwrites the resolved app name with the title. _Oops._ Here's the v2 code- https://github.com/microsoft/terminal/blob/7b775684e8206abdd12a6720252d0888f1c9d6d0/src/interactivity/win32/SystemConfigurationProvider.cpp#L174-L182 Note the copy from title into IconLocation just after IconLocation was filled and validated, on line 181. Here's the v1 code- ```c++ dwLinkLen = RtlDosSearchPath_U(CurDir, AppName, NULL, sizeof(LinkName), LinkName, NULL); if (dwLinkLen > 0 && dwLinkLen < sizeof(LinkName)) { pszIconLocation = LinkName; // there is no equivalent in v2-- the else block is omitted for linkLen being valid } else { pszIconLocation = AppName; ``` </details>

claunia commented

2026-01-31 04:51:18 +00:00

@eryksun commented on GitHub (Nov 15, 2021):

Maybe so, but it doesn't happen in Windows 7. I wish I had more Windows versions to test on.

This bug only occurs when conhost.exe is the default terminal application, and it uses the V2 implementation. It doesn't occur with V1, i.e. when "HKCU\Console\ForceV2" is 0.

I don't know why the fallback to the STARTUPINFO title was added in the V2 console. Yes, CreateProcessW() uses the application path as the default title, but the API has no flag to indicate the title is the executable path, i.e. something like STARTF_TITLEISEXENAME.

Anyway, the strange fallback code is not actually the bug here. This looks to be a bug in Windows. ConsoleAllocateConsole() is being called with a relative path in p->AppName, but it's supposed to be the fully-qualified path of the executable. It is highly unlikely that the SearchPathW(pwszCurrDir, pwszAppName, ...) call will resolve the relative name against the application's working directory. It used to work because pwszAppName was already a fully qualified path instead of a relative path.

@eryksun commented on GitHub (Nov 15, 2021): > Maybe so, but it doesn't happen in Windows 7. I wish I had more Windows versions to test on. This bug only occurs when conhost.exe is the default terminal application, and it uses the V2 implementation. It doesn't occur with V1, i.e. when "HKCU\\Console\\ForceV2" is 0. I don't know why the fallback to the `STARTUPINFO` title was added in the V2 console. Yes, `CreateProcessW()` uses the application path as the default title, but the API has no flag to indicate the title is the executable path, i.e. something like `STARTF_TITLEISEXENAME`. Anyway, the strange fallback code is not actually the bug here. This looks to be a bug in Windows. `ConsoleAllocateConsole()` is being called with a relative path in `p->AppName`, but it's supposed to be the fully-qualified path of the executable. It is highly unlikely that the `SearchPathW(pwszCurrDir, pwszAppName, ...)` call will resolve the relative name against the application's working directory. It used to work because `pwszAppName` was already a fully qualified path instead of a relative path.

claunia commented

2026-01-31 04:51:18 +00:00

@eryksun commented on GitHub (Nov 15, 2021):

ConsoleAllocateConsole() is being called with a relative path in p->AppName

I checked the initialization of kernelbase!ExeNameBuffer. It's copied from the base module name in the PEB loader data. It's just this base name that gets sent in the extended-attribute buffer of the NtCreateFile() call in kernelbase!ConsoleCreateConnectionObject(). This seems intentional, so I suppose at this level the app name was never meant to be used to actually find the application executable. It's probably meant just for just the command-line editor's per-app history and input aliases. Thus the SearchPathW(pwszCurrDir, pwszAppName, ...) call has always been strange. An application can have any arbitrary initial working directory. It has nothing at all to do with the executable path. For example, passing /D "C:\Windows\System32" to CMD's start command allows the console's SearchPathW() call to resolve the correct path of the executable, and thus to load the correct icon.

@eryksun commented on GitHub (Nov 15, 2021): > `ConsoleAllocateConsole()` is being called with a relative path in `p->AppName` I checked the initialization of `kernelbase!ExeNameBuffer`. It's copied from the base module name in the PEB loader data. It's just this base name that gets sent in the extended-attribute buffer of the `NtCreateFile()` call in `kernelbase!ConsoleCreateConnectionObject()`. This seems intentional, so I suppose at this level the app name was never meant to be used to actually find the application executable. It's probably meant just for just the command-line editor's per-app history and input aliases. Thus the `SearchPathW(pwszCurrDir, pwszAppName, ...)` call has always been strange. An application can have any arbitrary initial working directory. It has nothing at all to do with the executable path. For example, passing `/D "C:\Windows\System32"` to CMD's `start` command allows the console's `SearchPathW()` call to resolve the correct path of the executable, and thus to load the correct icon.

claunia commented

2026-01-31 04:51:18 +00:00

@DHowett commented on GitHub (Nov 15, 2021):

@vefatica just a question: how do you find this stuff? How did you find this one?

@DHowett commented on GitHub (Nov 15, 2021): @vefatica just a question: _how do you find this stuff? How did you find this one?_

claunia commented

@vefatica commented on GitHub (Nov 15, 2021):

@vefatica just a question: how do you find this stuff? How did you find this one?

I can't reconstruct the whole route but it started with my investigating #11704. That led me to mess around with the START command. It is also vaguely connected to a TCC issue wherein the initialization directive "UpdateTitle=No" is not always honored.

@vefatica commented on GitHub (Nov 15, 2021): > @vefatica just a question: how do you find this stuff? How did you find this one? I can't reconstruct the whole route but it started with my investigating #11704. That led me to mess around with the START command. It is also vaguely connected to a TCC issue wherein the initialization directive "UpdateTitle=No" is not always honored.

claunia commented

@malxau commented on GitHub (Nov 15, 2021):

The way I read this, szAppName is probably fully qualified. If it's not fully qualified, SearchPathW is used to resolve it to something fully qualified. It's intentionally not searching the PATH because the real purpose is relative to absolute name resolution.

The interesting part in this issue isn't the SearchPathW, it's the fallback to use the title as a path. That code appears to have been added in 2017, before the Github release, but after the code was maintained outside the Windows tree, so I don't have visibility into why it was done. Since it's 2017 I don't think it's true to say that this is ancient behavior that the current console team inherited, or that it will be widely depended on. It's very unclear to me why this would be useful - before that change, the code tried SearchPath, and if that failed, fell back to szAppName, which I understand. Falling back to the title, particularly in preference to szAppName, seems like a curious choice.

@malxau commented on GitHub (Nov 15, 2021): The way I read this, szAppName is probably fully qualified. If it's not fully qualified, SearchPathW is used to resolve it to something fully qualified. It's intentionally not searching the PATH because the real purpose is relative to absolute name resolution. The interesting part in this issue isn't the SearchPathW, it's the fallback to use the title as a path. That code appears to have been added in 2017, before the Github release, but after the code was maintained outside the Windows tree, so I don't have visibility into why it was done. Since it's 2017 I don't think it's true to say that this is ancient behavior that the current console team inherited, or that it will be widely depended on. It's very unclear to me why this would be useful - before that change, the code tried SearchPath, and if that failed, fell back to szAppName, which I understand. Falling back to the title, particularly in preference to szAppName, seems like a curious choice.

claunia commented

@DHowett commented on GitHub (Nov 15, 2021):

Here you go!

Merged PR 624729: WSL distros don't show icon when running

Make the console host try using the window title as a search path for the icon.
Fix up the window message loop icon patch to directly use the HWND
(it was broken after the onecore refactor).

Cherry picked from Pull request !615061.

Related work items: MSFT-11750393

If I had to guess: something about app execution aliases made this really wig out. This would be especially true if the AppName/AppPath was to the app execution alias (though I suspect it would not be, given that this data originates from within conclnt after the process has already started.)

@DHowett commented on GitHub (Nov 15, 2021): Here you go! ``` Merged PR 624729: WSL distros don't show icon when running Make the console host try using the window title as a search path for the icon. Fix up the window message loop icon patch to directly use the HWND (it was broken after the onecore refactor). ``` Cherry picked from Pull request !615061. Related work items: MSFT-11750393 --- If I had to guess: something about app execution aliases made this really wig out. This would be especially true if the AppName/AppPath was to the app execution alias (though I suspect it would not be, given that this data originates from within conclnt after the process has already started.)

claunia commented

@DHowett commented on GitHub (Nov 15, 2021):

That bug states:

Title: Console doesn't pick up the icon of Distro Launcher exe's

Body:
The exe has an icon, but for some reason, when launched from the start menu, the console can't find the appropriate icon.

It is quite terse. 😁

@DHowett commented on GitHub (Nov 15, 2021): That bug states: **Title**: Console doesn't pick up the icon of Distro Launcher exe's **Body**: The exe has an icon, but for some reason, when launched from the start menu, the console can't find the appropriate icon. It is quite terse. 😁

claunia commented

@malxau commented on GitHub (Nov 15, 2021):

Does the current start menu use STARTF_TITLEISLINKNAME? If so, the title value is (re)initialized from the shortcut, and I think my later change in https://github.com/microsoft/terminal/pull/6277 will fix it, by taking the icon from the shortcut target. If it doesn't, then, uhh, sad.

@malxau commented on GitHub (Nov 15, 2021): Does the current start menu use STARTF_TITLEISLINKNAME? If so, the title value is (re)initialized from the shortcut, and I think my later change in https://github.com/microsoft/terminal/pull/6277 will fix it, by taking the icon from the shortcut target. If it doesn't, then, uhh, sad.

claunia commented

@DHowett commented on GitHub (Nov 15, 2021):

If it doesn't, then, uhh, sad.

Alas. I think this applied to package launches, which don't even have a link and likely don't pass STARTF_TITLEISLINKNAME. There's some annoyingly complicated machinery that launches a package with package identity that wasn't part of CreateProcess until late Windows 11... and it's been the source of no end of trouble.

@DHowett commented on GitHub (Nov 15, 2021): > If it doesn't, then, uhh, sad. Alas. I think this applied to _package launches_, which don't even have a link and likely don't pass `STARTF_TITLEISLINKNAME`. There's some annoyingly complicated machinery that launches a package with package identity that _wasn't part of CreateProcess until late Windows 11_... and it's been the source of no end of trouble.

claunia commented

@eryksun commented on GitHub (Nov 16, 2021):

The way I read this, szAppName is probably fully qualified.

At first, it looked like it was supposed to be, but it would have been obvious that it's not had I checked the definition of CONSOLE_API_CONNECTINFO.AppName, which is limited to just 128 characters instead of MAX_PATH + 1.

The app name was intended for the console's per-executable command-line history and aliases. Code was added some versions later to read the icon on the host side by resolving the base executable name against the client's current working directory, i.e. SearchPathW(pwszCurrDir, pwszAppName, ...) (or equivalent NT RtlDosSearchPath_U call). That's nonsense. It could use a handle to the client process to query the executable path with QueryFullProcessImageNameW(). Or update the client-side code to send the full path of the executable instead of the base name.

It's very unclear to me why this would be useful - before that change, the code tried SearchPath, and if that failed, fell back to szAppName, which I understand. Falling back to the title, particularly in preference to szAppName, seems like a curious choice.

Falling back to just szAppName is not understandable to me. There's no reason to assume the base executable name will be found by the implicit SearchPathW(NULL, ...) call in ExtractIconExW(). For example, if I remove all Python installation directories from PATH, then start "spam" "C:\Program Files\Python38\python.exe" creates a console that has the default icon instead of Python's icon. If I add the Python 3.8 installation directory to PATH, then the ExtractIconExW() call in the console host finds "python.exe", and the console obtains the correct icon. But actually it's going to use any "python.exe" that it finds in PATH. No one should be satisfied with that behavior.

Using the title sometimes works because CreateProcessW() fills in the fully qualified executable path as the default lpTitle. For example, the console created by start "" "C:\Program Files\Python38\python.exe" always finds the correct icon. But this is unreliable because there is no STARTF_TITLEISEXENAME flag that indicates to the console that a path in the title is intentionally the executable path.

@eryksun commented on GitHub (Nov 16, 2021): > The way I read this, szAppName is probably fully qualified. At first, it looked like it was supposed to be, but it would have been obvious that it's not had I checked the definition of [`CONSOLE_API_CONNECTINFO.AppName`](https://github.com/microsoft/terminal/blob/fb597ed304ec6eef245405c9652e9b8a029b821f/src/host/conserv.h#L41-L53), which is limited to just 128 characters instead of `MAX_PATH + 1`. The app name was intended for the console's per-executable command-line history and aliases. Code was added some versions later to read the icon on the host side by resolving the base executable name against the client's current working directory, i.e. `SearchPathW(pwszCurrDir, pwszAppName, ...)` (or equivalent NT `RtlDosSearchPath_U` call). That's nonsense. It could use a handle to the client process to query the executable path with `QueryFullProcessImageNameW()`. Or update the client-side code to send the full path of the executable instead of the base name. > It's very unclear to me why this would be useful - before that change, the code tried SearchPath, and if that failed, fell back to szAppName, which I understand. Falling back to the title, particularly in preference to szAppName, seems like a curious choice. Falling back to just `szAppName` is not understandable to me. There's no reason to assume the base executable name will be found by the implicit `SearchPathW(NULL, ...)` call in `ExtractIconExW()`. For example, if I remove all Python installation directories from `PATH`, then `start "spam" "C:\Program Files\Python38\python.exe"` creates a console that has the default icon instead of Python's icon. If I add the Python 3.8 installation directory to `PATH`, then the `ExtractIconExW()` call in the console host finds "python.exe", and the console obtains the correct icon. But actually it's going to use any "python.exe" that it finds in `PATH`. No one should be satisfied with that behavior. Using the title sometimes works because `CreateProcessW()` fills in the fully qualified executable path as the default `lpTitle`. For example, the console created by `start "" "C:\Program Files\Python38\python.exe"` always finds the correct icon. But this is unreliable because there is no `STARTF_TITLEISEXENAME` flag that indicates to the console that a path in the title is intentionally the executable path.

claunia commented

@elsaco commented on GitHub (Nov 16, 2021):

Here's another example. Launching Powershell from Start won't show the correct application icon. Notice first tab's icon. The 2nd tab was launched by clicking +. 2nd and 3rd tab show the correct icons:

@elsaco commented on GitHub (Nov 16, 2021): Here's another example. Launching Powershell from Start won't show the correct application icon. Notice first tab's icon. The 2nd tab was launched by clicking `+`. 2nd and 3rd tab show the correct icons: ![powershell_no_icon](https://user-images.githubusercontent.com/3933920/141889126-fd777084-0ca0-4d8a-8a9e-d12793c2ac55.png)

claunia commented

@vefatica commented on GitHub (Nov 16, 2021):

That must be with WT as the default console handler, right, @elsaco ? On general-audience Windows (10.0.19043.1348 (2009, 21H1)), without an icon specified in my PowerShell profile (far below), and starting it from +, I get no icon at all. Is that expected?

            {
                "colorScheme": "Campbell Powershell",
                "commandline": "powershell.exe -NoLogo",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "icon": null,
                "name": "PowerShell",
                "startingDirectory": "v:\\"
            },

Edit: Likewise if I remove the "Icon:" line.

Edit2: And likewise if I give "commandline:" a fully-qualified name.

@vefatica commented on GitHub (Nov 16, 2021): That must be with WT as the default console handler, right, @elsaco ? On general-audience Windows (10.0.19043.1348 (2009, 21H1)), without an icon specified in my PowerShell profile (far below), and starting it from `+`, I get no icon at all. Is that expected? ![image](https://user-images.githubusercontent.com/61856645/141892160-4fcdeb00-5c6f-48f0-ae2f-8294df27fbd5.png) ``` { "colorScheme": "Campbell Powershell", "commandline": "powershell.exe -NoLogo", "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}", "hidden": false, "icon": null, "name": "PowerShell", "startingDirectory": "v:\\" }, ``` Edit: Likewise if I remove the "Icon:" line. Edit2: And likewise if I give "commandline:" a fully-qualified name.

claunia commented

@DHowett commented on GitHub (Nov 16, 2021):

It'll be best for us to keep this issue on its original: conhost's erroneous selection of icon based on the title. 😄

All discussion of windows terminal as the default terminal will need to be moved to a new thread where we can triage it independently.

@DHowett commented on GitHub (Nov 16, 2021): It'll be best for us to keep this issue on its original: conhost's erroneous selection of icon based on the title. :smile: All discussion of windows terminal as the default terminal will need to be moved to a new thread where we can triage it independently.

claunia commented

@sredna commented on GitHub (Dec 9, 2021):

The funny thing is that way back when we had SEE_MASK_ICON for ShellExecuteEx and I believe it was used to change the console icon but that has not worked for a very long time, NT4 was maybe the last time it actually did anything. Going back even further, Progman in 16-bit Windows had a undocumented way of assigning icons (STARTUPINFO still has a member for it).

I wish I had more Windows versions to test on.

Windows 8.1 does not use the icon from the title path.

@sredna commented on GitHub (Dec 9, 2021): The funny thing is that way back when we had `SEE_MASK_ICON` for ShellExecuteEx and I believe it was used to change the console icon but that has not worked for a very long time, NT4 was maybe the last time it actually did anything. Going back even further, Progman in 16-bit Windows had a undocumented way of assigning icons (STARTUPINFO still has a member for it). > I wish I had more Windows versions to test on. Windows 8.1 does not use the icon from the title path.

claunia commented

@jredfox commented on GitHub (May 19, 2022):

it's a feature from conhost.exe it displays the icon of the currently running process. cmd.exe will display the console icon. notepad notepad. but the only way to get it to display another icon is either start "Tittle" yourApp.exe or conhost yourapp.exe. I can't seem to change the icon at will from a batch file it will always display the cmd icon

why don't you guys add a new command consoleIcon [path] where you can specify the icon. To get around this I wanted both the color and the icon but it displayed black first. if you are able to change the icon from a batch file it changes everything.

@jredfox commented on GitHub (May 19, 2022): it's a feature from conhost.exe it displays the icon of the currently running process. cmd.exe will display the console icon. notepad notepad. but the only way to get it to display another icon is either `start "Tittle" yourApp.exe` or `conhost yourapp.exe`. I can't seem to change the icon at will from a batch file it will always display the cmd icon why don't you guys add a new command `consoleIcon [path]` where you can specify the icon. To get around this I wanted both the color and the icon but it displayed black first. if you are able to change the icon from a batch file it changes everything.

claunia commented

@zadjii-msft commented on GitHub (Jul 19, 2022):

Hmmm. Okay, so breaking this thread down:

The console currently uses the "title" as a fallback location to load the icon from, which can be weird.
The console does that as of 2017, seemingly to help support WSL distros.
This creates a new bug where start "C:\WINDOWS\system32\notepad.EXE" cmd now loads notepad's icon, because we're using the title as a potential icon search path.
(TODO) I don't know off hand if there's a better way to support the icons in the WSL distro case (app execution aliases)

Did I miss anything? I'm down in these weeds as a part of #9458, so this is a prime opportunity to resolve this, if resolvable at all.

@zadjii-msft commented on GitHub (Jul 19, 2022): Hmmm. Okay, so breaking this thread down: * The console currently uses the "title" as a fallback location to load the icon from, which can be weird. * The console does that as of 2017, seemingly to help support WSL distros. * This creates a new bug where `start "C:\WINDOWS\system32\notepad.EXE" cmd` now loads notepad's icon, because we're using the title as a potential icon search path. * [ ] (**TODO**) I don't know off hand if there's a better way to support the icons in the WSL distro case (app execution aliases) Did I miss anything? I'm down in these weeds as a part of #9458, so this is a prime opportunity to resolve this, if resolvable at all.

claunia commented

@LinHeLurking commented on GitHub (Oct 20, 2022):

If I open Windows Terminal first then select some predefined profile to open my WSL, it shows correct icon. But if I open corresponding distro xxx.exe, it launches in Windows Terminal without icon, like this:

And the profile command line is just set as the distro exe.

I've tested 2 distros and both of them show wrong icon. Maybe this is related with Windows Terminal?

@LinHeLurking commented on GitHub (Oct 20, 2022): If I open Windows Terminal first then select some predefined profile to open my WSL, it shows correct icon. But if I open corresponding distro `xxx.exe`, it launches in Windows Terminal without icon, like this: ![image](https://user-images.githubusercontent.com/35602373/196869372-45cd4cdf-72c7-4e90-87ef-6a2371723f00.png) And the profile command line is just set as the distro exe. ![image](https://user-images.githubusercontent.com/35602373/196869443-252195a4-9d7c-4f8e-b78e-22dc20b6a010.png) I've tested 2 distros and both of them show wrong icon. Maybe this is related with Windows Terminal?

claunia commented

@DHowett commented on GitHub (Oct 20, 2022):

If I open Windows Terminal first then select some predefined profile to open my WSL, it shows correct icon. But if I open corresponding distro xxx.exe, it launches in Windows Terminal without icon, like this:

And the profile command line is just set as the distro exe.

I've tested 2 distros and both of them show wrong icon. Maybe this is related with Windows Terminal?

I think this is (unfortunately) unrelated to the current issue. However, I'll suggest checking out the icon field in your opensuse-tumbleweed profile settings.

@DHowett commented on GitHub (Oct 20, 2022): > If I open Windows Terminal first then select some predefined profile to open my WSL, it shows correct icon. But if I open corresponding distro `xxx.exe`, it launches in Windows Terminal without icon, like this: > > ![image](https://user-images.githubusercontent.com/35602373/196869372-45cd4cdf-72c7-4e90-87ef-6a2371723f00.png) > > And the profile command line is just set as the distro exe. ![image](https://user-images.githubusercontent.com/35602373/196869443-252195a4-9d7c-4f8e-b78e-22dc20b6a010.png) > > I've tested 2 distros and both of them show wrong icon. Maybe this is related with Windows Terminal? I think this is (unfortunately) unrelated to the current issue. However, I'll suggest checking out the `icon` field in your opensuse-tumbleweed profile settings. <img width="744" alt="image" src="https://user-images.githubusercontent.com/189190/197046888-7155e4cc-584b-4261-bd95-d2a8d612aa21.png">

claunia commented