Can't really speak about the SxS implementation, as I haven't dived into it - but having the
ability to have several versions of a component installed is A Good Thing(TM). Theoretically, components should stay backward binary compatible except when major-versions are relased - but that's not always done. And installing an older minor-version on top of a newer minor-version-but-same-major-version can cause trouble... but so can installing a newer component, if an application depended (willingly or not) on a bug in an older version!
Can't recall when I've been bitten by "DLL hell" except for a really old game that needed a really old msvcrt version, but I know there's a lot of crap software around. Never experienced SxS crapping out... but I can imagine it happens when people go messing with "cleaner" style applications or muck around in %SystemDir% without knowing what they're doing.
While I don't particularly enjoy MSI, you
can't just compare it to linux package managers and say that the linux way is better - MSI offers a lot more flexibility. I haven't seen a linux package manager that lets you configure subcomponents of a package... if you'er offered any of that flexibility, either it's ports/portage-style compile-from-source, or you have to choose between several differently named packages - one package per featureset, ugh. Too bad MSI is so slow.
You mention Paint.NET. Photoshop starts faster than Paint.NET.-oldfogie
Perhaps if what you're comparing to is Photoshop 2, but definitely not the newer versions
.NET is interpreted bytecode - but without the decade or so of refinement that Java has.-oldfogie
It's JIT'ed (and interpreted for the codepaths that don't make sense to JIT). .NET hasn't been around as long as java, sure, but it's not like .NET hasn't benefited from research done before it was invented. As for speed wrt. Java, you can be sure that supports of either language will be able to come up with syntehtic benchmarks beating the opponent - but in the real world, the Java apps I've used feel slow and clunky compared to the .NET apps I've used. The reason most probably being the GUI toolkits used rather than the core VM speed, though.
I can't name a single .NET application that is recognized by major publications that ordinary users might use beyond Paint.NET. That's because they don't exist - even Stack Overflow can't seem to come up with a list beyond Paint.NET and Visual Studio.-oldfogie
Probably because a lot of the end-user desktop apps in use are old codebases, and a lot of new development is done for the web platform. Rest assured that a
lot of business development is being done i .net
I didn't see ANY benefits to learning a whole new language to discover new ways to crash software. We simply don't need a new language.-oldfogie
While it might not be your impression, C# and the .NET platform definitely makes it faster to develop than C/C++, and definitely easier to avoid a lot of common crash opportunities. Especially people clinging on to C (and using the insecure libc functions) really shouldn't be doing any sort of networked code, please.
Oh, you're a C++ developer who wants to use the Ribbon interface? Yeah, you get to wait a few months to do that while .NET developers get extra loving from us.-oldfogie
Heh. The Ribbon was introduced to MFC first, and not added to .NET until 4.0... so come again
. Also, saying that C# isn't a "
REAL" language is bullshit - it's a pretty damn fine
language, even if the .NET
framework isn't perfect.
If Microsoft had their way, they would only offer VC++ internally.-oldfogie
And that's why they've spent an enormous amount of time doing a lot of VC++ specific features in VS2010? Riiiiight.
A literal two byte modification is the difference that keeps the VC++ runtimes from operating under Windows 95 and later.-oldfogie
It takes more than that - there's imports for "recent OS" APIs, there's the PE header image/subsystem version fields, there's the loader config data section which Win9x barfs on, and iirc a couple of things more. But hey, you get the CRT sourcecode with Visual Studio... my biggest beef is that the recent linkers won't let you set an image version of 4, everything else is fixable.
Also, Microsoft deploys .NET through Windows Update but refuses to deploy the VC++ runtimes the same way so VC++ developers have to bundle the runtimes with their application but .NET developers do not have to bundle .NET. Another slap in the face.-oldfogie
I thought VC++ runtime updates were distributed through wupd as long as you use the recommended (MSI merge module) way of installing it? There's no proper way it can be done if you simply bundle the .DLLs in your own installer - sucks, but that's the way it is.
Microsoft refuses to provide a C/C++ route on Windows Mobile 7.-oldfogie
Pretty much
every phone company has One True Way to program their devices, and it's usually with a managed language. I think Symbian is one of the few exceptions?
Here's the ironic kicker: The important parts of .NET, Java, et al are written in...C/C++ and assembler. In other words, even the authors of those languages admit that C/C++ is better.-oldfogie
Pretty minor parts, really - especially the assembly (*y, not *er). And yes, that
is partly because there are performance-critical code pieces where it
does make a difference - and partly because of the chicken-and-egg problem of doing a new language.
As much as I like C++, it's a super quirky language with a boatload of problems (language as well as standard libraries). C++0x came too late, and doesn't address all of the problems. There's definitely a need for a richer language than C++, and a more comprehensive standard library - C# and .NET class libraries are pretty decent (even if the .NET class libraries definitely aren't perfect). And it's a helluva lot easier using p/invoke than JNI when you need to dip into native code
