3 ms·

Microsoft still hasn't ported Visual Studio to 64 bit, so I don't expect Linux support is coming any time soon.

arsenide 7y ago
Per a StackOverflow post, the reasons for this are detailed here: https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... Is there some reason you would expect a 64-bit Visual Studio port before a Linux port?
- mrpippy 7y ago
  The blog post is 10 years old, the reasoning was poor then and has not aged well. No mention of the performance benefits of extra registers, new instructions, security benefits, etc. The only advantage I can see to staying 32-bit is that Windows on ARM64 only has an x86 emulator, not x86_64. I think there’s a 0% chance of a Linux port: VS Code is the cross-platform/future dev environment for Microsoft. But I wouldn’t be surprised to hear that a 64-bit Visual Studio is coming soon to Windows.
  - pjc50 7y ago
    The new instructions are generally special-purpose, Visual Studio doesn't sound like an obvious target for vectorisation. Security is meaningless - VS is not on a security boundary. The memory size cost disadvantage is real, though.
hermitdev 7y ago
MS has explicitly stated they dont intend or expect to make VS 64-bit in any near timeframe. They say they dont need to because the components that would benefit from 64 bit are already out of process and communicate to the main UI over IPC. That said, nothing stops a 32 bit VS building/debugging a 64 bit process. I was doing this 10+ years ago. MS doesn't support running VS at all on Linux/Mac, and probably won't ever, or for a very long time out. Use VS Code, instead. Yes, you can target Linux/Mac from Windows running VS, but VS wont run on the same OS.
- Longhanks 7y ago
  This is a bad excuse for too much (internal) complexity. 64bit is over 10 years old at this point and there's no reason NOT to update programs.
jarjoura 7y ago
All of the underlying tools are native 64-bit, but it's hidden behind a project property that you need to turn on to use them. I think it's just the C# code editor process that's still only 32-bit.
- pjmlp 7y ago
  Managed language tooling is written in their respective languages, so I doubt about the process still being 32-bit.

Per a StackOverflow post, the reasons for this are detailed here: https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... Is there some reason you would expect a 64-bit Visual Studio port before a Linux port?

mrpippy 7y ago
The blog post is 10 years old, the reasoning was poor then and has not aged well. No mention of the performance benefits of extra registers, new instructions, security benefits, etc. The only advantage I can see to staying 32-bit is that Windows on ARM64 only has an x86 emulator, not x86_64. I think there’s a 0% chance of a Linux port: VS Code is the cross-platform/future dev environment for Microsoft. But I wouldn’t be surprised to hear that a 64-bit Visual Studio is coming soon to Windows.
- pjc50 7y ago
  The new instructions are generally special-purpose, Visual Studio doesn't sound like an obvious target for vectorisation. Security is meaningless - VS is not on a security boundary. The memory size cost disadvantage is real, though.

hermitdev 7y ago

MS has explicitly stated they dont intend or expect to make VS 64-bit in any near timeframe. They say they dont need to because the components that would benefit from 64 bit are already out of process and communicate to the main UI over IPC. That said, nothing stops a 32 bit VS building/debugging a 64 bit process. I was doing this 10+ years ago. MS doesn't support running VS at all on Linux/Mac, and probably won't ever, or for a very long time out. Use VS Code, instead. Yes, you can target Linux/Mac from Windows running VS, but VS wont run on the same OS.

Longhanks 7y ago
This is a bad excuse for too much (internal) complexity. 64bit is over 10 years old at this point and there's no reason NOT to update programs.

jarjoura 7y ago

All of the underlying tools are native 64-bit, but it's hidden behind a project property that you need to turn on to use them. I think it's just the C# code editor process that's still only 32-bit.

pjmlp 7y ago
Managed language tooling is written in their respective languages, so I doubt about the process still being 32-bit.