starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Terminal doesn't detect developer command prompt on ARM64 #17240

New Issue
Open
opened 2026-01-31 05:36:22 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 05:36:22 +00:00
Owner
Copy Link

Originally created by @Alovchin91 on GitHub (Apr 13, 2022).

Originally assigned to: @zadjii-msft on GitHub.

Windows Terminal version

1.12.10733.0

Windows build number

10.0.22000.613

Other Software

Visual C++ Build Tools 2022 17.1.4

Steps to reproduce

  • Install Visual C++ Build Tools 2022 on Windows 11 ARM64
  • Install Windows Terminal 1.12
  • Run Windows Terminal

Expected Behavior

There are profiles for Developer Command Prompt and Developer PowerShell for VS2022 in Terminal.

Actual Behavior

There are no such profiles.

Originally created by @Alovchin91 on GitHub (Apr 13, 2022). Originally assigned to: @zadjii-msft on GitHub. ### Windows Terminal version 1.12.10733.0 ### Windows build number 10.0.22000.613 ### Other Software Visual C++ Build Tools 2022 17.1.4 ### Steps to reproduce * Install Visual C++ Build Tools 2022 on Windows 11 ARM64 * Install Windows Terminal 1.12 * Run Windows Terminal ### Expected Behavior There are profiles for Developer Command Prompt and Developer PowerShell for VS2022 in Terminal. ### Actual Behavior There are no such profiles.
claunia added the Issue-BugProduct-TerminalTracking-External labels 2026-01-31 05:36:22 +00:00
claunia commented 2026-01-31 05:36:23 +00:00
Author
Owner
Copy Link

@Alovchin91 commented on GitHub (Apr 13, 2022):

Probably related to this but it's been marked as Fixed for the second time already so there's no reason not to trust them, right? 🙃

@Alovchin91 commented on GitHub (Apr 13, 2022): Probably related to [this](https://developercommunity.visualstudio.com/t/isetupconfiguration-is-not-registered-on-arm64/1236604) but it's been marked as Fixed for the second time already so there's no reason not to trust them, right? 🙃
claunia commented 2026-01-31 05:36:23 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 13, 2022):

What coincidence, we were just talking about this on a mail thread. I think internally this is https://task.ms/dd/1522793.

@zadjii-msft commented on GitHub (Apr 13, 2022): What coincidence, we were just talking about this on a mail thread. I think internally this is https://task.ms/dd/1522793.
claunia commented 2026-01-31 05:36:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 9, 2022):

This might be fixed in 17.3 Preview 2. I'm not super familiar with how VS tracks work, so it's hard for me to tell, and I won't be able to definitively confirm without ARM64 hardware.

I'm moving this out of 1.15 to 1.16 for now, since that's probably about when that'll be fixed.

@zadjii-msft commented on GitHub (Jun 9, 2022): This might be fixed in 17.3 Preview 2. I'm not super familiar with how VS tracks work, so it's hard for me to tell, and I won't be able to definitively confirm without ARM64 hardware. I'm moving this out of 1.15 to 1.16 for now, since that's probably about when that'll be fixed.
claunia commented 2026-01-31 05:36:24 +00:00
Author
Owner
Copy Link

@shuffle2 commented on GitHub (Jul 29, 2022):

I just installed VS 17.3 Preview 5.0 on arm64 device (surface pro x) and noticed that the "Developer Command Prompt" Terminal profile(s) do get created, however they specify -host_arch=x64 in their configured command lines (the target arch is correctly set to arm64, tho). This causes cl.exe when run from such a Terminal to be emulated x64 processes which is not ideal for speed reasons. Not sure if it's same as this issue or should have another one opened for it...

@shuffle2 commented on GitHub (Jul 29, 2022): I just installed VS 17.3 Preview 5.0 on arm64 device (surface pro x) and noticed that the "Developer Command Prompt" Terminal profile(s) do get created, however they specify `-host_arch=x64` in their configured command lines (the target arch is correctly set to arm64, tho). This causes `cl.exe` when run from such a Terminal to be emulated x64 processes which is not ideal for speed reasons. Not sure if it's same as this issue or should have another one opened for it...
claunia commented 2026-01-31 05:36:25 +00:00
Author
Owner
Copy Link

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

Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances? In here:
image

We probably need to update our own generator to pull in the ARM profiles on ARM, but I think they're supposed to be there now, after 17.3 preview 2.

@zadjii-msft commented on GitHub (Jul 29, 2022): Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances? In here: ![image](https://user-images.githubusercontent.com/18356694/181750131-d10d9706-7be0-4e69-827f-d2def7f9105d.png) We probably need to update our own generator to pull in the ARM profiles on ARM, but I think they're supposed to be there now, after 17.3 preview 2.
claunia commented 2026-01-31 05:36:25 +00:00
Author
Owner
Copy Link

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

Oh I mean, this would totally do it too:
5c35a64bb3/src/cascadia/TerminalSettingsModel/VsDevCmdGenerator.cpp (L39-L46)

I wonder if there's a clean way for us to pass in -host_arch=arm64, and have it stealth fall back to amd64 on versions of VS before there was an ARM toolchain. @heaths thoughts?

@zadjii-msft commented on GitHub (Jul 29, 2022): Oh I mean, this would totally do it too: https://github.com/microsoft/terminal/blob/5c35a64bb3e4d158ee8c56024c5ca2412999742a/src/cascadia/TerminalSettingsModel/VsDevCmdGenerator.cpp#L39-L46 I wonder if there's a clean way for us to pass in `-host_arch=arm64`, and have it stealth fall back to `amd64` on versions of VS before there was an ARM toolchain. @heaths thoughts?
claunia commented 2026-01-31 05:36:25 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Jul 29, 2022):

That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason.

@heaths commented on GitHub (Jul 29, 2022): That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason.
claunia commented 2026-01-31 05:36:26 +00:00
Author
Owner
Copy Link

@shuffle2 commented on GitHub (Jul 29, 2022):

Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances?

yup:
image

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2022\Visual Studio Tools>tree /f
Folder PATH listing for volume Local Disk
Volume serial number is 00000259 8843:F9C0
C:.
│   Debuggable Package Manager Preview.lnk
│   Debuggable Package Manager.lnk
│   Developer Command Prompt for VS 2022 Preview.lnk
│   Developer PowerShell for VS 2022 Preview.lnk
│
└───VC
        ARM64 Native Tools Command Prompt for VS 2022 Preview.lnk
        ARM64_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk
        ARM64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk
        x64 Native Tools Command Prompt for VS 2022 Preview.lnk
        x64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk
        x86 Native Tools Command Prompt for VS 2022 Preview.lnk
        x86_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk
@shuffle2 commented on GitHub (Jul 29, 2022): > Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances? yup: ![image](https://user-images.githubusercontent.com/113063/181821604-d90136cf-f0ec-46f4-9e1d-a7325e799e5a.png) ``` C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2022\Visual Studio Tools>tree /f Folder PATH listing for volume Local Disk Volume serial number is 00000259 8843:F9C0 C:. │ Debuggable Package Manager Preview.lnk │ Debuggable Package Manager.lnk │ Developer Command Prompt for VS 2022 Preview.lnk │ Developer PowerShell for VS 2022 Preview.lnk │ └───VC ARM64 Native Tools Command Prompt for VS 2022 Preview.lnk ARM64_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk ARM64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk x64 Native Tools Command Prompt for VS 2022 Preview.lnk x64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk x86 Native Tools Command Prompt for VS 2022 Preview.lnk x86_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk ```
claunia commented 2026-01-31 05:36:26 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 9, 2022):

That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason.

This is probably a bit aggressive, but... 17.3 preview builds have ARM64 native tool developer prompts already; if we just put a stake in the ground, call it ">=17.3", and bear the risk of a little wrongness if it turns out that ARM64 is pushed back to 17.4 or further... how bad would that be?

What I imagine the worst case scenario to be: we mess up the seven people (guess; not informed by data) who have installed the entire amd64 VS on arm64 and simultaneously use it with Terminal.

@DHowett commented on GitHub (Aug 9, 2022): > That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason. This is probably a bit aggressive, but... 17.3 preview builds have ARM64 native tool developer prompts already; if we just put a stake in the ground, call it ">=17.3", and bear the risk of a _little_ wrongness if it turns out that ARM64 is pushed back to 17.4 or further... how bad would that be? What I imagine the worst case scenario to be: we mess up the seven people (guess; not informed by data) who have installed the entire amd64 VS on arm64 and simultaneously use it with Terminal.
claunia commented 2026-01-31 05:36:26 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 9, 2022):

Immediately afterwards

Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. 😄

@DHowett commented on GitHub (Aug 9, 2022): _Immediately afterwards_ Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. :smile:
claunia commented 2026-01-31 05:36:26 +00:00
Author
Owner
Copy Link

@shuffle2 commented on GitHub (Aug 9, 2022):

Fwiw: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-3-is-now-available/

Version 17.4 will be the first version of Visual Studio generally available as a native Arm64 application.

@shuffle2 commented on GitHub (Aug 9, 2022): Fwiw: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-3-is-now-available/ > Version 17.4 will be the first version of Visual Studio generally available as a native Arm64 application.
claunia commented 2026-01-31 05:36:27 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Aug 9, 2022):

Immediately afterwards

Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. 😄

I wonder if it's worth querying that the arm64 components are installed, which can be done similar to what I did here in vswhere: dac187ab5f/src/vswhere.lib/InstanceSelector.cpp (L249-L299)

I'd be happy to submit a PR for this (wouldn't even need a version check then), but it was my (mis?)understanding from the internal thread that we really didn't need to detect the host. Or was that just orthogonal?

@heaths commented on GitHub (Aug 9, 2022): > _Immediately afterwards_ > > Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. 😄 I wonder if it's worth querying that the arm64 components are installed, which can be done similar to what I did here in vswhere: https://github.com/microsoft/vswhere/blob/dac187ab5f3a5f28ab59f5c069aeaf3c3a51aa30/src/vswhere.lib/InstanceSelector.cpp#L249-L299 I'd be happy to submit a PR for this (wouldn't even need a version check then), but it was my (mis?)understanding from the internal thread that we really didn't need to detect the host. Or was that just orthogonal?
claunia commented 2026-01-31 05:36:27 +00:00
Author
Owner
Copy Link

@Alovchin91 commented on GitHub (Aug 9, 2022):

I believe this is a bit more complicated.

One can install C++ Build Tools for ARM64 from an x64 package. In fact, that's what I've been doing for Rust development for ages. However, that doesn't mean that ARM64 native toolchain is available — it only appeared in 17.2.

But there's more. Even though ARM64 native toolchain (by that I mean the HostARM64 folder) is present in 17.2 and works, the VCVARS BAT is broken in 17.2. So going with 17.4 is probably the safest bet. (Yet to check with 17.3)

@Alovchin91 commented on GitHub (Aug 9, 2022): I believe this is a bit more complicated. One can install C++ Build Tools for ARM64 from an x64 package. In fact, that's what I've been doing for Rust development for ages. However, that doesn't mean that ARM64 native toolchain is available — it only appeared in 17.2. But there's more. Even though ARM64 native toolchain (by that I mean the HostARM64 folder) is present in 17.2 and works, the VCVARS BAT is broken in 17.2. So going with 17.4 is probably the safest bet. (Yet to check with 17.3)
claunia commented 2026-01-31 05:36:27 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Aug 9, 2022):

A version check alone isn't enough, though. The component may not be installed. The APIs support querying for the exact component(s), though there is some risk - though small - of the teams changing component IDs in future versions.

@heaths commented on GitHub (Aug 9, 2022): A version check alone isn't enough, though. The component may not be installed. The APIs support querying for the exact component(s), though there is some risk - though small - of the teams changing component IDs in future versions.
claunia commented 2026-01-31 05:36:28 +00:00
Author
Owner
Copy Link

@Alovchin91 commented on GitHub (Aug 9, 2022):

there is some risk - though small - of the teams changing component IDs in future versions.

I would deem it highly unlikely as that would break waaay too much 3rd party code.

@Alovchin91 commented on GitHub (Aug 9, 2022): > there is some risk - though small - of the teams changing component IDs in future versions. I would deem it highly unlikely as that would break waaay too much 3rd party code.
claunia commented 2026-01-31 05:36:28 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Aug 9, 2022):

I was the architect on the VS Setup engine. It's happened. That's why we documented that customers should ideally only depend on workload IDs, which shouldn't change unless deprecated (removed, specifically), for example. But, the VC team has been pretty good about keeping component IDs unchanged exactly for this reason.

@heaths commented on GitHub (Aug 9, 2022): I was the architect on the VS Setup engine. It's happened. That's why we documented that customers should ideally only depend on workload IDs, which shouldn't change unless deprecated (removed, specifically), for example. But, the VC team has been pretty good about keeping component IDs unchanged exactly for this reason.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Product-Terminal Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17240
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?