News for hackers. Stuff that matters.
Re:Cross-compiling binaries for Windows is easier than build... by josephcsible on Saturday June 18, 2022 @08:41PM (#31795118)
> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6

Doesn't that tie you to a really old C runtime, and aren't security holes often found in the C runtime?

Re:Cross-compiling binaries for Windows is easier than build... by adzm on Saturday June 18, 2022 @10:06PM (#31795486)
It links dynamically to msvcrt.dll which is updated as part of the os. I believe it still gets updates as long as it doesn't break the ABI. Modern vc++ links with the universal CRT which is an independently updated msvcrt distribution.
Re:Cross-compiling binaries for Windows is easier than build... by ygra on Sunday June 19, 2022 @02:11AM (#31796595)
Re:Cross-compiling binaries for Windows is easier than build... by userbinator on Sunday June 19, 2022 @03:42AM (#31797140)
Of course he has to toe the company line. But the truth is far simpler.
Re:Cross-compiling binaries for Windows is easier than build... by samus on Sunday June 19, 2022 @05:29AM (#31797729)
Similar problem to Java applications directly accessing internal JDK packages, and then breaking once access was restricted.
Re:Cross-compiling binaries for Windows is easier than build... by dwattttt on Saturday June 18, 2022 @11:54PM (#31796018)
msvcrt.lib includes things other than direct imports to msvcrt.dll; bugs in that code are going to be linked into your binary at compile time.
Re:Cross-compiling binaries for Windows is easier than build... by jcelerier on Sunday June 19, 2022 @03:30AM (#31797072)
A quick Google check seems to yield only one CVE in msvcrt.dll in 2012, wouldn't call this "often" especially for a DLL which is likely among the top 5 most used in the world
Re:Cross-compiling binaries for Windows is easier than build... by ranger_danger on Saturday June 18, 2022 @11:24PM (#31795853)
Both static and dynamic linking to a newer runtime (as they are versioned) will break backwards compatibility. For newer OS features you need, you can always GetProcAddress() the needed functions at runtime instead. The real downside to staying on VC6 is all the compilers' ancient optimizations, or lack thereof.