Posted by jpluimers on 2012/06/19
The delphi – Custom Messages in Non-Windowed Classes – need a default handler? – Stack Overflow thread on SO is very interesting.
It explains how to use AllocateHWND to route messages for a TThread into a message handler of an object instance.
–jeroen
Posted in Delphi, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2012/06/06
There was a nice short discussion on Entropy Overload where Ivan Levanshew seemed to want to be Delphi way more C++ and Barry Kelly explains why Delphi isn’t C++.
Both Delphi and C++ are great languages, but both have weaknesses too. It is good that their individual strengths complement each other, and their weaknesses don’t crossover too much.
Ivan Levashew said…
It’s XE2 now, and there is still no proper RAII despite Delphi runtime already having all the required functionality for years. Variants copying and destruction is an example.
It’s a pity. Read the rest of this entry »
Posted in C++, Delphi, Delphi XE2, Development, Software Development | 1 Comment »
Posted by jpluimers on 2012/06/05
A long while ago I read about Embarcadero Discussion Forums: Barry Kelly on LLVM … I think it was 2010, the thread is gone now (probably because the Embarcadero forum index does not go back more than one year), but the title still shows up at Google search: Barry+Kelly+on+LLVM
Barry Kelly is one of the Delphi compiler engineers, so it got me thinking and made me archive some links (I wish I had archived the content as well as the Wayback Machine didn’t archive some defunct links.)
Today Paweł Głowacki presents the Mac and Mobile Development for Windows Developers event and indicated future Delphi compiler platform targets like ARM will indeed make use of the The LLVM Compiler Infrastructure Project..
(if you still want to come: you are welcome, there are a few spots left; The event is June 5, 2012 at 9:30 AM – 1:30 PM
at the High Tech Campus Eindhoven Conference Center, The Strip).
Delphi leveraging LLVM for ARM is important in more than a few ways: Read the rest of this entry »
Posted in Delphi, Development, FireMonkey, OS X FMX, Software Development | 10 Comments »
Posted by jpluimers on 2012/05/30
Delphi seemingly makes the distinction between reference and value types disappear, especially because it hides the ^derefererncing operator for most usages:
Rudy Velthuis wrote a great article on pointers in general. Though it was in the Delphi 2009 timeframe, almost everything is very valid. A few things are missing, some additions are below.
I’m not going into deep detail here right now, just a few notes to get people interested going.
Hopefully I will some time in the future to either go into more detail, or point to articles that do.
Even with those additions to Rudy’s list, I’m not 100% sure everything is complete now (:
–jeroen
via: delphi – Why does TValue.Make require a pointer to an object reference? – Stack Overflow.
Posted in Delphi, Development, Software Development | 4 Comments »
Posted by jpluimers on 2012/05/29
Just a few notes on things I told Delphi cross development students over the last nine months or so.
For Mac OS X apps:
For iOS apps:
Steps:
–jeroen
via: Developer Tools Overview – Apple Developer.
Posted in Delphi, Delphi XE2, Development, Software Development, xCode/Mac/iPad/iPhone/iOS/cocoa | 1 Comment »
Posted by jpluimers on 2012/04/26
Some very interesting tips from game development that apply juts as well to general software development.
On code health:
Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available. I want my code to be healthy. If you go to the doctor and tell him “it hurts when I do this,” then you expect him to find out why it hurts, and to fix that.
Though tools like SourceMonitor can help you track your code health, the best tool is between your ears.
–jeroen
via: Dodgy Coder: Coding tricks of game developers.
Posted in .NET, Batch-Files, C#, C# 2.0, C# 3.0, C# 4.0, C# 5.0, Delphi, Delphi x64, Delphi XE2, Development, JavaScript/ECMAScript, PHP, PowerShell, Scripting, Software Development | 1 Comment »
Posted by jpluimers on 2012/04/10
Lot’s of corporate environments keep killing the productivity of their software developers by running WorkPace. They claim to prevent RSI, but the main thing they do is getting you out of your mental flow.
Workpace (yes, it is written in Delphi) hooks itself into processes by injecting REC300.DLL into it.
That particular DLL prevents Delphi XE2 from installing in several of the systems colleagues tried, and gives you error messages like these:
'' is not a valid integer value
Followed by a bunch of access violations, and Process Monitor indicating issues reading the key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\REC300.DLL which is part of WorkPace 3.0 (an old 2007 version).
The next problem was Digital Guardian (an old 2010 version) hooking itself into all processes. Uninstalling that is a pain, as it requires a special uninstall key, but luckily the automated update script on the SCCM server’s distribution share contained that in an encrypted form. Uninstalling this solved the problem.
Maybe newer versions of WorkPace and Digital Guardian wouldn’t have interfered with the Delphi XE2 install. If so, that would be another example of technical debt.
WorkPace and Digitual Guardian are most likely there because of government induced regulations in the corporate environment.
I’m feeling a bit like Dilbert now: the corporate environment is interesting, but often they make “getting work done” so much harder than it could be.
–jeroen
Posted in Delphi, Delphi XE2, Development, Opinions, Software Development, Technical Debt | Leave a Comment »
Posted by jpluimers on 2012/04/05
O'Reilly book "Unicode Explained: Internationalize Documents, Programs, and Web Sites"
Withe the growing integration between systems, and the mismatch between those that support Unicode and that do not, I find that a lot of organisations lack basic Unicode knowledge.
So lets put down a few things, that helps as a primer and gets some confusion out of the way.
Please read the article on Unicode by Joel on Software, and the book Unicode Explained. The book is from 1996, and still very valid.
Unicode started in the late 80s of last century as a 16-bit character model.
Somehow lots of people still thing Unicode is a 16-bit double-byte character set. It is not. It uses a variable width encoding for storage.
All encodings except the 32-bit ones are variable width. The UTF-16 encoding is a variable width encoding where each code point (not character!, see below why) takes one or more 16-bit words.
This is because – as of Unicode version 2.0 in 1996 – a surrogate character mechanism was introduced to be able to have more than 64k code points.
The architecture of Unicode is completely different than traditional single-byte character sets or double-byte character sets.
In Unicode, there is a distinction between code points (the mapping of the character to an actual IDs), storage/encoding (in Windows now uses UTF-16LE which includes the past used UCS-2) and leaves visual representation (glyphs/renderings) to fonts.
Unicode has over a million code points, logically divided into 17 planes, of which the Basic Multi-lingual Plane has code points that can be encoded into one 16-bit word.
There is no font that can display all Unicode code points. By original aim, the first 256 Unicode code points are identical to the ISO 8859-1 character set (which is Windows-29591, not Windows-1252!) for which most fonts can display most characters.
By now, you probably grasp that Unicode is not an easy thing to get right. And that can be hard, hence people love and hate Unicode at the same time. Maybe I should get the T-Shirt :).
One thing that complexes things, is that Unicode allows for both composite characters and ready made composites. This is one form where different sequences can be equivalent, so there can be Unicode equivalence for which you need some knowledge on Unicode Normalization (be sure to read this StackOverflow question and this article by Michael Kaplan on Unicode Normalization).
There are many Unicode encodings, of which UTF-8 and UTF-16 are the most widely used (and are variable length). UTF-32 is fixed length. All 16-bit and 32-bit encodings can have big-endian and little-endian storage and can use a Byte Order Mark (BOM) to indicate their endinaness. Not all software uses BOMs, and there are BOMs for UTF-8 and other encodings as well (for UTF-8 it is not recommended to include a BOM).
When only parts your development environment supports Unicode strings, you need to be aware of which do and which don’t. For any interface boundary between those, you need to be aware of potential data loss, and need to decide how to cope with that.
For instance, does your database use Unicode or not for character storage? (For Microsoft SQL Server: do you use CHAR/VARCHAR or NCHAR/NVARCHAR; you should aim for NVARCHAR, yes you really should, do not use text, ntext and image). What do you do while transferring Unicode and non-Unicode text to it? Ask the same questions for Web Services, configuration files, binary storage, message queueing and various other interfaces to the outside world.
The Windows API is almost exclusively Unicode (see this StackOverflow question for more details)
Let’s focus a bit on Delphi now, as that the migration towards Unicode at clients raised a few questions over the last couple of months.
One of the key questions is why there are no conversion tools that help you migrate your existing source code to fully embrace Unicode.
The short answer is: because you can’t automate the detection of intent in your codebase.
The longer answer starts with that there are tools that detect parts of your Delphi source that potentially has problems: the compiler hints, warnings and errors that brings your attention to spots that are fishy, are likely to fail, or are plain wrong.
Delphi uses the standard Windows storage format for Unicode text: UTF-16LE.
Next to that, Delphi supports conversion to and from UTF-8 en UTF-32 (in their various forms endianness).
External storage of text is best done as UTF-8 because it doesn’t have endianness, and because of easier exchange of text in ISO-8859-1.
Marco Cantu wrote a very nice whitepaper about Delphi and Unicode, and I did a Delphi Unicode talk at CodeRage 4 and posted a lot of Delphi Unicode links at StackOverflow.
A few extra notes on Delphi and Unicode:
With Delphi string types, stick to the UnicodeString (default string as of Delphi 2009) and AnsiString (default string until Delphi 2007) as their memory management is done by Delphi. WideString management is done by COM, so only use that when you really need to. Also avoid ShortString.
For any interfaces to the external world, you need to decide which ones to keep to generic string, Char, PChar and which ones to fix to AnsiChar/PAnsiChar/AnsiString(+ accompanying codepage) or fix at UnicodeChar/PUnicodeChar/UnicodeString.
Of course remnants from the past will catch up with you: if you have Technical Debt on the past where characters were bytes, and you abused Char/PChar/array-of-char/etc you need to fix that, and use the Byte/PByte/TByteArray/PByteArray. It can be costly to pay the accrued debt on that.
–jeroen
PS:
Posted in .NET, C#, Delphi, Development, EBCDIC, Encoding, ISO-8859, Software Development, Technical Debt, Unicode, UTF-8 | 2 Comments »
Posted by jpluimers on 2012/04/04
Thanks to Randy Glasbergen for the debt image
I love this quote from Jeff Attwood on technical debt in 2009:
periodically pay down your technical debt
and the Computer Weekely article about half a year ago:
Short-term speed may come at the price of long-term delays and cost.
Lately, I find that I need to explain Debt in relation to IT and Software Development more and more often.
We now all know what happens with the financial system when we let debt get out of control.
The same holds for your IT and Software Development.
Debts get introduced by not “playing by the rules”. The quotes are there because you can not always play nicely, and the rules are not always clear or known.
Lets give a few examples of rules that – from experience at clients – are more often than not neglected. The examples are based on Windows, but could just as easily be Mac OS X, Unix, OS/400 or anything else.
These few were examples ranged from technically very broad to specific. There are more, but these will give you a rough idea how wide the field of debt can be. Even debt outside the realm of Technical Debt can turn out to be really expensive.
Every time you postpone or skip a Windows version, you collect some debt in the hope (often wrongfully called expectation) that you earn more on the money/resource you just didn’t invest and putting that money/resource to use otherwise. The same holds for any other kind of debt.
The main problem with debt is not the total of the debt, it is the interest rate that makes the accrued debt grows faster than most people and organizations realize.
This is actually one of the main causes of the current world wide financial crisis, the same holds for many IT debts.
And for all kinds of debts, you often don’t know how high the interest rate will be, so the accrued value can be way beyond what you expect.
I’ve regularly seen projects collecting so much debt, that migration costs raised to thousands of hours because of it, resulting into management taking another very bad decision: rewriting the stuff from scratch. Don’t do that: Joel on Software excellently describes what happens when you do that.
What to do about it?
You might say “don’t collect debt”, but you can’t always avoid debt.
So you need to build periods where you pay off accrued debt. And you need to do that regularly, in order to avoid the interest pitfall.
This does not limit itself to software development (though that’s what I normally focus at). It covers a wide range of IT topics.
Sometimes, you can even pay your debt in advance. For instance, I was among the first to switch from Windows XP to the x64 of Windows Vista. I knew it would cause pain, but it immediately payed back by being able to use much more memory, and run more Virtual Machines at the same time. That made me more flexible and productive.
–jeroen
via: Coding Horror: Paying Down Your Technical Debt.
Posted in *nix, .NET, Delphi, Development, Opinions, Power User, Software Development, Technical Debt, Windows, Windows 7, Windows 8, Windows Vista, Windows XP | 9 Comments »
Posted by jpluimers on 2012/03/28
Duh, I always thought @ could only be used for strings.
Not so: just like with the & in Delphi is used to escape keywords, the additional use of @ in C# is to escape identifiers:
The prefix “@” enables the use of keywords as identifiers, which is useful when interfacing with other programming languages. The character @ is not actually part of the identifier, so the identifier might be seen in other languages as a normal identifier, without the prefix. An identifier with an @ prefix is called a verbatim identifier.
–jeroen
via: naming – What’s the use/meaning of the @ character in variable names in C#? – Stack Overflow.
Posted in .NET, C#, C# 2.0, C# 3.0, C# 4.0, Delphi, Development, Software Development | Leave a Comment »
The Wiert Corner - irregular stream of stuff 