Agree with BatBoy. Bad code is written by bad programmers.

In reply to a post by Sark:

As for your reliance on poorly written historic OS from Microsoft accepting grot

Well.. it's not just Microsoft that makes these trade offs. Try passing bad data to Linux system calls and see how far you get before your app crashes.

Whereupon you invalidate your own argument throughout the thread. You almost seem to be defending the indefensible.

You say "There are literally thousands of workarounds built into Windows to enable broken apps to continue to function ....". If an app crashes due to invalid submission to the OS, that is entirely and utterly the app-writer's problem.

My position is that the OS should provide a graceful end to the app by providing an error response. If Linux doesn't do that, that's a shame. But MS doesn't. According to you, it tries to accommodate the bad data. That is the wrong thing to do. The Linux approach is the more valid.

Heck even easier try passing bad data to C standard library functions; they do almost zero validation.

Quite.

I started on C with absolutely unadulterated K & R from Digital Research. Then used my C programming on MSDOS by converting all of my background libraries including a self-written B-Tree indexed database system to use MSDOS system calls instead of CP/M ones.

That's quite apart from my mainstream interest in business application systems for which my libraries were simply tools. Systems which worked, didn't crash whichever OS they ran on, and didn't crash when unforeseen data combinations or invalid user data was input.

Well it's what you make of it. C# is a much higher level language than C++. It'll do a lot more for you behind the scenes. It has its pros and cons.

That I agree. But both are highly inefficient languages, where the raison d'etre of C is efficiency. I still believe in code-efficiency. If you have to inherit something that is already more than a couple of levels deep, you should copy the original code and make changes to it reflecting the intermediate changes and your own requirements. Preferably cutting out anything that is redundant.

My position is that the OS should provide a graceful end to the app by providing an error response. If Linux doesn't do that, that's a shame. But MS doesn't. According to you, it tries to accommodate the bad data. That is the wrong thing to do. The Linux approach is the more valid.

My position is that validating every input to an API function to ensure compliance is not always possible (either at all or in a reasonable amount of time) and therefore an error response can't always be provided. Unless you count a crash box as a graceful error. This should not be a controversial point of view. It's how (almost) every important OS or low-level library works in the real world. (I add almost as some specialist systems can't tolerate any errors whatsoever. Medical equipment e.g.)

Linux, Windows, OSX all behave the same way for any random app. But Microsoft make a big effort to ensure important apps continue to work following a major upgrade. I strongly suspect Apple do the same. The technical merits/demerits of doing so are pretty much irrelevant. It's a business requirement for Microsoft; they simply can't sell their product if the apps don't work. So the technical people have to lump it and make it work.

(Linux distributions generally don't have to deal with users installing random binary apps as everything comes from their repos. They can fix any problem apps at source.)

That's quite apart from my mainstream interest in business application systems for which my libraries were simply tools. Systems which worked, didn't crash whichever OS they ran on, and didn't crash when unforeseen data combinations or invalid user data was input.

I'm sure your libraries never did crash but I wouldn't be so confident that they would deal with all invalid inputs. Still, higher level libraries don't necessarily have the same performance constraints as those at a lower level. If the validation is affordable - go for it. Your users will let you know if it turns out to be too expensive.

If you have to inherit something that is already more than a couple of levels deep, you should copy the original code and make changes to it reflecting the intermediate changes and your own requirements. Preferably cutting out anything that is redundant.

We could get into an extended discussion on object oriented design. But on this, yes I agree, if the hierarchy is getting to be more than 2 levels deep then there are likely better patterns worth considering. Depends on how much of the existing code base you have control over, I guess.

In reply to a post by Sark:

I'm sure your libraries never did crash but I wouldn't be so confident that they would deal with all invalid inputs.

There's a process called testing which you need exposure to.

So the RC stage is removed

beta -> RTM

instead of

beta -> RC - RTM

That is not good - seems like they want to get patches/updates out faster, and want to remove the extra testing to do so.

And we all know what that means...

They've introduced Agile development?

You mean they've introduced what bad programmers think agile development is?

Rather than what agile development really is.

This begins to sound like a complete cockup, running alongside the newer thread about an update breaking the computers.

I have updated 2 devices to Win 10 so far. One of them is a decent laptop that generally is working fine except that Edge keeps hanging. The other is a tablet that was working ok until I installed an update on Sunday and now the touchscreen is mis-reading taps and so it is now impossible to enter the password (I have had to buy a cable to convert micro usb to standard usb so I can plug in a keyboard/mouse to be able to log in and hopefully fix it).

So far Win 10 is looking significantly worse than Win 7 was when it was released.