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.
Related
A number of delphi applications that I work with use an activex chartfx control. I realize that the company softwarefx stopped supporting delphi a while ago but we are transitioning to 64 bit builds and this component is our main obstacle. We could convert all our charts to TeeCharts if necessary but this would be a lot of changes.
I have gotten the 32 bit chartfx component to install and compile in xe2 but am unsure of the next step. Support did provide me with 64 bit dlls.
So I guess I have 3 questions:
has anyone sucessfully moved chartfx to a 64 bit delphi environment or
could you direct me to instructions on creating a component that is 32 bit at design time but can be 32 bit or 64 bit for compile?
is there a better way to do this?
edit: uploaded chartfx62 client server delphi code to http://www.filefactory.com/file/ce61229/n/Cfx62ClientServer_TLB.pas
You need to get the 64 bit ActiveX DLLs to go with your 64 bit runtime. Designtime Delphi is still always 32 bit.
If ChartFX doesn't supply 64 bit version you are stuck. Having looked on the website it seems that the vendor does not yet supply a 64 bit ChartFX ActiveX and is soliciting feedback as to how much demand there is for it.
I would recommend transitioning to TeeChart which is native Delphi code and has a very strong tradition on Delphi. You can be confident of future support for other platforms as and when they become available.
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.
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.
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!