If there was a "Ansi switch" for Delphi 2009/2010/XE/XE2 (the unicode versions), you would simply be exchanging the problem you have now, with far worse problems.
For that reason, there can not be a switch. This idea was discussed carefully, I happen to know from first-hand conversations with the people who made the decision, and the decision to break your code was not undertaken without due diligence. There was simply no other way to go. To make Delphi truly Unicode, it was essential to alias String=UnicodeString.
Therefore, you must change all your String declarations to AnsiString, and Char to AnsiChar if you wish to have single-byte non-unicode character and string types in your application code. In most of your code, and in most places, that is not necessary. But where you explicitly need byte-size processing, such as binary protocols over RS232 and RS485, or binary file formats (EDA, etc), you need to change your code.
If you don't want to port your code yourself, pay someone to do it. I ported a huge library of scientific components and applications up myself, and it took me several weeks to test and find all the bugs. Afterwards, I had a reasonable modern codebase that has not broken again since 2009 when I upgraded.
When you get to the XE/XE2 divide, you may encounter some more pain having to do with your code's assumptions that Pointer types are the same size as Integer or Cardinal, which is no longer true in Win64. Again, Delphi guys have no desire to break your code, they're just following sane engineering practices, in that case, Win64 dictates certain things.
Why didn't they change every VCL control property to USTRING instead of String? Why didn't they make every RTL function take both USTRING and STRING and provide overloads?
Because normative Delphi development is now purely Unicode. USTRING is, and would be a special case. String is the native (normative) string type, and it is, in fact, also known now as UnicodeString.
It so happens you were already using a type alias. Strings in delphi 1.0 were limited to 255 characters in length. When they introduced Delphi 2.0, and the long string type, internally called AnsiString, they aliased the existing common type String as String=AnsiString. When we got to Unicode, every VCL component and every VCL method that takes a string still takes a string. However String is now String=UnicodeString.
Delphi 7 already has WideString for example. We don't need a half-way move to unicode. Whether you realize it or not the entire software development world now expects string types to be unicode. Delphi is part of a global phenomenon. The internet is unicode. Your Windows 7 operating system is pure native unicode.
Reading the embaracadero unicode white paper convinced me that migration is too horrendous to tackle at this time. I guess I'm stuck with D2007 for the foreseeable future.
It's actually not that bad.
Your parallel with Windows 7 is actually quite ironic since we had to ditch 7 due to incompatibility with several of our key tool chains. We only use XP and xp64 now which is a bit sad since it proves Microsoft did have a painless migration path to 64 bits, they just chose not to promote it.
Well, you're painting yourself into several corners then. Enjoy the long slow slide into obsolescence. Windows XP is also native unicode, or didn't you know?
Warren, I am not anti unicode, I am sure there are plenty of people that want unicode. I just can't use unicode in my applications and am frustrated at being forced to use old tools. Even localisation is causing me headaches in delphi, I'm fed up of having to poke a decimal point char into the decimalseparator variable every time I need to do a floattostr or vice versa. I can't be having users save a file in England only to have customers in france complain it doesn't load because delphi is expecting a comma. There should be compiler switches to turn these features off, its just common sense.