Skip to content

Windows XP end of life April 8, 2014 - easily move your Delphi and C++ apps forward

It’s 2014. On April 8, 2014, Microsoft will stop supporting Windows XP (Microsoft recently announced that they will continue to provide virus warnings until summer 2015). By moving, now, to RAD Studio XE5, Delphi XE5 and C++Builder XE5 you can move your apps forward to Windows 7 and 8 and take advantage of many of the new Windows features with support already built into our latest releases. You can also expand the reach of your apps to Mac OS X, iOS and Android. Before your customers and users exit Windows XP, you can easily update your apps to support 64bit, Unicode, Mac and mobile, new VCL styles, REST Client Library, Cloud, FireDAC’s universal SQL database connectivity, DataSnap multi-tier architectures, Touch/Gestures and a whole lot more. You can be hyper productive using LiveBindings, IDE Insight and IDE version control integration.

64-bit Windows

To move your 32-bit Windows VCL and FM apps to 64-bit all you have to do is add the 64-bit Windows target platform in the Project Manager Window. All Windows technologies are 64-bit enabled including FireMonkey, VCL, RTL, the compilers and debuggers. We have lots of documentation, videos and blog posts to help guide you.

Videos show you how easily it is to move your apps to 64-bit Windows:

VCL Styles

Windows themes first appeared in Windows and have been expanded in subsequent Windows releases. Delphi and C++Builder have supported the Windows themes. First, we added the Project | Options | Application| Runtime Themes | Enable runtime themes choice. Delphi and C++Builder now have full support for customizing the look and feel of your VCL applications using styles and themes.

VCL style and theme classes

Videos to help you with VCL Styles

Unicode enabled since 2008

I recently blogged about Unicode support in C++Builder. You can find the information and numerous links at http://blogs.embarcadero.com/davidi/2014/01/20/43342. For Delphi developers we also have a boat load of information and documentation.

IDE Version Control Integration

The XE5 IDE comes with Subversion integration. Use "File | Open From Version Control …" and checkout projects from your source code control system. All of our samples and code snippets are continually uploaded to SourceForge so you can easily update all of the samples to your hard drive.

If you want to use other version control systems, the IDE has "Version Insight" which is the IDE API and integration points we used in adding Subversion. Also on Source Forge are the source files to integrate for git and other integrations - http://sourceforge.net/projects/radstudioverins/.

Need Migration Help?

If you need moving your Delphi and C++Builder apps forward to XE5, Windows 7/8, Mac OS X and mobile, post a comment or email me (davidi at embarcadero.com). We can schedule an online meeting, Skype session (davidi99) or a Google+ Hangouts on Air live broadcast. It will be cool to have a live session helping you move your project forward while other developers watched!

{ 11 } Comments

  1. Thomas Mueller | January 31, 2014 at 8:55 am | Permalink

    What are these "Apps" you keep talking about? I don’t have any "Apps" written in Delphi/C++ Builder for Windows XP, I have applications, programs and tools.

    (Sorry to nitpick I am really getting annoyed about people calling everything an "App".)

  2. David Intersimone | January 31, 2014 at 9:39 am | Permalink

    I did not meant to annoy you - and I don’t worry about anyone picking nits. For me it is a shorthand word I use these days to save characters on Twitter. Now it is burned into my fingertips and I have to think harder to type application.

  3. KMorwath | January 31, 2014 at 11:22 am | Permalink

    Sorry, but 1) Delphi doesn’t support Windows 8 yet. A "skin" is not support. 2) It’s only XP that will be desupported - applications written for it will still run on 7 and 8. Unless you’re one of the Delphi developers who learnt to code with Windows 3,1 and never "upgraded" your skills, thereby writing bad application that tries to write everywhere and need admin privileges just to start. If your applications are coded correctly following Windows guidelines, any application written for Windows 2000 onwards will run even if XP is no longer updated. What would need an update is the Delphi IDE, true, because it’s mess of old code, .NET/J# dependency and many other issue may prevent you to use it on newer operating systems.

  4. David Intersimone | January 31, 2014 at 11:58 am | Permalink

    Kent - you pop up again - good.

    If you can define what "Windows 8" support means to you - feel free. Is it WinRT? We never claimed to support WinRT although it is on our public roadmap.

    Is it calling APIs (which APIs)? Since Delphi 1, we have never claimed that we include Delphi or C++ header files for every Windows and/or Windows Subsystems APIs but you can still call native APIs yourself as a developper.

    Is it applications running on Windows 8? We are testing continuously on Windows 7 and Windows 8/8.1 to make sure that VCL and FM applications run on these latest Windows releases.

    Is it something else?

    Also - the R&D team is continually working on the IDE in each version add capabilities and fix issues.

    BTW - what is the latest version of Delphi/C++Builder/RAD Studio that you own/use?

    Thanks

  5. Kmorwath | February 1, 2014 at 12:43 pm | Permalink

    Windows 7 and Windows 8 supports means supporting *all* the new APIs that have been introduces since then (including WinRT, but not WinRT only). For example does the RTL/VCL supports VSS (Volume Shadow Service)? Does it support the native ribbons available since Windows 7? DirectX 11? CompressionAPI? DirectComposition? WebSocket API? DirectXMath? TaskBar API? And I could keep on for a while. Probably Delphi still doesn’t take advantage of many APIs introduces with XP/2003.
    Yes, I can call APIs myself - I can do it with *any* version of Delphi before XE5 but Delphi 1 because that’s the only Delphi and applications that won’t run in any 64 bit Windows OS. Everything properly written from Delphi 2 onwards *will work* in Windows 7 and 8. Unless of course you need a WindowsRT application, which you can’t code in Delphi.
    "Supporting" an OS doesn’t mean you can access its APIs only - it means to take advantage of its facilities from the tool library itself, not let the developer do all the hard work. Delphi doesn’t especially because one of the biggest disadvantages of its precompiled libraries it can’t target a given OS easily. You can’t say to Delphi "compile only for Windows 7 onwards", and have the compiler use APIs which are not available before. The RTL/VCL need to be written for the lowest supported OS. And AFAIK XE5 still supports XP, thereby it still uses and calls APIs available in it even if more advanced APIs are available in later version of Windows, thereby if you’re using any previous version upgrading to XE5 won’t change your life when XP will be desupported - you’re still writing XP applications.
    If I were your R&D team I would look for a way to be able to target an OS to compile for, and have the compiler select the best API calls for that target - maybe using some defines, declaration or attribute to tell the compiler the minimum version that API is available, so it can link it for the proper target.
    That would be a great, professional addition to the tool, enabling to write more modern applications and take advantages of newer APIs as soon they become available, when supporting older OSes is not required. Thereby, I’m sure it will never be implemented.

  6. David Intersimone | February 1, 2014 at 1:39 pm | Permalink

    Kent - thanks for your list. I will forward to Product Management and R&D. If a developer wants to use Delphi to build 64-bit Windows application then they would at least have to have Delphi XE2.

    I am curious about a few things regarding you:

    1) what kinds of programming/applications do you build that you need all of the APIs and sub-systems already built in to Delphi instead of just a few? We have continually added capabilities to make programming and Windows programming easier with each release.

    2) what version of Delphi do you own and use? You never seem to answer this question every time I ask it (I can’t find you in our product registration database under your name or the email address you use in your blog comment posts - maybe I am doing my SQL queries wrong).

    3) where do you live and work? Maybe we can meet in person on one of my travels about the world.

    Thanks again for sending along your lists and suggestions. I really appreciate it.

  7. Kmorwath | February 2, 2014 at 12:22 pm | Permalink

    1) We build system applications which are strongly tied to the underlying OS. It looks Delphi wasn’t able to keep pace with Windows APIs. Windows 3.1 had a few only - but from NT4 onwards they grew larger and larger, and Delphi was left behind. We found with every Windows release, we had to build more and more libraries ourselves to support new features.
    2) Now we’re using XE2 (exactly because of 64 bit support) - but most development has shifted to VC++. Products aren’t registered under my name - they are bought by my company which I won’t name because I’m not speaking on my company behalf.
    3) Now I live and work in Tallin - but I’m not working for Skype :)

  8. Marco Cantu | February 3, 2014 at 8:11 am | Permalink

    Kent

    I partially disagree with your assessment. On Windows, Delphi doesn’t support a minimum common denominator, but it has direct support for many later APIs, and that thanks to the delayed binding of DLL functions (so if we have Win7 calls in win.pas you can still compile and run against Windows XP, until you call the specific unsupported API).
    Delphi has specific components for Windows Vista+ (like the new common dialog and task dialog), it has many newer APIs (for example ShellApi including the toolbar buttons support). We have native VCL support for Direct2D which is not in XP, and the Windows Image Component part to TImage (again not working on XP).

    You are right that Delphi hasn’t got a complete API coverage, as it was never the case since Day 1 (hence the JEDI project). We always look forward to add new APIs and are looking forward to add latest DirectX and more in the near future. It is also true we might ignore some APIs where we have an alternative native and cross-platform solution (like Ribbon). Finally, not all Microsoft APIs are easy to consume from a native tool, which occasionally limits our possibilities.

    I fully understand the request to add more APIs (and we can do more on this side), and deprecate older one, which is really subject to market requirements. While we’d second Microsoft in hoping old XP machines acceptance will fade soon, this will take time and in that time we need to keep some support.

    I personally know Delphi customers who cannot move beyond 2007 not for Unicode migration, but because they have a (small) percentage of users on Win 9x. Scary, I know. Today Window 8 is only on a fraction of the business desktops, with Windows 7 still growing.

    In any case, thanks a lot for reminding us native Windows API support is important!

  9. David Intersimone | February 3, 2014 at 11:35 am | Permalink

    Joe - whoever you really are (your joe@gmail.com email address is invalid and bounced back to me), twice you have posted a comment to this blog post.

    Be more professional in your blog comments and you will have access to more of my attention and time. There is no reason to use such bad language nor to “shout” by using all capitals.

  10. Wes | February 3, 2014 at 1:59 pm | Permalink

    Woot! Rock on Delphi! I’ve been solving real business problems faster than other tools since Delphi 1. Still on the honeymoon baby!

  11. David Intersimone | February 12, 2014 at 5:00 am | Permalink

    Bill - the team is working on additional compilers for the platforms. Win32 is on the list. We now have C++11 compilers for Win64 and iOS/Arm. More to come. Which version of C++Builder do you own?

Bad Behavior has blocked 4 access attempts in the last 7 days.

Close