Development

Why a "case <string> of" statement in Delphi is a dangerous idea

Over and over, people ask the case .. of statement to be expanded to allow strings, i.e.

case S of
  'String one': DoSomething;
  'String two': DoSomethingElse;
end;

Looks nice, doesn't it? Sure, but the devil is in the details. Strings are complex data types, and comparing strings is not a straightforward tasks. If you use just a single, simple encoding, and a simple language like English, a comparison may be as simple as comparing bytes. But there are different encodings, and there are many different languages.

Delphi development is now fully outsourced

Eventually, the real change Idera brough to Delphi are surfacing.

Embarcadero discontinues AppMethod - the risks of the subscription model

Embarcadero (recently acquired by Idera) announced AppMethod, its cross-platform only development tools, available only under a subscription model (Individuals $299 per year, per developer, per platform. Enterprise $999 per year, per developer) and launched less than two years ago, will be no longer be available, and "will be merged into RAD Studio 10".

Mom, a modal loop ate my service messages!

A colleague of mine was using the "modernized" service implementation I wrote about some time ago. His services needs to be notified when a user logs on/off or locks/unlocks the machine. Everything was fine for a while, until he started to complain it worked for a while, but then, "randomly", notifications weren't triggered any longer.

Mocking your customer is not a way to sell more... or it is?

Resident Embarcadero wizard of Oz, David Intersimone, has been so bold to write about Delphi "security". You know I already wrote about the utterly lack of security in Datasnap (but relying on web server security using https), but there are some true pearls in that article.

Embarcadero misses the Feb 1st, 2015 deadline for 64bit iOS apps

Despite what promised, Embarcadero wasn't able to meet the February 1st, 2015 deadline for 64 bit iOS apps. Not a surprise. Just another warning Embarcadero is trying to do too much with too little, and aligning someone else deadlines and releases with your own is difficult and usually not worth the effort.

Modernize you Delphi Windows application: use Windows 2000 (and later!) services.

No, the title of this blog post is not a mistake. Delphi, including XE7, only implements services using NT APIs obsoleted since Windows 2000. Windows NT was EOLed in 2004, 2000 in 2010, and XP last year, yet Delphi still doesn't take advantage of the new APIs. What are the advantages? Well, using the "extended" RegisterServiceCtrlHandlerEx() and its HandlerEx() callback, services can receive more and useful notifications (control codes). The new control codes allow to be notified of and handle:

Local elevation points in Windows and Delphi

Since the introduction of Windows Vista and the new security model for applications, application running under User Account Control (UAC) should adopt a "least privilege" model, running as an "unprivileged" user almost all the time, and requesting higher privileges only when needed, even if the user has those privileges.

Requesting higher privileges is called "elevation". A good application uses "local elevation points", meaning it elevates only when it really needs it, and then reverts to a non elevated stated afterwards. These operations are those identified by a little shield on the control (button, menu item, etc.) that activates them.

But how to perform this kind of elevation? There is not a simple way, say an ElevateProcess() or ElevatedThread() API. First, elevation can't be performed for a single thread. It needs to be performed at the process level, and there are good security reason behind this choice. Second, elevating a whole process would also elevate all threads within. Thereby, elevation require to "spawn" a new process. There are at least three different ways to perform this, in this post I'll explain what I believe is the most elegant and flexible one, albeit complex - the COM Elevation Moniker.

No, I do not want your damned applications in my <appdata> folders!

There is lately a trend, pionereed by applications like Skype and now commonly used by Chrome, that totally ignores Windows guidelines, rules and best practices, installing executables in folders like <appdata> instead of <program files>. The reason is simple: now Windows enforces proper security rights, and thereby unprivileged users are not able to write into folders designed to host executables.

Are you a Delphi developer, or a Windows developer?

This is not a rethorical question. And not because now Delphi targets OSX, iOS or Android, and it applies to those writing Delphi applications that runs on Windows only. There's a real difference, and it's important to understand it especially now the usual lame BorInCodeDero marketing is trying to use the end of Windows XP support to sell Delphi upgrades. But is Delphi today a real Windows development tool? My answer is no.

Pages

Subscribe to RSS - Development