Posted by jpluimers on 2012/06/21
Another interesting SO thread that explains [##] numbers in DFM files.
They are used to determine the order of subcomponents when using form/frame inheritance.
–jeroen
via: Strange [number]s in Delphi DFM files – origin and necessity? – Stack Overflow.
Posted in Delphi, Development, Software Development | Leave a Comment »
Posted by jpluimers on 2012/06/20
So I won’t forget:
I was trying to generate from the interop.scripting.dll which I guess was the automatically generated dll without strong naming. A wrapperof a wrapper apperently doesnt work.
The following did work:tlbimp.exe C:\WINDOWS\system32\scrrun.dll /keyfile:..\nameHere.snk /out:Interop.Scripting.StrongNamed.dll
The suite of .NET projects I’m refactoring relies in part on scripting in the Microsoft Script Runtime because the original was build by people bringing their COM love from the VB6 world into the .NET world.
I don’t see COM as the first class citizen it was in the VB6 era. On the other hand, COM and ActiveX play an important role in the .NET world. Sometimes I regret that, as dealing with COM is hard.
Some consider COM a first class citizen in .NET as it was in VB6, especially after the dynamic keyword was added in C# 4.0. The variant type available since Delphi 2 since 1996 does more or less the same as dynamic keyword in C#. I know how Anders Heijlsberg disliked the Delphi Variant support of COM. But COM is what the market wanted in 1996, and that seems true until today.
But I digress.
At least parts of the .NET code needs to become strongly named, so I’m hesitating:
Not sure yet.
Opinions anyone?
Anyway, I’m expecting a few problems here and there, so I’ll be using the CLR Interop Tools like the P/Invoke Interop Assistant and Type Library Importer in Managed Code where needed.
–jeroen
via: Strong name for Interop.Scripting – .NET Framework.
Posted in .NET, C#, Delphi, Development, Software Development, VB.NET | 1 Comment »
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 »
The Wiert Corner - irregular stream of stuff 