Slashdot Mirror
Microsoft Declines To Make a 64-Bit Visual Studio (uservoice.com)
OhPlz writes: A request was made back in 2011 for Microsoft to provide a 64 bit version of Visual Studio to address out-of-memory issues. After sitting on the request for all that time, Microsoft is now declining it, stating that it would not be good for performance.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
We don't want to do the work.
32 bits ought to be enough for anyone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
And that's why we are staying with Windows 98
The day they broke that limit, some cheered. Others looked upon it with dread, knowing the hellspawn that would follow.
"and we have a really, really lame explanation for our underlying laziness and/or incompetence"
"also, fuck you, developers."
I've fallen off your lawn, and I can't get up.
I don't quite understand why would anyone have a solution with 10k (yes, thousand) projects. To me it seems that the project is structured incorrectly.
The real problem is that the fancy built-in designers, such as the WPF designer, only work with 32-bit components in 32-bit Visual Studio. When someone writes a component that is 64-bit, because it references a DLL that in-turn references, say, a 64-bit Oracle driver, which is part of code that we don't have control over. Now the designer won't load and shows a cryptic error message.
I was waiting for this. Not disappointed.
Thank you.
I have a quad core 3.5Ghz with 32GB of RAM, VS2015 installed on an SSD. It takes over 15 seconds to get to a working state. After the last update (2), then the Update patch, it now pops up some idiotic error about scc something-or-other every time it starts, and every time I open a project. An update for this POS software takes at least 15 minutes -- with far and away most of the time spent sitting at 99% complete with the status message: "Visual Studio is configuring itself -- this might take a while."
Yeah no shit it might take a while.
In summary Visual Studio has become one of the worst programs I use. It is horrifically bad in all aspects: Hard to use, impossible to navigate, useless documentation.
When I wander over to the C++ forums on reddit I frequently see their runtime library/compiler guy -- I think his name is STL, sheepishly saying what an antiquated POS their C++ compiler is. That doesn't give me warm fuzzy feelings either.
It's all just more nails in the coffin as far as I'm concerned. I rarely develop for Windows anymore and when I have to it's because I'm forced to. The entire Windows platform is a complete disaster from a developer's point of view. All the years of MSDN trying to sell whatever the current darling language, what's-old-is-new-again (C++ is back, did you notice?), terrible, TERRIBLE API design, and just general CRUFT (did I mention that COM is back too..?) have finally caught up to them.
They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
Anyone who actually believes this has no business working on development tools.
No 64 bit version "because not needed" on Linux meanwhile you have to install 64 multilib packages and compile from source many of those on ArchLinux just to run Steam. Come on guys, you can argue that staying 32 bit is smaller but then it actually becomes larger because you have to install tons more 32bit libraries to support legacy on our all shiny 64 bit systems. In effect it is smaller and leaner to go all 64 bit.
is and has always been a disgusting kludge on top of the 32-bit (that they finally managed to get in decent shape). Faced with the necessity to build something just as ugly for another product, I'm not sure I would have reacted differently than they did.
Oh, and the bit about valuing the feedback is priceless, of course.
I can assure you, the best way to get rid of dragons is to have one of your own.
Microsoft makes very good developer tools - but the decision on how to make them, unfortunately, has constantly been shaped by a LONG series of internal political decisions on what products they want to be promoting at that very second.
DirectX, Crystal Reports, 'Modern' (metro to everyone else), the dot Net framework, phones, MS-specific java,, etc., etc... Some of them ended up good ideas, some of them were just what they wanted to push to capture some market. It's a big part of why it's actually something of a bad idea to just read Microsoft documentation on their own products - they'll tend to color every piece of introductory material in light of what they want to promote at that moment, what they want YOU to do for THEM.
They also tend to stall on some technologies that they feel will shift resources in a way that won't help them at that very moment. Shifting to 64-bit developer tools might be a bit expensive to test binary interoperability with everything - and Microsoft also hasn't found a very good consistent method of hosting 32-bit DLLs into 64-bit executables that isn't just some piped communication between different process spaces. I can understand their reluctance to commit resources into something they're not sure they can make work seamlessly.
But really, I've seen a lot of my Visual Studio exe memory usage stats floating up to the large-address-aware 32-bit limit. Even if it doesn't meet 100% compatibility/interoperability, I think it would still be a good idea to start an experimental option of a set of 64-bit build environments. Perhaps with embedded 32-bit memory spaces that you can host stuff in without loading errors, if at all possible - but 64-bit-only restrictions if that's not possible would also be acceptable.
Ryan Fenton
Sure that would mean using more memory?
GCC and LLVM have full 64-bit capabilities and are free.
Anons need not reply. Questions end with a question mark.
Damn right, any project this big should be done with professional tools!
Glad MS finally admits it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Visual Studio remaining a 32-bit application means NOTHING. Unless a SINGLE source file exceeds the 4GB limit, no issue will occur.
Let me get this straight. Are you honestly suggesting that if I try to compile or refactor a monstrosity that a 3.9GB C++ file worth of nested template forests would be, this 32-bit version is going to take it and not fall over or grind to death swapping? I'm not a VS user, and will be happy to stand corrected (and amazed), this is an honest question.
And, of course, the compilers that come with VS have supported the development of true 64-bit applications forever.
We know. Restating the unrelated obvious and tagging it 'obvious' does not your point make.
Every end has half a stick.
Once you use IntelliJ and their other IDE's for C/C++ you won't ever like Visual Studio again.
JetBrains has great IDE's.
ultimately benefit from being 64 bit as it allows for things like better vectorized string comparisons? I mean if anything it'd be a measurable improvement in speed. You get more GPRs and larger/wider vector registers. And it wouldn't shock me if a templated piece of c++ managed to make the compiler, optimizer, preprocessor and linker manage to consume a fair bit of that 32 bit address space for a given single compile process.
VS does not give even a tiny crap about how big your files are. It's a text editor, file manager, build controller, source code repository client, and a million other ancillary dev tools all rolled into one. It is not a compiler.
Visual studio is "devenv.exe", and is 32-bit only.
The compilers are "cl.exe" (C++), "csc.exe" (C#), "vbc.exe" (Visual Basic), and "fsc.exe" (F#). All of these are 64-bit.
So unless your MSBuild script (basically a makefile that works with all of Microsoft's compilers) is larger than 4GB, you're just fine working with devenv.exe. If your MSBuild script gets larger than that, you're doing it wrong.
The big problem is debugging.
We've got a 64-bit app which VS will happily build and the app runs fine. But if we want to debug it live VS chokes, falls over and dies, out of memory once the app uses more than 3 GB.
It's legit using > 4GB because it's heavy image processing of large color images at high dpi and the machines are specced for it. Obviously, we could page stuff in and out of memory ourselves, but that rather defeats the purpose of 64-bit OS and would slow everything down (speed is paramount here, burning memory to get it was a primary design decision) - and the program runs fine when not debugging in VS.
What the fuck are you taking about.
I, for one, welcome our 640Kb address space overlords!
.NET is still going strong after 14 years. A new cross platform version of it is at RC2. People are desperate for .NET to die but it doesn't seem to be going anywhere.
4194304k ought to be enough for anyone
I worked at MS in early 00s. We didn't use VS to write code. We used a stripped down version of VS or even WinDbg to debug. Nowadays I use Vim and YouCompleteMe (on Linux) and it just works. Zero dollars, easy to set up.
The immediate reaction is to say it is silly that they are not offering a 64-bit version.
But many developers are likely using a number of extensions - which will currently be 32-bit because that's what Visual Studio is, and 64-bit would require all the extensions provide new versions as well.
It probably wouldn't take a huge effort to offer Visual Studio as both 32-bit and 64-bit versions (just like Office). But a more useful - although much longer - use of engineering effort would be to take the full Visual Studio experience on to the CLR.
Developers....?
Developers....?
Developers....?
Spot on. Something isn't right there.
Changes to 64-bit applications are not allowed. :-(
Like VS6 too much real work was done with it for it to go away any time soon. But it's now abandonware. MS obviously isn't interested in keeping it up to date any more. All the versions that still work will probably continue to for some time, just as you can still run VS6 apps. (Actually, VS6 apps run better than older .NET apps today, having way fewer dependencies.) But expect things to start breaking, add-ons to stop being supported and working, and expect no help from MS when these things happen.
They're on to the next shiny thing. .NET isn't it any more.
Brackets contain world's first nanosig, highly magnified:[.]
How ridiculously broken does your overall OS and Application Development design have to be to make the transition from 32 to 64 bit this hard?
I'm REALLY not Trolling; but OS X went through an entire CPU ARCHITECTURE change (and actually TWO, if you count iOS as an offshoot of OS X, and THREE if you count the "Classic (Blue Box)"/Carbon APIs), PLUS handled 32 to 64 bit transition (some of it happening at the SAME TIME as the PPC to Intel Transition), and almost ALL OS X users noticed NOT A SINGLE THING.
In fact, with OS X, the ONLY place I have heard of ANY 32 to 64 bit pains were with Audio Unit Plugins. There might be a few others, but it CERTAINLY wasn't front-page news anywhere.
Can you IMAGINE how wonderfully that all would have gone with Microsoft?
Oh, and NT is supposedly every bit as CPU-Agnostic as NeXTStep (afterall, there was even a version of Windows NT for PowerPC); so I really don't want to hear anything about how much harder it is with Windows.
MS has a bunch of THE LAZIEST DEVELOPERS ON THE PLANET.
I think their argument is that if your project is so large that it needs 64 memory space to parse and generate the binary, then it's too large and should be broken up into smaller modules (dll's, resource files, etc.) The MSVC will definitely produce 64 executables if you configure it to. It's actually more a limitation they put on themselves. Because it means that their running compiler must run as a 32 bit binary. Which requires higher level of discipline from their compiler designers.
Any guest worker system is indistinguishable from indentured servitude.
It wants its newfangled CPU architecture back.
Escher was the first MC and Giger invented the HR department.
The Visual Studio engineering system is horrible. You can tell with how over the years Visual Studio is comprised of so many small iterations. Or a new feature is added, and then never worked on again. If they had a decent engineering system they certainly could afford to do a 32-bit and 64-bit build.
It should involve only minor code changes - if even. Even large software projects seldom require more than a new compiler flag.
A couple else suggested this, and i tend to agree: they're not doing it because they can't. My guess is that the VS codebase is a mess to begin with.
You've clearly never converted a significant amount of legacy code from 32 bits to 64 bits. Strange things happen, and it's not always easy to isolate the cause. My guess is that there are a lot of calls to unmanaged Win32 libraries that would break, not to mention variables that are declared with non-portable sizes, such as Int32 instead of Int.
Then there is performance. I suspect they aren't joking when they suggest that performance of a 64-bit version would be slow, if for no other reason than that the larger executables would take longer to load.
I did, actually. I even migrated legacy VMS code to x86-64 Linux back in the day, a mixture of C++ and Assembler, and it was never particularly hard. A chore, yes. But not hard, and the resulting binaries were no slogs either. Properly written executed 64 bits code can yield significant performance boosts, if only because the register space is twice as big as x86.
Keep in mind, we're talking about an IDE here. There are plenty of use cases, specially for large projects, that could have developers using more than 4GB of RAM at work.
PHP lol that's a good one
Actually, come to think of it, that's may be why they aren't implementing 64 bit. Maybe they still don't use it themselves.
Notepad++? Meh. I use "echo -n" and write directly to the executable file. That way I don't need makefiles or even "source code", I just put my bash_history in git; when I need to build on Winblow$ I use AutoHotKey and a cygwin shell with a bunch of "arrow up + enter" macros.
lucm, indeed.
If 4,000 represents 0.01%, it means that 40 million people use Visual Studio to code. Yet according to IDC there's about 18.5 million programmers in the world, including hobbyists. This means Microsoft controls roughly 220% of the software development market. I had no idea they were so successful!
lucm, indeed.
Use a proper compiler and make system. GCC + make.
Or let go of antiquated technologies and use the javascript compile and make system. It's called "CTRL-S", although some geeks use ":wq" or "ZZ" on linux.
lucm, indeed.
32 bits should be enough for everyone
Cry havoc, and let slip the dogs of war
...forever wary. .Net and C#....all had to be rewritten every 4-5 years as MS switched their recommended product for major corporate programming. And everybody had to buy new MS software, but importantly, spend 100X as much re-writing.
I did months of work in, I hope I have the version number right, VB 3. That would be about 1997. VB4 comes out, and my VB3 program just won't load into it; there don't even seem to be conversion tools worth using, easier to start again. My program had served about 70% of its purpose, so we just kept it running a little longer and ditched it entirely.
But the only proprietary environment I ever again coded in was VBA for Excel, which I correctly surmised they had almost no ability to break with non-compatibility because of the backlash. None of the VB stuff in the nineties was for major corporate applications and it was mostly user-department small apps that were sabotaged. But spreadsheets, man, those often run the business.
Anyway, my little user-department apps now all in Perl and so forth, are often still running (I'm retired) in their late teens and early 20s. The IT department applications, which did stick with MS all the way, through VB6 and
I watched that the whole last 18 years, marvelling that anybody would have their development environment depend on a corporation whose interests are SO divorced from theirs that they'd inflict a million-dollar rewrite on them just to sell $10,000 worth of software.
And I freely admit that I don't track things like CPU specs any more, is why Windows is still 32 bit? Are modern CPUs still coming in 32 bit? I have no problem slapping 16 gig or more of RAM in any of my Macs and they just say Cool! Why do we have to buy a 64 bit version of Windows to get more than 4 gig of RAM in a box?
When you sympathize with stupidity, you start thinking like an idiot.
640K should be enough for anybody.
There's no time like the present. Well, the past used to be.
All program languages allow nonsensical constructs. 0 + 0 won't generate an error in any language I am aware of (not to say none of them, just thirty or so.) Doing something twice, like a=0; a=0; won't generate an error, etc. It's not up to the language to catch you when you're stupid (at least, it shouldn't be... every attempt at that I have run into has turned into some kind of annoyance) it's up to you to not do stupid things.
c's automatic type conversions are generally useful when they are used with a knowledge of what is going on. When you want something else to happen, you can use explicit casts. When even that won't do it, there are always unions - you can do damn near anything you can imagine with a union. And if *that* won't do it, then just start copying raw memory around. :)
The point being, what you want to do should be available for you to do, and not constrained by the idea that someone with low skills might get in there and do something that is in some sense functionally wrong or unexpected -- because if it is unexpected, then that's a reflection on a lack of understanding the language. Not on the language (unless, of course, it's a bug in the compiler / interpreter / parser, etc.)
I've fallen off your lawn, and I can't get up.
Also, it isn't that c is a footgun; it's that c is a railgun, so you definitely shouldn't point it at your foot.
If you're the kind of programmer that aims at your foot, then use a language that keeps its "muzzle" pointed away from you until you go through the equivalent of a weapons safety course for the big guns. Otherwise.... yup, no feet. :)
I've fallen off your lawn, and I can't get up.
We've got 64-bits... and cookies.
Basically all functionality comes from extensions (even the 'built-in' functionality). And extensions *can* be written as 64-bit (https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/). So what's the big deal, fellas? The built-in extensions don't need the extra address space -- it's normally costly (but often helpful) extensions like R# that do. Even in a solution with > 100 projects, I wasn't even pushing a gig.
This is much ado about nuffin.
There are people in my office that try to use Excel as a relational database.
There are days when I know Excel is there. I just can't go to work. Then I day dream of launching dead, bloated, stinking, plague infected cows, into the Microsoft campus, using a trebuche. Each with an office 365 licence for Excel glued to their silken, bovine, fur......good times......
There should be a dialog or something that pops up each time Excel opens that says, "This program is for counting. It is a violation of the terms of service to use this application as a database.". Not that anyone reads the shrink wrap.....I'm just bitter now....
The Holsteins outside look nervous. I wonder what they are sensing......storm maybe.... :|
Seriously, if your project is running out of memory while building then maybe the problem is with the project.
That ship sailed in December 2011, when the Firefox web browser became too large to build with profile-guided whole-program optimization without exceeding 3 GB. See Firefox Too Big To Link On 32-bit Windows.
A unnamed spokesman said 640k should be enough for anybody.
Games need to catch up to 64-bit land.
I thought they already had, first with the Atari Jaguar, then with the Nintendo 64, and finally with the AMD Jaguar processor in the PlayStation 4 and Xbox One consoles.
The 64-bit version of Office isn't exactly a resounding success. The Office install program even strongly encourages you to use the 32-bit version unless you have a compelling reason to install the 64-bitter. Memory bloat is an issue, but the biggie is compatibility with add-ins: a lot of them are NOT 64-bit ready, including some of Microsoft's own. The 64-bitter doesn't feel any more responsive and starts up slower on older systems.
There are some strong similarities between Office and VS: flagship products, extensive 3rd-party ecosystem including add-ins, IO-bound, massive codebase & dependencies. Emphatically not just a matter of a changing a few compile switches!