Incompetence at Microsoft

Whoever does user interface design at Microsoft is an incompetent ignorant imbecile.

When an application freezes and you attempt to close the frozen application a dialog box is displayed that asks if the user wants to close the application or wait for it to start responding again. Then after the user confirms that they wish to close the application another dialog box is displayed saying it is sending information to Microsoft and asking the user to wait. The send information to Microsoft dialog box always freezes.

So, let us review what is happening here.

  1. The user is experiencing an application freeze.
  2. The user just forced the frozen application to close so they can restart it and continue with their work. It is very likely they have lost work as a result.
  3. Microsoft adds insult to injury by deliberately causing another application freeze just so that they can be notified about the previous application freeze.

Are you fucking insane? You not do that you fucking assholes!

Advertisement

Worst job

What is the worst job imaginable? What characteristics make a job worse than any others? Are boring meaningless jobs worse than jobs that result in you being covered in filth all the time? If a dirty job provides an essential service does that make it better than a boring meaningless job that does not require you to cope with physical discomfort?

Is there any job in existence that is worse than Redundant Peon at the Redundant Department of Redundancy?

Inquiring minds want to know.

Regnad

There is a fork in the path ahead of you. There are also two signs, telling you where each fork goes. The sign for the right fork reads “Regnad.” The sign for the left fork reads “Shortcut to Regnad.” What should you do? Inquiring minds want to know.

Being a high ranking general must be difficult.

Being a high ranking general must be difficult. One problem you may run into is that you must choose your words very carefully. Otherwise the following might happen…

General: Hands assistant cold food that needs to be reheated. “Nuke this for me.”
Assistant: “What yield of atomic bomb should I use, sir?”
General: “What are you talking about?”
Assistant: “You asked me to nuke this. I need to know what yield of atomic bomb to use.”
General: “You asshole. Nuke is slang for microwave. I want you to heat that up in the microwave for me.”
Assistant: “Sorry sir. What settings should I use?”
General: “Microwave it on high for 1 minute.”
Soldier: Very well sir!

Being a high ranking general must be difficult.

Being a high ranking general must be difficult. One problem you may run into is that you must choose your words very carefully. Otherwise the following might happen…

General: “Nuke it from orbit. It’s the only way to be sure”. Stops paying attention and as a result does not hear the soldier reply.
Soldier: “Very well sir!”

Some time goes by. There is an atomic bomb detonation at the target that was being discussed earlier.

General, shouting at Soldier: “You asshole. It was just a famous quote from a famous movie. It was not an order.”

Hopefully there are many safeguards in place to keep this from happening in all militaries that actually have access to atomic bombs. If not, may god have mercy on us all.

On Idiot Proofing and Future Proofing

You can attempt to idiot proof something by guarding against mistakes typically made by the idiots of today.

You can attempt to future proof something by guarding against foreseeable mistakes that might be made by reasonable people at some point in the future.

However, you cannot future idiot proof anything. Idiots keep getting more idiotic. There is no way to predict what mistakes the idiots of tomorrow might make.

I curse you.

This is my message to the following people.

  • Anyone who is anti-LGBTQ+.
  • Anyone who is anti-immigrant.
  • Anyone who is anti-abortion.
  • So many others.

I curse you. I cast upon you the greatest curse I have the power to cast.

May you live a long and pointless life. And many years from now when you are laying on your death bed, may you find yourself alone instead of being surrounded by friends, family, and loved ones because you have driven them all away through your evil, hateful acts. And may you, on the day you die, finally realize and accept just how evil you are. And may your last thought in this life be as follows. “What awaits me? Will it be a reward? Will it be rest, peace, and forgiveness? Or will it be a well deserved punishment?”

The Carbon Programming Language is not a legitimate successor to the C++ Programming Language.

The Carbon Programming Language was recently announced as an experimental successor to C++. In my opinion the Carbon Programming Language is not a legitimate successor to the C++ Programming Language.

If you create a new programming language that is meant to be a successor of an existing programming language, do not break every single rule of the original language.

In C, C++, C#, and many simular languages data types are on the left and variable names are on the right. Anyone who has any experience in these programming languages expects any programming language that claims to be a successor to follow this most basic of syntax rules. This rule is such a basic rule of the language you should not even consider breaking it for a so called successor language.

The Carbon Programming Language breaks that rule.

Maybe people who have not ever used C and C++ will be willing to learn the Carbon Programming Language, but people with 20+ years of experience will hesitate because the code is too different.

This should be obvious.

Putting the variable name on the left and the data type on the right may make parsing easier, but millions of people who have experience in C or C++ or C# expect the data type to be on the left. Google, by going against these expectations is greatly limiting the adoption of the Carbon Programming Language.

Why does Visual Studio always do this?

Why does Visual Studio always do the wrong thing when creating a new solution or project file in an existing directory.

Consider the following scenario.

  1. There is source code but no project file in the directory c:\Path\To\ProjectName.
  2. You create a new project file named ProjectName in the directory c:\Path\To\ProjectName. You expect the project file to be directory c:\Path\To\ProjectName\ProjectName.vcxproj because that makes sense.

    Note that ProjectName is already repeated twice in that path.
  3. What Visual Studio actually does is create a directory named ProjectName in the directory c:\Path\To\ProjectName and then places the file ProjectName.vcxproj in that directory so that the full path to the project file becomes c:\Path\To\ProjectName\ProjectName\ProjectName.vcxproj.

    Now you have a path where ProjectName is repeated three times.

Every time this happens I have close the solution file, to go to the directory in Windows Explorer, move the project file up a level, delete the extra ProjectName directory, manually edit the solution file in a text editor, then reopen the solution file in Visual Studio. Please, just put the project file in the specified directory.

Friendly Reminder: If you release a NuGet package please sign all the DLLs.

Please. I am begging you. If you release NuGet packages sign both the Debug and the Release DLLs. Do not just sign the Release DLLs.

I wasted four hours today debugging the following exception: “FileLoadException: A strongly-named assembly is required. (0x80131044)”.

I was debugging the debug build of an application that uses the Titanium.Web.Proxy version 3.1.1397, obtained using NuGet. The Titanium.Web.Proxy uses BouncyCastle.NetCore version 1.8.10.

I have a python script that copies the build output from the output directory to the appropriate location on my test PC where I have the product I am working on installed. This python script replaces the files already present in the application installation directory with the files produced by building the product on my development PC.

The build process, which uses MSBuild, copies the DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy to the output directory. This is useful for release builds because the installer project pulls all DLL and EXE files from the build output directory. My python script previously copied the BouncyCastle.NetCore and Titanium.Web.Proxy files to my test PC in addition to all the DLL and EXE files for the application.

The problem is that the Debug DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy are not signed. When a .NET assembly depends on another assembly and the dependent assembly is not signed .NET will throw a “FileLoadException: A strongly-named assembly is required. (0x80131044)” exception when the first assembly attempts to load the dependent assembly.

It took me four hours to find out why this exception was occurring.