One month after Diving Back into Delphi: Hey I still Really Like Delphi!

I spent most of 2016 not writing Delphi code.  Yeah, I fixed the odd bug here and there, but mostly I was focusing on C#, ASP.Net core, and lots of other stuff.   Starting January 2017, I've gotten back into Delphi in a big way, because I'm working at a new job.  So far I have to say, I like it.  Delphi, and the new job.

I was kind of dreading going back to Delphi after having escaped it for almost a year.  But I have to say there's a few things I really really like in Delphi that I miss when I'm working in the .net and visual studio world:

1.  I like that the language isn't as complex as C# and there isn't fifteen ways to do things.

2. I absolutely love CodeSite and haven't found anything as useful for C#, although Serilog+Seq, comes close, and is web based, which is a bit more modern than CodeSite.

3. I absolutely love Nexus Quality Suite and haven't found any other tool for profiling and watching apps run, and seeing what they're doing inside, as much as NQS.  Now there are a lot of tools for .Net but actually NQS is pretty awesome.

4. I actually just like how pascal syntax works, it's clean, it's just the right level of verbosity. Begin and End are better than Curly Brackets, dammit!  And Colon-Equals is objectively the right way to do assignment. And strings should be one based! Fight me!

Giving up again on Windows 7, and on Windows as my main operating system for work machines

I recently switched back to Windows 7, for work purposes, for a couple of weeks. Here's what I've learned, and why I'm switching back to Windows 10, but only inside a VM:

1. Suspend and resume, and sleep/wake functions in Windows 7 are horrible, even on decent hardware.  Windows 10 is vastly superior, faster and more stable.

2. Windows update on windows 7 is horrible and broken, and even the ability to supposedly "pause" these updates, is actually only a partial pause. There are still times when TrustedInstaller.exe is going to chew up all your I/O bandwidth and pwn your machine. 

There really is no stable way to run modern 32 bit or 64 bit Windows applications on your computer, and maintain control of your computer, unless you fight Windows by boxing it in a VM.

I'm switching back to "Windows 10 in a VM", on a very fast Solid State Drive with a huge amount of RAM. I can pause Windows 10 updates by one simple trick. Shut windows 10 off, and only use Windows for what I actually need it for, which is when I'm getting paid to write and repair Delphi code.

If anyone has read any formal write-up on what sorts of invisible installs Microsoft slides out to users, even in Windows 7, and what they do, and why, I'd like to know about it.

Other surprising things in Windows include:

* The ready boost features, which like most attempts at smart caching, show that caching and cache invalidation are truly hard problems, NP hard, nearly impossible problems.  You can speed some users up, deploy your solution, and actually end up decreasing their net system performance for THEIR workloads.  ReadyBoost in Vista was a complete disaster.   It has been scaled back and restricted in its application and it rarely hurts you on Windows 7, and on Windows 10, it has been coralled and controlled enough that it rarely has a downside.

* The windows search indexing feature, and the windows defender anti-virus active mode, can radically cripple your system performance by adding I/O latency, stealing I/O bandwidth and CPU resources, and of course, all of it steals RAM.

When I have performance problems on Windows, I am used to switching to the I/O monitoring features of the Windows Resource Manager.  Most often, my computer, when slow is I/O bound, it is seldom ram/swap bound, and most often its programs that are doing things I literally do not care about, taking away the resources that should be doing work I care about.

I do not see a solution here, since Microsoft does not permit you low level control of your own system. At one time, in the Windows 2000, NT, XP era, Microsoft permitted you to turn off ANY service in Windows, and the list of services that ran in the background was quite manageable. The list of processes on a freshly booted Windows system is so large, and so much stuff runs now, that you just better realize that about 8 GB of RAM, and about 4 MB/s of your total I/O bandwidth, and at least one full core of CPU, is off the table, that's reserved for Microsoft, and whatever it decides to use your computer for.   If sometimes it finishes and you can actually use your WHOLE computer for a few minutes, you should really be thanking Microsoft and not so annoyed that, on the whole, Microsoft thinks your computer should be doing something other than compiling your code or serving up a database to your users, that 75% of your computer is yours,  most of the time, and that 25% of it is Microsoft's most of the time.

Windows 10 then introduces this "active hours" configuration, which just might be the critical factor in deciding whether to use Windows 10 or Windows 7 for serious professional development work. Microsoft has at least decided that, for now, during the hours of 8 AM to 7 PM, I am permitted a modicum of control over what happens on my computer.  Thanks, Satya.

Delphi 10.1 Berlin Pro Tip: Renaming CommunityToolbar bpl and good riddance to it.

In Delphi 10.1, without all the latest updates, if you get Delphi startup crashes, you can get around them in some cases, by removing optional parts of Delphi that are taking delphi down.   One such piece I usually rename so that it can't get re-enabled again, is the community toolbar IDE plugin bpl,

I go into the Program Files (x86), folder, then Embarcadero\Studio\18.0\bin, then rename CommunityToolbar240.bpl, by putting a tilde (~) on the front of the name.

Not only does Delphi 10.1 berlin RTM  actually start up without access violations and crashes, an unsightly and useless toolbar is gone from the IDE. I consider that win-win.

I believe the above issue must have been  fixed in Update 1 or Update 2.  But given with how much of a pain installing so called updates that are really not updates but full reinstalls is you can't really blame me, can you? I work in a variety of VMs and  it's not a one time reinstall for me, but a series of VMs with a series of Delphi versions in each.    I have had crashes in the community toolbar ever since whatever version it was first introduced in, and it remains one of the ugliest and most pointless IDE plugins ever.

There are other IDE plugin bits which are optional in Delphi, and if you're having a startup crash, one of the other things i sometimes have tried disabling is the debugger plugins for the C++ builder (if you have the full "RAD Studio" SKU, you have both), and a few other things which have historically been bad.

If you're running out of memory or you find the IDE is slow, it's also helpful to remove bits that might be causing that, and see if the problem goes away, even if only as a technique to find and isolate, and kindly report your findings in the Quality Portal.

If renaming the dll/bpl doesn't make things better, you can always change your environment back to its original state, by putting it back to its original name.

I also find that if my registry settings are to blame, renaming the current-user embarcadero BDS registry hive to "BDS_old" and then starting with a fresh settings, and see if the crash/problem goes away is also a helpful step in bisecting and understanding bad Delphi IDE states.  Clearly the rename is going to nuke all your local configuration settings and get you back to install-time defaults.  If your environment is self contained and easily set up again by just running some package-install and library-path setup tool, this technique can be doubly useful.