Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

blogs.msdn.com

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#71

Post by malkia »

anon4 wrote: post #50
malkia wrote: post #13

71, 80, 90, 100, 110, 120 - Did I miss any of these? - 6 different "C" runtime versions (apart from side-by-side sub-versions) for compiler that was released in span of 10 years. It's not that I like the MSVCRT runtime. It's just that I have to target it. Any popular commercial product that has some form of plugin architecture (Autodesk for example) through DLLs would require more or less for one to compile it's own…

Can't you distribute plugins as an archive of compiled, but unlinked .obj files and link them on import to the runtime you use?

Even if that was possible, you need a linker. Also recent versions of MSVC plug-in a pragma that contains the version number of the MSVCRT dll and once a .c/.cpp file was compiled with specific version it has this version in the .obj file, so if you try to link it with another version it'll complain. Recently they've added this for debug/release builds (NDEBUG, _DEBUG) (so you can't mix them - but I think this was done only for C++ - because of STL)

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#72

Post by aninteger »

rwallace wrote: post #64
rossy wrote: post #10

The discussion in the comments is interesting. MinGW, the compiler for VLC, LibreOffice and most other FOSS projects on Windows does exactly what Raymond says not to do. In fact, the entire purpose of MinGW is to make GCC able to target msvcrt.dll. Developers and users love this, since they don't have to distribute and install the CRT with the program. Developers following the GPL aren't even allowed to distribute th…

MinGW relies on dynamic linking? I'm surprised at that because when I ran a test just now, Microsoft C++ compiles Hello World to an 84k executable whereas MinGW generates a 261k executable. I always assumed MinGW was doing the right thing and linking statically against (its own version of) the standard library; if not, where does the extra file size come from?

That's probably because you wrote C++ and are usimg C++ streams. Try just using printf. The binary, after stripping, will be much smaller (I think less than 20k). You can use DependencyWalker to check what DLLs you are linking to.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#73

Post by fhars »

evacchi wrote: post #52
ygra wrote: post #43

Earlier quoted context omitted.

The automatic tag closing behaviour is even specified now. But look at it another way: imagine browsers accepted only valid HTML and every browser had some bugs in what they consider valid. Writing a document in a way that it displays at all might be a challenge already then. Add to that that not everyone is on the latest browser version (that was probably more true in the 90s as well) and you get all the current pai…

I may be wrong here, but isn't implicit tag closing consequence of html deriving from sgml? mandatory tag closing is something that came with xml AFAIK

Yes, but then nobody implemented the SGML definition of HTML correctly. According to the standard, browsers should have parsed

    qux
as

    barbaz>qux
since it did not only include optional closing tags, but also short tags. (This is incidentally why several SGML-based HTML validators used to complain about "end tag for element A which is not open" in the presence of href attributes without quotes.)

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#74

Post by vertex-four »

antocv wrote: post #45
ido wrote: post #39

Earlier quoted context omitted.

You can still run honest-to-goodness PC DOS 1.0 .com files from 1981 designed to run on the original PC out of the box in 32 bit windows 8.

You can run a.out files from 1992 on Linux too, so what.

While the kernel developers never break compat, userland developers are much happier to, which leads to all sorts of issues. Even if your a.out file is statically linked, it might depend on a service that's since been replaced.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#75

Post by davidgerard »

csense wrote: post #30

Does Linux suffer from this problem? I think the answer is "no" because Linux distros generally recompile the world with each new major standard library version. If any C standard library gurus are reading this, feel free to chime in!

The Linux world largely ignores binary compatibility. If you want old binaries to work on Linux, the API this is most achievable with is ... win32. As provided by Wine.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#76

Post by tanzam75 »

anon4 wrote: post #51
ygra wrote: post #48

Earlier quoted context omitted.

Just imagine you're linking against the MSVC10 runtime and want to distribute your program to people who run Vista. How could the runtime even be part of the system? It didn't exist back then. So you have to bundle your dependencies anyway and you need to do that with everything else you use as well. The OS does nothing else: It ships with the dependencies it needs. If there was no program in a standard Windows insta…

So why do I need to distribute it? Why can't it be part of the standard install machinery "oh btw my program needs MSVCR10.DLL be a dear and fetch it from Windows Update"? Heck, this could be embedded in a manifest inside the .exe - "I need these MS libs with these versions" and when you double-click Explorer could parse that, check that those are installed and if not launch a "this program requires additional compon…

What's bizarre is that it's easier to create a .NET program that runs on every supported version of Windows without having to worry about installing the prerequisites.

Simply compile to .NET 3.0. You can do this even on Visual Studio 2013. The resulting program will run on Windows Vista and Windows 7 without any install. It will also run on Windows 8 and 8.1, which bundle .NET 4, because Windows will automatically install .NET 3.5 when your program attempts to run.

This scenario doesn't work for Visual C++ programs. Each new version of Visual C++ ships with a new runtime library, and it's neither bundled nor automatically installed by Windows.

In other words, .NET executables are more portable than Visual C++ executables! Talk about bizarre.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#77

Post by rwallace »

aninteger wrote: post #72
rwallace wrote: post #64

Earlier quoted context omitted.

MinGW relies on dynamic linking? I'm surprised at that because when I ran a test just now, Microsoft C++ compiles Hello World to an 84k executable whereas MinGW generates a 261k executable. I always assumed MinGW was doing the right thing and linking statically against (its own version of) the standard library; if not, where does the extra file size come from?

That's probably because you wrote C++ and are usimg C++ streams. Try just using printf. The binary, after stripping, will be much smaller (I think less than 20k). You can use DependencyWalker to check what DLLs you are linking to.

Ah, I was using C but I didn't realized needed to strip the binary, after doing that it comes down to 39k which is smaller than the Microsoft equivalent so you're right, it does seem to be using dynamic linking :(

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#78

Post by _wmd »

api wrote: post #19
gilgoomesh wrote: post #14

Why can't Windows officially include standard versions of this library? You know, like Windows already does with .NET versions since Vista or every other OS does with libstc++ or libc++? Forcing every C/C++ program to bundle their own MSVCRTXX.dll is pretty silly.

I must confess to statically linking my Windows binaries. It's better than making the user click through extra installers-within-installers to install the right MSVC redistributable. It also seems to paradoxically improve load times. Shrug.

There's little paradoxical about it.. if you link against 20 DLLs, that turns into 20 directory lookups and then random paging potentially across the entire drive, whereas a .EXE is more likely to appear contiguously on the drive, and after the first page of it is loaded in, the OS readahead mechanism might opportunistically snarf something like the next 256kb worth of pages for free as part of the same IO.

Ignoring IO, and depending on the size of the app (particularly C++ apps though), the linker might be spending a huge amount of time on symbol fixups.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#79

Post by pantalaimon »

vertex-four wrote: post #74
antocv wrote: post #45

Earlier quoted context omitted.

You can run a.out files from 1992 on Linux too, so what.

While the kernel developers never break compat, userland developers are much happier to, which leads to all sorts of issues. Even if your a.out file is statically linked, it might depend on a service that's since been replaced.

This is why when it comes to old (2000 era) Linux games, it's much easier to just run the Windows version in wine than to go through all the hoops to gather old libraries and get the sounds working.

Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel

#80

Post by userbinator »

bananas wrote: post #31
userbinator wrote: post #12

Earlier quoted context omitted.

> and your application's installer installs the redistributable DLL for that version I don't want an installer, nor to include the redistributable which is around 2 orders of magnitude larger than the application itself! I want a single tiny binary, just download and run on any system, and that's what using MSVCRT allows.

What's wrong with an installer? An unattended installer or even a click through one is no obstacle these days.

- I write my applications to run anywhere and not require any installation. There is a huge convenience factor in this. As a collorary, they also don't require uninstallation since they do not "embed" themselves into the system (registry, config files, additional files elsewhere, etc.)

- It makes for a bigger download, of code and data that would never be used again, with one extra step the user has to do before use, and also an extra step for me to build the installer too.

I can see the advantages of an installer for large applications that need to be "installed" since they modify various other things in the system, but that's not the type of applications I work with.

Post reply on HN