I only see x86 version in msdn downloads.
Rico Mariani basically says:
The size of the pointers expands so all things being equal, the performance of a 64-bit Visual Studio would be less.
All the current add-ins would break.
Because there isn't much need for the IDE to take advantage of the 64 bit benefits.
The Framework itself comes in 32 and 64 bit editions.
Which x64 benefits do you want the IDE to take advantage of?
I bet most of the work would be testing both editions and managing the code for both editions from a single codebase. This isn't how the IDE team has worked (multi-CPU-architecture) the entire time it has existed. They took the big bet on managed code in VS10, so I can see how they might not want to take on additional risk in that cycle.
If I was managing such a task I'd wait for a longer release cycle.
Update: I was wrong in thinking .NET 5 would be released with Win 8, but no. Instead we got .NET 4.5, then .NET 4.5.1 with Win 8.1. Many small, incremental releases with the shortened Windows release cycles.
Related
I downloaded Visual Studio 2013 from DreamSpark but it's the 32-bit version and I couldn't find any 64-bit version. Is there none, and if so why is there no 64-bit version of Visual Studio?
Update (May 2021)
Visual Studio 2022 will ship as a 64-bit build: https://visualstudiomagazine.com/articles/2021/04/19/vs-2022.aspx
Original answer (Dec 2013)
First, there is a 64-bit C++ compiler that comes with Visual Studio tool set. So you can always change your project settings to make 64-bit builds of your app as needed.
Now, to answer the original question.
Think of it from a cost and ROI perspective. From years of shipping software at Microsoft, here's how I've seen the consideration for 64-bit builds get made.
When the 32-bit app works just fine on 64-bit, it's almost a non-starter to consider 64-bit.
Most of the projects at Microsoft aren't simple little Visual Studio projects in which the developer can just flip the Project settings from 32-bit to 64-bit. (I actually don't know if the Visual Studio team compiles Visual Studio with a VS project.) They are often well over a million lines of code that build with the VS compiler set, but from a command line and Makefile environment. Switching to 64-bit means updating a lot of this build infrastructure.
There is a cost of porting from 32-bit to 64-bit. The first cost is just fixing the bugs, getting the code to compile, restructuring the build environment, and all the upfront work just to get the initial build going.
There is an ongoing cost you pay for having separate 32-bit and 64-bit builds of an application. You have to build it twice every day. You have to run the test collateral on it twice every day. It's not a 2x cost, but it's not free either.
With more SKUs from the same code base, it increase that chances that a developer will break something when he checks in. Of course there can be automated tests to prevent this, but it will slow the developer down since he will have to go back and fix the other SKU that he doesn't have installed locally on his test machine.
Now here are some of the motivations for moving to 64-bit:
You really need to take advantage of 64-bit performance and memory architectures. Large database servers that use as much memory as possible will benefit from accessing more than 2GB limit imposed on a 32-bit Windows process.
You need to integrate with something already compiled with 64-bit. For example, if you want to write a shell extension for Windows, you will need a 64-bit build to run on 64-bit Windows. That doesn't mean the entire app has to be ported, but it does mean this component will need a separate 64-bit build.
You have a platform or API story for external developers to consider. Usually, they have their own needs for 64-bit builds. Hence, they may need a 64-bit ready API from you even if your native app can get away with 32-bit support.
Your team has just been re-organized into the Windows division and your team's code has been deemed necessary to be included into the next Windows release. There's no decision to be made anymore - your code will be compiling for 32-bit, 64-bit, and ARM (Surface RT).
Source code files should not be multiple gigabytes -- there's no reason for a text editor / development environment to use 64-bit pointers, which consume twice as much RAM for no benefit. Larger pointers make data structures containing pointers larger, requiring more memory bandwidth to move them around, and fitting fewer inside the CPU's data cache, so that the number of cache misses may increase as well.
The 32-bit editor is perfectly capable of launching and interacting with the 64-bit compilers, linkers, and debuggers when needed. Having only a 32-bit editor also simplifies the plugin model greatly.
The reason is the same as it has always been. It would require a significant effort to port a code base as large as Visual Studio to 64-bit and according to Microsoft, the benefits would be few and far in between.
In fact, MS claims that such a port could slow down Visual Studio due to the consumption of more memory. There would be poorer cache locality due to 64-bit pointers being stored in various places in the code. There is much code in VS that uses custom arena based allocators, although MS is trying to get rid of them. These could also possibly result in poorer performance, since pointer management within the arena would deal with 64-bit pointers which would occupy twice the space of their current 32-bit counterparts.
Given the tens of millions of lines of code that are Visual Studio, the effort to convert, test and tune a 64-bit version seems fraught with delays while having a seemingly small chance of having a positive outcome. If anything, MS seems more intent on porting Visual Studio to managed code in order to reap the benefits present there - a decision that is hard for us C++ developers to swallow.
For the present term, Microsoft recommends running Visual Studio in a 64-bit version of Windows, thus doubling the available address space (2 GB to 4 GB) without paying a 2x penalty for pointer storage within the VS process.
Is Visual studio 2010 slower than 2005? I just had my laptop upgraded to windows 7 64bit with visual studio 2010, and vs 2010 is much slower than vs2005 was when I had xp. Any upgrades or configurations you can think of that might help me out?
Turn off the "Enable rich client visual experience" and turn on "Use graphics hardware acceleration if available"
Extra features always come at a cost. If you don't upgrade your computer at a similar rate you upgrade your software, you'll find it gets slower and slower.
About VS2010 specifically, the UI uses WPF, so you need at least a decently passable graphics card to handle it. Intellisense also got a lot better, so it will use slightly more CPU.
For what it's worth, 2010 runs very smoothly on my computer.
Depending on your setup, Visual Studio 2010 can be faster than VS 2010 or slower. I'm not sure from your question in what way Visual Studio is running slower, though.
Is it just Visual Studio, or is anything else slower?
You mentioned you're running Windows 7 x64. If you have more than 4 GB of RAM, this is a good idea. If you have less than 4 GB, you're probably going to be slower than if you're running 32-bit. It's also worth looking at your Windows 7 performance rating--if it's low, applications like Visual Studio will be slow too.
The hardware requirements are listed over at http://www.microsoft.com/visualstudio/en-us/products/2010-editions/ultimate/system-requirements, but those are bare-bones requirements. If you're doing SharePoint development, then you'll need a much beefier system (SharePoint will compete for a lot of your system resources). I'd want at least 1 GB more RAM than recommended there even without SharePoint. The processor speed is fine for multiple cores, but if you have an old laptop 1.6 GHz and a single core won't be that fast.
Most people find an SSD drive helps incredibly.
Launching Visual Studio does seem to take longer, but to me it runs faster once it's up. F1 help is non-blocking now. Compiles can be done in parallel. Navigation and adding references is faster.
Grab the productivity power pack from vscodegallery.com--that adds a lot of shortcuts.
Visual Studio has more features than previous versions. Most people install everything. It may be better to just install the features you need.
The previous poster mentioned having a good video card or chipset. That's probably a good idea, but disk I/O and CPU are probably more important.
I'm talking about VS 2010 Professional/Ultimate RTM (not express versions).
Google doesn't show much other than stuff about the beta 2 and RC versions.
Will it run OK on a Core 2 Duo E6550 2.33GHz with 3GB RAM and NVIDIA GeForce 8400 GS?
Edit:
How does it go with R# 5.0?
I've been using the Premium RTM daily since release and experienced no problems whatsoever developing with C#/ASP.NET MVC2.
My machine is also similar specs to yours and has been running just fine.
Regarding your edit, I've also been doing all of this with Resharper 5.0 - again, no problems whatsoever.
I haved runed it for since release now, and i must say i have had no problem at all, but hey diden't have any with VS 2008 ether. But evythings works great fast and all this while looking nice :D Eclipse go home .D
I installed VS 2010 Ultimate RTM, in my laptop and its specs is exactly like yours except the Nvidia, and it is working perfectly with no problems.
I've been very impressed with 2010.
Even the Beta and RC releases were stable. I find VS2008 SP1 hanging on average twice a day for me.
So far the only thing to crash 2010 was a third party plugin.
Stability: Good
SVN Support (using ankh): Good
2008 to 2010 project upgrade: Good.
No reason not to upgrade.
The only thing is that it requires 3 restarts on XP and 1 on 7...
I was running the RC for a few months before the RTM version was released, and even the RC version was rock solid as far as I was using it.
I didn't use a stopwatch but I got the impression that it is a bit slower at startup than its predecessor.
Is there any 64 bit Visual Studio at all? Why not?
For numerous reasons, No.
Why is explained in this MSDN post.
First, from a performance perspective the pointers get larger, so data
structures get larger, and the processor cache stays the same size.
That basically results in a raw speed hit (your mileage may vary). So
you start in a hole and you have to dig yourself out of that hole by
using the extra memory above 4G to your advantage. In Visual Studio
this can happen in some large solutions but I think a preferable thing
to do is to just use less memory in the first place. Many of VS’s
algorithms are amenable to this. Here’s an old article that discusses
the performance issues at some length:
https://learn.microsoft.com/archive/blogs/joshwil/should-i-choose-to-take-advantage-of-64-bit
Secondly, from a cost perspective, probably the shortest path to
porting Visual Studio to 64 bit is to port most of it to managed code
incrementally and then port the rest. The cost of a full port of that
much native code is going to be quite high and of course all known
extensions would break and we’d basically have to create a 64 bit
ecosystem pretty much like you do for drivers. Ouch.
No! There is no 64-bit version of Visual Studio.
How to know it is not 64-bit:
Once you download Visual Studio and click the install button, you will see that the initialization folder it selects automatically is C:\Program Files (x86)\Microsoft Visual Studio 14.0
As per my understanding, all 64-bit programs/applications goes to C:\Program Files and all 32-bit applications goes to C:\Program Files (x86) from Windows 7 onwards.
Update: April 19th 2021
Microsoft announced their preview Visual Studio 2022 64 bit
Visual Studio 2022 is 64-bit
Visual Studio 2022 on Windows is now a 64-bit application. This means you can open, edit, run, and debug even the biggest and most complex solutions without running out of memory.
see https://learn.microsoft.com/en-us/visualstudio/ide/whats-new-visual-studio-2022
no, but it runs fine on win64, and can create win64 .EXEs
No, but the 32-bit version runs just fine on 64-bit Windows.
Is there any 64 bit Visual Studio at all?
Yes literally there is one called "Visual Studio" and is 64bit, but well,, on Mac not on Windows
Why not?
Decision making is electro-chemical reaction made in our brain and that have an activation point (Nerdest answer I can come up with, but follow). Same situation happened in history: Windows 64!...
So in order to answer this fully I want you to remember old days. Imagine reasons for "why not we see 64bit Windows" are there at the time. I think at the time for Windows64 they had exact same reasons others have enlisted here about "reasons why not 64bit VS on windows" were on "reasons why not 64bit Windows" too. Then why they did start development for Windows 64bit? Simple! If they didn't succeed in making 64bit Windows I bet M$ would have been a history nowadays. If same reasons forcing M$ making 64bit Windows starts to appear on need for 64Bit VS then I bet we will see 64bit VS, even though very same reasons everyone else here enlisted will stay same! In time the limitations of 32bit may hit VS as well, so most likely something like below start to happen:
Visual Studio will drop 32bit support and become 64bit,
Visual Studio Code will take it's place instead,
Visual Studio will have similar functionality like WOW64 for old extensions which is I believe unlikely to happen.
I put my bets on Visual Studio Code taking the place in time; I guess bifurcation point for it will be some CPU manufacturer X starts to compete x86_64 architecture taking its place on mainstream market for laptop and/or workstation,
Update: From the visualstudio 2022 preview site quoting https://web.archive.org/web/20211030202827/https://visualstudio.microsoft.com/vs/preview/:
Our 64-bit upgrade Take advantage of all your computer’s resources to scale Visual Studio to the largest of projects and complex workloads without running out of memory. You can continue to run and debug your 32-bit apps.
It seems they did what I was expecting they are dropping old 32bit support, quoting https://web.archive.org/web/20210910130939/https://learn.microsoft.com/en-us/visualstudio/extensibility/migration/update-visual-studio-extension?view=vs-2022:
Visual Studio 2022 RC is a 64-bit application, and introduces some breaking changes in the VS SDK
I want to thank every upvote for keeping this answer. As a thank you I want to add one more prediction: I still believe the trend will lean towards VSCode in time while VSCode forks or turns-into something like Eclipse Theia. Most probably they will give full support on cloud platforms with that. Especially for enterprises that will add great value and for the marketing sake I cannot find any better excuse about "move your onprem into the Azure" stuff. Anyhow seems we are correct about: Why Visualstudio was not 64 bit while it should be 64bit long ago,
Update: I think this will be the last update. Yes it was the direction I expected: https://vscode.dev/ deployed to public,
We're looking at upgrading from Visual Studio 2005 to Visual Studio 2008. I discovered the following disturbing comment.
From Update WINVER and _WIN32_WINNT:
Beginning with Visual C++ 2008, Visual C++ does not support targeting Windows 95, Windows 98, Windows ME, or Windows NT.
Does this mean that if we rebuild our products with Microsoft Visual C++ 2008, they will stop working on Windows 98 machines? It sounds like it, but I have trouble believing they'd make that big a change.
It's not just about .NET 3.5. It's about the Windows SDK header file macros and definitions pulled in by the mandatory version bump in WINVER. So yes, Colen, Visual C++ 2008 binaries will target the Windows NT APIs only and while occasionally they may work on Windows 98, you should assume that you cannot use Visual Studio 2008 to target Win9x. You will have to use Visual Studio 2005 or older.
Yes, it does mean that: The Windows CreateProcess and LoadLibrary APIs on Windows NT before Windows 2000 and all of Windows (95, 98, and ME) will not load a DLL or EXE file made by Visual Studio 2008 (VS 9), because the PE header in the file has the required OS version field set to 5.
The error message upon attempting to load a Visual Studio 2008-generated EXE file will (be a very unfriendly modal error dialog) actually say "You need to upgrade your operating system to run this program".
I experimented with editing the field to 4. The binary will be loaded, but any use of the Visual Studio 2008 C-runtime will hang or crash the process. There are ways to get Visual Studio 2008 projects to not use their native C-runtimes, but if massive use of C++ features is important to you, this approach is not going to scale past a small application.
Visual Studio 2005 (VS 8) has most of the features of Visual Studio 2008, but it still targets early OS versions which is why at my shop we are sticking with that for the moment.
It's natural that they do not support older versions of their operating system on their newer products. It would cost them more (not just monetary cost, but also making harder or impossible to provide some newer useful features) to make things work with the limitations (and often bugs) of older systems. This happens all the time, and with everyone; new versions of GCC drop support for older less popular architectures; new releases of glibc require a more recent minimum kernel version; and so on.
These operating systems have long been retired; from Microsoft's point of view, nobody should be using them anymore. If you still want to develop for them, you can use older tools of the same vintage.
The 3.5 Framework won't even install on Windows 2000 Server at this point. So I don't believe that they will on 95, 98, or NT either. Microsoft doesn't want the responsibility of supporting these retired operating systems anymore.
It is my understanding that with the most recent KernelEx all MSVC versions targeting XP could potentially work (results depending on how many "newest" functions/features you will then decide to use)
With respect to what the answer could have been in 2008 instead, there were quite a number of patched libraries even back then (check links on the Wayback Machine if they are broken).
While I agree with JesperE, Windows 98 is such a small percentage of users that it makes little sense to target them, unless of course you know a large percentage of your customers are in fact using Windows 98.
In any case, you can in fact target Windows 98 in Visual Studio 2008 (you can't develop on Windows 98). You must, however, target your projects at .NET 2.0 only, you cannot use any 3.0, or 3.5 features.
I'd recommend that you take this as an opportunity to stop supporting Windows 9x. This is a good reason as any to do so. And, at least if you're writing C/C++ code for the Win32 API, life is much easier if you can assume that the target OS is Windows 2000 or later.
According to .NET 3.5 information, Windows 98 is not supported by .NET 3.5, so I would imagine that is what they mean. You can still do .NET 2.0 and lower development, but if you use the 3.5 libraries, Windows 98 is not supported.