After first giving each a fair try, I decided to switch pretty much each and every one of the defaults from the finger apps to the real applications.
I remember using a Bayesian spam filter plugin for Outlook a long time ago. It actually worked really well.
I'm not using it right now simply because I'm too lazy to install it again. At some point I just accepted defeat and now I just skim through the dozens and dozens of emails I get every day looking for anything important. I don't even bother deleting the sea of junk anymore as it just takes too long, and HD space is cheap.
EDIT: Part is also because I'm a big procrastinator. I did join Procrastinators Anonymous, but no-one ever shows up for the meetings.
@swheaties: It's ironic that you talk about the pre-Windows 8/10 start menu wasting space, while the "modern" design language is all about wasting huge amounts of space for the sake of making it possible to operate with fat fingers.
I assume you mean there aren't enough good posts on the internet about the Win 10 start menu.
So I'll add another to the huge amount of bad posts: The Win 10 start menu sucks. Thanks for the fugliest OS evar Microsoft!
Agreed. This just looks and feels like a giant step backwards. A de-evolution. Looks/feels less professional.
As if the look and feel fits somewhere between Windows 3.1 and Windows 95.
It's hard for me to fathom that they spent an incalculable amount of resources to end up with something that is worse, that no-one asked for, all while no-one had any major complains about Windows 7 which would justify such a drastic change.
The root cause of this change is to make it fit in with MS's mobile strategy. A failed strategy (no, my Surface Pro 3 can't work as a tablet because the tablet apps are missing or simply suck to the point of being unusable).
Yea, let that sink in for a while... This change was done chasing after a failed mobile strategy. Due to Apple Envy. I love(d) MS, but they are no Apple, so they should stop trying to be like Apple and stop abandoning what used to work.
@cheong: That sounds interesting, haven't seen that done before.
I did make a tool a few years ago that runs as a post build step, that will take a .Net DLL, decompile, twiddle the corflags and recompiles to produce one x86 and one x64 output DLL. It also implements "DllExport" functionality so that you can add an attribute to any method that tells it to export the method as a native function (reverse P/Invoke).
Reverse P/Invoke functionality is built into .Net, however it isn't exposed all the way through (ie, the support is at the IL level, but you can't use it from C#). This allows you to create managed plugins for unmanaged hosts. For instance I use it to create VST plugins for audio hosts, and as far as the host is concerned, it is an unmanaged plugin.
And while on the topic of a new VS release...
Does anyone know if there have been any improvements to the VS package projects? I used the VS Package Builder plugin to create a VS package due to the difficulty in creating and maintaining menus, toolbars etc. However MS abandoned VS Package Builder circa VS 2010, so I'm still using VS 2010 to maintain my VS plugins. It would be really great to use a newer VS for creating VS plugins.
@BitFlipper: Setting your project to "Any CPU" is down right evil. That allows for undiagnosed bugs to slip into your projects. Consider what happens if you develop against "any cpu" and your project uses a 32 bit DLL (think Crystal reports for example). It works in testing. You deploy to a web server that happens to be a 64 bit server and suddenly your working project dies a horrible death.
Personally I vote whoever thought of "any CPU" should be taken out and shot (figuratively of course)
Any CPU does have its uses but I agree it can be evil. One of the main goals of .Net was being platform agnostic, so I can see the purpose of Any CPU there. I have various managed plugins that gets loaded by both 32-bit and 64-bit hosts (even unmanaged hosts in some cases) and there it helps so I don't need to manage multiple configurations. In addition, one of my projects can only run as 64-bit due to P/Invoking into 64-bit native DLLs, and even there it isn't a problem. If you are going to try and run it on a 32-bit OS, it wasn't going to work regardless.
However, since we are in this boat now, we might as well make the best of it... Using Any CPU during development doesn't mean you need to use if for the release builds. Your release builds can be set to x64.
Maybe this will allow one to do XAML design when the project configuration is x64. It always bugged me that I had to revert back the x32 in order to use the XAML designer. I mostly do my XAML design in the code window but it is nice to see the results in the design view.
If possible, set your projects to Any CPU. I have a 64-bit only solution, but setting all the projects to Any CPU allowed the designer to work without complaining, and my projects to run as 64-bit. Not sure if it would help in your case though.