Synopse

A variety of programming languages suffer from a denial-of-service (DoS) condition against storage functions of key/value pairs in hash data structures, the condition can be leveraged by exploiting predictable collisions in the underlying hashing algorithms.

The issue finds particular exposure in web server applications and/or frameworks. In particular, the lack of sufficient limits for the number of parameters in POST requests in conjunction with the predictable collision properties in the hashing functions of the underlying languages can render web applications vulnerable to the DoS condition. The attacker, using specially crafted HTTP requests, can lead to a 100% of CPU usage which can last up to several hours depending on the targeted application and server performance, the amplification effect is considerable and requires little bandwidth and time on the attacker side.

Source: #2011-003 multiple implementations denial-of-service via hash algorithm collision

Among all trolling subject in forums, you'll find out the great Garbage Collection theme.

Fashion languages rely on it. At the core of the .Net and Java framework, and all scripting languages (like JavaScript, Perl, Python or Ruby), you'll find a Garbage Collector. New developers, just released from schools, do learn about handling memory only in theory, and just can't understand how is memory allocated - we all have seen such rookies involved in Delphi code maintenance, leaking memory as much as they type. In fact, most of them did not understood how a computer works. I warned you this will be a trolling subject.

And, in Delphi, there is no such collector. We handle memory in several ways:

• Creating static variables - e.g. on the stack, inside a class or globally;
• Creating objects with class instances allocated on heap - in at least three ways: with a try..finally Free block, with a TComponent ownership model in the VCL, or by using an interface (which creates an hidden try..finally Free block);
• Creating reference-counted variables, i.e. string, array of, interface or variant kind of variables.

It is a bit complex, but it is also deadly powerful. You have several memory allocation models at hand, which can be very handy if you want to tune your performance and let program scale. Just like manual recycling at home will save the planet. Some programmers will tell you that it's a waste of cell brain, typing and time. Linux kernel gurus would not say so, I'm afraid.

Then came the big Apple company, which presented its new ARC model (introduced in Mac OS X 10.7 Lion) as a huge benefit for Objective-C in comparison with the Garbage Collection model. And let's face it: this ARC just sounds like the Delphi memory model.

I'm a long-time registered user of Total Commander.

This tool is my daily file manager. I never use Windows Explorer, since Total Commander is just faster, more easy to use (especially with the keyboard), has a lot of plug-ins. I even created my own plug-ins to access some custom file formats, and navigate into them just like with any folder. And it includes a lot of well written commands for FTP access or file comparison, which made other tools (like WinMerge) unnecessary.

There is a new beta version of Total Commander available, which targets Windows 64 bit. I just thought: 'Whoo, this is a real-world Delphi XE2 64 application'. I downloaded and tried it. Worked as expected, and integrates seamlessly with Windows Seven (for the shell extensions). Then I took a look at the executable... and discovered it was not compiled with Delphi XE2... but with FPC !

Delphi is sometimes assimilated to a RAD product - and this is a marketing label - but IMHO Delphi is much more than RAD.
With Delphi, you can make very serious and clean programming.

Including SOLID style of coding.

The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):

• Single responsibility principle: the notion that an object should have only a single responsibility;
• Open/closed principle: the notion that “software entities ... should be open for extension, but closed for modification”;
• Liskov substitution principle: the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
• Interface segregation principle: the notion that “many client specific interfaces are better than one general purpose interface.”;
• Dependency inversion principle: the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”. Dependency injection is one method of following this principle.

If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.

They certainly help to fight the three main code weaknesses:

• Rigidity – Hard to change something because every change affects too many other parts of the system;
• Fragility – When you make a change, unexpected parts of the system break;
• Immobility – Hard to reuse in another application because it cannot be disentangled from the current application.

Luigi Sandon wrote on Embarcadero's forum: 

And then you ask yourself: "why use a native compiler if its code may be even slower than jitted one?". Hope the new developers will also develop better and faster code - and not viceversa.

Embarcadero is just following the Wirth's law slower than others:

"Software is getting slower more rapidly than hardware becomes faster"

Speed is only a matter of compiler for mathematical computing intensive tasks.
Most of the time, in real apps (like business apps), the main speed issue is more the framework size (and the number of dll invoked), memory consumption, and general design (e.g. how caching and SQL are written).

Delphi, Java or .Net can do slow apps.
Delphi, Java or .Net can do fast apps.

You can do small and fast stand-alone apps with Delphi, running from Windows 2000 to Windows 8.
It is not possible with Java nor .Net.

This is the main difference IMHO with native code and JIT - about memory use, ease of distribution and no need of an external runtime framework.

From a StackOverflow question about a freezing Delphi application, I posted some experiment-based debugging tricks.

May help any developer in his/her fight against random bugs...

You know all that one of the most exciting features of Delphi XE2 is the MaxOSX Cross-Platform feature.
You've got the UI part, that is FireMonkey, but underneath, you did have some RTL modifications in order to let our Windows-centric solutions be OSX ready.

The first main step was to make our code speak with the "Objective-C" way of coding.

Objective-C is the primary language used for Apple's Cocoa API, and it was originally the main language on NeXT's NeXTSTEP OS. It's some object-oriented C variant, but something other than C++ or Java. In fact, Objective-C sounds more like a SmallTalk variance of C than another  C++/Java/C# flavor. For instance, the Objective-C model of object-oriented programming is based on message passing to object instances: this is just another way of doing it. It has some advantages, and disadvantages (I don't want to troll here) - but it is definitively nice. And the memory model is just something else, more close to our reference-counting way (as in Delphi interface implementation) than a garbage collector.

For our PDF generation Open-Source library, this is a small fix update.

It can now be compiled under Delphi XE2.
But it's still working from all previous IDE versions, starting with Delphi 5, and still 100% free - released under GPL/LGPL/MPL license, choice is yours.

Unfortunately, Delphi's 64-bit compiler (dcc64) and RTL do not support 80-bit extended floating point values on Win64, but silently alias Extended = Double on Win64.

There are situations, however, where this is clearly undesirable, e.g. if the additional precision gained from Extended is required.

The Open-source uTExtendedX87 unit provides a replacement FPU-backed 80-bit Extended floating point type (TExtendedX87) for Win64.

We already shipped a sophisticated set of logging classes some month ago.

Since then, its features have been enhanced, and the system has been deeply interfaced with our main ORM framework. Now almost all low-level or high-level operations can be logged on request.

But since the log files tend to be huge (for instance, if you set the logging for our unitary tests, the 6,000,000 unitary tests creates a 280 MB log file), a log viewer was definitively in need.