This question already has answers here:
Closed 11 years ago.
Possible Duplicates:
How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode
How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?
I would like to know the approach for migrating from 32 bit [Delphi 7] to 64 bit. What all things i should remember and what all steps i should follow?
What all complexity i might face?
please provide me step by step migration process. What things i should address first?
There are 2 possibilities
1. Using yet to launch Delphi 64 bit version
2. Updating existing code and functionality to use 64 bit OS features
There is no 64-Bit Delphi-Compiler at this time. So you can not do it now, you have to wait until the next Delphi-Version. For the next Delphi a 64-Bit compiler is announced. You can not "use" 64-Bit-OS-Features (What are they? What do you mean exactly?) with 32-Bit compiler. A 32-Bit-application will allways run in the WOW3264-Emulator (on a 64-Bit Windows, of course).
What all complexity i might face?
As stated by Andreas, there's no yet 64-bit Delphi compiler ATM. You can use FPC for now, and regarding the complexities, Lazarus/FPC wiki has addressed them.
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to also prepare for 64-bits when migrating to Delphi 2010 and Unicode
I have already developed an application in Delphi 7. Now I need to enable it to support 64 bit.
Delphi 7, and indeed all released Delphi Win32 versions, only produce 32 bit executables. However, 32 bit executables run perfectly well on 64 bit operating systems through the WOW64 emulator. Although this is an emulator, a word that usually implies degraded performance, WOW64 performance is not readily distinguishable from native 64 bit performance.
If you wish to port your Delphi app to 64 bit you need to wait for the next version of Delphi to be released which will produce 64 bit executables.
Then you will have to port your app from Delphi 7 to the latest version of Delphi. This will be a big job because you will also have to port from ANSI string code to Unicode string code. In my view this part of the port will be more time consuming than the 32 to 64 bit part and if you wanted to get a head start you would be wise to start the Unicode port now by upgrading to Delphi XE.
You can check this official Embarcadero video which covers the subject.
As the title suggests!
I'm trying to get a 64bit dll
No.
Nope. Delphi 7 was released in 2002; the first AMD64 processor was released in 2003. No way Delphi 7 knows how to generate 64-bit code.
All released versions of Delphi following the 16 bit Delphi 1 emit 32 bit targets. At the moment your options are:
Wait until the upcoming 64 bit Delphi release. We anticipate this some time this year, but your port will be non-trivial.
Port to FreePascal. Again, a non-trivial port.
Port to a completely different language: even more work than porting to Free Pascal.
Carry on running 32 bit code.
Compiling a program means to translate your source files into CPU opcodes (and something more, it has to generate a executable image that can work on the OS it was designed for, respecting the OS ABI - Application Binary Interface). Each type of CPU has its own set of opcodes, and even if the Intel x86 architecture has many similarities among 16, 32 and 64 bit opcodes, there are enough differences and the ABI is anyway different.
Creating a 64 bit exe/dll means to generate 64 bit opcodes using also the new 64 bit ABI, and to do that a compiler must be written to "know" them, what a compiler can do is defined by how the compiler itself is written, not by the system it is run on. Delphi 7 compiler "doesn't know" about 64 bit CPUs and exe/dll ABI, and thereby can't generate it. This is true as well up to Delphi XE. The next version should be the first one to come with a 64 bit compiler, you can wait for it, or if you're in a hurry there are some partially compatible compilers like FPC.
New version of CrossKylix as been updated two weeks ago.
Even Kylix has discontinued long time ago, but it's seems still used by some of Delphi developers.
Has any one used it successfully on cross-platform development for Windows and Linux?
As Mason said, we're using CrossKylix for the Linux version of Beyond Compare, but only for release builds, which are kicked off from FinalBuilder. For that usage, it's been great. We did try doing CLX development on Windows for a while, but CLX for Windows had different bugs than CLX for Linux, so it wasn't worth it long-term.
Our actual Linux development is still done using Kylix 3 running on SuSE 10 virtual machines. We use both GDB and the Kylix debugger for debugging, though the Kylix debugger doesn't work well for backgrounds threads anymore. We dropped CLX design-time support a long time ago though, so almost all of our feature development is done in Delphi 2007 and the VCL.
I am also actively using Simon's other project, CrossFPC, for our 64-bit Windows shell extension, and it's worked great.
I'm using CrossKylix for years, and it worked for me like a charm.
It's one of the reasons why I like to maintain Delphi 7 compatibility in our source code, because Kylix 3 is based on the same compiler as Delphi 7: only the back-end generates natively ELF files instead of EXE.
For server applications and command-line tools, even a small cgi program, CrossKylix is just great! You can develop and test with Delphi under Windows, then Cross-compile it, and run the executable under Linux with no problem.
I've used this for years on a french "dedibox" with runs under a Via C7 (now much faster Nano) CPU, and made AES and SHA encryption of the data in more than 1500 KB per second (yes KB per second, not bytes per second) thanks to the PadLock engine!
I discovered some problems about the Kylix RTL and WideString under modern linux: if your Linux is configurated with UTF-8 encoding (which is now the standard for most distributions), WideString usage failed. So I've corrected this in the Kylix system.pas: in fact, our Enhanced RTL is cross-platform, and works with Delphi 7 and CrossKylix.
See http://synopse.info/forum/viewtopic.php?id=66
In one of Jim McKeeth's early podcasts, he interviewed Craig Peterson of Scooter Software, one of the coders for BeyondCompare. He mentioned how they used CrossKylix for the Linux port of BeyondCompare.
From what I've read from the previous posts, Delphi 7 is stable and has the best help system but is slow, Delphi 2007 is fast but the help system is bad and the IDE is buggy. Delphi 2009 is stable and fast but the help system is bad too. The posts were made when 2010 isn't available yet. I am planning to upgrade from Delphi 7 to 2010. Is Delphi 2010 stable, fast and has a good help system?
Delphi 2010 is one of the best Delphi releases ever. It stabilizes some of the new features introduced in Delphi 2009. The IDE is fast, and in the project I used it was very stable.
The thing there is that the IDE and the help system are build as a RAD Studio for different languages. Especially the help system tries to be everything for everybody. Even having only one personality installed, it has many entires about other languages I do not care about (but I can filter them). Yet there are many entires missing depth that never made it into the new help format.
The help system starts painstakingly slow (especially at first startup). But, to be fair, this is partially do to the MS Help System being a pain in the neck (this, in my opinion, just was the wrong path to chose).
Embarcadero invests quite some effort into the help system, and it had several updates during the 2010 release.
You do know about the varying expense of conversion to Unicode as 2010 is fully Unicode based?
Here are some reasons why I stick to Delphi 7, having Delphi 2010 at hand to recompile and test what I wrote in Delphi 7, in a cross-version manner:
if your source code compiles on Delphi 7, and you make careful usage of Unicode/AnsiString, it will work as well with Delphi 2010;
if your source code compiles on Delphi 7, it will work as well with Free Pascal, so
cross-platform and 64 bits are open to you;
if your source code compiles on Delphi 7, it can be cross-compiled with CrossKylix directly from the Delphi 7 IDE - see Has any one used CrossKylix for real Cross-platform development?
Delphi 7 runs well on my Windows Seven 64 bits system, if you install it not in "C:\Program Files" but in "C:\Progs" for example;
Delphi 7 starts faster than Delphi 2007, and MUCH faster than Delphi 2009/2010 - see http://andy.jgknet.de/dspeedup
generated code is almost the same since Delphi 7 - when I need speed, I use better algorithms, and assembler if it's worth it;
Delphi 7 IDE is as powerful as Delphi 2010 IDE, if you use some IDE enhancements like http://www.cnpack.org;
Delphi 7 help is still the reference - why waiting for 20 seconds on my Core i7 processor waiting for the awful MS help system to launch? and if you want to create an application able to run under XP, its content will be enough for you; if you want to know about newer OS, just use msdn web site directly, or via google: it sounded to me easier than the help integrated with Delphi 2005/2010;
I use the assembler/CPU view a lot: all Delphi IDE have the Alt-F2, but you can close this window by the escape key on Delphi 7 - I was not able to find such a keyboard shortcut under Delphi 2007/2010, and it's very annoying;
Delphi 7 executable size are small, and even smaller with our LVCL libraries (30 KB for a form with buttons);
I didn't have the need for generics and such up to now - I like knowing which code is generated;
Delphi 7 is Unicode ready, whatever you say - its associated VCL was not, but CharSets are not evil, and work well - what I do is develop under Delphi 7, then compile with Delphi 2010 and get all the Unicode benefits if needed;
I use a large screen (at 1920x1280 resolution), and Delphi 7 makes it easy to have multiple edit windows at once - newer IDE locked layout was not a good idea... at such that EMB officially added the "Delphi 7 way undocked IDE" feature to Delphi 2010: and marketing sell it as a new feature;
and so on, and so on...
You can use Delphi 7 help in Delphi 2010, if you want to.
Use this or this addon. See item 5 here for instructions (sorry, it's machine auto-tranlation).
P.S. You can have more than one help installed. Say, a F1 for Delphi 7 help and Ctrl+F1 for Delphi 2010 help.
delphi 2010 is stable and fast and is actually a good delphi compiler after years of half-baked releases, they have improved help system in delphi 2010 but i still think delphi 7 help system is superior(but thats just my opinion).you do know delphi 2010 has a 1 month trial do you? download it and play around and see if you like it
EDIT: forgot to mention if you buy delphi 2010 you'll get marco cantu's Delphi 2010 Handbook for free ,the book covers whats new in D2010 so if you consider book as part of help system than help system is OK :)
Delphi7 was faster, but it was a lot simpler. I wouldn't worry too much about performance of the IDE, especially if you're working on a modern PC. At work I've got an old P4 machine, and it runs just fine.
New language features like methods on records and generics make it well worth it to switch.
For me it's hard to live without TList<T> nowadays.
For a while I've desperately tried to keep code Delphi7-compatible, but I've ported most of the important applications to D2010 already, and whenever I need to start D7, it all feels so low-tech and simple.
I've always hated the crappy component palette in the older Delphi's. Delphi 2010 has a much better interface, and the filter function is a real time-saver.
I've decided to give up on Delphi7 and just make full use of D2010's capabilities. That makes life a lot easier.
I searched around but I couldn't find a straight answer to these questions, only bits and pieces: if I install windows seven x64,
1 - will I be able to use delphi 2007+ as I'm used to aka start it, code in it, debug in it, compile in it ? I've seen the debugger issue and the hex edit workaround.
2 - will my application compiled in that environnement work on 32 bit versions of windows ?
3 - will my application I compiled with delphi on 32 bit windows work this 64 bit version ?
(of course all this is assuming "normal" applications as-in I don't expect things to work if I'm playing with pointers expecting them to be 32 bits long, obviously)
The overall question of this would be, as someone who is moving to windows seven 64 bits, will I be able to/should I use this as my main delphi developpement platform or will i be better off keeping a 32 bit boot for delphi dev ?
Thanks to anyone who can give me a clue about this
As Mason Wheeler stated, there's a problem with the 2007/2009 debugger and 64-bit platforms but it can easily be fixed.
I'm using D2007 (with this fix) on Windows 7 64-bit on a daily basis and it works just great.
There is now a hotfix for this.
No idea about Windows 7 64 bit version, but I have been using Delphi 4, 5, 2007 and 2009 for nearly a year now on Windows XP 64 bit, and given the effort Microsoft spends on backwards compatibility I don't see why things should be very different on Windows 7. This answers your last question - no need to keep a separate partition. Use virtualization for running things on a 32 bit system. Windows 7 does AFAIK offer you a virtualized Windows XP subsystem - at no cost, but you may need to download it separately.
Re 2. and 3.: The OS an application is compiled on does not matter for the deployment, as long as the compilation itself works. I have only ever been compiling 16 bit Delphi programs on 32 bit Windows versions, without problems. You should however always test on clean installations of your target OS versions, as a developer PC is sufficiently different from a user PC to not assume that everything will just work. This however is general advise, and has nothing to do with a 64 bit OS.
Your Delphi programs will run on a 32 bit layer (WOW64 - Windows on Windows 64) of Windows 64 bit which is close enough to the real 32 bit OS that you do not need to care about it, unless you work very closely with the lower system level.
I was doing some work on Delphi 2007 under Windows 7 64-bit yesterday, and it was a disaster. Every time I'd leave the program while debugging, either by quitting out normally or by stopping the debugger, it would raise an assertion failure that I couldn't get out of, bringing down the entire IDE. (This never happened under XP.) Apparently the WOW64 emulator isn't quite as stable as it ought to be... :(
If you're going to try to work on Windows 7 64-bit, I'd strongly recommend upgrading to Delphi 2010, which was built specifically with Windows 7 compliance in mind. If that's not an option, then at least install a VM with XP on it for your dev work.
Answers are:
1. Yes - With the workaround for the debugger issue
2. Yes - Delphi 2007 (native) will only build 32 bit applications
3. Yes - Unless it's a Device Driver or low-level service
First apply the patch as mentioned on Olaf's Blog. This fixes the debugger exit error.
Second, Install Windows XP Mode, which is a fully clean (and legal) windows XP 32bit virtual machine.
Compile application on Windows 7 64bit. Install onto the virtual machine. It should just work. Rinse, lather and repeat for other applications you are developing.
XP Mode is available to all owners of Windows 7 Professional and Ultimate editions. Don't know about corporate editions.
This is what I'm currently using for development as I had to perform an emergency OSectomy of a Macbook Pro
I run Delphi 2007 on Windows 7 Professional 64 bit and it was fine for a bit until a patch Tuesday a while ago. The IDE would die after throwing the debug error (SetThreadContext failed). I applied the patch found at http://cc.embarcadero.com/item/27521 and no more problems.
HTH. YMMV.
Doug
FYI, I am running Delphi 7 on Win7 64-bit. The trick to run this version is to NOT install to the Program Files(x86) folder - instead, install to something like C:\Delphi7. Been working with it this way for about a month now with a pretty heavy development load and it works great!