I wrote a two earlier blog posts around puns in programming book indices before:
the 1992 Turbo Pascal 7.0 Language Guide having both entry in the manual about Recursion (“recursive loop, see recursive loop”) which of course is similar to “infinite loop” and entries for “infinite loop See loop, infinite” and “loop, infinite See infinite loop”.
In the last one, I promised to list more occurrences which I now finally had time for to do.
But let me first elaborate more on the observation that modern computer books (like for instance on C# and Delphi beyond version 1) lack these kinds of index pun.
On the Delphi side, the index entry joke for recursion got removed no later than Delphi 3 (I am still looking for a Delphi 2 version of the Object Pascal Language Guide, see further below) even before the book being fully redone electronically and the index pages generation being automated in
I think I even understand why that is: the process of creating of indices. By the start of this century, more and more indices were automatically being generated and for the last 2 decades or so, all of them are. Back in the days however, indices were mostly done by hand. Nowadays, with everything automated, it is actually pretty tricky in most environments to add such an “infinite loop” index entry like in the Turbo Pascal book, as it would require two things at once:
The first public showing of that demo did not include main thread protection. It originates from a session at the the 1995 Borland Developers Conference where Ray Konopka showed the below code from Bob Ainsbury.
Recently I had to play some notification sounds in a Windows Delphi application where the application deployment should be as easy as possible: preferable copying the EXE around.
The thing that more recent Delphi versions made a lot easier is embedding WAV files as WAVE resources, more on that further on. Read the rest of this entry »
It was back in the days when lots of new things in the Delphi world were happening: Delphi 2 – the first 32-bit version – came out half a year before and the upcoming Delphi 3 was going to be a game changer as well. New features were rock solid and sales were booming.
A long time ago, Lars Fosdal wrote this on the Delphi G+ group:
It really is beyond me why there is no Project.rc file which includes
Project.version.rc
Project.icon.rc
Project.themes.rc
Project.manifest.xml
and so forth.
That way, the .res file would be a compile-time thing (or even a thing of the past) – and the resource linker would assemble the various bits from their individual sources.
It has been an issue forever. Vincent Parrett correctly commented that if you clean out too much out of the Project.res file, the IDE gets confused:
The only thing it is used for is version info and the mainicon (the IDE gets confused if don’t do that).
Like many of the G+ commenters, I’ve switched to script based resources for my own projects a long time ago. That’s also the reason why I forgot: this approach just works for any Delphi version.
This post is a reminder to self to see if the IDE has finally refrained from doing Project.res handling itself.
Delphi Component/Tool vendors have to support a truckload of Delphi and C++ Builder versions which can be a pain: they have to work around problems in Delphi and C++ Builder versions that have long been abandoned by Borland/CodeGear/Embarcadero/Idera/…
This means that sometimes the Delphi Component/Tool vendors have to work around stuff in a way normal applications vendors would never do.
Recently I learned that sometimes this can be a painful thing: keeping DFM files in binary state.
I’m not kidding about either the DFM file format nor about supporting old versions:
That’s why TeeChart still has most DFM files stored as binary files (again the ‘most’ word).
For version control and searching this is a pain, so normal application developers (the ones not using Delphi XE5 Update 1 for Android work) should run convert.exe with the -t (target=text) switch on DFM binary files.
I’ve seen this question coming up a few times, and bumped into this at a client recently: the UAC dialog coming up when debugging a 32-bit executable.
This is caused (more details below) by Installer Detection Technology introduced in Windows Vista (with UAC) and tightened in more modern Windows versions.
The solution is to either:
not include Installer, Patch, Update, Upgrade, Setup, … in your EXE name
provide a correct manifest to your EXE (getting this right can be hard)