Hacker News Reader

Comment by sriramk | Hacker News Reader

ex-VS person here (from 5 years ago though).

It is never an either-or. It is always a complex mix of what customers ask for, what the strategic priorities/market realities are.

Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests.

On promotions - I think it's the reverse problem. People only get promoted for working on something that's perceived to be hard.

View on HN

> Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests.

Note that you switch between "devs" and "customer" there. I argue that the real problem is that for VS those demographics are different. Devs in "Microsoft shops" don't go out and decide on a complier, they use VS because that's all there is. And the decision to purchase that compiler is made for them by the suited management class who frankly don't care about C++11 support beyond what they see in a line item checklist.

But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them.

Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave.

> ... they use VS because that's all there is

On Windows there are lots of compilers to choose from.

There are other words around those words. ajross is describing a corporate environment where the choice is sometimes made for you.

I understood Microsoft shops as Windows ISVs, if he meant companies 100% committed to Microsoft tooling then you are right and I made an hasty comment.

For every Windows ISV there are a hundred companies where the software development toolchain is chosen by someone with nothing more than a thin grasp of the concepts involved.

They read in magazines the new shiny IDE has better team support and integrates seamlessly with Exchange and the SharePoint intranet deployed last year.

But let's be realistic here. Most of those shops will never hire someone to write C++ code. In all likelihood, they are still porting VB3 apps to VB.net.

Or they get someone like us that moves code from C++ to Java and .NET, because C++ is legacy.

The last time I managed to do a full greenfield C++ project at work was around 2005.

The enterprise has moved away from it long time ago and incoherence talk of Microsoft about going native does not help.

If they are serious about that I would expect proper C++11 support and improve ngen to the point I could use it as a real native code compiler. Not dumb UI changes.

>But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them.

>Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave.

Is there any quantifiable metric to measure this so called exodus beyond anecdotes and the ".NET is dying" posts on here?

If there was an IDE for .NET on par with VS, it will definitely see uptake regardless of suits.

Well, just to address the first point there is undeniably an "exodus" from Visual Studio. Just look at all the code shipped to run in browsers, or iOS, or Android, or on node or rails. A decade and a half ago a far (far!) greater fraction of that was spend in a Microsoft IDE.

But that's really not the point. The upstream discussion was much narrower, and focused specifically on C/C++ support, which frankly sucks in the windows world compared to the renaissance we're seeing in Unix with our dueling multi-architecture full-support C++11 implementations.

I'm not nearly expert enough to comment on how good or innovative the .NET support in VS is, but I'm perfectly willing to believe it's great.

Just look at all the code shipped to run in browsers...

I use Visual Studio ship code to run in browsers every day.

And HN is hardly representative of the software industry at large.

Undeniably? Not quite.

Your reasoning is really faulty because you aren't accounting for overall growth in the industry. If the world Irish population increases by 20% does this mean that the Asian population shrunk? Of course not.

Consider that Tablet and Smartphone platforms are in addition to flat PC sales. http://www.guardian.co.uk/technology/2013/feb/01/tablets-cro...

http://www.wcu.edu/ceap/houghton/edelcompeduc/ch1/handhelds/...

Same goes for the world wide web in general. http://www.businessinsider.com/how-many-web-sites-are-are-th...

You can't say logically that because there are more rails sites there are less Microsoft ones.

C# is pretty popular here: http://langpop.corger.nl/

here as well:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

And that doesn't count non-C# .net ecosystem languages.

Could there be an exodus? Sure, but your reasoning is just wrong here.

Did you miss the bit where I said the "exodus" (I even used scare quotes!) wasn't the point?

I think so. Haha. Sarcasm detector is on the fritz.

Almost all video games are produced in Visual Studio, more or less. Even the one for Sony/Wii (plugins/extensions in Visual Studio, etc, although using different compilers).

That accounts for a lot of software out there.

And no, I don't like Visual Studio, but it's the best tool out there for the majority of the people I work with.

For what it's worth, I've been using SharpDevelop almost full-time at work. Then again, I'm more of a Linux guy working at a .Net shop because "Hey, why not. C# is nice enough"

Mozilla has been fighting the MSVC linker's 3GB virtual address space limit for years. Mozilla has asked Microsoft for a 64-bit linker that can produce 32-bit code, but Microsoft apparently has no plans for such a configuration.

https://groups.google.com/forum/?fromgroups#!topic/mozilla.d...

What I want to know is how someone can see that their software project has become unlinkable on a 32-bit OS and somehow think that this is purely a compiler problem.

Keep in mind that this is the group that thinks de-prioritizing 64-bit windows builds is a-okay while at the same time they need 64-bit windows machines running 32-bit linkers to build their 32-bit windows binaries. ...phew, what a mouthfull.

Mozilla has never struck me as the most... forward looking.

For one thing, I don't think their JIT produces code that properly follows the Windows x64 ABI yet. It really should be disabled in 64-bit builds until they do.

Their stated reason for de-prioritizing 64-bit builds wasn't technical; rather they say they don't have the manpower to do both. Perhaps the manpower issue is that they don't have enough people to work on the JIT issues on x64 and do everything else, but I do not believe they specified.

Following the ABI is only an issue at module boundaries. If you control every callsite of a function, you can invent whatever calling convention you want.

But you still need the function tables and follow prolog/epilog conventions with x64 for SEH to work.

btw, Google Chrome doesn't have a 64-bit version* for Windows. The Chrome team also disabled PGO on Windows because of the same MSVC linker limitations that Mozilla hit.

* Edit: oops, I corrected a typo where I wrote "32-bit build".

You mean a 32-bit build system?

Sorry, I had a typo in my post. I mean Chrome for Windows is a 32-bit application. There is no 64-bit Chrome for Windows.

Yes, though that is far less a pain in the ass since they use multiple processes. I can't count the number of times I have run out of memory with firefox on windows despite having far more than firefox was using.

I'm actually about to sit down and write a blog post about VS compiler memory issues, and I had a long talk with the Firefox guys a few weeks ago about this issue. It's not all their fault.

Awesome - where's it likely to get posted?

Visual C++ Team blog

And when?

It's not just Firefox; other large projects like Chromium also exceed this limit when using MSVC's profile-guided optimization (PGO) on 32-bit Windows. (Chrome's solution is to build without PGO; Firefox's is to limit PGO to only a portion of source directories.)

I am a bit confused. That thread seems to claim that Microsoft isn't producing a 64 bit linker, my install seems to disagree with them (vc\bin\amd64). Then you claim that the linker won't produce 32 bit code, but /machine:x86 seems to disagree with that. I tested this by building as 32 bit, then just repeating the link using the 64 bit linker and /machine:x86, worked fine.

So what are their problems exactly? That they are building with VS 2005 (from what I saw in that thread) and MS isn't backporting changes to the 2005 toolset?

The problem is cl.exe for x86 is only 32-bit, and the design of most build systems don't make it easy, especially as Mozilla was using PGO.

You mean it only produces 32 bit code? This disagrees (http://msdn.microsoft.com/en-US/library/x4d2c09s(v=vs.80).as...) going back to at least 2005.

The following list describes the various versions of cl.exe (the Visual C++ compiler):

...

x64 on x86 (x64 cross-compiler) Allows you to create output files for x64. This version of cl.exe runs as a 32-bit process, native on an x86 machine and under WOW64 on a 64-bit Widows operating system.

What they are currently doing is running a 32-bit linker to produce 32-bit output on 64-bit windows.

This 32-bit linker is apparently LARGE_ADDRESS_AWARE, so running it on 64-bit windows gets them 4GB to play with (which they are apparently rapidly burning through.) What they need is a 64-bit linker to run on 64-bit windows that can produce 32-bit output.

      OS  Linker  Output  Mem
  1   32  32      32      3GB
  2   32  32      64      3GB
  3   64  32      32      4GB
  4   64  64      32      8TB

They use to be doing 1, now they are doing 3. They need to do 4, but apparently cannot. My understanding of this may be wrong, or they may be wrong, I don't know.

You need to add cl.exe to the table.

I'm not sure where that fits in. Are they wanting to use a 64-bit cl.exe and a 64-bit linker to make 32-bit output? Does mixing and matching the cl.exe and the linker change how much memory the linker can use?

I am baaarely familiar with Microsoft-world development.

Yes, they can use a 32-bit cl.exe and 64-bit linker, but most build systems don't make it easy.

You can't use a 32-bit cl.exe and a 64-bit linker to produce 32-bit binaries if you're doing PGO (which is the whole point of this "using lots of memory" issue). In particular, the 64-bit linker can't produce 32-bit binaries when you're using link-time code generation, which PGO does.

I am talking about the cl.exe executable that output x86-32 code itself, not the code it produces. You can use a 32-bit cl.exe to cross compile 64-bit code, but not the other way round.

Ahh gotcha, I hadn't look at that angle. That is unfortunate.

The problem is link time code generation. With link time optimization[0], which is a prerequisite for profile guided optimization, cl just compiles the source into some intermediate representation. Actual code generation is all done in link.exe at the final link. And /machine:x86 doesn't work with link.exe when using -GL. The x64 link.exe is not capable of generating x86 binaries with LTO.

[0] http://msdn.microsoft.com/en-us/library/0zza0de8%28v=vs.100%...

(Mozilla is building with 2010 now.)

> (Mozilla is building with 2010 now.)

Also note that the problem still exists in VS2012, and in fact is even worse because the linker memory usage has gotten higher in general. Fortunately we now have a fairly good workaround (developed with help from Microsoft -- maybe some of the people in this thread?) that limits which files participate in PGO:

https://bugzilla.mozilla.org/show_bug.cgi?id=871712

Ahh, one variable I hadn't factored in. The mix-n-match option mish-mash of C++ is so fun :)

Disclosure: I'm a new guy at Microsoft, not in the VS team, just speaking from prior experience as a Win32 developer.

There are still internal limits in the PE32 format which mean parts of the output as a whole will be limited to 2 GiB or so, regardless of the address space available to the linker.

I too have hit internal linker limits from time-to-time, but the span of computing history in which it makes sense to have a 64-bit linker building a load module output with 32-bit internal limits to run on 64-bit processors doesn't seem like the place to be in the great scheme of things. Just my personal observation.

In Mozilla's case the _output_ is nowhere close to 2GiB.

What hits the 32-bit limit is the link-time code generation, which has to have the entire program's AST, plus all the profiling information, plus whatever other data structures it's using in memory all at once.

Same with Qt5 and /LTCG - visual studio can't compile (I've tried out the 64-bit compiler targeting 64-bit since there is a 32-bit compiler targeting 64-bit too).

After checking again with my logs, it was failing while building QtWebkit (ahem - other posts explain it too).

For my custom Qt5 build, I've disabled /LTCG only for QtWebkit (32/64bit debug/release) and was able to deal with this limitation (at some other cost I guess)

If you compile with /LARGEADDRESSAWARE and run the executable on win7 64 bits, your process has a maximum of 4 gigabytes of ram. I know, I tested it up to 3.6 g. Not bad at all!

> Often the problem with these queries is that there are not enough devs complaining to MSFT.

No. "Customer complaints" are not a substitute for product design sense.

Any survey of your customers is inherently biased: Your customers, by definition, are people who were willing to buy the product. You're rarely going to discover your biggest problems by counting the number of customers who report them, because your biggest problems are the ones that make people unwilling to become your customers in the first place.

Top voted on SQL Server Connect is a relatively simple issue (on the face of it) that's been outstanding for 8 years in two separate tickets, with no meaningful response from MS.

https://connect.microsoft.com/SQLServer/Feedback

I think devs don't complain because there's not much point.

Very true.

It took me 9 months and 45 calls to support to get a relatively simple regression in IE9/ClickOnce fixed and all we got was a fucking registry fix that we now have to ship to 2000 clients.

Basically they broke ClickOnce in IE9 for launching via scripts due to the new download prompting stuff.

Neither the framework team or IE team wanted to take responsibility leaving my poor support rep to reverse engineer both products.

Reply on news.ycombinator.com