Jump to content

Official - Windows 10 Worst Crap Ever!


bookie32

Recommended Posts


https://www.onmsft.com/news/autumn-creators-update-was-a-mistranslation-says-microsoft

"...The UK site that showed the “Windows 10 Autumn Creators Update” was simply translated wrong for British English, says Microsoft. Ars Technica reports that it will be called the Fall Creators Update worldwide, even for users in the southern hemisphere where technically it will be Spring.

So that’s one confusion out of the way for the Windows 10 Fall Creators Update, but it still doesn’t make much sense to many other regions that Microsoft has a reach.

Should Microsoft use a different naming process for its major Windows 10 releases?...."

Perhaps just call it: The Rise and Fall of Win10

Link to comment
Share on other sites

Microsoft OS 1.0, 2.0, 3.0 would have been fine.

Keep "Windows" as a, well, graphic multi-windowing OS for business.  We should have been on Windows 9, SP2 or so by now.

-Noel

Edited by NoelC
Link to comment
Share on other sites

  • 2 weeks later...

Three out of three computers updated to 16251 Pre-release Win 10.  Took awhile but they all made it.  Had to learn how to get into Safe mode to fix some old crap application software for one old Dell laptop.  All computers are running OK.  Don't know what to think of this crap?  They did all take several hours to make the transition.  Malwarebytes found no malware.  Ghostery stopped a lot of tracking, etc.  All three computers are now in safe security mode, powered off.  :cool:

Link to comment
Share on other sites

8 hours ago, Dibya said:

May be deathofwindows update .

Followed by Resurrection Update! :D


BTW, update KB4032188 apparently implements a workaround for a crashing bug (64-bit pointer truncation) caused by 64-bit vorbis.acm used by some software. One example of MS fixing other people's crap.

Link to comment
Share on other sites

Well, to be fair an OS IS supposed to be defensive against application software causing problems.  It's nice to hear that there are engineers within Microsoft who actually still care about robustness.

-Noel

Link to comment
Share on other sites

5 hours ago, NoelC said:

Well, to be fair an OS IS supposed to be defensive against application software causing problems.  It's nice to hear that there are engineers within Microsoft who actually still care about robustness.

-Noel

Sure, like - say - sandboxing high risk attack surfaces, such as Windows Defender.

No, wait, they didn't :dubbio::

https://blog.trailofbits.com/2017/08/02/microsoft-didnt-sandbox-windows-defender-so-i-did/

jaclaz
 

Link to comment
Share on other sites

7 hours ago, NoelC said:

It's nice to hear that there are engineers within Microsoft who actually still care about robustness.

Agreed, though we can only go so far. It seems that author just compiled both versions of vorbis.acm, but only tested 32-bit version. People always talk about ability to utilize more memory and security when it comes to 64-bit, but it's also nice for correctness testing. Though pointers are just one issue (some devs loved to store pointers in int), there are some trickier problems where the program that worked correctly in 32-bit mode no longer does when compiled in 64-bit mode.

Sometimes application developers explicitly go against documentation. I remember reading a conversation somewhere at stackoverflow.com where the asker insisted why he shouldn't do a particular thing in DLL's DllMain function. The documentation says only very simple things can be done in DllMain, ideally it should be empty, but he wanted to do something heavy and potentially dangerous just because it happened to work when he tried it. There's one more ceveat, selecting DLL project in Visual Studio puts a tempting looking DllMain stub without any "Dragons ahead" warning. At least this is still the case in 2015 version.

Either way, the workaround for vorbis.acm was a probably a good move if that thing isn't maintained anymore.

Link to comment
Share on other sites

On a related note I've found - disappointingly - that it's all too common a practice to set compiler warning levels low.  That probably implies it's like that in proprietary software development as well.  "What you don't know can't hurt you", right?

Wrong. 

I'm SURE there would have been some message emitted about that pointer truncation error if only the programmer hadn't made a sweeping "I don't care about warnings" gesture.

Why wouldn't everyone want the warning level turned all the way up?  The compiler is already capable of telling people they're stuffing a 64 bit loaf of bread in a 32 bit bread box.

Sorry for the small rant.  I just contributed some work - most of which was accepted, happily - to an open-source project to tidy up hundreds of warnings about mixing up signed and unsigned values. 

I've mandated /Wall here at my company (which is one level more picky than /W4 in Visual Studio).  There a very few overly pedantic ones (like emitting a message for every function that's been successfully inlined) that we suppress, but for the most part, if liberties have been taken with the code, the programmer will know about it right away.

-Noel

Link to comment
Share on other sites

4 hours ago, NoelC said:

"What you don't know can't hurt you", right?

I saw a line of code once where the author wanted to allocated space for variable array of pointers, so he multiplied the variable holding amount of pointers by 4, then wrote in the comment that a pointer may not be necessarily 4 bytes in size. I found it intriguing that he took time to write that comment instead of just using sizeof keyword straight away in place of 4.

Edited by UCyborg
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...