Session expiration Your session is going to expireClick here to extend


3,000 - 6,000

Posted on

2012-09-26 07:39:13.0



This project has expired

Why don't you register anyway? We are sure that you will find many similar projects out of the thousands waiting for you!

Post similar project now



There are 40 DLLs that need to be converted from Delphi2007 32 bit to Delphi XE2 64 bit. To see the present version working, we can provide a video.
The application consists of a bunch of toolbars embedded into AutoCAD2012. No previous knowledge of AutoCAD is required.
The current 32 bit version has a number of items that need to be converted and or replaced. These are:
Step 1. First of all port the application to 32 bit Unicode (Delphi2009). 
It is essential to understand the difference between “string” and “AnsiString”. If a piece of  code works whether a character is one byte or two bytes, use string. If the string must be 8-bit, use AnsiString. Then everything will migrate properly, and even work with both Delphi 2007 and 2009. If it matters whether strings are Unicode or not, you can use {$IFDEF UNICODE}. The UNICODE compiler directive is defined in Delphi 2009, but not in Delphi 2007.
Step 2 Then, port to 64 bit (XE2).
I would expect step 1 to be harder than step 2. For step 1 there is Marco Cantù's Unicode whitepaper - I'm not aware of anything similar yet for 64 bit. It is essential to keep these two porting steps separate. Smaller independent tasks are always easier than one bigger combined task.
Regarding the 64 bit port I can think of the following issues to deal with:
1. All 3rd party libraries need updating. Orpheus components. These are not available for 64 bit applications and would need to be replaced by native XE2 components. Paradox tables. There are 7 tables used at present. Code would need to be written replacing these. SQLLite should be used to replace the Paradox tables. New string routines addressing the 64 bit space would need to be done. 
2. All inline assembler will need attention.
3. Access to Windows API functions need looking at. A common idea is to pass Integer(MyObject). That needs to be replaced with NativeInt(MyObject).
Other than that I don't think there is much to be concerned about. The Unicode port is likely to be far more problematic.