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.
After seeing (32-bit) in task manager I thought it must be a mistake. Shouldn't dev tools be a little bit closer to the bleeding edge?
However, a VS project over 4GB tells me someone is doing something wrong.
"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.
Needs more than 640K.
-- Bill Gates
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.
m$ is right. Use a proper compiler and make system. GCC + make.
i so hate and loth microsoft now, and i think most of the world feels the same way. die microsoft just die.
This is really bad - and against the trend.
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
Big difference. The team size is unbelievably small as it is, with those who knew the guts have already left.
Silent?
This site gets ever worse- focusing as it does on State Department guideline PROPAGANDA against Iran and Russia. The so-called 'tech' articles are now just the (badly considered) 'SUGAR' to help the State Dept propaganda Slashdot articles go down.
Visual Studio remaining a 32-bit application means NOTHING. Unless a SINGLE source file exceeds the 4GB limit, no issue will occur. And, of course, the compilers that come with VS have supported the development of true 64-bit applications forever.
Sure that would mean using more memory?
It eats-up memory like nothing I've ever seen before. My 32 GB desktop swaps like hell when running builds on a large Java project, and simple things like find usages can take tens of minutes. I wish it was limited to 4 GB.
Back when Microsoft stabbed the VS6 community in the back some of us told you you would be fools to migrate to .NET, because Microsoft had proven themselves to be an untrustworthy company which will sell you out for a chance to pimp their latest not even very good product. Well it's taken 13 yaers but welcome to the club. They almost sold you guys out with Silverlight as the supposed dev tool for Metro, but the howls of outrage deterred them and then Metro flopped. But hey, no 64 bit for you guys either. Sucks to be us Microsoft platform devs. Hey, there's always web development...
Brackets contain world's first nanosig, highly magnified:[.]
GCC and LLVM have full 64-bit capabilities and are free.
Anons need not reply. Questions end with a question mark.
I agree with all of their reasons. Posting anonymous because the open-minded slashdot hive-mind can't tolerate dissent even when it is informed.
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.
The exe for SQL Server management studio is devenv. Plugins for it (which are not officially supported, but which are possible) use the visual studio object model. There are times when you want to copy large result sets out of SSMS to your business-user tool of choice - excel, access, tableau, etc. Out of memory exceptions are common when these result sets are large.
It's true that there are other ways to get the data out... import/export, SSIS, etc. But as someone who, on some days, might write 20 to 30 ad-hoc queries for business analysts to consume, I assure you that the extra few minutes required to do anything other than copy-paste *does* add up. Therefore the memory limitation of SSMS is a real, practical frustration in my day to day work.
The same argument applies to SSDT, or any other data-centric development tools based on visual studio.
As a long time fan of visual studio, and someone who has developed almost entirely within the MS ecosystem for 20 years, I outright reject the MIcrosoft argument as empirically absurd.
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.
Afraid of Open Source ? Or simply afraid of linux/FreeBSD ?
... Oh, sorry just a communication thing to say "We still exist" ...
Those OSes can do the job efficiently...
I was only wondering why they could think that a 32 bits is most of the time a better deal ?
Should people use a 16 bits so it would be better ? And who knows a 8 bits could do the trick I suppose ?
May be it is just a marketing thing
What the fuck are you taking about.
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.
Microsoft declines to sell an OS that isn't Global Mother Fucking Spyware.
Bill is down to his last $80 Billion. Of course he doesn't want to talk about the expenses of selling an OS that isn't Global Mother Fucking Spyware.
He isn't paying anybody to mention it either.
Thanks Microdot.
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....?
Microsoft also claim that a C++ program that uses DLLs does not have to conform to any language standard since DLLs are "modules". For example, static destructors are not sequenced correctly when using DLLs. This causes all sorts of issues when combined with new language features such as threading.
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.
If Microsoft is unwilling to move VisualStudio to 64-bit what is Microsoft using to develop the 64-bit versions of it's own software with? They obviously aren't using their own development studio.
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.
People should dump the whole .Nut and just go to Java/C++/PHP within Eclipse.....
Fuck 64 bit, fuck compiler, fuck editor, fuck visual, fuck studio, fuck memory, and FUCK YOU!!!!!!
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.
In the mean time Power 8 supports both little endian and big endian.
They should just open source the code as they have been doing with their other technologies. We will make it 64-bit.
It's called Windows 10.
You had a good run.
I haven't even THOUGHT about Visual Studio since 1999.
Microsoft really doesn't have a 64 bit visual studio?
Glad I wasted absolutely no time in that development environment
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.
I use Visual Studio every day. For my purposes, it is far and away the most useful IDE I've ever dealt with. It's better than anything I've used for embedded systems C and C++. Better than anything I've used for Python. It's better than Eclipse. It's better than XCode. It's better than Android Studio was and the only thing that comes close for me is IntelliJ for Java and Scala. But I'd rather not write in Java, thanks.
Refactoring, search, analysis, debugging, profiling and customization are all there in one tool and they're all either very good or the best.
It can be clunky sometimes. It can be slow. It can break. I've built and heavily edited open solutions with 50+ projects and 60K+ files. It didn't run out of memory. I don't need it to use more than 4GB of memory. I want it to be slightly more reliable and faster never hurts. I don't think that going on a 64-bit "upgrade" adventure going to yield more stability, more speed or more features. The very few people who really need more memory for the VS process have work-arounds. I expect that if anyone needs 64-bit VS, it's probably Microsoft. If they aren't doing it for themselves, it probably doesn't need to be done soon.
IDEs are pretty complex beasts. If you guys are going to complain about it, go ahead and point to a better one.
It's gone through some very strange development. Some of the releases got quite good, then inexplicably they threw out the profiler without offering a replacement, absolutely screwed up VS2003 with a bug which caused unnecessary lengthy recompiles, in VS2010 they screwed it further so if you wanted to have a common include directory you had to go inside every fucking subjproject to add it, shit like that. The last good change with runtime recompiling in 2003, but that was still without a profiler, ut no other change after that has added anything useful.
They just fuck with the GUI. They add flash-in-the-pan proprietary coding technologies which only a few people give a fuck about and years later even those stop caring. There haven't been any good additions for a long time. The GUI remains a nightmare. Intellisense remains a mess. And the greatest improvements to Intellisense have been Visual Tomato who do far better work with VS than anything Microsoft have done in the past decade.
So ShanghaiBill, I believe you. The Microsoft Visual Studio "team" should engo a mass firing and be replaced with better coders who give a shit about their work. And Microsoft, just buy out Visual Tomato for Gods sake. They are so far ahead of lazy Microsoft's shit programmers it is pathetic!!!
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.
32 bits should be enough for everyone
Cry havoc, and let slip the dogs of war
Given that almost everyone in technology has sold people on how great 64 bit is. Now Microsoft and some others seem reluctant to embrace 64 bit for some applications? Seems to me memory issues could be solved other ways then moving to 64 bit? But maybe I am mistaken? I guess for me, I just have seen a lot of technology sold to the public that may in fact just be to move new product than actually helping anything. We are just now seeing popular apps like Google Chrome move to 64 bit as the default rather than 32. Yet, Firefox remains today as a 32 bit platform. Even though it runs perfectly well and I doubt many people even care its still 32 bit.
The original poster is referring to the new Windows runtime WinRT (which is COM), and the use of C++/CX to interface with it.
WinRT is only useful if you are wining universal apps. WPF is still the premier desktop development platform, but it doesn't interop well with C++. For C++ desktop development you're still stuck on MFC for first party solutions.
...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.
if they addressed the plethora of issues that are resolved by merely running as administrator.
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.
M$ telling people to write better code.
Best laugh I've had in a long, long time.
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!