Windows is not a Microsoft Visual C/C++ Run-Time delivery channel • Hacker News Board

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

#81

Post by userbinator » Sat, Apr 12, 2014, 4:13 PM UTC

rwallace wrote: post #77

aninteger wrote: post #72

Earlier quoted context omitted.

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 :(

For comparison, VC6 defaults give 40K (statically linked), switching to dynlink shrinks it to 16K, add a few more switches and it drops to 1.5K.

Is it possible to do that with the latest versions (i.e. linking to their CRT instead of MSVCRT.DLL), or are they incapable of doing it for some odd reason? These are the options I used:

/MD /O1 /Os /link /align:4096 /filealign:512 /merge:.rdata=.text /merge:.data=.text /section:.text,EWR

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

#82

Post by aninteger » Sat, Apr 12, 2014, 4:35 PM UTC

rwallace wrote: post #77

aninteger wrote: post #72

Earlier quoted context omitted.

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 :(

Well, yes and no. Yes it does link to msvcrt.dll but it also brings in its own runtime too statically (mingwrt). Standard mingw links libgcc dynamically but you can use TDM gcc if you want to link it statically. I can't think of a bad reason not to use TDM gcc.

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

#83

Post by quotemstr » Sat, Apr 12, 2014, 6:55 PM UTC

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…

> 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 plugins with the exact version the main application was compiled.

Maybe Autodesk requires that ,but it's not true in general. Modules using different versions of the C runtime can coexist happily in the same process and talk to each other using plain function calls, COM, or whatever else you come up with. You can't share FILE*, malloc()ed memory, or other CRT-specific objects between them, but you don't have to: use LocalAlloc (on the process heap or an explicitly shared heap), the COM allocator, or something like that.

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

#84

Post by gizmo686 » Sat, Apr 12, 2014, 7:02 PM UTC

api wrote: post #18

mattgreenrocks wrote: post #3

A lot of 'real' ( cough ) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore. If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and…

This is part of what's driving the rise of feudal app store models. Users like them too-- at least most users who aren't concerned with (or don't understand) things like openness and freedom. They prune the ecosystem of shitware to at least some extent. Personally I think OSes need to evolve toward a model where apps are more strictly containerized, something like Docker (Linux) but for everything. The user should st…

I wonder if we will see app stores move more towards the package manager model we see in most Linux distros, where users can easily add third party repositories, remove first party repositories, and have dependencies handled automatically.

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

#85

Post by vetinari » Sat, Apr 12, 2014, 7:47 PM UTC

dredmorbius wrote: post #65

antocv wrote: post #45

Earlier quoted context omitted.

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

Without recompiling or hunting for old libs? I know there were a couple of pretty significant glibc upgrades, and IIRC the binary format changed at some point from something earlier to ELF. Hrm. "something earlier" seems to have been the a.out format, based on Eric Youngdale's 1995 Linux Journal article: The ELF Object File Format: Introduction http://www.linuxjournal.com/article/1059

Yes, without recompiling. That's the point, a.out is a binary format and if you recompile with current toolchain, you will get ELF.

You will need the original shared libraries and linker, though. They will run.

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

#86

Post by vetinari » Sat, Apr 12, 2014, 7:50 PM UTC

pantalaimon wrote: post #79

vertex-four wrote: post #74

Earlier quoted context omitted.

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.

Old Linux games use OSS, which you may get to run. They may also require obsolete Xfree extensions for direct framebuffer access, which the modern hardware will not allow though.

If you are extra unlucky, they may require direct console framebuffer access and unless you have also the old hardware with old drivers, you are going to get it on modern system.

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

#87

Post by vetinari » Sat, Apr 12, 2014, 7:51 PM UTC

doctorwho wrote: post #25

ryandrake wrote: post #5

Earlier quoted context omitted.

Yea, you can't simultaneously say "Developer, don't do this!" and then "Well, to maintain backwards compatibility with developers who did it, we're going to let you do it. BUT DON'T DO IT!" MS is in a tight spot. They have this maintanance mess because of their otherwise admirable dedication to backwards compatibility.

Microsoft's dedication to backward compatibility is why Windows ruled the desktop world for several decades. Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today? Microsoft always went above and beyond the call of duty to support hardware and software (with runtime code modificat…

AFAIK, Android has never broken it's public API.

If you hacked it and used internal APIs, you were warned - it is all over the documentation and mailing lists, that these are going to change.

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

#88

Post by vetinari » Sat, Apr 12, 2014, 8:17 PM UTC

jevinskie wrote: post #22

rwallace wrote: post #15

Microsoft C++ supports static linking with the standard library, which you should be using for release builds. That way, your program will always be using the exact version of the standard library that it was tested with, and it's guaranteed not to interfere with anything else on the target system.

What can you do for the situation where you ship a library instead of an executable? My team's product is moving to statically link libstdc++ and libgcc thanks to the runtime linking exception in GCC. It will allow us to use C++11 on old systems. We are grateful that libstdc++ is backwards compatible to GCC 3.4 (other libstdc++'s can link against us)! I'm looking into statically linking musl libc so our product could…

glibc itself is not supposed to be linked statically, because it itself dlopens other shared libraries - for pam, for nsswitch, etc. These are system specific (as configured by admin), so there is no one size fits all.

You may statically link another libc, but then the users may wonder why your app does not works as it should, when they configure nsswitch for example and your app will not respect that.

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

#89

Post by jodrellblank » Sat, Apr 12, 2014, 8:22 PM UTC

mattgreenrocks wrote: post #3

A lot of 'real' ( cough ) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore. If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and…

Whether it's inane programs inserting themselves into the systray

You mean the taskbar notification area? - http://blogs.msdn.com/b/oldnewthing/archive/2003/09/10/54831...

You could try arguing - Mr Chen appears to be active on StackOverflow http://stackoverflow.com/users/902497/raymond-chen

This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and inane they will be.

They can already do enough. My browser could be "my agent on the internet" but instead it's become "in control of the enemy, something I must neuter" to stop some website owner from ruining my computer's context menus, clipboard, playing unwanted sound, downloading and playing/displaying unwanted noise or adverts, taking me away from pages I was looking at, intercepting my mouse clicks and neutering them.

None of these things should ever have been at the control of the website.

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

#90

Post by CamperBob2 » Sat, Apr 12, 2014, 8:35 PM UTC

delhanty wrote: post #26

jevinskie wrote: post #21

Earlier quoted context omitted.

Yes, resorting to static linking is a pretty good solution for executables. Pitty about the bloat, but it works! How would static linking work with libraries? Would you get multiple heaps?

Sometimes you do get multiple heaps, but it can be made to work if one is careful not to allocate on one heap and then free on the other heap. One example is a C/C++ COM addin for Excel say - instead of freeing the Excel allocated memory directly the addin DLL invokes addRef/Release appropriately on the IUnknown interfaces to the various objects it gets handed by Excel. That can be automated a bit with ATL and CComPt…

Sometimes you do get multiple heaps, but it can be made to work if one is careful not to allocate on one heap and then free on the other heap

Agreed, and it's sad to think how much confusion and grief would have been saved if they'd just made this a mandatory policy from day 1.

Windows developers regularly jump through an entire maze of hoops -- and make their users do the same -- just so they can call free() on a pointer they got from some random DLL, or do other goofy things that they shouldn't be allowed to do.