The Great C Runtime Refactoring | Hacker News Reader

The Great C Runtime Refactoring

blogs.msdn.com

116 pointstwoodfin41 comments

All very well, but I'd be really happy once (if) we ever get proper C99 support in MSVC. We basically need that at the neovim project if we want our code to compile with MSVC. We don't want to compromise either, by for example compiling as C++ and not using some C99 features (we do use compound literals, we don't cast from void pointers, et cetera). The CRT improvements in MSVC 2013 and 2014 are a step, but only a small one. Sadly, compiling as C forces some kind of old mode where we can't even use declare-anywhere. For now, it seems like we'll need to let MingW and its offspring do it. Does anyone have a workaround?

Never going to happen. For Microsoft C's time is passé.

Herb Sutter already stated this multiple times.

He was very clear that C99 support was only was is required by the C++ standard and to allow specific well known open source projects, which he referred to, to be ported to Windows.

So it's "only" required by their primary language standard, as well as used in some very popular software...

If that's barely enough to move Sutter into action, I wonder what would be an actually compelling case to him. The heavens open and a booming voice commands him to implement features X, Y and Z?

> their primary language

I read somewhere that Microsoft settled on C89 for the Windows kernel etc. so as far as their primary language goes their compiler implements it just fine.

Kernel code is being made C++ compliant according to a BUILD session when the going native wave started.

As of Windows 8 is possible to use C++ for kernel code (vc++ got a new flag /kernel).

Visual Studio 2013 launch

http://events.visualstudio.com/eng/visual-studio-2013-launch...

At minute 18:51. Focus is C++, there are no plans for C conformance.

Sounds like the next (2015) version should implement a lot more C99 compatibility, if I'm reading between the lines correctly.

You don't have to read between the lines. The first CTP for the next version is out, and it does in fact implement a bit more C99 compatibility.

Chromium uses an LLVM-based tool to automatically convert ffmpeg's C99 source code into MSVC-compatible C89:

https://github.com/rbultje/c99-to-c89

http://git.chromium.org/gitweb/?p=chromium/third_party/ffmpe...

The fact that this exists alone is indicative is what a terrible platform Windows is.

Entitled Windows users have absolutely no right to complain when programming language communities treat them as second class citizens.

This tool has been unnecessary since VS2013. I posted some background info and links about it and MS' apparent attitude reversal back in Nov: https://news.ycombinator.com/item?id=6728226

The actual commit: http://git.libav.org/?p=libav.git;a=commit;h=16381923fb7b908...

VS 2013+ does support compound literals and mixed declarations and usage. The latter is oddly buggy, but it's a rare area where they're fairly responsive to bug reports.

If GCC (MinGW) is working for you then why do you, a FLOSS developer, want your code to be compiled using the proprietary MS compiler? I'm genuinely interested.

It's often better to integrate with the native tools of a given platform. For example, I wouldn't really ever contribute to a Mono project, even if it's on Linux, because .NET is weird Windows stuff. Same thing in reverse with MinGW and Windows.

And if you want your project to truly treat Windows as first class, you have to recruit people who know, love, and use Windows.

> if you want your project to truly treat Windows as first class, you have to recruit people who know, love, and use Windows.

HN rumor has it that these creatures are mythical ;)

Given the vast number of famous counterexamples, HN rumour (as usual) is pretty wrong.

Why is .NET "weird Windows stuff"? Apart from obviously Windows-specific libraries like WMI, WinForms, etc. Even Microsoft released an example of the CLI that'd compile for FreeBSD among other OSes. So the cross-platform part of the runtime and much of the basic libraries is truly built-in.

Or did I miss your point?

I was slightly exaggerating for effect.

Windows has a number of native compilers: MSVC, MinGW GCC, Clang, icc, Pelles C, Embarcadero C++Builder etc. Nothing makes MSVC special, except that it happens to be from the same vendor as the operating system. MinGW GCC is free software, has better standards support, better warning output and can compile more FOSS libraries. These are all pretty desirable features, especially if you're a FOSS developer.

I consider myself a Windows user and developer, but I have no love for MSVC. I'd much rather have everything I use compile under MinGW GCC.

You're the first person I've ever heard who considers MinGW GCC 'native.' Every time I've worked on an OSS project that uses MinGW, every Windows dev who comes along says "ugh, MSVC++ please."

We must run in different circles.

I think "native" meant "doesn't target a VM."

To give you a short and blunt example - if your API is C++ then you can't mix gcc/msvc dlls - simply because exported symbols won't be found, and much more other (hidden) problems.

According to the article, C99 support was one of the motivations for doing this.

"As part of this work, we've completely rewritten the core implementations of the printf and scanf functions (now with no #ifdefs!). This has enabled us to implement the remaining C99 features for the stdio library, to improve correctness checks in the library, and to fix many conformance bugs and quirks"

> Does anyone have a workaround?

I've been using clang-cl ( http://llvm.org/builds/ ) for my personal stuff.

Pros:

* creates binaries that link to the platform CRT (no need for any redistributable) as long as you keep within C99 or C11

Cons:

* not officially supported yet

* doesn't yet support enough C++ to be useful for anybody wanting that

* while the C99/C11 language is available, you still need to rely on the Windows header files and libraries, so you have variable length arrays, declare anywhere, compound initializers, _Generic, but not snprintf, fenv.h, etc.

clang-cl and MS C++ ABI compatibility for Clang/LLVM is going to be very exciting. Some said it was an impossible project but it is quickly progressing. The start of SEH is already committed. I believe the mangling is complete. Linkage types are still being tweaked. Windows Phone is already partially supported. The inalloca attribute has been in ToT for a long time. I think it will be in a usable state within a year.

Sometimes you just have to use a binary library that you cannot recompile. If it is C++, you are limited with your compiler choices due to ABIs.

I hope the various sanitizers are ported as well!

Is there any problem with MinGW ? From my very limited experience gcc is just a better compiler than MSVC: it generates faster code, has more options to configure it (more optimization options, more options for displaying warnings, all the new floating point stuff available, actually supports new standards and let you choose which language version you want etc.).

it generates faster code

Not sure if that is true in general - the few proper benchmarks I found indicate that there is no clear winner. (Except for the Intel compiler, which beats both)

Right. I am speaking from experience with relatively simple number crunching code. It became faster once I upgraded to newer version of gcc. Now even very simple things (like say 8 queens) are just 5-10% faster when compiling with GCC 4.8 comparing to MSVC.

No, I like both gcc and clang, and thus mingw. Still, we would like to be portable to as many modern, often-used compilers as we can.

Also anecdotally, I wrote a software renderer a few months ago that ran almost 50% faster when compiled with MSVC 2013 than with MingW 64 (gcc 4.8), all optimizations enabled. This might not be true for other types of programs though.

GCC certainly releases more often than Visual Studio, with the end result being that GCC has support for newer standards much sooner than Visual Studio. But if you intend to run your programs on Windows systems without GCC installed, you have to find the support DLL, and it's not always easy to find.

From the blog post: >We have eliminated most of the manual resource management in the code through the introduction of several special-purpose smart pointer and handle types. Enormous functions have been split into smaller, maintainable pieces. We have eliminated 75%(2) of the conditional compilation preprocessor directives (#ifdef, #else, etc.) by converting internal implementation details to use C++ features like templates and overloading.

FYI... The author of the blog post (James McNellis) also has an excellent video presentation that explains that paragraph in more detail.

http://channel9.msdn.com/events/TechDays/Techdays-2014-the-N...

I kind of joked here: https://news.ycombinator.com/item?id=7843301 - but now I can't really wait for it. This is huge! This means that once major products pick up and develop their creative tools (Maya, MotionBuilder, Photoshop, etc.) - plugin developers no longer have to ship for multitude of CRT versions.

Also finally things like Python, Perl, etc. can stick on one runtime and not care for a very long time.

Great stuff Microsoft! I really really can't wait for it. I don't care even if no new C++ features are implemented - only this is that important.

Nice to see them talking about C99, even after they said the focus is only C++... when for everybody else, the horizon is C11. Guess it's something along the lines of "let's handicap a bit all open-source projects that want to support Windows by forcing them to use an older language version that also has platform specific gotchas, maybe even rewrite the runtime to add more platform specific goodness"...

I was expecting them to figure out symbol versioning (eg how glibc deals with the similar problem). It isn't clear if they have done that, or instead are hoping to always have backwards/forwards compatible code and data structures.

"We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. "

+1 I love it.

Do I smell irony?

Yeah, eventually people will have to accept that C is dead on Windows (Visual Studio), unless Microsoft's management decides otherwise.

Of course they wouldn't have to do that if they had a functioning C compiler.

But snark aside, this is going to help GCC and CLang which will be able to target the stable runtimes. It doesn't matter than VCRuntime will continue to be versioned since each compiler will provide its own startup and EH (they already do). In fact, I wonder if this is a move to begin officially supporting alternate compilers. Is VCExpress going to be replaced with a LLVM-based package?

Will it be possible to create a shim msvcrt.dll that forwards to the new libraries? Then old programs can finally take advantage of bug fixes.

I doubt that GCC (MinGW) will be able to use this. What a pitty.

MinGW relies on the CRT that ships with every Windows since Win95 (and Visual Studio 6).

Microsoft could fix this situation by merging the CRT that ships with Windows (the original one) and Visual Studio (the forked of version madness) together. A simple Windows update for Windows NT 5.x+ would be great (of course it should be backward compatible).

"Before this refactoring, the sprintf functions, which write formatted data to a character buffer, were implemented by wrapping the result buffer in a temporary FILE object and then deferring to the equivalent fprintf function."

＊headdesk＊

That's actually common practice. Look at other libc implementations.

Even the original implementation did that:

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc...

Reply on news.ycombinator.com